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 backlog is simply the prioritized collection of work that is remaining on a project. This could be a spreadsheet or table that contains a list of user stories. It could also be a stack of index cards that each holds a unique item of work.
Most of the backlog consists of user stories that implement functionality of benefit to the user. However, other work will be on the backlog as well. Some common examples include:
- User deliverables. Not every item on the product backlog requires software coding. For example, the product owner may want a User Manual, training content, frequently asked questions, etc. If the deliverables are to be created by the project team, the work needs to be prioritized and included in the appropriate iteration.
- 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.
As each iteration begins, a planning meeting is held between the product owner and the project team. The product owner identifies work on the product backlog that he would like completed in the iteration. The project team validates they can complete the work. The mutually agreed upon work is then pulled off the product backlog and implemented during the iteration.
The user stories do not contain a lot of detail. When the story is prioritized for a specific iteration, there should be enough information so that the product owner and team can remember the context and can work together to define the detailed requirements.
In a traditional project, changes to user stories would be added using scope change management. In Agile, the concept of scope creep does not occur during an iteration. The amount of work in an iteration is fixed by the team velocity. If the product owner continues to add new items to the backlog, there may be additional iterations to implement the work. The total number of iterations, and the timeline and budget needed to execute the iterations, is determined by this same product owner.