Using stories effectively is a topic regularly asked about and discussed in forums, training and when coaching. It’s a big topic, however, that I can’t really cover in detail in a blog. Instead, I’ll provide my top 5 tips with some explanation for each.
1) Do the reading
There has been a lot written on user stories, some of it good and some in my opinion less so. Four books I recommend to anyone to acting as a Scrum Product Owner, Product Manager or Scrum Master:
This is the definitive guide on user stories and has been for over a decade. It gives a good overview of the philosophy behind user stories, how to use them in a development process and some decent examples.
This is a great guide for starting new products or features and essential learning for product lift-offs and user story workshops
This book covers a lot of ground, but it has some good insight into user story and product backlog development. It’s also on the recommended reading list for the Scrum.org Professional Scum Product Owner certification.
I don’t agree with all of the ideas, but it is a helpful guide and encourages you to think about your user stories differently, which is often the first step in using them effectively.
2) Don’t write them alone
Some product owners and managers think that as their role is to create a roadmap and to manage the backlog, the task of writing stories falls solely to them, so they spend a lot of time at their desk crafting “perfect” user stories.
User stories are not meant to be written alone. You might jot down a story and some acceptance criteria on your own, but your next step should be to discuss it with the target user, customer and development team. In fact it’s usually best to write stories in a workshop with representation from “the business” and the development team. You will always end up with more and better stories this way, and save yourself a lot of time, believe it or not.
If others are able to write stories in your backlog (which they should), then the first thing on your agenda should be to chat with the person who wrote it to understand and refine the story as best you can.
3) Leave the details as late as possible
It is common for Product Owners to think they have to be working well ahead of the team, defining all of the details. They start putting together screen mock ups, workflows, business rules and so on. The idea is that when it comes to do the sprint planning, everything is ready to go; the team can hit the ground running.
It rarely works out that way, and it often results in waste. Priorities change and features are postponed or canceled. Unforeseen technical challenges, dependencies and assumptions make a mess of the design. The story also often balloons as everyone contributes. Then the team has trouble breaking it into sprint sized pieces.
One more point I’d like to make is that the more you write and document, the less flexibility the team has. When a story is documented down to the smallest detail, people are more likely to deliver it “as specified” rather than find ways to minimize the work and maximize the value.
This of course begs the question – when is “as late as possible?” It will depend on the team, the product, the organization etc. I recommend erring on the side of too late rather than too early and then spending time working closely with the team during the sprint to fill in the gaps. Also, before you start into the details, get agreement on the KPI and the value the stakeholders are looking for and put the story in front of your team for their questions and comments and to ask them what details they need and don’t need. Why make screen mock ups if the team feels they can just have the designer sit with them for a few minutes?
4) Focus on the value, explain “why”
A short piece of advice, which leads into the next point. Think about the who and the why before you specify the what. Make sure you understand what kind of user will benefit from the story and what they are really trying to do.
5) Use stories as an exercise, not an end point
The user story should be an exercise, not a specification. The templates or structures are not intended to make the story something that a developer can look at and start coding from. They’re meant to ensure you think through the what you’re trying to achieve, and for whom, before you commit to delivering it.
It’s important to keep in mind that your mileage will vary. How you use stories will depend almost entirely on your product, your team, your environment and many other factors. In particular, if you or your team is new to Agile, you should approach these recommendations as a goal, not as a “must change right now.”