Adopting a Product Backlog Maturity Model

A healthy Product Backlog is critical to the success of any Agile team. When a team works closely with its Product Owner to create well-crafted backlog items, they have the best chance for consistently delivering high-value software frequently. This usually means a cadence of examining and refining items on the backlog where they gather enough detail to prioritize, estimate, and ensure the team has the right amount of information at the right time. This is the Product Backlog refinement process in Scrum, with a portion of each Sprint set aside for this activity. A Product Backlog maturity model can help the team maximize the time spent during refinement and gauge the health of their backlog.

A maturity model is a method for classifying each backlog item based on how refined it is and is a guide for which items need to be addressed in your upcoming refinement sessions. Every item on your Product Backlog does not have to have the same amount of detail. Items toward the top of the backlog are commonly more valuable and require more detail since the team would be addressing them sooner. If you are trying to create any sort of release plan, there is also a certain set of items on the backlog that have been targeted for your next upcoming release. The rest of the backlog items are intended for possible future releases. Basically, you can segment your Product Backlog into these three categories, each of which has specific requirements for how refined its items are.

Ready to Play

The predominant guidance is that a team should have two Sprints worth of backlog items refined enough so that the team can immediately start working on them. An often-used term for this is “Ready to Play.” This would be the highest maturity level and where any backlog item needs to reach before work can begin.

Targeted for Release

Typically, a Product Owner uses a team’s past velocity to determine how much work they can handle each Sprint. Velocity is most commonly the sum of the estimated sizes of all the completed items in each Sprint, often done using Story Points. This metric can be used to forecast how much of the Product Backlog can be feasibly slated for the next release. These backlog items can be loosely categorized as “Targeted for Release.” At the end of every Sprint, any changes to the backlog or updates to the team’s velocity metric are used to update that release plan, so the specific items in this category can change over time.

Some teams may use other methods for sizing backlog items and determining how much work a team can consistently deliver, but in most cases, there is some method for a Product Owner to project which items the team can conceivably complete for the next release. Whichever method the team uses, items in the release plan need to have undergone some level of estimation effort.

Future Backlog

The rest of your backlog items not in the next release can simply be classified as your “Future Backlog.” New backlog items can come from various sources. Still, ultimately the Product Owner needs to assess each one and determine if it needs to be done immediately, slated for the next product release, or if it can wait for a future release. This means those items need just enough detail for the Product Owner to prioritize them.

Maturity Levels

Each category described above can have a maturity level defined. When a new item is added to the Product Backlog, we need just enough information to determine its priority. Typically this would mean the item is provided enough detail for the Product Owner to make that decision. User Stories are one frequently used format to capture the user, their need, and the specific value of the functionality proposed in the backlog item. That information can be enough for prioritization.

We will call that Maturity 1, which will mean items at that level are in a format like a User Story with enough information for the Product Owner to determine their priority on the overall Product Backlog. If it is determined that the item does not need to be in the next release, then it can remain in the “Future Backlog” and, at this time, may not need to be refined beyond that point.

If the Product Owner does consider the item targeted for the next release, then it needs to be refined enough so that the team can estimate it to determine how it fits into the release plan. This we will call Maturity 2. Since most release plans rely on some type of estimate for forecasting, any item determined to be “Targeted for Release” will need to be refined to at least this level.

When it is determined that an item will be worked on by the team in the next two Sprints, the team needs to refine it to the point that they are confident they could begin work on it. This means all of our “Ready to Play” backlog items would need to have enough information for the team to make that decision. We will call that Maturity 3.

Any backlog item that has yet to be reviewed by the Product Owner, or did not have enough information to prioritize it, can be considered Maturity 0.

Utilizing Maturity Levels

These three basic maturity levels can help determine when and what backlog items to address during refinement sessions. Here is one approach:

1. Before each refinement session, the Product Owner will review any new backlog items and determine if they have enough information to prioritize them.

• If there is enough information, they move it to the appropriate spot on the Product Backlog and mark it as Maturity 1.
• If there is not, they should note their outstanding questions and determine who they need to follow up with to get the necessary information.

2. At the beginning of the refinement session, the team will ensure all backlog items in the “Ready to Play” section of the Product Backlog are at Maturity 3.

• Any items not at Maturity 3 need to be refined until the team determines they have enough information to make that designation. If they need additional information to achieve this, the Product Owner will note all of their questions and ensure they get answered as soon as possible.
• The team may also want to quickly review items for the next Sprint that may already be Maturity 3, but they have not discussed them in a few weeks and need to refresh their memory with a short conversation to confirm that item is still at that maturity level.

3. The team moves on to the backlog items “Targeted for Release” and ensures that they are all at least to Maturity 2.

• Since this level is typically about estimating the item, this is an excellent time for an activity like Planning Poker.
• If the team starts to dive into more detail than required to reach Maturity 2, the Scrum Master (or any other member of the team) can ask if the current discussion would have a significant impact on the size or priority of the backlog item. If it does not, note the topic as an outstanding question that can be addressed in a future refinement session when this item needs to be Maturity 3.

4. If time allows, the Product Owner and the team may elect to review any backlog items in the “Future Release” and see if any of those warrant a discussion.

Things to Consider

Maturity levels are a tool to help the team and the Product Owner have the right level of conversation about the right backlog items at the right time. This supports the Agile concept of “Just In Time” requirements. Having productive and valuable conversations is the point, not assigning the maturity level.

There is always a temptation to refine items to Maturity 3 before it is required according to these categories. One thing to consider is that the team’s memory of these discussions decays over time, and no amount of documentation will ever replace those conversations. Additionally, the longer that detailed information sits, the more possibility some of those details can change. Even when a backlog item is refined to Maturity 3, if it sits around too long, the team will need to review it to refresh their memory and confirm it is still valid.

The definitions of the maturity levels above are ambiguous on purpose. Every team will need to determine the specifics of what “enough information to do XYZ” means to them. Many factors, such as the app domain’s complexity, the team’s skill level, the Product Owner’s domain knowledge, etc., will be significant in determining the particulars of your definitions for each maturity level.

Wrap Up

This simple and practical method for determining the maturity level of backlog items can help teams focus their time on having valuable conversations at the right time while ensuring that the Product Owner has a healthy Product Backlog.

You can learn more about this and other techniques for getting the most return on investment from your Product Backlog on this recording from one of our past webinars.