Create a Product Backlog

17 Jan

The Scrum Guide has a lot to say about the Product Backlog, and rightly so. It’s pivotal to everything a Scrum Team does. But one thing the Scrum Guide doesn’t tell you, is how you create a Product Backlog. So, here’s one way you can do exactly that.

The Product Backlog and the Scrum Guide

You probably already know that the Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any changes to be made to the product. Items in the list are referred to as Product Backlog items and each item has the attributes of a DOVE (Description, Order, Value and Estimate). This information is readily available in the Scrum Guide.

But the Scrum Guide makes no mention of how the Product Backlog is created and there’s a very good reason. The Scrum Guide is a framework and methods of creating a Product Backlog are a technique that you can use on top of that framework. The Scrum Guide leaves it to you to decide what technique you’d like to use.

My Technique for Creating a Product Backlog

There are a number of techniques that you can use to create a Product Backlog. My intention here is not to cover all of them but to introduce just one that, based on my experience, is proven to work well. The technique is a well-known one in the Agile world so you can take comfort from the fact that this is a well trodden path.

“An Agile Coach walked into a room full of developers … “

It sounds like the start of a dubious joke but the first time I saw this technique used was by a really great Agile Coach. Let’s call him Trevor (because I don’t know any coaches called Trevor).  Trevor called a one-day meeting with the Scrum Team and stakeholders. His first action was to advise the meeting that he wanted everybody to think about what was needed in the Product and write each idea down on a single Index Card. One Idea. One card. Simple. He didn’t care how they did it – they could organize and decide that for themselves. He had only one question for them.

How Long do You Need?

Having presented this simple request, Trevor asked the meeting how long they’d need to get this done. One hour came the consensus reply. Trevor started the time-box running. There followed a cacophony of sound as tables were pushed together, chairs pushed aside and Sharpie pens uncapped. Ah! The heady aroma of Sharpie pens … But, I digress. The meeting formed themselves into groups and started writing furiously, unfettered by notions of having to specify exactly what they wanted.

One Hour Later

After an hour, discussions were still being had and people were still writing but Trevor called time and had everyone step away from the Index Cards and pens. We all know that you cannot think of everything up-front and there comes a time where further pondering is of little value. With over 300 ideas on the board, there was more than enough to be getting on with. Trevor asked just one more question.

How Long do you Need to Remove Duplicates?

After some humorous debate, it was agreed that twenty minutes would do it. Trevor set the time-box running again. What I like about this part of the technique is that, if any cliques had formed in the first part of the meeting, they were all brought together in the search for duplicate ideas. Before the time-box expired, the meeting concluded that they’d removed all duplicates.

Which Ideas are Really Valuable?

The next part of the meeting was interesting. Trevor asked for everyone to agree on the top twenty ideas, then accepted the time-box and set the meeting running again. Bedlam. Factions quickly formed over what was considered to be important. Stakeholders in particular can get quite passionate at this stage. In the end, a grudging consensus was reached on twenty four valuable ideas. But rather than forcing the meeting to limit to twenty, Trevor let it go. I learned later that the important part of this section is not that only twenty are chosen. It’s the discussion that people have about the most valuable ideas. It leads to a common understanding of what is wanted.

The Attributes of a DOVE

The next thing that Trevor asked for, was that the top twenty four items each be decorated with a Description of what was wanted, an Order relative to the other items, a business Value and an Estimate. There are different techniques for doing all of these and I’ll cover that in a separate article. The meeting managed this easily within their agreed time-box.

“The Punchline is …”

After six hours, the meeting ended with a well-formed Product Backlog. Twenty four of the items were detailed enough to be taken in to Sprint Planning and the Scrum Team was ready to start work. That Product Backlog served for a project that lasted 18 months.

I’ve seen this technique work for one Scrum Team and I’ve seen it work for ten Scrum Teams. The skill is in keeping it simple and focused. Try it yourself or ask an Agile Coach / Scrum Master to help facilitate it for you.

Trackbacks/Pingbacks

  1. Creating Your Definition of "Done" - Scrum Training for Scrum Masters and Developers - 11 May 2014

    […] preparation, it’s common for scrum teams to go through activities like user story workshops. Creating a product backlog. Estimating. Agreeing business value. Maybe even creating a product vision. There’s usually a […]

  2. Creating Your Definition of "Done" - 14 May 2014

    […] preparation, it’s common for scrum teams to go through activities like user story workshops. Creating a product backlog. Estimating. Agreeing business value. Maybe even creating a product vision. There’s usually a […]

Leave a Reply