• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Tim Cooke
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • paul wheaton
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Tim Holloway
  • Carey Brown
  • salvin francis

User stories and requirements

 
Ranch Hand
Posts: 497
10
Android Open BSD Slackware
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I received an email from a director in my company that said something like I am going to become product owner to use a Business Intelligence software called Tableau if I am going to:
prepare the User stories & Requirements and making a meeting to discuss them, then we will do testing and acceptance

I am really confused, because I do not know what I should do, because in internet the user stories are depicted as general scenarios and not  as use cases.
And also what they mean for requirements?  It means that every user story have to have some specific constraints?
In the internet I am finding everything and the opposit of everything.

Is expected I do maybe instead of user stories, the use cases on post it assigning a priority and on the other side the requirements,
or should I instead produce a so called product requirement document?

Of course I cannot ask back to the director, he is just expecting I come up with something and I do not know what exactly I should produce


 
Sheriff
Posts: 13685
227
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You should get together with the folks on your development team and ask them these questions.

The unfortunate reality is that what a "user story" is depends largely on the team that uses that term. The ultimate goal is to communicate something that the software system needs to do. The term "user story" used to represent "a promise to have a future conversation," the physical representation of which was an index card with a single simple sentence written on it. A user story was never meant to be a requirements document. However, over time and through naive adoption and semantic diffusion, the meaning of the term has been bastardized and expanded by many so-called Agile adopters into something entirely different. I suspect you're in a situation where the original meaning and intent does not apply.

So, again, you need to get with your development folks and maybe other product owners and ask them to help you understand exactly how they communicate requirements with each other via the "user stories" in Tableau and whatever other means and processes you're expected to follow as a product owner.
 
Giovanni Montano
Ranch Hand
Posts: 497
10
Android Open BSD Slackware
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:You should get together with the folks on your development team and ask them these questions.

The unfortunate reality is that what a "user story" is depends largely on the team that uses that term. The ultimate goal is to communicate something that the software system needs to do. The term "user story" used to represent "a promise to have a future conversation," the physical representation of which was an index card with a single simple sentence written on it. A user story was never meant to be a requirements document. However, over time and through naive adoption and semantic diffusion, the meaning of the term has been bastardized and expanded by many so-called Agile adopters into something entirely different. I suspect you're in a situation where the original meaning and intent does not apply.

So, again, you need to get with your development folks and maybe other product owners and ask them to help you understand exactly how they communicate requirements with each other via the "user stories" in Tableau and whatever other means and processes you're expected to follow as a product owner.


Clear Junilu, like always thank you for your detailed response. But let's imagine a prisoner dilemma.
I have to come up with something to the meeting on the basis of what I have, then of course as is in the Agile manifest, things will change.
In this logic, please how would you define the requirements? I mean stocastically, if we consider (even if wrong, that user cases=user stories because my company just started with Agile) the requirements would be just some technical specifications linked to every user story right? So for every user story I would put some requirements/
I would do a post it with the user story on the front side and requirements back on the post it
 
Junilu Lacar
Sheriff
Posts: 13685
227
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why would you, as a product owner, attach anything related to technical requirements to anything? This is another messed-up thing about how many organizations approach division of labor/responsibilities and the worst thing about this is that they often attribute failures to agile software development.

I don't know what the development culture is in your organization so I can't really say anything about what you're asking.

If you want to know what I do on my team, we have supporting documentation that are very similar to what Simon Brown describes in his book, Software Architecture for Developers (SA4D), we do test-driven development, and we have frequent interactions with our product owner and business users.

We use an ALM tool called Rally and in it we can create links in the user story items that refer to any supporting documentation. If Tableau is anything like that, then I guess you could try linking to whatever supporting documentation you are supposed to create. Again, you really should talk to other people on your team about these things. The best people here can do is speculate.
 
Junilu Lacar
Sheriff
Posts: 13685
227
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Giovanni Montano wrote:So for every user story I would put some requirements/
I would do a post it with the user story on the front side and requirements back on the post it


I assume you meant Post-It™ note.  If you're doing things old-school like user stories on Post-It™ notes on a Scrum board, how are you going to fit requirements on the back of it? Back in the early days, the XP folks would write engineering stories on the back of the user story index cards. The engineering stories were also short "reminders" of future conversations they needed to have, like "Must be transactional" or "Authenticated and authorized users only" or "Use a messaging system".  
 
Giovanni Montano
Ranch Hand
Posts: 497
10
Android Open BSD Slackware
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:

Giovanni Montano wrote:So for every user story I would put some requirements/
I would do a post it with the user story on the front side and requirements back on the post it


I assume you meant Post-It™ note.  If you're doing things old-school like user stories on Post-It™ notes on a Scrum board, how are you going to fit requirements on the back of it? Back in the early days, the XP folks would write engineering stories on the back of the user story index cards. The engineering stories were also short "reminders" of future conversations they needed to have, like "Must be transactional" or "Authenticated and authorized users only" or "Use a messaging system".  


Yes I was refering to Post-It.
Great you come with some book source. My aim is to become the product owner and do something called backlog, in the Business Intelligence department of my company.
My real aim, is to propose some Python and R implementation even without tableau, because my real-real aim is to work as a developer in the Business Intelligence department.
That is why I want to show to him that I am a nice guy to get along with.


Statistics and coding are quite beautiful, and there is a market for that.  Anyway Tableau is a sw to organize data from different sources with astonishing visual data reporting.
Is becoming the standard in the field. They do not want to give us the expensive licence so I need to convince them that I have really complex requirments, and that we should have a licence and not just a viewer. Plus I need to appear cool and credible and trying to put forth the possibility to candidate myself for a junior position as data scientist developer.

My strategy will be to fill  a lot of user stories, so that they will give me licence and ownership on the project( they mentioned product owner as you said)
and to put forward some more complex user story using my code as base.

a tipical user story(use case) would be:

As Analyst we need to retrieve a scatterplot with all the K customers sales and payments delays

some requirements (In general they should be linked to every user story, shouldn't be?)
Query database data
Populate the data
Represent them in a storyline

and so I would do for every user story

 
Junilu Lacar
Sheriff
Posts: 13685
227
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Your example of a user story is already going down the wrong path, the way most requirements go when you think about "how" instead of "what".

Your story specifies an implementation (retrieve a scatter plot) and implementation details (axes of the scatter plot are customer sales and payment delays)

The real user story still needs to be revealed, perhaps by asking 5 whys. Why do you need this kind of scatter plot as an analyst. Then ask why to the answer to that question. Then why to the answer to that question. And so on until you find the real user story.
 
Giovanni Montano
Ranch Hand
Posts: 497
10
Android Open BSD Slackware
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:Your example of a user story is already going down the wrong path, the way most requirements go when you think about "how" instead of "what".

Your story specifies an implementation (retrieve a scatter plot) and implementation details (axes of the scatter plot are customer sales and payment delays)

The real user story still needs to be revealed, perhaps by asking 5 whys. Why do you need this kind of scatter plot as an analyst. Then ask why to the answer to that question. Then why to the answer to that question. And so on until you find the real user story.



hope to get promoted as product owner, thank you. I spoke with a friend of mine and told me I should write user stories that are generic and the requirements are the ẃhy, and that the relation should be one user story one requirement. basically the requirement is what moves the task to done!

With this in mind, meditating on your nice feedback about the  5 whys, "mindfulling" your focus signature and sipping some matcha tea:


I am thinking about the what/why

1)why do I need this scatterplot as analyst?
to identify  what are the K customers that affect our performance

2) why do  I need to "identify what are the K customer that affect
our performance"?
Because K customers are the ones that affect much more our departmental performance

3) why that?
Because mgmt want to improve the corporation cashflow

4) why they want that?
because mgmt want to get his milion bonuses.... aaargh this is probably wrong, I want to create an user story not going back to the causes of the big bang.
Maybe I should focus on why to ask the user story for the need of my subdep.
So I would say : to find the most relevant customers that should be reviewed on a monthly base and to prevent outliers(values that go out from the average) payment performances

( so this would lead me to ask for a box-plot as follow up of this user story, but I guess I cannot link user stories.. so I should make a new one)

So I would wrap up in this way

As Analyst we need to query the system to retrieve a scatterplot distribution with axes: sales turnover of the K customers, and on the abscissa the days they pay with delay because( <here starts the requirement>) we need to
identify outliers  in their performance( from the trendline) to prevent the risk of bankruptcy and to pinpoint which customers affect our cash flow returns in an highly negative way.

(this would bring now to a second user story with the same representation with a box plot that offers the possibility to visually identify customers that budge from the average, and also a third user story regarding  a regressional predictive model)

is that correct? Or is too much descriptive and or technical? Please notice I did not mention any technical way the developer should act, to integrate the data, making inner sql joints, using phython or R etc
 
Junilu Lacar
Sheriff
Posts: 13685
227
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Giovanni Montano wrote:
As Analyst we need to query the system to retrieve a scatterplot distribution with axes: sales turnover of the K customers, and on the abscissa the days they pay with delay because( <here starts the requirement>) we need to
identify outliers  in their performance( from the trendline) to prevent the risk of bankruptcy and to pinpoint which customers affect our cash flow returns in an highly negative way.

(this would bring now to a second user story with the same representation with a box plot that offers the possibility to visually identify customers that budge from the average, and also a third user story regarding  a regressional predictive model)



I think you're getting closer. Looking over what you wrote, I would say your real user story is: "Identify customers who have a significant negative effect on our cash flow returns" or you can phrase that as "As an analyst, I would like to identify customers who have a significant negative effect on our cash flow returns so that I can (whatever benefit you get out of that)"

The means by which you do that can be different things, including having the system produce a scatter plot. The user story might also pave the way for thinking about other ways you might be able to pinpoint those customers. Business users might ask themselves, "Is a scatter plot really the best way to see these kinds of customers? Is there any other way that may be more effective? How much effort will it take the development to create the scatter plot? How much will it take to do it some other way?

These are the kind of questions that may come up during the conversation that gets started by the statement on the user story card. The "produce a scatter plot" part then becomes an engineering story that gets written on the back of the index card.
 
Giovanni Montano
Ranch Hand
Posts: 497
10
Android Open BSD Slackware
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:

Giovanni Montano wrote:
As Analyst we need to query the system to retrieve a scatterplot distribution with axes: sales turnover of the K customers, and on the abscissa the days they pay with delay because( <here starts the requirement>) we need to
identify outliers  in their performance( from the trendline) to prevent the risk of bankruptcy and to pinpoint which customers affect our cash flow returns in an highly negative way.

(this would bring now to a second user story with the same representation with a box plot that offers the possibility to visually identify customers that budge from the average, and also a third user story regarding  a regressional predictive model)



I think you're getting closer. Looking over what you wrote, I would say your real user story is: "Identify customers who have a significant negative effect on our cash flow returns" or you can phrase that as "As an analyst, I would like to identify customers who have a significant negative effect on our cash flow returns so that I can (whatever benefit you get out of that)"

The means by which you do that can be different things, including having the system produce a scatter plot. The user story might also pave the way for thinking about other ways you might be able to pinpoint those customers. Business users might ask themselves, "Is a scatter plot really the best way to see these kinds of customers? Is there any other way that may be more effective? How much effort will it take the development to create the scatter plot? How much will it take to do it some other way?

These are the kind of questions that may come up during the conversation that gets started by the statement on the user story card. The "produce a scatter plot" part then becomes an engineering story that gets written on the back of the index card.


i get it now.
Junilu thank you very much, I am going to write the stories.
 
Junilu Lacar
Sheriff
Posts: 13685
227
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just want to reiterate a very important point that often gets lost in the mechanics and detailed "motions" of writing a user story: The index card, the text on the card, the text on the back of the card, those are just a means to trigger communication between developers and users.  The communication part is what's important. Discussing ideas, getting everybody on the same page and creating a shared vision of what you're trying to achieve. The index cards and the statements are merely the triggers to start them and when the conversations are over and the software is created, the triggers for reminding you what the motivations were for adding the related features.

I like the analogy of a polaroid picture. The picture of you and your family on a beach somewhere doesn't mean much to people who weren't there with you because the photo only captures a single moment in time. However, the photo can trigger a flood of memories for anyone who was actually there and it can start conversations like, "Oh, I remember this trip! Remember how we had so much fun that day? We did this and that and all kinds of other things. We saw this person and that person. We went to that place and ate some wonderfully delicious meals, we had such a great time!" A lot of those details are not explicitly captured in the photo itself but the flood of memories brings back a lot of things to you.

This is the same kind of thing that should happen with a user story card.
 
Giovanni Montano
Ranch Hand
Posts: 497
10
Android Open BSD Slackware
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote: cut..


I see, other metaphor a zipped file with a long title
On the other hand I spoke with somebody in their dep team, they want some robust requirements, So I will do a mix, because Tableau is the centre of what we need. So I will spare technical terms about DB, coding implementations, but will be clear from the front end part, after all Tableau is what we need to use, is a constraint we need
 
Junilu Lacar
Sheriff
Posts: 13685
227
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is where the semantic diffusion that I mentioned earlier in the thread comes in. Tableau has something that your team refers to as user stories. They are probably totally different from what I described here. You say "Tableau is the centre of what we need" and it's ironic because it runs counter to the spirit of what is written in the manifesto, to hold as more important "Individuals and interactions, working software" over "processes and tools, comprehensive documentation". So you see, your team's "need" to have "robust requirements documented in Tableau" makes their claim of practicing agile software development somewhat suspect.
 
Junilu Lacar
Sheriff
Posts: 13685
227
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One more point to make sure you don't misunderstand me and think that I'm advocating for no documentation.

Documentation is fine and has its purposes. Documentation that is created after the fact is important. This kind of documentation allows others who were not involved in the direct conversation to have a better understanding of what kind of considerations contributed to decisions the team made in the past.

However, "robust requirements" that are written down prior to developing software tend to pull the teams away from certain behaviors that agile software development practices aim to promote. Pushing product owners and business users to write down requirements and make them available for consumption by other team members downstream in the development tends to foster a more "waterfall" mentality and team dynamics, rather than the collaborative and constantly engaged face-to-face discussions that agile practices aim to promote.

Also, feedback regarding mistakes and misunderstandings in the requirements are more likely to escape unnoticed when they are presented in the form of pages-long written requirements. There is a greater chance of getting immediate feedback when the mistake or misunderstanding is brought up during face-to-face collaborative discussions. Feedback is important and the sooner you get it and act on it, the less costly it is to make corrections.

If you're going to write down your requirements, make sure you don't forget to have conversations with multiple people soon after those requirements are written down, so that your teammates can give timely feedback on the requirements. The worst thing that could happen, and I often see this anti-pattern, is when users of tools like Tableau adopt agile-like terms like "user stories" and "product owners" but in practice still follow a very siloed and "throw requirements over the wall" type of process flow. This is NOT agile.
 
Giovanni Montano
Ranch Hand
Posts: 497
10
Android Open BSD Slackware
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes Junilu, I understand what you mean about robust requirements. Anyway you can be agile as you want, but if your boss is like mine, you cannot do nothing. He just took over the project, although he know I would have loved.
Never mind, and thank you will buy you soon a cake
 
Crusading Chameleon likes the size of this ad:
professionally read, modify and write PDF files from Java
https://products.aspose.com/pdf/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!