Agile101 – Use the Product Backlog to Hold Work

A well-prioritized agile backlog not only makes release and iteration planning easier, it broadcasts all the things your team intends to spend time on—including internal work that the customer will never notice.

“Here's the TenStep guest blog post "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 preferred 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 that contains a list of user stories. It could also be a stack of index cards that each holds a unique item of work.

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. 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. This includes.

  • 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.
  • IT deliverables. These are deliverables that are required by the IT organization. This might include a Disaster Recovery Manual, records retention document, change control documentation, etc. Some of these may have value to the user, but sometimes they are required for the IT organization.
  • 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.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>