Give Life to Your Product Backlog

A common perception when working in Agile is, "Welcome changes over following a plan." In the Agile Manifesto, however, the phrases "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage" still mean you need a plan to begin with.

How can we express the product backlog so that we can easily provide enough planning information to management without compromising on Agile principles?

A "flat" product backlog

Your first-ever product backlog may be a flat one, typically a list in a spread sheet. "Flat" refers to the product backlog's representation as a list. Another way to view this would be to use Mike Cohn's iceberg picture (page 19):

Figure 1: The product backlog iceberg, by Mike Cohn

As you can see, once stored in a spreadsheet, this is "flat."

Pros: It's easy to create and maintain, especially when you're new to Scrum.

Cons: Management — and the team — may want to see how this product is planning out beyond the coming sprint.

A mind map

This is a nice, easy way to express a product backlog, and it's helpful for breaking stories down without losing context. I have used it and seen it used as an effective tool for building product backlogs for complex products (and complex scenarios with multiple paths).

Explained in Amit Rathore's blog, it looks like this:

Figure 2: Product backlog as a mind map

Each leaf is a user story, and you can see in the example that leaves can be (very) small and still follow the INVEST model of good user stories.

Another way, still using a mind map, is called "effect mapping." I encourage watching this video for an explanation.

Pros: It's easy to use and helps create small user stories, and it works well with teams that are becoming more and more productive (being able to quickly break down stories into very small stories).

Cons: It's a bit difficult to see how the product is being built; you can get lost in the tree (although tools such as FreeMind let you apply filters).

User story mapping

I've used this idea, introduced by Jeff Patton, in this way: With the team, we look at the big features to build (that may include architecture work). Normally the team has a pretty good idea how to build the product for the next two to four sprints and can come up with small user stories/features. After that, user stories can be of different sizes, and spikes are required. We map them out on the wall with big features on top. Then, on the first line, are the user stories to be implemented now; next line below, user stories that have lower priority but still for the near future; next line are user stories with less priority. And so on; of course, this map constantly evolves as the team learns more about the product. So this is more mapping than a "map."

Figure 3: User story mapping

Another mapping method I like to look at is user story mapping.

Pros: This method is easy to use and makes it easy to think about the product as a whole. It makes you think about the big picture and how the team is going to build the product — and it helps the team interact more, because they can see and discuss how to build the product. This is a highly collaborative product backlog.

Cons: Our minds aren't geared to see timelines as rows; it might be a bit more difficult to see what will be in the coming sprint(s), although I suspect you can easily adapt and designate "row 1" for the next 3 sprints, "row 2" following 3 sprints, and so on. This assumes we know the velocity of the team. (Note: Be careful that the team builds the map and grooms it — this mustn't become a management planning tool).

Rolling-release look-ahead mapping

Whether your company has started its Agile transformation or is already scaling Scrums — or even if this is a small, isolated project— at some point you will be asked for a "plan." And as teams gain more experience in using Scrum, continuously improving, they're getting good at planning and are able to convey useful information that they use to improve themselves as well as their communication with the business, while keeping to Agile values and principles.

"How are we building your product?" "What can we expect to see in the next three sprints and for the next three to six months?" "Are we providing a visual and collaborative way of discussing the product backlog, taking into account priorities and timelines?" All of the above techniques can be used to answer these questions, but, visually, this might be not too obvious and it may take some time for people to understand how you're building your product.

This becomes more important when teams are working on the same product and release planning is being used to synchronize teams' work. For instance, with my team, we created a normal user story map but, because of release planning across lots of teams, we had to map out our next three sprints. So we simply reordered our stickers from a vertical view to a horizontal view and ended up with a product backlog that looked like this:

Figure 4: Rolling-release look-ahead planning

Pros: This gives an idea of how you're building the product, and it gets the team focused on what's going to be the goal of the next three sprints. After that, it gives a rough (but still accurate) idea of what's going to happen. Such a picture generates more feedback (hence more life). It can help represent the architecture runway (or the systems you're building). It's easy to use user story mapping initially and then move to horizontal user story mapping.

Cons: There is a risk that management will want you to map out the whole product backlog per sprint or take the plan as a commitment. This becomes less true as management understands Scrum better, but be careful. The right tools in the wrong hands are as problematic as the wrong tools in the wrong hands.

Note: The question marks indicate that this is our best guest from the information we have now; this is just a plan.

Conclusion

As teams become more and more mature and more effective at using Scrum, product backlogs should provide more and more visual, accurate information. This will enable more collaboration and feedback (either technical or from the business side). It will also help the team follow more accurate plans, while making planning itself more effective.