The 6 Backlog Item Types
And why I stopped calling them all User Stories
The term “user story” has become synonymous with the product backlog item. You’ve quite likely seen user stories that state something like “as a developer I want to see error logs so that I can fix bugs” or similar. And if you’re anything like me you’ll be trying your damnedest to hold back an ungodly rage when they crop up.
In this article I’ll talk about what a Product Backlog Item is, and why that’s not the same as a user story. I’ll describe the 6 types of backlog item I work with and show how making this clear will help to make sure you never have read (or write) a business or business user “user story” again.
This article is not about how to manage a product. I do not claim to be a product manager, but as a technical manager and as a Scrum coach, I have helped many product and delivery teams work more effectively together by creating great product backlogs.
What is a Product Backlog Item and What is a User Story?
A “Backlog Item” simply defines a distinct piece of functionality that has yet to be delivered for a product. The Product Backlog is a term used to describe all of the remaining Backlog Items, and a Sprint Backlog is a term used to describe a subset of them that a Scrum team have committed to deliver in a sprint.
The official Scrum Guide doesn’t mention the term user story at all, however Scrum co-creator Mike Cohen’s Mountain Goat Software describes a User Story as this:
Short, simple descriptions of a feature told from the perspective of the person who desires the new capability.
Indeed, the user story is a very powerful principal. It’s a very simple way of keeping product features distinct and focused on the benefit they have to the user. The unified format, that is often used, provides a valuable way of easily communicating the purpose of the proposed feature to any stakeholder.
But somewhere along the way the term became so synonymous with the backlog item that its usage became the default way of describing any feature or pretty much any deliverable to be produced by a development team. This is not only confused and misleading but also very much dilutes the potency of the term user story. Often, when I challenge someone’s use of the term on what it means, they say nothing of the perspective of the person who desires the new capability.
A Backlog is Populated by Many Types
The answer to this problem is quite simple: Relearn what a product backlog is. Crack open the product backlog can of worms and dissect its constituent parts. When I ask a team to do just this, we usually come to a very similar conclusion: There are 6 types of product backlog item, and each of these are explained below, alongside a little reasoning.
1: Feature (or User Story)
Let’s get this out of the way first. A Feature, or if you really feel it helps, call it a user story. It is a distinct piece of functionality that a user needs and that will add value to the product or strengthens the business proposition. Features can be big (“epics” maybe) or they can be small (“quickies” perhaps).
User Stories are often written in a formalised way. As a… I want… so that.. (when I… is also often included). In my view this is a very useful approach that certainly helps teams who need to shift to a more user focussed approach, but it should not be considered the only approach! In any event, you cannot detail a requirement well enough to be worked on with one sentence alone!
Before writing even a single Feature, you probably need to take a step further back. Start by understanding and documenting your product’s user types (clue: “a developer” isn’t one of them”), then create a story map. Story mapping is a hugely powerful method for understanding your user’s needs and creating a priority from it.
2: Change
I used to refer to these as Change Requests, but the shorter version not only removes superfluousness but also abstracts away from a term that carries a fair bit of emotional baggage! A Change details an amendment to an already delivered Feature. A Change must always relate to an existing/historic (and delivered!) backlog item.
The fundamental difference between a Change and a Feature is the that a Feature provides the user with the ability to do something, while a Change simply changes the way they do it.
3: Defect
A Defect is a problem with an already delivered Feature or a Change, which has been identified in a production environment (i.e. after the work is complete). A Defect is different to a bug, as bugs are identified before the production release of the Feature or Change. Bugs live only in a sprint and belong to an in-progress Backlog Item, while Defects live in the Backlog itself and relate to a delivered backlog item.
A Defect must relate to one or more specific acceptance criteria (functional or non-functional requirement) that has been identified prior commencement of work (or arguably during depending on how flexibly you are with letting changes to requirements come in late). If there is not a specific acceptance criterion to relate to then this would make it a Change.
These important distinctions can help in many ways. The point is not to assign blame, but rather to take ownership. Development teams are responsible for ensuring they deliver product increments that match requirements and meet the acceptance criteria. Product teams are responsible for ensuring that requirements are correct and meet the needs of the users and the business.
4: Technical Debt
Technical Debt is created for two reasons:
1 — When a bug is identified with an in-progress item (i.e. a functional or non-functional issue is found) and it is decided by the team (including the product owner) that it is low enough priority that it can be delivered without resolving the issue. In this instance it must be recorded that the acceptance criteria of the backlog item have changed: you are accepting this issue.
2 — The development team have had to make a shortcut that would reduce the ruggedness of the product (perhaps code could benefit from a refactor or there is a performance gain to be made).
More on tech debt… This article is a few years old now and I have recently published a new article that digs a bit deeper into Tech Debt and how to make it really work in your favour. Check out Managing Your Tech Debt.
If fixing the issue immediately would delay delivery or prevent the backlog item from being completed within the sprint, recording and accepting the problem such that it can be prioritised alongside other items to be addressed in a future sprint is important.
The risk here is that Technical Debt is pushed down the priority list and never resolved — as it is not perceived to bring about tangible benefit to the product, user or business. The term Technical Debt was originally coined by Ward Cunningham and the principal is that, like financial debt, it accrues interest. The longer you leave debt unpaid, the hard it will be to pay it back. The team, and especially the product owner, must create a model for prioritising and processing technical debt (some ideas here).
Tip: when approaching the start of a project or product, you could count any set up work which doesn’t strictly deliver any functionality for a user (implementing CI pipelines, creating solutions etc), as Technical Debt.
5: Technical Spike
A Spike is an investigation that helps to reduce the uncertainty of how a Feature might be delivered. Spikes are usually time-boxed bodies of work and they should feed into the backlog refinement process. A spike may result in a small prototype being created, or simply a document detailing the outcome of the research done.
Technical Spikes are useful ways of allowing developers time to find solutions before approaching the work itself. This is hugely important for increasing the amount of time until an entire re-write is required and keeping teams on the ball with good practice and good tech!
6: Business Requirement
Left for last not by chance. The business requirement Backlog Item fills the gap where product changes are required but they do not serve any of the platform’s users’ needs. This is really an edge case, examples could include meeting a regulatory need or helping with platform auditing and management (i.e. implementing logging, usage analytics etc.).
Creating Business Requirement backlog items will remove the need for “As a developer” or “As a DPO” type User Stories.
Dreamy, Happy, Backlog Heaven
So there are my “6 Backlog Item Types”. The purpose of each of the types is distinct, but if your team feels there is ambiguity between them or something is missing, then create more. But make sure you create a clear and shared understanding of the differences and document them well!
My experience has shown that the free and whimsical use of the term “user story” has lead to confusion and disenchantment in the product management process and has often produced ill-defined requirements. Making a clear distinctions of work types helps to ensure they are well defined and made ready for work.
Of course, separating your backlog into types if only one small piece of the puzzle. The principle ready is also an important one. Understanding what information a backlog item must contain and what gateways it must have passed before it is included in a sprint is vital to creating a smooth delivery process and consistently creating valuable product increments. Look out for my follow-up article on creating a Definition of Ready!
I hope you have found this article useful. Any constructive feedback is always well received so please do post a comment or chuck a few applause my way!