Writing effective User Stories is a challenge for even seasoned Agile teams. Many factors make it difficult, like different interpretations of the requirements and the fact that people think about problems in different ways. However, User Stories are really the building blocks of a successful Sprint and being able to deliver incremental customer value. Getting it wrong leads to delays or missing the mark on feature delivery, so it’s very important to get it right.
From an Engineers perspective, a common tendency is to write task-based user stories. When thinking about delivering a feature, engineers tend to think of how it will be built technically. This is important, but it should be the second step, not the first. You may have experienced a team’s focus on the technical – like what is needed to update the database schema, write some business logic, update the API or update the UI. All of these are needed, but the only one that actually provides customer value is the UI, because that’s how a customer will use the feature. (yes, some customers may hit your API directly, but work with me here). The problem is the UI won’t work until all other things are in place. So many teams and engineers write all the user stories to represent a “chunk” of work that when put together with all the other chunks of work, it will finally provide the customer value. Even worse is when the team creates user stories based on who can do it or what skillset will work on it. But this leads to essentially the same issue of delay getting value to the customer.
Agile principles think about it differently. They turn this on it’s side. Instead of horizontally slicing a feature, they vertically slice it. Also referred to as the ‘cake layering effect’. It’s not easy to do, especially at first, but does get easier when it is the focus of the team.
The INVEST Technique
A good reference tool when crafting User Stories is called INVEST.
I – Independent
N – Negotiable
V – Vertical/Valuable
E – Estimable
S – Simple/Small
T – Testable
And to add some detail about these:
Independent – If user stories are not independent it becomes difficult for a Product Owner to prioritize. Rather than having them in priority order, they need to have them in priority and engineering order. In other words, they need to know in which order they should be done and what user stories to put together in order to actually get a feature complete. It adds more complexity and challenge. It is much cleaner if the Product Owner can pick from and list of user stories that each independently provide customer value. In addition, dependencies add delays. And delays reduce lead-time.
Negotiable – User stories should not be a written requirement that is handed-off to engineers. Instead, the feature should be discussed and negotiated to create the smaller slices of customer value that fit into a sprint.
Vertical/Valuable – Does the story provide customer value or is it just a piece of the puzzle and needs to be combined with other stories to provide that value? Try to craft stories that deliver value and not just technical stepping stones.
Estimate-able – Sized. If it’s either sized too big or can’t be sized (infinity is not a size) then you should go back to N and make some smaller slices.
Small – Larger stories provide higher risk for completion in the Sprint. In general, the smaller the story the more likely it will be released as expected.
Testable – In order to get to DONE and meet the quality standard, the work needs to be testable and it should be part of the definition of done.
Writing effective User Stories will set the team up for more consistent success. If you take some time to talk about how they should be created, use techniques like INVEST to guide you and make sure everyone is focused on customer value, you will see a big improvement overall!
Work-Agile 