September 13th, 2021 by Thea Maisuradze

This is Part 2 of the larger paper on Good Agile Product Backlog by Dr. Sriram Rajagopalan, Enterprise Agile Evangelist, Inflectra.

Introduction

Our earlier blog about demystifying a good agile product backlog emphasizes how a good product backlog promotes stakeholder alignment. Emerging from the lean principles of attenuating waste and amplifying learning, Agile promotes a holistic view of the solution rather than just the technical system. So, any tool that incorporates backlog management should promote transparency of the backlog as well as committed items.

As teams work through multiple artifacts, a tool should support both - effectiveness of decision-making and efficiency in tracking the items through the delivery lifecycle. Therefore, it is critical to view the use of the planning board through the lens of the four agile ceremonies of iteration planning, daily standup, review, and retrospective. However, before we proceed with iteration planning, we need to understand the importance of a refined backlog. In this blog, we will review the stages of the backlog before items in the backlog are ready for the Agile Ceremonies.

The Focus of Agile Ceremonies

Too frequently, teams and even organizations embarking on Agile transformation fail to understand the benefit of the four Agile ceremonies. It is true that these ceremonies set an operating cadence. However, by using progressive elaboration and a timeboxing method, the Agile approaches reduce risk- and cost impact on the increment released to the customer for feedback. When the increment is small enough, the time taken to give clear, concise, and comprehensive feedback is also greatly enhanced. As the delivery teams own the commitments, they work to ascertain other stakeholder commitments to ensure that the product increments are sustained in operations to enhance value to the customer. From the perspective of the delivery team, this approach translates into an increased value to the customer and better product quality. Strategically speaking, the time to market and the potential cost of operational ownership is also reduced.

Figure 1: Benefits of Agile Ceremonies

Backlog Refinement

A team will not be able to demonstrate value if there is nothing valuable for them to work on. Therefore, one of the essential prerequisites for an agile team is a good backlog as represented by features from both the internal and external stakeholders but also the project team. Consequently, the backlog may have many items with some large epics and some essential features. As is common with any project, these ideas define the needs, expectations, and wants (Rajagopalan, 2020) of stakeholders while also requiring further refinement of backlog to ensure alignment with the strategic objectives, existing and desired technology stack, and team’s skills, capabilities, and competencies.

Figure 2: Backlog Refinement is an Ongoing Activity

Backlog refinement is initially required to ensure that the product represents a prioritized list of requirements for the minimum viable product (MVP). This refinement is an ongoing activity that happens throughout all four agile ceremonies. The product owner is ultimately accountable for refining this list of backlog items; the agile coach is responsible for ensuring that the refinement process is continuous and consistent. As Garbage-In-Garbage-Out (GIGO) principles illustrate, it is vital to develop reliably value-producing work that factors appropriate stakeholders’ inputs to avoid rework. Equally important is the increased transparency of the work coming to the teams. So, let us (additionally) discuss how a backlog emerges and how it can be viewed.

Initial State of Backlog

In the initial stage, the backlog may have a collection of extremely large items. Represented as the red rectangles, they show how the product backlog initially is a set of items that require more discussions and refinement. Then they will be split into reasonably sized requirement groups for the team to prioritize. Frequently, teams try to categorize these larger requirements immediately into Epic, Theme, or Feature. When teams do not agree on the meaning of these terms, an attempt at the categorization of large requirements creates confusion. What exactly these terms mean and how they can be used to determine the level of required effort in order to generate reasonable product increments to deliver these requirements is a topic of a much larger discussion. So, in the spirit of being agile, let us park that discussion for a future blog.

Furthermore, some teams may assign a subject-matter expert to break down a specific backlog item. For instance, in Figure 3, there is a large requirement called “Demo for Potential First-Time Users” of the library system. Whether this functionality should be a set of documentation with screenshots or a video illustrating the essential functions, or how this documentation or video be made available for non-English speakers or vision-impaired users are more details that require an SME to unpack. To facilitate product backlog, these requirements may be assigned to such a specific user.

Figure 3: Initiate State of Product Backlog

The Emerging State of Backlog

Meanwhile, matured teams or organizations with reasonable experience working in the Agile framework may have definitions to organize the requirement groups into themes, epics, features, use cases, and user stories. If a product owner has further aligned these requirements into product-specific higher-level requirement groups, frequently called Epics, then the product backlog can also be viewed a) by requirements not categorized under specific Epics and b) under requirements categorized into the higher-level product-specific groups.

This emerging state of backlog establishes a connection with both - the strategic direction of the product (with named epics and desired features as minimum expectations for generating value for the customer) and the stakeholder expectations to sustain the customer value by supporting business value, technical value, and process value features. In Spira, you can see this by grouping by Epic after selecting the product backlog as represented by the green rectangles.

The minimum viable product (MVP) emerging from the product backlog is inexorably aligned with the product roadmap, which is further aligned with the business strategy (such as horizontal and vertical product penetration). Consequently, good product owners also align product backlog items with the types of features (theme) that are released. It helps the product owners prioritize these requirements for additional refinement and balance them against the required experiments (spikes) to be carried out. So, Spira supports this good practice by allowing product owners and the teams to have increased transparency of product backlog by components (product features) as demonstrated in Figure 4. The red rectangles here indicate product backlog selection followed by a grouping of defined components that display the requirements grouped by the green rectangles.

Figure 4: Product Backlog by Product Features

**The Ready-State of Backlog**

The definition of ready may differ from one product to another in each organization. Nevertheless, the minimum expectation of a ready-state is that the requirement is scoped out in “just enough” detail and prioritized by the product owner aligned with the product roadmap. Consequently, a ready state is determined by how well the product backlog is risk-adjusted and prioritized. Many Agile practitioners associate the items in the product backlog with the DEEP property that stands for Detailed Appropriately, Emergent, Estimable, and Prioritized. In short, if items adhere to this DEEP property, then they are adequately refined for the team to discuss them in the planning sessions and potentially commit to executing on them.

Figure 5: Backlog Item Characteristics

At a very high level, Spira supports this DEEP property of the backlog item by allowing the prioritization of the features based on product goals aligned with strategic goals. A widespread priority scheme emerging from Dynamic Systems Development Methodology (DSDM) for prioritization is the MoSCoW principles (Todaro, 2019), highlighting what the team must, should, could, and won’t do. These priorities are mapped by categorizing requirements into critical, high, medium, and low. By selecting the product backlog in the planning section and grouping it by priority, the planning gives this ready state view (as illustrated in Figure 6). Please note that these cards are color-coded on the left margin of the card.

Figure 6: Priority Scheme Mapping for Ready State View

Teams can close the gap on what requirements are going through refinement to finally get to the “accepted state” (using the requirement workflow approval process) by exploring the “group by requirement” status. This status demonstrates what requirements are finally ready for iteration planning. Readers are directed to also incorporate the color code on the card’s left margin to also look at how cards can be brought into the iteration planning based on a mix of must, should, and could do to balance team commitments made in planning according to the team’s working agreements. Agile practitioners generally recommend balancing these priority stories committed in any iteration. For instance, having 60-20-20 as a rubric to bring must-should-could stories so that the team can ensure must-should are delivered while recognizing that risks may emerge during a sprint that can impact delivery.

Figure 7: Status & Priority Scheme Mapping for Ready State View

With the transparency enabled by role-based privileges, Spira allows a detailed overview of backlog items demonstrating the DEEP property of these requirements. Stakeholders’ input and approval are recorded, prioritization is confirmed, and enough detail is available for the team to think through the estimation. Such a ready-state nature of the product backlog sets the stage for the first stage of the Agile ceremony of Commitment Planning.

Figure 8: Ready state of items in the Backlog

Summary

Agile approaches promote experimentation so that teams can fail fast by discovering what does not work for the customer or in the technical implementation. However, failing fast is not a prescription to avoid planning. In fact, ‘if we fail to plan, we plan to fail,’ still rings true in Agile. This approach recommends just-enough planning to ensure that backlog item is detailed appropriately with input and feedback from stakeholders. This practice allows for:

continuous improvement of requirements through product increments in an iterative fashion
Estimating the level of work required along with priority alignment to the product strategy.

This DEEP planning sets the stage for Commitment Planning as the first stage of the Agile ceremony. We will discuss the four agile ceremonies and Spira’s support for them in the next blog.