If you have ever worked on a project which used Scrum then you may have run into the “blank backlog” issue. Where do we start? Since there are no perfect answers we will need to work this out through experience. I have been using a “Product Backlog filler” exercise with customers which has been refined through these experiences.

When starting a Scrum project it is recommended we begin with a vision. A high level plan of what the product will do from which we can derive a Product Backlog from. I have found that this vision does not have to be written in “stone” (or paper if that is what you use…) but it should be in a form that can be communicated effectively (pictorially on a white board potentially…). A vision is usually followed quite closely by a list of value statements for the consumer of the product. If we can identify the value for our consumers then we have a nice foundation to start driving out user stories from.

In most situations I have found it best to have the Product Owner and ScrumMaster (possibly myself) work on the initial Product Backlog. This allows for a coherent product development story to be constructed before working with the delivery team. This is not a hard and fast rule since I have recently broken this trend because of the project type and delivery team experience with Scrum. When we have a list of product consumer value phrases created I will place these on a white board or visualization instrument (easel pad, index cards taped on a wall, etc…). We then ask the question “Who wants and supports these value statements?”. This creates a discussion of potential roles and parties to the product being developed along with defining their characteristics. While listing out these roles and parties we may generate some that are not valid or can be merged into a more suitable description. This is great since the discussion will then better define the role and party boundaries.

After this discussion of the roles and parties either attaining or supporting the value statements, we can start to work on the “goals” which will give them the list of values stated. This will usually start with a value to be achieved and a role or party that is interested in this value from the product. Once we decide on these then it is just a matter of writing as many “goals” as possible to make this happen in the product. I use the term “goal” as it is identified in the User Story template by Mike Cohn:

As a <user>, I want to <goal> in order to <value>

Where is one of our value statements identified from the vision, is the role or party identified to attain or support the value statement, and is the list of features which will achieve the value statements for our identified roles and parties. Now that we have all three parts of the User Story template we can write out the actual user stories and put them into our Product Backlog to start a “good” conversation with the delivery team.

In this blog entry I have identified one method for driving out user stories for a Product Backlog which I have found to be useful. There are many other methods which achieve the same goal. I suggest that anybody using Scrum should take a look at how user stories can be used as a powerful way to capture features to be developed in their products. The template developed by Mike Cohn for user stories has been quite powerful in projects I have been involved with and is further explained in his books “User Stories Applied” and “Agile Estimating and Planning”. Take a look at these for more information and other supporting methods for developing products through the user story medium.

Be Sociable, Share!

• 
•