In agile development methodologies user stories are a common way of capturing requirements that need to be implemented by the development teams.
In my opinion user stories are a very good way to describe functionality from a user perspective, there is however one big pitfall that people always fall into with open eyes (time after time).
The biggest mistake you can make with a user story is to see it as as static description of functionality, basically a small part of a design. This is definitely not how user stories were intended. A user story is an element on the product backlog that evolves over time. It’s alive… It’s alive…
User stories are often referred to as Card Conversation Confirmation (Jeffries 2001).
- Card; The basics of a user story should be small enough to be written on a card or sticky note. Within one sentence you should be able to describe the functionality that is requested.
- Conversation; The most important role of a user story is to trigger conversation. A user story is not complete, it represents a customers’ requirements but it does not document them. Team members, product owners and stakeholders should always keep that in mind. The story is there to get people talking, not to provide a “design” (damn I said the D word).
- Confirmation; Even though conversation is the most important factor of a user story, it does not mean that the results of the conversation should not be stored in any way. The outcome of discussions related to a user story should be added as acceptance criteria, development notes, attachments, etc to the user story.
Ok this is all very interesting but you are probably thinking “I can find this in any wikipedia article or agile related book, but how does this actually work”. And you are absolutely right about this so let’s look at an example of how a user story progresses through an agile development process.
Card: Define the user story
The first step in the lifecycle of a user story is the initial definition of a user story. The product owner captures the functional question of the stakeholder. It all starts with the format in which the story is written down. The format we use in our teams is:
In order to ..benefit.. As a ..role.. I want ..functionality..
I have adopted this format after being advised about this by Zilverline, this format is slightly different than the format you find in most books about user stories. Most books suggest to use the following format:
As a ..role.. I want ..functionality.. In order to ..benefit..
This of course is suitable as well but the subtle difference in the order of the description actually has an important reason. The most important part of a user story is to know the user benefit that should be achieved by implementing this user story, if the development team does not know why a customer wants to have a certain feature they are also not able to discuss the feature implementation and possible alternatives with the customer or the product owner.
Since the format that is mostly used (according to most literature and examples) lists the benefit only as a last item many people forget to mention it and just stop with the definition of the user story as soon as the role and functionality are described. By explicitly stating the benefit as the first element of a user story definition the person that writes this definition is forced to think about the customer benefit first.
Now about the most interesting part of this phase of the user story. Many people already continue with more detailed descriptions of the user story like adding acceptance criteria and maybe even things like screen mock-ups and so on.
In my opinion as a PO you could already stop after writing down this first definition of the user story and take the story to the team to start the discussion. By adding a lot of information up front you are thinking for the team. Maybe the team is so experienced that they have enough information with these first few sentences to already implement the feature. And if not the discussion with the team will tell you what needs to be added to the user story definition.
So my advice would be to write down the definition and then take the story to the team to discuss it, which is the next step in the lifecycle of the user story. So read on if you want to know all about it.
Conversation: discuss and extend the story.
After the initial definition of the user story is created it can be discussed with the people that actually need to implement the story. Remember that I started this article with the statement that a user should not be static? It is a common mistake made by teams and product owners.
Many teams have all kinds of interesting discussions related to a user story. With the Product Owner or customer they discuss the functional requirements of the feature to implement and together they discuss all kinds of implementation related questions and solutions, but where is the outcome of these discussions stored? Usually it remains in the heads of the team members, but why is that?
Remember the agile manifesto that each agilist hangs above his bed, in the toilet and has tattooed on certain body parts, this manifesto contains the following:
Working software over comprehensive documentation
This is often misinterpreted in a way that people think you should not document anything in agile projects. This is definitely not true. Documentation is still important in agile projects but the biggest difference is that in an agile project you document what is needed compared to documenting everything up front as is the common procedure in traditional software development practices.
This misconception of documentation in agile projects usually leads to people not documenting at all. My recommendation to teams always is to add the outcome of discussions about a user story to the user story itself. This is what user stories where intended for, you start with a minimal description about the feature and then you start discussing it, any information important for the implementation of the user story can be added as notes to the story, these could be all kinds of information, for example:
- UI mockup created by the team
- Notes about affected areas to inform testers what to cover.
- Notes about crappy legacy code that needs to be refactored when the feature is implemented.
- A note that there are no unit tests for the legacy code and the decision by the team to implement these as part of the story completion.
- The contact details of the stakeholder that can be contacted for functional input on this feature.
I guess the point is clear, everything that provides useful information to the people that will be working with the user story can be added to the story. Just make sure that in every case you ask yourself the question if it is useful information to add because the pitfall of this is that you end up with huge user stories with a lot of useless information.
So when does all this information needs to be added? There is a simple answer to this: “When it is needed”. And that should always be the criteria. If the team still needs to estimate a story then information such as a screen mockup is probably not necessary to make the estimate, but the fact that a few team members know that there is old legacy code that needs to be refactored can be important at this stage since it can influence the estimate.
So different stages of the development process of a user require a different level of documentation in the user story.
Confirmation: specify the acceptance criteria.
Although adding a lot of information to the user story is useful for the people that are working with it, it still says little about if the product owner will accept the story, which is somewhat important if we want to earn business value with the work that we do.
Making sure the story adds business value is the last of the three C’s of a user story, Confirmation.
To be able to verify if the work of the team addresses the business need for which the new feature is intended we need some criteria for the user story that we can verify. We call these acceptance criteria.
The previous section described information being added to the user story by the team. The acceptance criteria is information that is added by the product owner. Some of the criteria will emerge from the discussions with the team but in the end the product owner will decide if it is a criteria which determines if the user story gets accepted or not.
There is a generic format for specifying acceptance criteria which is used in some teams, this is also known as the Gerkhin language:
Given ..condition 1.. and ..condition 2.. and condition 3 When ..action.. Then ..expected result 1.. and ..expected result 2..
This basically describes in a sentence which pre conditions are required, which action is performed and what the expected results are.
The benefit of this notation is that there are some Behavior Driven Development tools that support this language. The down part of this notation, in my opinion, is that it often creates quite complex acceptance criteria which can be hard to understand by the end user. And after all that is what user stories are about, describing functionality from a user perspective.
Is there a fourth C, no but I thought it would be nice to add a conclusion to this article. So which conclusions can we take regarding user stories:
- User stories evolve over time, new information constantly emerges when discussing a user story. This new information might be added to a user story to document the discussion.
- Information about a user story that determines if a story will be accepted will be stored in acceptance criteria.
- Team and Product Owner share responsibility for the information in a user story.
- Don’t specify up front, specify the absolute minimum, start the discussion and capture the results of the discussion in the story.
- Moantain Goat documentation of user stories: http://www.mountaingoatsoftware.com/topics/user-stories
- Wikipedia about Behavior Driven Development: http://en.wikipedia.org/wiki/Behavior_Driven_Development
- Mike Cohn’s book about user stories:
Trackback from your site.