Creating the Product Backlog

///Creating the Product Backlog

Creating the Product Backlog

Traditional requirements gathering techniques focus on obtaining the maximum amount of information from as wide a user base as possible early in the project lifecycle. The  more effort we put into gathering requirements upfront, the more likely we are to build what the customer will want, right ? Well, this approach makes a number of assumptions :

  • We can have perfect knowledge of what the end user may want by putting more effort in at the requirements stage.
  • The requirements that may be made 6 -12 months in advance are going to remain valid and accurate till the project goes live.
  • Market, business and technology factors will remain unchanged during the lifecycle of the project.

As you can probably tell, these assumptions are not justified. In reality, we should expect change to occur across the people, process and technology spectrum. We are also unlikely to be able to anticipate user needs far in advance. For this reason most Agile methodologies of frameworks recommend ‘Just In Time’ planning.

Traditional requirements gathering techniques focus on obtaining the maximum amount of information from as wide a user base as possible early in the project lifecycle. The idea being the more effort we put into gathering the requirements upfront the more likely we are to build what the customer will want. This approach makes a number of assumptions :

  • We can have perfect knowledge of what the end user may want by putting more effort in at the requirements stage.
  • The requirements that may be made 6 -12 months in advance are going to remain valid and accurate till the project goes live.
  • Market, Business and technology factors will remain unchanged during the lifecycle of the project.

In reality agile says that we should expect change to occur across the People, Process, Technology spectrum, additionally we are unlikely to be able to anticipate user needs far in advance. For this reason most agile processes recommend ‘Just In Time’ Planning.

A Change in Format

Instead of a lengthy requirements document, we write them as ‘User Stories’ in the form of a short paragraph describing the purpose of the functionality and the user role impacted by that functionality and the benefit derived from the implementation of that story.

The collection of stories will likely be in varying sizes and will form what is known as the ‘Product Backlog’ – essentially an ordered list of requirements that can be added to, deleted from, and re-prioritised at each sprint. This gives us the flexibility to add, remove and re-prioritise important features for the business.

Product Backlog

 

 

 

Product Backlog Iceberg

So that we do not have a huge backlog with thousands of items we use the metaphor of an iceberg to describe the size and shape of the backlog stories. Smaller stories are at the top, with larger stories towards the bottom of the backlog. It looks something like this :

Iceberg

We keep the stories larger at the bottom of the backlog not just so that we do not end up with an unmanageable backlog in terms of size, but so that when we break them up closer to the time of implementation, we are in a much better position to ‘progressively refine’ the stories with the most up-to date information reducing the possibility of changing requirements.

Once you split up a large story, frequently referred to as an ‘Epic’ story, into something smaller, if you do not need trace-ability then it is best to delete or get rid of the Epic. If you feel that you need to understand the context of the stories and how they fit together, a ‘Story Map’, may be the best way to manage context. This would be in addition to the backlog, and useful during backlog re-prioritisation and during Release and Sprint planning.

Product Backlogs should be DEEP

Mike Cohn in ‘Succeeding with Agile’, and Roman Pichler in ‘Agile Product Management with Scrum’ say that the backlog should be ‘DEEP’ which stands for :

Detailed Appropriately : Too much detail too far in advance and it can become invalid, change or lose relevance. Too little and you may miss out on important details, see Introduction to User Stories, for more on this.

Estimated : The Product Backlog should be estimated. The further down the backlog, the less effort will we put into estimation and so will be likely be given orders of magnitude estimates only.

Emergent : The Product Backlog is constantly being ‘refined’ and updated. The backlog gradually ‘emerges’, stories are split and clarified and have their acceptance criteria added.

Prioritised : The Product Backlog should have a clear order in which the stories are to be tackled, these may change and be updated over time. The priority of the backlog stories should depend upon :

  • The business value derived from that story or feature and the risk profile of that story.
  • Estimate, size or cost of the story.
By |2017-09-16T11:08:17+00:00June 5th, 2016|Agile, Scrum|