5 Common Mistakes We Make Writing User Stories

3 August 2011

Most of the issues with gathering requirements in agile software development and agile testing derive from issues with User Stories. Somehow expressing requirements in such a simple form causes a lot of trouble to agile teams. Of course art of writing good User Stories is the most difficult for new teams starting with a new agile project or these, which freshly transformed development methods to agile software development methodologies. Mistakes made at that point lead to wrong Test Cases, wrong understanding of requirements, and the worst of all wrong implementation which can be direct cause of rejecting the deliverables of the iteration. Lets take a look at the five most common mistakes people make writing User Stories.

Introduction to User Stories

User Story is a short description of customer’s need. User Stories are commonly used in agile software methodologies and frameworks such as  Extreme Programming or Scrum as a way of gathering requirements. Whenever possible User Story should be written by a customer otherwise it can be written by business representative in behalf of the customer or referring to a potential customer aliased as persona. User Story should be kept short and fit on 3×5 inches index card. The text on that card covers role of the user in the system, the need expressed by user and the benefit from implementing described feature.

The main purpose of using this tool is estimation of an effort needed to implement a new feature in software accordingly to the Definition of DONE for the team. User Stories also enable conversation that leads to extracting business and technical requirements and eliminating hidden assumptions. Sometimes they are mistaken with Use Cases and Use Scenarios, but the biggest difference is that they are much shorter and do not describe the application interface, steps or flows in the application. Implementation of User Story is confirmed by Acceptance Test being derivatives of Acceptance Criteria sometimes referred as Conditions of Satisfaction. For estimation at that level we use only points, ideal days or other unit representing size rather than actual time that needs to be spend implementing the feature. There is also simple template helping to make sure that all the elements are kept, “As who I want what so that why.” Here is the longer and more descriptive version of that template:

“As a <specific user/persona/role>” I want <desired feature/issue that needs to be solved>, so that <benefit from implementing the feature>” + Acceptance Criteria

Each of these elements is important and has a role in expressing and understanding the captured requirement.

The Five Most Common Mistakes

1. User Story for a User

Example: "As a user I want to be able to manage ads, so that I can remove expired and erroneous ads."

At the first glance you don’t see any issues with that User Story, because all the required elements are present. Now tell me who is the user for whom you are going to build that feature of ads management and what does he understand ads management? Is that a portal administrator, who wants to have possibly of database clean-up and ads moderation? Or maybe it is an advertiser, who wants to have list of all ads he submitted to the side and have possibility of removing ads when they are not needed any longer or there was error found in the content? As you may noticed, I mentioned only two different roles with different expectations from the system. I this case what is missing is persona or role mentioned.

2. User Story for Product Owner
Example: "As a Product Owner I want the system to have possibility of deleting ads, so that users have possibility of deleting ads."

And again, all three elements are here, but there is something wrong. First of all this User Story is type of ‘you want story, here you have one’. Obviously person writing this User Story did that only for sake of doing it. You can have a  Product Owner as role of person using the system if you build software for teams using agile software development. That indicates issues with implementation of agile methodology in that organization.Second of all you have here exactly the same issue as in the previous example. There is no role or persona to give you clues about user expectations.

3. User Story for Developer

Example: "As a developer I want to replaced the folder widget, so that I have maintained folder widget."

This typical example of Story for a Technical Backlog or technical requirement representation. Sometimes User Stories like this one are also part of so called technical debt. Technical debt consists of necessary maintenance tasks like software updates, re-factoring, changing frameworks and so on. They are totally rightful to be implemented, but represented like in the example above they do not represent value for the customer and you will not get a buy-in from Product Owner. Also from the ‘agile point of view’, you need to deliver a business value at the end of every iteration and the team needs to be able to present it to the stakeholders on the review meeting. How to write such a story correctly? Rewrite it from a user point of view with persona on role.Example: ‘As a commercial user I want the system to allow me run multiple searches at the same time, so that I can do my job faster.’ Task to go with it can be: ‘Re-factor search handling mechanism to allow multiple threads for single user.’, ‘Update java version to 64-bit one.’ Acceptance criteria need to define some measurable and testable definition of improvement like: ‘Single user can run 5 searches at the same time.’ and ‘Search returns results in less than 4 seconds.’

4. No Business Value or Benefit for Customer

Example: "As an commercial advertiser I want to have filtering option."

We have the role, we have the need, but reason and business value are missing. Why does an commercial advertiser want to have filtering option? What does he want to achieve?

5. No Acceptance Criteria or Conditions of Satisfaction

Here you can use as an example one of the examples above. The problem in such practice is often underestimated. Not having Acceptance Criteria sometimes referred as Conditions of Satisfaction can cause the whole chain of mistakes starting with wrong definition of development tasks or wrong estimation. Story can failed the tests or Test Cases will cover different criteria due to lack of understanding. Acceptance Criteria pay great role is confirmation of requirement understanding and decide about acceptance of iteration deliverables. Conditions of Satisfaction question the User Story enable conversation between the Product Owner and the team. Good way of gathering Acceptance Criteria is asking questions such as ‘What if … ?’, ‘Where …?’, ‘When …?’, ‘How …?’. Use examples and simple drawings to remove assumptions. It can happen that Story needs to be refined and re-planed or quite often split to smaller stories.

Article Rating

Current rating: 2.7 (7 ratings)

Comments

DSK Chakravarthy, CSM, 8/21/2011 10:27:57 AM
Out of my experience, most of the stories are created with the ROLE and FEATURE, but they miss the BENEFIT part. When they realise the 3 vital points, the stories would be targetting the need.

Anyhow, thanks for the points and trowing the light on the angle that every story writer has to give attention at.
Mishul Prasad, CSM, 8/23/2011 11:30:26 AM
Like the stories and it is great to see someone adding acceptance into the process. I have started doing this within my work and our story cards now hold acceptance criteria so that we can ensure that 'business value' is met.

Mishul
Krystian Kaczor, CSP,CSM, 8/25/2011 2:58:18 AM
I am happy to see that you find the article useful. Thank you for comments.
Mao Lin, CSM,CSD, 8/30/2011 9:51:52 PM
I found out if attach an scenario matrix on the story, it will help developer to understand the story.
Anita Upadhyay, CSM, 8/30/2011 11:41:37 PM
The acceptance criteria is a critical element as it helps the team understand how the product owner will validate the feature is complete or not. This provides more insight in to the expectations from story implementation.
Paul Whelan, CSM, 8/31/2011 3:20:42 PM
We explicitly state the value/business benefit on the card, eg

"As a user I need the ability to..... so that....
The Value to Our_Company is...
A/c
1)
2)

We often get stories where the value can't be stated - 9 times out of 10 these are binned..
Mario E Moreira, CSP,CSM, 9/3/2011 10:15:04 AM
What I find helps the PO and team a lot with personas is to first consider the potential personas you would have using the product. This can remove some of these mistakes upfront. Also once you have most of the personas established (note: you may find some more down the line as others use the product), you can then provide a robust understanding of the persona (e.g., most end-users are between 18-25, have experience with web interfaces,...)
Jon Cotter, CSP,CSM, 9/7/2011 5:00:10 PM
One little trick I use to avoid some of the first 3 pitfalls is not to allow the word "want". It is much harder to cheat the stories when people are forced to say "I can" or use the actual verb. Obviously some people will still get around it, but that has helped me in a number of cases.
Krystian Kaczor, CSP,CSM, 9/8/2011 7:40:25 AM
Jon, thanks for the trick. I will try it in practice.
Sunita Nayak, CSM, 9/8/2011 10:19:17 AM
The acceptance criteria defines the boundary of "Definition of Done" for that specific feature or story card.
Krystian Kaczor, CSP,CSM, 9/8/2011 11:26:44 AM
Sunita, that's not correct.
Definition of DONE is set of activities and standards that need to be performed and satisfied for every task delivered by the Team and it depends on tools and technologies that the Team has at the moment. Acceptance Criteria are checkpoints for the Story to know that the Team will delivered what was expected by the PO and agreed at the Sprint Planning Meeting. Product Owner has to accept the User Story with some criteria satisfied, that's why it's called Acceptance Criteria.
Rajesh Francis, CSM, 9/26/2011 4:06:48 AM
1) Do you think we should have a sign off from the Product Owner on all stories.
2) How about defining dependencies in the story? How can i write dependencies?
3) Can user stories have prototypes or flow defined?

Krystian Kaczor, CSP,CSM, 9/26/2011 10:03:28 AM
Hi Rajesh,
1) What kind of sign off? If from business value point of view, the answer is yes. Usually PO writes Stories and the User Stories need to be accepted by the Team as being ready to plan.
2) Defining dependencies in the story? Why would you do that? Stories should be independent (the INVEST model).
3) If you ask about interface prototypes and flows, definitely yes. Any prototypes, examples, flow help understanding User Stories and do better planning.
If you are not entirely happy with my answers, please clarify your points and ask more precise questions.
Aniruddha Ray, CSM, 9/29/2011 1:49:44 AM
Rajesh

My 2 cents w.r.t your questions -

1) The product owner (and ONLY the product owner) should sign off on a story (after the Sprint Review). He is the person who evaluates whether the implemented story has achieved the "Business Need".

2)It's a very Big risk to have dependencies Defined in stories. You should avoid that since then it leads to "entitlement" problems for the users.Try and build independant stories (you can use INVEST model as mentioned by Krystian)

3) In the initial sprints it's a Good practice to build stories that build prototypes (in case they fail you can change course....part of Inspect and Adapt principle).

Hope this helps
Anantha Narayanan, CSP,CSPO, 10/5/2011 12:14:42 AM
As Mike Cohn says, a user story is a start of a conversation. It should be groomed and organically grown by the product owner and the team. As a ----, I want ----, so that .... is a good template to use.
Amit Prakash Bhatt, CSM, 10/9/2011 2:00:00 PM
One point regaring the business value:

There may be times when a deliverable is not directly usable by the end user. For example - a middleware library.
In these cases it's difficult to figure out the business value from an end-user's point of view and we start treating this User Story as a "Business Debt".
However we must keep in mind that every single element that we are implementing has some direct or indirect business value for the end user. Although this "value to the customer" may not come in the "User Story Statement" itself, however we must mention it somewhere in the detailed description or remarks section in the software tool that we are using to manage our User Stories.
This helps both - team & product owner/management understand the ROI of the User Story in context.
Arijit Sarbagna, CSP,CSM, 11/2/2011 9:04:52 AM
@Krystian: Just an amazing article! Excellent work!!! Just loved it!
It is a fact that story writing/elaboration is often a victim of "over simplification", "over population" (i.e. too many people trying to explain one simple/small need) & often "over complication".
If I am asked to pick one catch line from your article, I will use - "Use examples and simple drawings to remove assumptions". As the saying goes, "a picture is worth a thousand words" & this should be followed to maximum possible extent. In my personal experience, I have always encouraged people to use diagrams (i.e. even a white board scribbling/sketch) or wire-frames to explain their need. And being a big follower of implementing standard documents, I roll out story templates per project need. That again is quite simple, just ensures that the document has enough placeholders for the story writer to easily navigate & fill-in as much data as possible. If we don't have standards/templates, pretty soon you will end up with a story repository - where all have their own taste & flavor & competes to be different that the rest - which is quite frustrating for the developers.
So, to be in a better position on story elaboration, we should work towards: (1) having simple story templates in place (& encourage all to use it); (2) use version control/revision notes in your story (more often this part is taken care by the ALM tool itself); (3) reduce assumption of the person/team who will eventually read the document - by providing as much information as possible, ideally provide mock-ups/screen-shots/wire-frames; (4) most importantly, get PO buy-in on this document (along with crisp Acceptance Criteria) - so that you don't need to make a path change in the requirement once sprint starts.

Agile is amazingly fun & exciting to work with - if we follow what one said nicely - "The ability to simplify means to eliminate the unnecessary so that the necessary may speak.".

Cheers!
Nick James, CSM, 11/4/2011 3:48:22 PM
Hi Kristian, I find one of the biggest mistakes in story writing, is in the sizing, either too epic or so decomposed that they no longer represent a marketable, shippable feature. This is a skill of story writing that only comes with time and the experience of trying to estimate superset stories and blowing one's sprint velocity.
Krystian Kaczor, CSP,CSM, 12/23/2011 2:06:00 PM
@Anantha I agree that it's only a beginning and it's very important to have the right base for conversation. What makes a requirement is 3C. Card (with User Story on it), Conversation, Confirmation (Acceptance Criteria).
Krystian Kaczor, CSP,CSM, 12/23/2011 2:07:55 PM
@Arijit Thank you for your comment. It's really valuable.
Krystian Kaczor, CSP,CSM, 12/23/2011 2:08:34 PM
@Nick At the beginning you can help yourself with splitting using some patterns: http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/
Ruben Sadoyan, CSM,CSPO, 3/21/2012 4:16:39 AM
Nice one! Many thanks, Krystian.

My 5 cents: another common mistake regarding acceptance Criteria is if they are not written from the point of view of the same persona used as user story "who", that brings to misunderstandings and wastes of all kinds.

Regards,
Ruben.
Timothy Korson, CST,CSP,CSM,CSPO, 4/2/2012 8:34:14 AM
As a scrum practitioner, I would like to see more articles that discuss common Scrum pitfalls like this one, so that my team and I can quickly identify and avoid them.
Charles Bradley - Scrum Coach, CSP,CSM,CSPO, 5/4/2012 5:25:30 PM
@Timothy,
Here are some common pitfall articles I've written about Scrum and User Stories that might help: 1) "User Story Traps" http://scrumcrazy.wordpress.com/2011/01/05/user-story-traps/ 2) "User Stories: Best and Worst Practices" http://www.scrumcrazy.com/User+Stories+Best+and+Worst+Practices 3) "Bad Smells of the Sprint Backlog" http://scrumcrazy.wordpress.com/2010/10/07/bad-smells-of-the-sprint-backlog/ 4) "Bad Smells of the Daily Scrum" http://scrumcrazy.wordpress.com/2010/09/18/bad-smells-of-the-daily-scrum/ 5) "User Story Basics" http://www.scrumcrazy.com/User+Story+Basics . Hope these help!
Charles Bradley - Scrum Coach, CSP,CSM,CSPO, 5/4/2012 5:31:14 PM
@Krystian, [quote]User Story is a short description of customer╬ôÇÖs need.[/quote] I would quibble a little bit with this statement. I like your emphasis on Acceptance Tests and that's great, but acceptance tests are part of what "A User Story is..." A User story is a description + conversations + confirmations(acceptance tests). More details on my web site. "A User Story Checklist" : http://www.scrumcrazy.com/A+User+Story+Checklist
Suresh Agarwalla, CSM,CSPO, 9/1/2012 4:59:41 PM
This is really helpful article.
How do you write user story for usability requirement (e.g. any one can use the site without any help - Easy to use)?
Jeevan Mathew, CSM, 10/18/2012 2:19:53 PM
@Suresh: This is an interesting question!
Here is my opinion: Say the site you are referring is something like a social site such as a news site where anyone can surf and scoop what is of interest to that user.
Lets take this example: The site has too many categories of news that it is impossible to show all of them in main screen.
The story can be like this: As a new user I should be able to easily see all the news categories so that I know they exist and can browse them.

Now lets take another example: An intranet site to manage users.
You have a new user registration screen, where you need to fill a lot of fields for which you need some business knowledge.
The admin user had training on domain, how to use the site etc. However, since the new user registration process is done not very often, the user might still want to refer the help documentation but wont not like search through them.
So the user story can be like this. As a user admin, i would like to get quick access (not having to browse through the help manual) to help guide for X, Y,Z fields so that I can enter the correct values for these fields faster.
One implementation of this would be creating a context based or field level help, which would show when hovered over a help icon.
Bill Rinko-Gay, CSM, 11/7/2012 2:10:42 PM
This a good list, but the write-up seems to suggest that development work will continue from the User Stories alone. In Agile, prefer spoken communication to written communication. There is value to disciplined writing of user stories, but you can't blame "a wrong implementation" on the documentation. If it comes to that, the wrong implementation should be blamed on over-reliance on documentation as opposed to direct communication.
Aashish Agarwal, CSM, 5/2/2013 1:16:48 AM
@Krystian: This is quite useful article. Thanks for sharing.
@Bill: This is an important observation. Extremes in either side are dangerous.

It is important to always remember that all this movement is to deliver a software that solves customer problems without any surprises.
Tim Sorweid, CSM, 5/28/2013 12:59:57 PM
Who writes the user stories? Is it the development team as the project or series of tasks are introduced to the team in the planning meeting? Or is it the product manager as he works with stakeholders to fill the backlog?

You must Login or Signup to comment.