The Liberators
Published in

The Liberators

The Product Backlog contains all the work necessary for a product, in whatever format works best for the Scrum Team and its stakeholders

Myth: In Scrum, the Product Backlog has to consist of User Stories

Busting the Myth

A bit about User Stories

Techniques for capturing work on the Product Backlog

  • 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);


  • 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 a 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”;


You can already support us with $1/month. Find out more on



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Christiaan Verwijs

I liberate teams & organizations from de-humanizing, ineffective ways of organizing work. Passionate developer, organizational psychologist, and Scrum Master.