Scrum is intended as a simple, yet sufficient framework for complex product delivery. Scrum is not a one-size-fits-all solution, a silver bullet or a complete methodology. Instead, Scrum provides the minimal boundaries within which teams can self-organize to solve a complex problem using an empirical approach. This simplicity is its greatest strength, but also the source of many misinterpretations and myths surrounding Scrum. In this series of posts we - your ‘mythbusters’ Christiaan Verwijs & Barry Overeem - will address the most common myths and misunderstandings. PS: The great visuals are by Thea Schukken.
Myth 4: In Scrum, the Product Backlog has to consist out of User Stories
Today’s myth is best understood by an example from a team we recently worked with. Their Product Backlog featured this item: ‘As a designer, I want to set up a style guide so that all developers can do basic design themselves’. This format - ‘As a [role] I want to [action] so that [reason]’ - is commonly referred to as a ‘User Story’. Further reading of the Product Backlog yielded similar examples: ‘As a visitor I want to view the site on a mobile device so that I can view it on the way home’ and ‘As a developer I want to have an API so that I can query orders from the backend of the app’. Why didn’t the team just write three shorter items, respectively: “Create style guide”, “Support mobile devices” and “Allow querying of orders from backend (API)”? Instead, they went through quite some effort to formulate everything in their Product Backlog as User Stories.
When we challenged them on the formulation of the items, the team responded that this was how Scrum was explained to them. They’d been told that Product Backlogs consisted out of User Stories. Even if it felt forced at times, and made the team lament the ‘administrative burden’ of having to reformulate obvious tasks into User Stories just for the sake of it.
Today, we will bust the myth that the Product Backlog has to consist out of User Stories.
We will do so by going back to the purpose of the Product Backlog and User Stories. In the process, we also bust a related myth; that User Stories are an inherent, necessary part of Scrum.
Busting the Myth
According to the Scrum Guide, the Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. More succinctly put, it lists all the work that is deemed necessary for the product.
How Scrum Teams decide to capture this work is entirely up to them. They can write User Stories, they can use a bunch of keywords, write use cases or even draw pictures. As emphasized in earlier posts, the Scrum Framework only describes what needs to be done, but does not enforce how it needs to be done. The realities of product development are too complex for one-size fits-all solution, silver bullets and generic techniques.
About User Stories
Over the years, User Stories have become the ‘go-to’ technique for most Scrum Teams. Their use has been heavily advocated by books, blogs (including our own) and trainers. As it stands, they are considered ‘good practice’. Originally coined in 1998 by Alistair Cockburn, the use of User Stories became dominant in Extreme Programming (XP). With the rising popularity of Scrum in the meantime, it comes as no surprise that User Stories carried over to Scrum along with other XP-concepts (like story points and the ‘stand up’).
The popularity of User Stories is easily understood. They are vastly different from the extensive specifications of more plan-based approaches. Instead of trying to capture every detail of a feature in lengthy requirements and bullet lists, User Stories simply describe the functional essence from the perspective of a user: “As a shopper I want to put a product of interest in my shopping basket so that I can buy more products at one”. The strength of User Stories lies in their simplicity. By design, they are incapable of conveying every detail of what's needed. As a Scrum Team progresses through the Product Backlog, delivering items as part of working Increments, they will eventually need to have a conversation about what is needed to implement an upcoming item that its User Story so succinctly describes. But they’ll have that conversation when they’re about to implement it, not at the onset. In effect, items on a Product Backlog are reminders for future conversations, based on the knowledge and the insights that have emerged by then. This fits well with Scrum’s empirical approach to product development and the inherent cone of uncertainty.
Techniques for capturing work on the Product Backlog
So there’s absolutely nothing wrong with User Stories. They are a great technique for capturing functional requirements in a ‘good enough for now’-manner that leaves room for further conversation. But Scrum doesn’t prescribe nor require them. Other techniques are fine, as long as they help promote three things:
- They make the Product Backlog understandable to the Scrum Team and its stakeholders. A stakeholder should be able to view the Product Backlog and have a good sense of what's coming up and in what order;
- The level of detail they demand should fit the uncertainty of product development. Items that lie further into the future should require less detail than items that are about to be pulled into a Sprint;
- They should foster an ongoing communication and conversation between the Scrum Team and stakeholders (which includes users);
Some work can be captured with a few keywords or a short sentence. If both the Scrum Team and stakeholders understand what a “Responsive site” means, why go through the effort of forcing it into the User Story mentioned in the introduction? And what about technical work? Like building an API or setting up infrastructure? If used in moderation, a technical description of work is fine if that's the simplest, most understandable way to capture it. There’s little value in a vague User Story “As the company we want three instances of a site, so that a crash of one instance doesn’t bring everything down” if it is also understood if we just write “Set-up load-balancing for site” on a post-it. That the Product Backlog as a whole needs to be understandable to the Scrum Team and to its stakeholders doesn’t mean that every single item has to. The Product Backlog remains an ongoing conversation.
A healthy Product Backlog contains a mix of items. Some items will be technical tasks (e.g. ‘Install new web server’ or ‘Create backup schedule for production database’), whereas others will be functional (e.g. ‘Subscribers can store items to their reading list so that they can read them at a later moment’). User Stories are a great way to capture functional requirements if they flow naturally from the conversation where they are identified, and their formulation doesn’t feel forced and ‘an administrative task’. If you find yourself forcing something into a User Story-template, you do well to consider other techniques.
Tips
- If you find yourself forcing requirements into a ‘User Story’-template, consider what purpose the story serves. Is this the best way to make the Product Backlog understandable both to the Scrum Team and its stakeholders?
- The template of ‘User Stories’ is only a guide. There’s nothing wrong with shorthands like ‘Visitors can register for newsletter’;
- Explore other ways to capture requirements on a Product Backlog. Instead of using user stories, we prefer to ask this question for every item: “What becomes possible or easier after implementing this item?”. We write down the answer on so-called ‘Feature Cards’. The back of the card contains two more detailed questions that are generally answered during Refinement or Sprint Planning: “What criteria apply to this feature?” (e.g. acceptance criteria) and “How do we know that this feature is working as intended?” (e.g. test cases). Again, this is just a technique;
- The forced nature of ‘User Stories’ is especially obvious in non-IT environments. Meant to capture functional requirements in applications, the template isn’t all that useful outside of IT. It often leads to weirdly phrased or vague internally-oriented items, like “As marketeer I want to send a mailing to group X so that they are aware of new products” or “As team member I want to write a plan to see how Y can be done”. We prefer to ask non-IT teams to focus on putting the outcomes they want to achieve on the Product Backlog, not what they are going to do, e.g. “Notify group X of new products” and “Strategy for achieving Y”;
Closing
In this post, we’ve busted the myth that a Product Backlog has to consist entirely out of User Stories. By describing the purpose and characteristics of the Product Backlog, we also busted the related myth; that User Stories are an inherent, necessary part of Scrum.
What are your thoughts on this myth? Do you agree with this post, or not at all? Let us know in the comments.
Want to separate Scrum from the myths? Join our Professional Scrum Master or Scrum Master Advanced courses (in Dutch or English). We guarantee a unique, eye-opening experience that is 100% free of PowerPoint, highly interactive and serious-but-fun. Check out our public courses (Dutch) or contact us for in-house or English courses.
