Misconceptions about the Product Backlog
There are a lot of misconceptions about the Product Backlog. In fact, I would say it is probably the least understood artefact of Scrum. Getting it wrong can cause big problems, not just for your product and its roadmap, but for your developers too. Being a product owner is a hard job, and easy to get wrong. This article will dispel some of the misconceptions about the product backlog.
The Product Backlog is not a giant list of stories
A lot of people think the product backlog is basically a big list of user stories, ranked in order, from highest to lowest priority. Like if you had a big spreadsheet, and every row in the spreadsheet was a user story, with an identifier, a name, and a description, And that’s your backlog.
This seems nice and simple, but it is a terrible product backlog, for a number of reasons:
- the stories aren’t related to each other in any meaningful way
- the stories are not only unrelated to each other but they are not related to any particular horizon or release
- there is no explanation of the “bigger picture” of how the stories relate to the product, its features and its vision.
A product backlog is really a roadmap
A good product backlog begins with a roadmap, which is a very high-level view of the future of the product. There is obviously a lot we don’t know at the beginning, but a product owner should start with a roadmap and a vision of how the product might evolve. And then start breaking that roadmap down into features or epics, and releases or horizons. This lets you:
- relate stories to each other, via a feature or epic
- map dependencies between stories
- define the features and epics, and what value they provide and why you are building them.
Features and epics can go in the backlog. And they can have their own description, value, risk, benefits, dependencies and acceptance criteria defined. They can be assessed and prioritised, All of this provides the “bigger picture”. If you just have a list of stories, then as someone once said, you have “a bag of leaves, instead of a tree”.
A product backlog should be a tree, not a bag of leaves
So you do want stories in your backlog, but you want other things too. And you want the stories to flow on from those other things. The stories go in last, not first. So if you want a tree:
- start with a product vision and a roadmap
- break that down into features and epics
- map the features and epics into horizons or releases
- then break them down into user stories.
This is a big topic and deserves a lot more coverage. I would recommend you read User Story Mapping by Jeff Patton if you want to know more.
You don’t need to estimate all the stories in the backlog
Some people think you need to have estimates on everything in the backlog because otherwise, they are not ready to be worked on. That is, they do not meet your Definition of Ready. And while having some stories ready to pick up is good, you don’t need everything in the backlog ready to be picked up. The fact is, some of the things in the backlog might not be worked on for a long time. Some of them might never be worked on. And that’s ok.
Remember, your backlog is fundamentally waste. To be more specific, it is the “Inventory” type of waste in Lean Manufacturing. It is a stockpile of stuff, sitting around. Not doing anything, not going anywhere, not adding any value. You can spend a lot of time building and defining and estimating a huge backlog of scope. Or you can spend time actually doing work. That is, actually building software.
Get the balance right
So there is a balance, and getting the balance right is tricky. If you don’t estimate anything, you don’t know how long it will take to build anything. If you estimate everything, it’s a lot of work. I think it’s good to use an “n+1” or “n+2” system, where you have the next one or two sprints of work well defined and estimated and ready to pick up. So if you go into sprint planning, you can have a forward view of where you are going to be. And if things chop and change and you decide to pull something else out of the backlog that is a bit further back, you can do so. But you don’t spend 90% of your time in planning and estimation.
This is complex and probably needs its own blog post with a snazzy infographic, which I might do someday if I feel a bit more artistic and creative.
But how do we do release planning if we have unestimated stories?
People get worked up over this, but it is very simple. You can just use averages. So you have the next one or two sprints of stories estimated, and for the remainder of your backlog, you can just use average story points (for that team) for each story. So you have 50 points of stories in your next two sprints, with an average of 6.2 points (it probably won’t be a Fibonacci number, that’s fine). You have another 30 stories in your backlog. So your backlog size is 186 (6.2 times 30) plus 50 (your estimated sprints) for a total of 236. See? Easy.
The truth is, some stories will turn out to be larger than the average, and some will turn out to be smaller, and that’s fine. Sometimes your velocity will be higher, sometimes it will be lower, and that’s fine. If you can, try to get the team to try and break stories into similar sizes, so everything is close to a 5 or 8. It makes this simpler and more accurate. You can even do rough estimates for features where you haven’t even broken them up into stories, but using feature-level estimates, or using an average number of stories per feature and multiplying that out.
And remember, estimation isn’t that valuable in the first place. Don’t spend too much time on it. Because the uncertainties of benefits are higher than the uncertainties of costs.
You shouldn’t put every idea you can think of in the backlog
Some product owners go a bit crazy when they go to Agile, and go “wow I can put anything I want in here! Amazing!”. And spend the next 20 days stuffing the backlog full of random bits and pieces, like kids in a candy store.
This is not a good practice. Remember, backlog items are a form of waste. You want a clear roadmap and a vision for your product, not a big random laundry list of “stuff that might be cool”. The backlog should reflect your product vision and strategy. It should be able to accommodate changes but don’t overdo it and overthink it. Focus on your current sprint and the next couple of sprints. Trying to think hard about much further than that is pure speculation and not valuable.
You can also remove things from the backlog
Some people think that once something goes in the backlog, it can never come out. They might think “what would be the point of removing something in the backlog? It’s just an idea, it’s just a potential scope item. We might never build it, but there’s no harm having it in there”. There is, it is waste. It confuses things and muddies the waters.
Again, the backlog is not a laundry list, it is a roadmap of features against releases and reflects a product vision and strategy. Keep it tight and clean and up to date. Do not be afraid of deleting things. If you really want to go back to it later, you can probably dig it up or think through it again (things may have changed so that might not be a bad thing anyway).
The developers should have a say in the backlog
Some people think the product backlog is exclusively the domain of the product owner. And that is partially true, but not quite right. The product owner has say over what goes in it and in what order. They are responsible and accountable for the product backlog. And generally, the developers look after the sprint backlog, since that is their domain. They are building the scope that goes into the sprint. But a wise product owner always talks to the team as they build up and manage the backlog.
The developers understand the technical space of the product. They understand what other teams are working on and what new technologies are coming along (well, they should). They understand the technical risks and dependencies of the work. So discussing the product backlog with them is extremely important.
Sprint planning should be a “no surprises” environment. Nobody should stick their hands up when they a backlog item and say “what the hell is that? I have no idea what that even means”. Sprint planning should be about deciding on which well-defined and understood scope items the team is prepared to move into the sprint.
I hope this article clears up some misconceptions about the product backlog! This is a big and quite difficult subject and there is a lot more reading you can do if you are interested in this area.
