Starting with Scrum: 2 - The Birth of the Backlog

This is the second article in the 'Starting with Scrum' series. In the first article we discussed how to get started with Scrum by determining what the Product Goal is. In this article we pick up where we left off, and focus on the next step: building the very first iteration of the backlog.

Want to read the full Series? See here for the link to: Article 1, Article 3

The Backlog

With a clear Product Goal, the next step is to make it accessible and visual for everyone. We do this by creating a Product Backlog. The Product Backlog (also known as scrum artifact) is very functionally defined as: 

An emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.
– Scrum Guide

But what I find much more interesting in the context of this article is how the Product Backlog can be seen as the deliverable (artifact) that demonstrates a commitment to the Product Goal:

The Product Goal describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. The rest of the Product Backlog emerges to define “what” will fulfill the Product Goal.
– Scrum Guide

In our case, having just had the Product Goal workshop, this is where the fun begins because the items that ended up on the whiteboard during the workshop are more or less our main “epics”! Who would have thought it could be so easy?

Of course, the Product Goal workshop will usually focus on the most important aspects, the value proposition, and ignore the simple things – stuff like what to do with privacy, user management, and so forth. This is a good time to think about those.

To find out what is missing, I’ll usually start a second workshop right away to profit from the thrill of the Product Goal workshop. I’ll ask the team to think about what is missing. For this I like to use a simple liberating structure called 1–2–4-all, a technique that helps muster the thoughts of all team members and boosts creativity by getting team members to discuss ideas with each other.

I’ll do my best to present this as a game. I will encourage the team to try to come up with anything that might be remotely useful – the sky's the limit! Whether we end up actually doing it is a completely different question, one that is not important at this stage. The goal is to create an exhaustive picture of what needs to happen. 

This will usually result in a lot of hilarity, with the most amazing and crazy ideas, but it also seems to be a very effective way of getting the creative juices going. By the end of the workshop the team will usually have a very complete picture of what needs to be done.

Rough High-level Guestimation

Once we have the complete list of items, it is time to estimate them. Depending on the maturity of the team, I will take one of two approaches:

1. With a mature team, we will be comfortable estimating in story points, or in sprints if we go beyond a certain maximum, typically our average velocity.
   
   
2. With a less mature team, I will ask them to name the easiest thing on the list and call that “1”. Then I’ll ask them to sort the rest of the stories into “2” – twice the amount of work, “3” – three times the amount of work, and so on. When we are ready, I will ask them to estimate the “1” in story points. Then I’ll go off and extrapolate that for all the other items.

Often the first reaction of less mature teams at this point will be that there is not enough information to estimate. This is often a moment of stress in which all the misconceptions and bad experiences with estimates will come back; for example, the popular exercise of secretly converting estimates to deadlines. This is a critical moment in which you need to help the team feel safe. Get them over this threshold and estimation will be a breeze from then on. Two things I often find work very well are:

• Explain very clearly to the team that the purpose of the rough estimates is purely for the sake of initial prioritization and that there will be ample time to review and improve the estimates later.
• Explain that the goal of the rough estimates is not to create a timeline or a set of deadlines, but to visualize the complexity and uncertainty in order to be able to deal with it empirically and manage risks.
• Use bucket estimation: Set up a table with the Fibonacci sequences in the title row, and ask the team to individually move the items to the columns in the table. Making it feel like a game will automatically create a sense of safety.

An Error Margin for our Estimates 

Once we have the first set of estimates, I will ask the team for a worst-case scenario estimate. This will usually turn into a fun activity where people get creative with everything that could go wrong. And that’s fine, because again, fun is essential for the creative process. After all, estimating is primarily a creative process where the team must create a mental picture of themselves doing the work. The fact that the team might seem to get a bit carried away is not a problem, because no matter how mature a Scrum Team is, there is always a tendency to underestimate the amount of work involved.

Worst-case estimates give an indication of the uncertainty of each epic, but can also be used to generate an error margin for the whole project. Basically, for each epic, find the difference between the worst-case estimate and the regular estimate, square it, add all the squares of all the epics together, and take the root. That is the error margin for the project as a whole. Together with the sum of the regular estimates, you end up with a range in which the project can be reasonably delivered.

And that’s it! There you have it, the first step in creating the backlog! The first iteration of many to come, witness the birth of a backlog.

Conclusion

If anything, I hope that this article shows that a backlog doesn’t have to be complicated. It is just a way to help us oversee what we are getting ourselves into. With this approach we make creating the backlog an iterative game where we work with the knowledge at hand. That way we remove the usual stress when trying to work out exhaustive requirements. And we put the focus on the uncertainty: with the error margin we make the uncertainty visible and the conversation automatically changes from one about deadlines to one about forecasts.

For me, there are two things I value most about this approach.

First of all, it makes the backlog a joint responsibility of the whole Scrum Team. The PO may be accountable, but this is in the true sense of the word: The PO is the one to explain the backlog and the decisions that the team makes to stakeholders, but the responsibility is shared. Ownership of the complete project belongs to the whole team.

Second, it keeps everyone focused on the high-level approach. It seems to be human nature to dive into the details; it is an urge that is hard to dissuade, a bit like trying to keep bears away from honey. Focusing on individual stories, especially using a tool like Jira, encourages this behavior. We open a story and are automatically drawn down the rabbit hole: is it a good user story? Is it an epic? What are the acceptance criteria? Requirements? Is it valuable? What is the priority? What is the solution? How does it relate to other stories? 

It is exhausting. And terribly inefficient. But it also seems to be human nature, in the sense that it is the default behavior I see. The challenge therefore is that it is so ingrained that rationalizing it is not enough. This high level approach offers a way of looking at the work in such a way that it keeps the details out of sight. Having been a programmer myself, I remember this is something I had to learn consciously myself, to stay put on the desired level of detail.

With the backlog in hand, the PO can go off and figure out priorities. Some priorities will have been discussed during the initial kick-off workshop, but having estimates and some idea of the risk involved will help make the harder decisions. Whatever the case may be, with the estimates the PO has the necessary tools to translate the backlog into a roadmap.

With the roadmap the team can focus on breaking down the first item, the epic at the top of the backlog, creating the first user stories. The first “proper” backlog refinement, so to speak.

That will be the subject of the next installment in this series.