I know there are plenty of books and resources dedicated to user stories, but as I consistently see people writing bad ones here’s a few things to remember.
Write them with the stakeholder/product owner and challenge their assumptions
To some it may seem shocking to think there are people out ther writing stories without the stakeholder/product owner present, but I’ve seen it enough to feel I need to reiterate this point. Also, don’t allow the stakeholder to dictate to you. Question their justification and assumptions and ensure they are clear in the final story.
Don’t just write “As a customer…” or “As a staff member…”
You might as well write “As a person” for all the difference it makes. Which customer and in what context? Where are they in your application and what role do they play?
Write it so your gran would understand
Anyone should be able to pick up a user story and quickly understand it. Avoid acronyms, abbreviations, tech speak or business jargon. Misinterpretation can be very costly.
Use a whiteboard
When defining the user story, if you can, use a whiteboard. It will allow you to refine it easily whilst also making it visible to everyone in the room.
Don’t forget the “So that…”
In my mind the “So that…” is the most important element of the User Story Holy Trinity but it’s invariably left off the end. Any work must have justification and everyone should know what it is. This is the “why” and often exposes the real business need as opposed to what the stakeholder thinks they need. The process of gathering this element often redefines the whole story.
April 22nd, 2009 at 9:22 pm
Great points Rob. A generic user is of no use but it’s amazing how many times you see this.
Completely agree on “so that”. I’ve worked with teams where the reason given for leaving out why a story is important is because it’s hard to think about. No kidding. I’ve worked with teams where they were throwing out stories after giving the “so that” part of the story a few minutes of thought. The team came to the conclusion that some of the stories had no real value and were on the backlog because it was easy to throw on there. It’s amazing how much progress can be made by paying attention to these two little words.
April 24th, 2009 at 2:59 pm
Hi Rob, thanks for these useful summaries.
Another thing I like to stress is that a story should have a title. It’s amazing how difficult some people find it to put a simple, clear subject on top of their stories. Doing so demonstrates that the story has some kind of cohesion – it does one specific thing. It also makes it much easier to discuss things like prioritisation later on.
April 24th, 2009 at 10:40 pm
Liz Keogh (author of JBehave, a Java BDD framework) has suggested, and I for one agree, that there’s a better template that promotes the vital ’so that’ info to the front of the story:
http://lizkeogh.com/2008/09/10/feature-injection-and-handling-technical-stories/