Ready Backlog

January 6th

This is pretty much the single most important thing to do. No, really — this is what makes all the difference. It’s about creating business value, team efficiency, motivation, everything.

So — what is a ”ready backlog“, anyway? It’s a backlog that is …

  • well prioritized — most (business) valuable user stories up top
  • regularly refined — shared understanding across the team
  • thoroughly reviewed — transparent to stakeholders and kept up-to-date regarding new insights
  • ready — as in: the upcoming user stories meet the Definition of Ready (you have one, right?)

All this requires the product owner to have the authority to develop a compelling product vision and make decisions without constantly having to ask someones permission.

Well Prioritized

The good thing about a backlog is the fact that it’s a linear list of user stories. There is no way that two stories share the same priority. There needs to be a decision which one ranks before the other. But how do you make that decision?

Well, entire books have been written about this, but I guess it boils down to the balance between effort (story points) and (business) value. It’s the product owner’s job to deliver as much business value as possible with the least effort. Easy, right?

There are plenty of ways to quantify business value: story points, casino chips, actual money, you name it. Just make sure that you calculate the ratio: a user story that delivers 40 story points of business value and has 5 story points of effort seems like a pretty good deal. The fancy feature that is all the rage might have 40 business value points as well, but if the effort came in at 100 story points of effort, there might be value in doing the other story first. Like always: your mileage may vary and nothing is just black and white. But still.

Do you quantify business value?

Regularly refined

Even the most compelling product vision doesn’t get you started without a shared understanding across the team. The idea behind the backlog refinement event in Scrum is that the product owner discusses the backlog items with the team, gathers feedback and creates a shared understanding that no documentation in the world could ever deliver.

It’s not necessary to refine the whole backlog all the time. A balanced backlog looks something like this:

Ready Backlog

Based on Definition of Ready | Scrum Inc.

Notice how the top of the backlog is refined in greater detail, while the items further down the road are pretty rough.

Why should it be like that? It’s pretty likely that there will be a lot of reprioritization and new learnings as time goes by. So there is no value in refining something that might never happen. It would even be a lot of waste.

Thoroughly reviewed

I’ve had a project once, where everything was going well. Good backlog, great refinement sessions, we were responding to change like a chameleon to a tv screen. We were glad how well we applied the agile values to our work. Until the the day when the client realized that quite a few things that he was expecting at launch day might not make it.

We had forgotten to share our change of plans with the stakeholders. Whoops. Some more refinement had to be done that day.

So — when you conduct a sprint review, don’t just talk about what has been done. Share your plans for the upcoming sprints with the stakeholders (not only in sprint review) and see which new insights might affect those plans and how.

Ready

This is the part that has – in my experience – the highest impact on efficiency during the sprint and therefore on velocity. So what does ready mean?

That depends on the context you’re in. In the context I find myself in a lot it means:

  • it meets the INVEST criteria
  • the product owner has developed a shared understanding with the team
  • the story is estimated (story points)
  • there are no external dependencies that could prevent the team from resolving the story
  • needed artifacts (sketches, wireframes, designs, you name it) are readily available

It helps to write this down as the Definition of Ready. It’s a handy checklist for the product owner to be sure the team can focus on the work. Instead of gathering all the missing information during sprint.

The Definition of Ready should be a living document. Whenever you identify something that can be improved within the process of sprint preparation, extend it.

Do you use a Definition of Ready?

And do yourself a favor: have a great backlog refinement meeting so that your sprint planning can be short and sweet. It’s pretty demotivating for everybody when you start off your sprint with an endless planning meeting. The shared understanding should already be created. Some minor adjustments might take place, but overall it’s just what you already talked about in prior refinement sessions. That way everybody can kick-off the sprint energized with a spirit of getting stuff done.

So, is your backlog ready?

comments powered by Disqus