“Scrum User Story — How do I write a good one as Product Owner”
I looked a bit puzzled when the student posed her question. Where does one start? but it was not the first time I had gotten the question so perhaps it is good to share some thoughts on User Stories and how they can be useful (or not) for a Product Owner.
User stories, I love them, and I hate them.
Lets start with the fact that Scrum doesn’t talk about User Stories. Originating from Extreme Programming (XP) User Stories were a blessing. Rather that receiving and writing long documents about what the product should do and trying to anticipate all possible mistakes that a programmer or tester could make, we could now have a conversation. Mike Cohn, the inventor of User Stories, came up with nothing more than Index Cards, or Story Cards to achieve the same thing.
Mind you, before XP development team members were sitting in separate buildings, and when I was system designer and showed up in the testers building they would ask me what it was that I was doing there. (We didn’t even consider them team members either.)
So User Stories changed all that and I love them for it, but lately it seems like everything has to be a User Story. What about constraints? wireframes? logs? stories? or even requirements? The good thing was in the conversation but luckily Scrum doesn’t care about the format, as long as it is “well understood.”
So what makes a User Story a User Story?
Well, it should be about the user, and it should be a story! as simple as that sounds, we can still get it wrong very easily. A handy way to think about the User Story are the three C’s:
- Card — Its written compact so it fits on an index card
- Conversation — It is used as an invitation to a conversation, not to handoff work
- Confirmation — We add the newly discovered information from the conversation when needed, sometimes in the form of acceptance criteria
Wasn’t there some sort of template?
Indeed you remember well, the user story template:
As a < type of user >, I want < some goal > so that < some reason >.
Imagine an error message on a device, rather than stating: “the font size must be 24px” we can now write: “As a person with limited eyesight I want to be able to understand the received message.”
This opens up a whole list of options, where large font size is probably one of, but you can also thing of others like oral messages and at the very least the dpi of the screen is now also taken into account.
Some handy tips then:
For the <Type of user> go back to your personas and use those, be weary if user stories are about “the user” since for most products there is more than one type of user and they may need a different solution. Also if the <Type of user> reads: “Product Owner, Manager, Tester, Developer, CEO, Computer” it is probably not what you want. Make sure it is about User needs.
<Some goal> often becomes the solution rather than the problem: “a button, a trigger, some report, a graph, an alarm.” It’s tough be focus on the pain of the user; what will go wrong when the don’t have this? I don’t want a smoke detector, I don’t want my house to burn down.
<So that> is often completely lacking, yet it provides crucial information for ordering of the Product Backlog. Why does the user need problem solved? how big is his or her pain? What are the consequences of not having the feature. This often triggers powerfull discussions that lead to better solutions.
So who writes those User Stories then?
Often we see that User Stories are written by the Product Owner. But it can also be a team effort, especially when one Product Owner has multiple Scrum Teams.
The risk is still there that User Stories become just another pile of requirements, so ask yourself: when is my story complete? do I really need 98 acceptance tests to be documented? (yes I have seen this)
Sometimes stories are huge and we find that we struggle to make them smaller, team work can really help to make stories smaller and one powerful technique is called User Story Mapping, which we will cover in a later blog.
Making it the right size
So I talked about teamwork to make it smaller, but how does that work exactly? Well, here are 6 ways to think about making User Stories smaller:
- If the User Story is about a user workflow, it usually involves steps where we can break up the story: login, continue, select, order, pay, refund etc. Start with the beginning and end of the workflow and fill in the gaps later on.
- Is it about multiple similar things? words like managing, configuring, setting up etc. are dead give aways that we can split the story in several sub actions.
- Variations on user profile, eg. returning customers should be handled differently, words like “flexible”, “returning”, “power user” etc. typically hint in that direction.
- Complex interaction, e.g. handling a reservation for a flight can be broken in a simple flow: book me a ticket from a-to-b, and more elaborate ones e.g. pick seats and upgrades
- Lots of work and little work. “Oh and we also need to support the old system.” might be a good splitting point.
- Performance. Lets first do one user, than 1000, than a million. There is a bit of danger here because it may require a completely different approach, but in general we don’t want to invest in scaling unless we are sure people like the solution.
Conclusion
There we have it, agile software development changed the way we look at requirements. Agile projects avoid waste by thinking in conversations and stories rather than requirements
Tell me more
If you’re a Product Owner, Product Manager, Scrum Master or Agile Coach with about a year (or more) of experience under your belt, go and explore the Stances of the Product Owner in the Professional Scrum Product Owner-Advanced class. Find a trainer to your liking or in your area, and deepen and expand your Product Management knowledge and skills. And let us know what you think about the training! What did you like? What can be improved? Let’s collaborate to take the profession of Product Ownership to the next level.
If you’d like to experience the all-new Professional Scrum Product Owner-Advanced class, go to Scrum.org to find a class in your area. If you’d like to participate in one of our classes, check out our Xebia Academy page for more information or inquire for an in-house class via training@xebia.com.
