Agile101 – Use the Product Backlog to Hold Work
Agile101 – Use the Product Backlog to Hold Work
In an Agile project you don’t create large documents to hold user requirements. In fact you don’t need a traditional document at all. The Agile technique is to create a product backlog. The backlog is simply the prioritized collection of work that is remaining on a project. This could be a spreadsheet or table. It could also be a stack of index cards that each holds a unique item of work. It could also be in an Agile software tool.
The initial product backlog is generated at the start of an Agile project. It consists of all easily identified work that is known when the project starts. The following types of work are placed on the backlog.
User stories. User stories describe how stakeholders, or actors, interact to do something of value. These stories are a few sentences, or perhaps a paragraph. They are just detailed enough so that the product owner remembers what the scenario is, and can provide detailed requirements when the user story is worked on by the team.
Standalone deliverables. The product owner and Agile team may need standalone deliverables created on the project. For example, the product owner may need the team to create a user manual, training content, frequently asked questions, etc. The project team may need a disaster recovery manual and a records retention document. This work needs to be prioritized on the backlog and included in the appropriate iteration. You don’t need a user story to explain these types of deliverables – just put them on the backlog.
Defects and bug fixes. Many bugs that slip through testing are really more nuisances than severe errors. They need to be fixed but there is discretion as to the timing of the fixes. These types of fixes can be placed on the backlog and prioritized in a subsequent iteration. In some cases, the team will wait until the end of the project for one final cleanup of bugs and errors.
Non-functional requirements. User stories are great to describe processes, and how different actors interact to accomplish some work. However, other requirements may be more descriptive rather than process oriented. These are called non-functional requirements. For example, if your project is to build a chair, we would need information on weight, size, color, etc. You don’t need a user story to explain the color of the chair – just list it.
As each iteration begins, a planning meeting is held between the product owner and the project team. The product owner prioritizes work on the backlog. The team estimates the size of each element on the backlog, and pulls off only enough backlog elements that can be completed in the next iteration. This subset is referred to as an iteration backlog.
In a traditional project, changes to product backlog would be added using scope change management. In Agile, there are no formal scope change requests. The work in an iteration is fixed. The product owner can continue to add and prioritize new items in the full product backlog. This may result in additional iterations. It is also likely the some of the lower priority iterations will not be completed. The total number of iterations, and the timeline and budget needed to execute the iterations, is determined by this same product owner.
