Remember: DEEP

Remember: DEEP

I like to describe the product backlog in Agile projects as the hub from which all other activities spring.  The backlog encompasses more than just the features that the project will deliver. The backlog includes features, bugs. technical work and research. As with many agile tools and techniques, despite the power and importance of the backlog, the life cycle of project backlog items included in the backlog is fairly simple and straightforward.  The backlog is a list of work items that are prioritized and accepted into a sprint. The team breaks the items down into tasks and activities for the sprint backlog and then demonstrates or reviews the completed items at the end of the sprint. Work that was not accepted, incomplete work items and new work items are added (or re-added) to the backlog.  The backlog is continually groomed and prioritized.

Backlog items include:

  1. Features – The functionality delivered by the project is identified in the list of features on the product backlog.
  2. Bugs – You need to capture defects when they are identified so the team can allocate effort to fixing them. Note: Defects that can be correct on the spot are probably not worth the overhead of tracking.
  3. Technical Work – Non-functional work items make up substantial portions of many projects.  Non-functional work can range from network changes to application architecture changes.
  4. Knowledge Acquisition – Research is an occasional, but important feature in many projects.  Teams need to set aside time to determine solutions, explore an idea and/or learn a new process or tool.  We have explored the concept of spikes (a specific quantity of time set aside to develop an answer) as one mechanism for knowledge acquisition.

The items on the product backlog must include all of the items a team will work on during the project. All the items on the backlog can and should be described using  a user story because it makes the team go through the discipline of determining who will be affected, by what and the value of the work item. While the product backlog includes the overall requirements, backlog items don’t become truly operationalized until they are accepted into sprint planning and broken down into tasks and activities.

Roman Pitchler and Mike Cohn (and many others) have described four attributes of a good product backlog.

  • Detailed Appropriately – Backlog items that are to be done soon needed to be understood and granular enough to be completed in a single upcoming sprint (the sprint should be upcoming very soon). Those that will be worked until later in the project don’t need to be as well understood.
  • Estimated – Each backlog item should be estimated.  The level of precision of the estimate for any item will vary based on the how soon the work items will be completed. Estimates are useful as a trigger to break work items down and as an input into prioritization.
  • Emergent – The backlog will evolve and change over the life project.  Backlog items will be added, completed, split, changed, deleted base on the feedback the team gathers as they learn and deliver value.
  • Prioritized – The work items that are the highest value or need to be done first need to at the top of the backlog. The product owner with the support of the team owns the prioritization process.

The DEEP mnemonic gives the discussion backlogs a metaphysical feel. More importantly it provides the team with a reminder that in Agile, gone are the days of the big requirements document that acts as a contract to drive development. Backlogs, however, are more than of a to-do list that acts as the central planning tool for Agile projects.