The product roadmap is a high-level vision for where you want your product to go. The product backlog follows up on the roadmap by serving as a list of features and requirements that help shape the product goal. Mike Griffiths (2012) defines the product backlog as “the ordered list of everything that might be needed for the product” (PMI-ACP Exam Prep, p. 38) and lists several categories of items typically found in a product backlog, including features to be built, functions, requirements, quality attributes, enhancements, and fixes. Building and maintaining the product backlog is key to realizing the high-level project goal, and takes the combined effort of the product owner, development team, and ScrumMaster. In this blog post, we will look further at how the product backlog fits into an agile project and how to successfully create and maintain it.

The Agile project team uses the product backlog to take the roadmap’s high-level vision and produce features and requirements, which end up as themes, epics, and user stories. The product owner helps prioritize the product backlog, and the highest-priority items typically receive more detail from themes (very high-level common functionality, such as the frontend of a website) and epics (high-level, very large user stories, such as an entire section of a website) to become user stories. A user story is a piece of functionality that is independent, negotiable, valuable, estimable, small, and testable (recall the “INVEST” model).

As items rise in priority, the product owner works with the development team to break the items into user stories. From there, the team chooses the highest-priority items to define their sprint goal for sprint backlogs. As the project progresses, the product owner continues to prioritize features and requirements based on changes, and the development team continues to refine estimates as their work continues. In addition to user stories and the items described previously, the product backlog also stores any modification requests, bugs, and defects.

Some of the best practices with the product backlog include making sure that the product backlog is groomed, that it is communicated well, that the granularity of detail increases as items go from the product backlog to release and iteration backlogs, and that the product backlog does not contain too many items that do not add value to the project. Below, we will describe each of these in more detail.

Best Practices

1. Make sure the product backlog is groomed.

Griffiths (2012) defines “grooming” as “adding more detail and order to the backlog and refining the estimates of the backlog items” (PMI-ACP Exam Prep, p. 38). Each of these activities is a distinct, yet important, part of the grooming process, and each activity is likely to involve different team members. Typically, the product owner will add more details and refine priorities, while the development team is usually the best source of refined estimates, since they are performing the work.

It is important that both parts of the team perform their grooming activities. Failure to groom the product backlog is a pitfall because the backlog will quickly become obsolete and will not reflect the latest status of the project.

2. Make sure the product backlog is visible.

One key component of Agile is clear communication, and like many other critical pieces of information that might be included in an information radiator, the backlog needs to be highly visible by everyone involved in the project. A visible product backlog benefits everyone involved in the project. Product owners can quickly see what needs more detail, ScrumMasters can quickly see evidence that the agile process is being followed by inspecting how the backlog is groomed, and development teams can quickly see what is coming up so they are not blindsided by future sprints.

Failure to keep the product backlog visible is a pitfall because doing this deprives project team members of necessary information to make key decisions. For example, if the developers cannot see the product backlog, they have only a limited picture of the project. This limited picture may be fine for sprint-to-sprint progress, but over time, the team may lose sight of the overall goal.

3. Make sure product backlog items become more granular as they flow through the release backlog into the iteration backlog.

Granularity refers to the fineness of the detail in each item. Not only should items closer to the iteration backlog have more detail, but they should also be of appropriate size. Product backlogs can accommodate themes, epics, stories, and tasks. However, release backlogs should have more stories and tasks, and iteration backlogs should contain tasks primarily. Having items in an iteration backlog that are not granular enough is a pitfall because the team may need more time asking questions and learning how to implement the item, and taking this time may slow down their overall progress.

Below is a picture illustrating the detail as items get closer to the iteration backlog.

4. Make sure everything in the product backlog adds value.

Not every item in the product backlog is going to be high-priority and high-value, but for each item in the backlog, the requestor needs to be able to show the value of that item. While change is an important part of agile, another important part is delivering constant value to the customer. Including items with little to no value in the backlog is a pitfall that may put greater burden on the development team for a smaller potential return.

Another way to look at these is suggested by Mike Cohn, with help from Roman Pichler; both are experienced Agile experts. Cohn (2009, December 14) suggests the abbreviation “DEEP” to keep in mind when reviewing product backlogs. The product backlog should be:

• Detailed Appropriately, so the team has enough information to work on something when it comes up
• Estimated, so the product backlog can be used in planning
• Emergent, or dynamic; changing over time
• Prioritized, so the highest-value items are at the top

Following these best practices and avoiding the corresponding pitfalls should help in creating and maintaining a product backlog that supports the work of an Agile project. With an effective product backlog, the project will have the bridge it needs to go from the product roadmap’s abstract vision to the more concrete release and sprint plans. In addition, stakeholders and developers will have a good idea of how the team plans to implement the project’s vision.

What are your experiences with product backlogs? Please let us know in the comments.

If you are looking for further assistance, or have a specific roadblock you need to get around, we’re happy to help. We specialize in Agile Transformation. We can help your team successfully implement Agile, or get back on track with Agile with a little bit of coaching or training.

References

1. Cohn, Mike (2009, December 14). Make the product backlog DEEP. Mountain Goat Software. Web.

2. Griffiths, Mike (2012). PMI-ACP Exam Prep. RMC Publications, Inc., Milwaukee, Wisconsin.