In the third installment of this blog series on “20 Controversial Topics of Debate in Agile“, I will cover whether there is a “right” way to write User Stories. Writing User Stories sounds deceptively simple, but just like Agile itself, User Stories are:
“easy to learn but difficult to master”.
Scrum Guide
There is nothing prescribed in the Agile Manifesto or the Scrum Guide about User Stories. That said, I think they are a great way to communicate business needs from a customer’s perspective. This gives the developer context on not only what they need to build, but why.
Anatomy of a User Story
So, which of the following combinations of a User Story is the correct format?
Who
What
Why
As a / I am a…
I want to / would like / need / must have…
So that / so I can…
Role / User Type / Actor / Persona
Feature / Functionality / Goal / Action
Business Value / Reason / Benefit
In my opinion, almost any combination of the above could be a viable User Story. So… my answer is that NO, there is not one single correct way to write a User Story (feel free to debate with me in the comments below). As long as you have all three parts of a story expressed (who, what, and why), the format really doesn’t matter all that much.
In fact, there is a ton of variability in how User Stories are written. It depends a lot on who is writing, what level the stories are written at, and what the goal of the story is.
All that said, I will leave you with a few “pro” tips to use when writing your User Stories:
Prioritization
It’s hard to prioritize backlogs, so some practitioners bake prioritization into it by using the middle part of a User Story differently (want, need, must have, etc.). This can help organize your backlog into big buckets that are more easily prioritized by your Product Owner or Business Analyst than a giant list of User Stories.
Don’t forget the “Why”
One bad habit I have seen a LOT is that the author gets lazy and starts omitting the last part of the User Story: the why. Don’t get into this bad habit! The “why” is critical to help the developers understand the reason they are developing the story.
Final Thoughts
User Stories are deceptively simple; they are easy to learn, but difficult to master, just like Agile. To make the most of your User Stories, just be sure to include all three parts: 1) who, 2) what, and 3) why. If you do this, it will be hard to go wrong.
So, what is your opinion? Do you have a preferred method of writing User Stories? If so, what is it? I would love to hear what you think!
Up next in this blog series is debate #4:
- Can you use a Sprint 0 in Agile?
- Do you need Documentation in Agile?
- Is there a “right” way to write User Stories?
- What’s the best way to write Acceptance Criteria?
- How long should your Agile sprints be?
- Should all your Agile teams be run the “same” way?
- Which “flavor” of Agile is best?
- Can agile co-exist with waterfall?
- Story Size – What’s an Epic, Theme, Feature…?
- Can the Scrum Master be a team member, too?
- Can distributed Agile teams work?
- How should you estimate in Scrum & Agile?
- Is it OK to add items to the current Sprint?
- How should you manage your Agile backlog?
- Can an Agile team have more than one Product?
- What is the optimal size for Agile teams?
- Should Agile teams stay together?
- How should you handle defects in Agile?
- Can a hybrid of Waterfall and Agile succeed?
- What are the official roles on an Agile Team?
Nice post. I like to think there is no wrong way to write a user story …. But there are some ways that tend to work better than others. The interesting thing it is communication so those ways can change based on the situation and who’s talking. Personally, I like the “In order to…as a … I want” variation for the same reason I use the English Opening in chess. It’s just a little different than what other people are doing and most of time works just as well. Also, as a developer, writing the why first forces me to think about that part and following the well followed textbook template will always equals the well followed textbook template ….but not always equal a well understood user story.
Today’s ‘Best Practices’ lead to dead ends; the best paths are new and untried”
– Peter Thiel
Thank you, Mike! I really like your quote about best practices – I like to think that there no “best practices” – only “better practices”, because we should always be inspecting and adapting as we discover new and better ways of doing things.