What are some techniques you have found helpful to create an initial backlog?
Published on AgileConnection (https://www.agileconnection.com)

Home > What are some techniques you have found helpful to create an initial backlog?
Kent J. McDonald's picture

What are some techniques you have found helpful to create an initial backlog?

I'm looking to hear about people's experience with different ways of creating a backlog that is more than just a list of stories and does not cause the team to lose the forest in the trees.

Millard Ellingsworth's picture

Presuming you have a product vision of some sort, "story storming" (brainstorming about stories) is a good way to build a backlog of things people want. The more cross-functional participants involved the better. It will likely start as "just a bunch of stories", but you are just starting and you need something to work with (right?). Progressive refinement is a good strategy for evolving that sack of stories into a worthy product backlog.

Then your stakeholders (from all groups) and Product Owner can start to prioritize which functionality should be completed first. You can think of your backlog as being in three segments: actionable, emerging and stuff (those terms may be mine but the idea has been around). Stories that clearly need to be done first need to be fleshed out into an actionable state -- explained to a level that successful implementation is possible (however you define "done"). You want want to spend the time to get the entire backlog in that shape at once -- it's not necessary and you have enough to work on.

Emerging stories are the next tier of requirements and need to be moved into an actionable state before the current set of actionable stories is exhausted. Of course, all the time, people are adding things to the backlog and changing priorities of items, so backlog grooming is a good practice to get into. The other stories survived to make the backlog but may or may not ever get shipped. Don't waste time on them until they start to look more important.

Mike Cohn did a nice piece on progressive refinement of your product backlog on developerWorks very recently: http://www.ibm.com/developerworks/rational/library/user-stories-product-...

I have a piece linked in the Resources section on how to cutomize Rational Team Concert to help manage this process. http://www.ibm.com/developerworks/rational/library/sprint-with-rational-...

 

Skip Pletcher's picture

Assuming the question refers to product backlog,

We begin with a standard backlog which is basically three unknowns:

  • What is the problem/opportunity?
  • What might be a solution/exploit?
  • How would we deliver that?

This distinguishes work in the problem domain, solution domain, and project domain.  The team tackles all three and in the process begins to define items which more fully populate the backlog.

The challenge is in recognizing the right level of detail amid the great uncertainty of getting started.  We want items which are valuable for planning/valuing/sizing but not so granular as to make the overall set unwieldy.  These are 'planning work items' which are probably going to be subdivided at some time in the future into chunks which better map into the team's velocity.  

 

Venkatesh Krishnamurthy's picture

1. Open Space

2. Assumptions and Questions exercise

 

Above techniques should be used with all the relevant stakeholders in place

3 Answers

Venkatesh Krishnamurthy's picture

1. Open Space

2. Assumptions and Questions exercise

 

Above techniques should be used with all the relevant stakeholders in place

Skip Pletcher's picture

Assuming the question refers to product backlog,

We begin with a standard backlog which is basically three unknowns:

  • What is the problem/opportunity?
  • What might be a solution/exploit?
  • How would we deliver that?

This distinguishes work in the problem domain, solution domain, and project domain.  The team tackles all three and in the process begins to define items which more fully populate the backlog.

The challenge is in recognizing the right level of detail amid the great uncertainty of getting started.  We want items which are valuable for planning/valuing/sizing but not so granular as to make the overall set unwieldy.  These are 'planning work items' which are probably going to be subdivided at some time in the future into chunks which better map into the team's velocity.  

 

Millard Ellingsworth's picture

Presuming you have a product vision of some sort, "story storming" (brainstorming about stories) is a good way to build a backlog of things people want. The more cross-functional participants involved the better. It will likely start as "just a bunch of stories", but you are just starting and you need something to work with (right?). Progressive refinement is a good strategy for evolving that sack of stories into a worthy product backlog.

Then your stakeholders (from all groups) and Product Owner can start to prioritize which functionality should be completed first. You can think of your backlog as being in three segments: actionable, emerging and stuff (those terms may be mine but the idea has been around). Stories that clearly need to be done first need to be fleshed out into an actionable state -- explained to a level that successful implementation is possible (however you define "done"). You want want to spend the time to get the entire backlog in that shape at once -- it's not necessary and you have enough to work on.

Emerging stories are the next tier of requirements and need to be moved into an actionable state before the current set of actionable stories is exhausted. Of course, all the time, people are adding things to the backlog and changing priorities of items, so backlog grooming is a good practice to get into. The other stories survived to make the backlog but may or may not ever get shipped. Don't waste time on them until they start to look more important.

Mike Cohn did a nice piece on progressive refinement of your product backlog on developerWorks very recently: http://www.ibm.com/developerworks/rational/library/user-stories-product-...

I have a piece linked in the Resources section on how to cutomize Rational Team Concert to help manage this process. http://www.ibm.com/developerworks/rational/library/sprint-with-rational-...

 
©2011-2013 TechWell Corp.