8

ART Backlog Management

The ART Backlog (formerly the Program Backlog) is the holding area for upcoming Features and Enablers for the ART. Product Management is responsible for managing and maintaining this backlog.

Ensuring that the ART Backlog is well-refined and maintained is a foundational component of a successful ART. In this chapter, we are going to look at what the ART Backlog is and how it differs from other backlogs. We will dive into Features and Enablers, ensure our backlog is ready for PI Planning, and delve into WSJF.

In this chapter, we will cover the following topics:

• The ART Backlog
• What is a Feature anyway?
• Feature prioritization
• Backlog preparation for PI Planning

The ART Backlog

The ART Backlog is a Kanban system that manages the work of the ART. Product Management is responsible for its management and maintenance. The ART Backlog contains both Features and Enablers.

The ART Backlog differs from the Team Backlog in that the items span across the entire ART and are worked on during the Planning Interval (PI). Alternatively, compared to the Portfolio Backlog, the ART Backlog is more granular. The Portfolio Backlog often contains work for several Development Value Streams and spans multiple PIs.

While Product Management has the primary responsibility of managing the ART Backlog, key contributors and collaborators include the System Architect, Business Owners, and Product Owners.

The work in the ART Backlog should come from the Portfolio Epics and Portfolio Enablers. It is split into Features and Enablers that the ART will be able to deliver in a PI or less:

Figure 8.1 – Example flow from Portfolio Backlog to ART Backlog (© Scaled Agile, Inc.)

If you’re implementing Essential SAFe®, there is no intentional need for the work to come from the Portfolio Backlog. Remember to only scale to the Portfolio, Solution, and Full configurations when necessary.

Ensuring that the ART Backlog is well maintained is one of the most critical items for the ART. Without a well-defined and refined backlog, the ART will struggle to deliver value and determine what they should be working on.

The ART Backlog is typically represented via a Kanban Board. In Figure 8.2 we have an example of how the Features flow through the system, including the usage of WIP limits and some example policies.

Figure 8.2 - Example ART Backlog in Kanban (© Scaled Agile, Inc.)

Product Management is responsible for ensuring the backlog is continuously prioritized and updated and shepherds the Features through the process in the same fashion as an Epic Owner at the portfolio level.

The ART Backlog is a critical tool for the ART. It visualizes the work that is in progress, as well as what is coming down the pipeline. We can see the different types of work (Features versus Enablers) and ensure that we have an appropriate Capacity Allocation to keep our ART running full steam ahead.

What is a Feature anyway?

As per SAFe®, “A Feature represents solution functionality that delivers Business Value, fulfills a stakeholder need, and is sized to be delivered by an Agile Release Train within a PI.” (© Scaled Agile, Inc.)

Great! Now, what does that mean to me in the real world? How do I deliver one?

If we asked you to identify Features on a car, you would likely list things such as anti-lock brakes, power windows and locks, remote start, leather seats, and so on.

Features don’t have to be hard to define, yet we see many ARTs struggle to define them. When you approach your system, think about what the key aspects are; that becomes your starting point for your Features.

When identifying and writing your Features, make sure you include a Benefit Hypothesis Statement. Simply capture what you expect to gain or accomplish by delivering the Feature.

Lastly, don’t forget to capture the Acceptance Criteria. These are the key items necessary to consider the Feature “done.”

Pro tip

Features don’t need to be written in user-story voice. Use a short phrase or name to capture the essence of the Feature and then keep the Benefit Hypothesis short and sweet.

Example Feature: Adaptive cruise control

Example Benefit Hypothesis: Cruise control that automatically adjusts speed to the vehicle ahead of it

Let’s take a look at a specific type of Feature: Enablers.

Enablers

An Enabler is simply a type of Feature that supports NFRs or extends the Architectural Runway.

We often differentiate between a Feature and an Enabler to help with prioritization and sequencing or to help ensure we have a balanced Capacity Allocation.

Enablers, like Features, are captured and prioritized in the ART Backlog. They have a short title, Benefit Hypothesis, and Acceptance Criteria.

SAFe® identifies four different types of Enablers:

• Exploration: Research and support for future development or customer needs
• Architectural: Work to build the Architectural Runway
• Infrastructure: Work to create or optimize environments
• Compliance: Work to support specific compliance activities

Pro tip

When you are first starting, don’t get caught splitting hairs on whether an item is a Feature, an Enabler, or the type of Enabler. At the end of the day, it’s all work that needs to be done. As you mature, the Capacity Allocation will likely become more important, and you will get a better sense of whether it’s an Enabler or a Feature. Worry about it then.

Capacity Allocation

Many people confuse Capacity Allocation and Capacity. Capacity Allocation is the percentage of the different types of Features and Enablers that are planned.

In the following example, we can see the percentage of new Features versus Enablers versus Technical Debt and maintenance work on the system. You will need to determine the Capacity Allocation for your ART and know that it will change over time:

Figure 8.3 – Capacity Allocation (© Scaled Agile, Inc.)

Understanding your Capacity Allocation is important to help ensure that the ART is providing a balanced solution. We need to ensure that we have enough Architectural Runway items balanced with the new Features that are being requested. If we skew one way or the other, we run the risk of building infrastructure that isn’t needed or requires additional development when we start using it, or we don’t have the infrastructure in place to support the new Features and ultimately can’t deliver them.

Now that we know what Features and Enablers are and why we need to balance them, let’s look at why sizing them is so important.

Feature Sizing

We know that a Feature should “fit” into a PI, but how exactly do we accomplish this? Feature sizing is a bit of an art (not an Agile Release Train) and a bit of a science. We want the Feature to be of value to the customer, but it also can’t be so big that it takes us a long time to deliver it.

The challenge that Product Management is up against is the same challenge that Goldilocks had with the three bears: finding the Feature that is “just right.” When we first launch an ART, the Features tend to be “too big.” We lack the knowledge and experience to know how much work the ART can deliver in a PI.

We often see this play out in the first stage of PI Planning. Product Management presents the top 10 Features, and at the end of Day 1, we realize that we will be lucky to complete 1 (or at best, 2) of the Features. To avoid this in the future, ARTs will often overcorrect, and we will see Features that are “too small.” Now, almost every Feature can be delivered in a single iteration.

It can take upwards of a year after the ART is launched before we start to normalize and get Features that are “just right.” The question becomes, how do we get Features that are “just right” earlier in the process? There’s no magic bullet, but here are strategies to adopt early with your ART:

• Get feedback: This seems like it should be simple and that it would be a normal part of the process, but often, Product Management works in a bubble with only the Product Owners and doesn’t ask the teams that will be doing the work to share how long it will take to deliver it. The estimate doesn’t need to be precise, and an understanding needs to be established that this isn’t a commitment but an estimate.
• Keep batch sizes small: Suggest that Product Management creates a couple of Features to start, maybe two or three, and then gets feedback. Are the Features too big, too small, or just right? Maybe the Features have too much detail or not enough. In the same way that we look for the teams to get continuous feedback on the work they are delivering, Product Management and Product Owners should get feedback on the work they are delivering in the form of Features and stories.
• Definition of Done: Ensure that the Definition of Done (DoD) aligns with and supports the current environmental setup. We have encountered DoDs stating the work needed to be in production for the Feature to be considered “done.” The organization had constraints and bottlenecks in the process and the fastest timeline from development to production was eight weeks (almost an entire PI). We adjusted the DoD from production to pre-production and then worked with the System Team on streamlining the move to production over time.

What about Points?

We typically don’t assign points to Features or estimate them from a points perspective. When we size Features, we are looking to ensure that they are deliverable in a PI. We want to leverage the concept of relative sizing to help with estimation.

Pro tip

When we relatively size Features, we often start with a Feature that took us three to four iterations to complete and call that a medium. We then take a new Feature and decide whether this new Feature is bigger, smaller, or the same size as our first Feature.

Some ARTs add up the number of story points once the Feature is completed and establish ranges for Features, similar to Epics, to help with forecasting. For example, a small Feature is 50 to 150 points, while a medium Feature is between 150 and 300. We could then potentially look at the average velocity of the ART and the Features in the backlog and roughly estimate when a Feature could potentially be delivered. We strongly encourage you to use this practice with extreme caution as it can lead to perceived commitments.

Pro tip

When working with teams and ARTs, I typically encourage T-shirt sizing the Features as small, medium, and large. I look for a small Feature to be delivered in about 2–3 iterations, a medium Feature typically is 3–4 iterations, and if we have a large Feature, we work to split it into smaller Features.

Now, let’s take a look at some options for splitting and combining Features.

Feature Splitting and Combining

In our experience, most of the time, we see Features that are “too big” based on the feedback from the teams. We will want and need to split our Features into smaller, more manageable work to keep our batch sizes small. There are many different ways and methodologies to split work. SAFe® has 10 ways [6]. Ultimately, whatever practices you follow for splitting stories, you can scale those to Features.

Here are some ways you can split stories that apply to Features:

• Workflow steps
• Business rule variations
• Major effort
• Simple/complex
• Variations in data
• Data entry methods
• Deferred system qualities
• Operations (for example, Create, Read, Update, Delete (CRUD))
• Use case scenarios
• Break-out spike

One watchpoint when splitting Features (or stories) is that we want to try and keep each Feature as independent as possible from another Feature to enable early value delivery.

If you find that your Features are generally “too small,” it’s important to work with the teams to identify natural combinations using the same concepts you used to split a story, only in reverse. Combine Features that were originally split by operations into one or maybe two Features.

Caution – but Jira doesn’t have Features!

Many of your organizations use Jira as your agile tool, as it is one of the most popular tools on the market. At the time of writing, Jira currently doesn’t have “Features” in the sense that SAFe® has defined them. There are numerous workarounds and add-ons available to leverage Features in Jira. However, my advice is Keep It Super Simple (KISS). Simply use Jira Epics as Features and ensure that the organization understands. A Rosetta Stone of sorts in that, in our organization, a Jira Epic is equivalent to a SAFe® Feature.

Now that we know what Features are and why they are important, let’s take a look at some ways we can prioritize them.

Feature Prioritization

Weighted Shortest Job First (WSJF) is a common prioritization technique for Features in the ART Backlog. Our backlogs often have many Features, and it can be difficult to know which to prioritize first.

Why WSJF?

Principles of Product Development Flow, by Reinertsen, [9] described a model where we want to minimize the amount of money lost by delaying a job. We refer to this as the cost of delay. Our organizations strive to get the most value in the shortest amount of time, and by using WSJF, we can empirically determine which jobs provide the most value in the shortest amount of time.

So, why WSJF? We want to identify the Features that will give us the most value in the least amount of time. Let’s look at how to do this.

Applying WSJF

WSJF can seem pretty complicated with the numbers and values, and math! Let’s simplify this. We need four things when we look at WSJF:

1. User Business Value: How important is this to our business or customer?
2. Time criticality: Are there key dates we need for the Feature?
3. Risk Reduction and/or Opportunity Enablement (RROE): What risk are we avoiding, or what opportunity are we creating?
4. Job size: How big or how long will it take to complete the work?

With these four pieces of information and some math, we can get the WSJF score and start working on the highest-valued items.

User Business Value, time criticality, and RROE are summed to determine the Cost of Delay (CoD).

The formula for WSFJ is simply the cost of delay divided by job size:

Pro tip

We use Job Size as a proxy for the duration; however, we still may need to refactor this as it’s not always a good proxy.

This seems simple, and it is when you have a few more tricks up your sleeve:

• Use a spreadsheet (or similar tool) to capture the values
• Use a modified Fibonacci for the values of 1 to 20
• Every column must contain a 1
• Use relative estimation in determining the values
• One at a time, estimate the CoD components (user Business Value, time criticality, and RROE) and then the job size for all Features

Let’s go through an example step by step. We are getting ready to sell our house. We have three things that we want to get done before we sell our house. We will consider each of these a Feature:

• Landscape the front yard.
• Fix a leaky faucet.
• Paint the bedroom.

Here’s an example:

Feature	User Business Value	Time Criticality	RROE	CoD	Job Size	WSJF
Landscaping	+	+	=	/	=
Fix Faucet	+	+	=	/	=
Paint Bedroom	+	+	=	/	=

Step 1

First, we will look at the User Business Value column and determine which Feature has the least value to us. It is important to note that when working through this with your organization, you will want to agree on what each of the columns means to your organization.

In our scenario, we think that fixing the leaky faucet would provide the least amount of value when selling the home, so we will give it a 1. We think that landscaping will give us the most value as first impressions and curb appeal are important when selling a house:

Feature	User Business Value	Time Criticality	RROE	CoD	Job Size	WSJF
Landscaping	13 +
Fix Faucet	1 +
Paint Bedroom	5 +

Step 2

We will now look at Time Criticality. Our realtor (US)/estate agent (UK) wants to take pictures of the house for the listing, so both painting the bedroom and the landscaping are urgent priorities. Fixing the leaky faucet is our least time-critical item:

Feature	User Business Value	Time Criticality	RROE	CoD	Job Size	WSJF
Landscaping	13 +	8 +
Fix Faucet	1 +	1 +
Paint Bedroom	5 +	8 +

Step 3

Our third step is looking at the RROE. We think painting the bedroom is our 1 because buyers might still choose to repaint, so we have limited OE, and there isn’t any risk reduction we could identify. We think that the landscaping and curb appeal will create some opportunity, but there isn’t any risk we are reducing. The leaky faucet won’t pass an inspection, and there is a possibility that the leak could get worse and flood the house, so we scored that higher:

Feature	User Business Value	Time Criticality	RROE	CoD	Job Size	WSJF
Landscaping	13 +	8 +	3 =
Fix Faucet	1 +	1 +	8 =
Paint Bedroom	5 +	8 +	1 =

Step 4

We now total the User Business Value, Time Criticality, and RROE into the CoD column and estimate the Job Size. We think that fixing the leaky faucet will take the least amount of time, so we have given it a 1. Landscaping is significantly more work, and we thought that painting was somewhere in the middle:

Feature	User Business Value	Time Criticality	RROE	CoD	Job Size	WSJF
Landscaping	13 +	8 +	3 =	24 /	8 =
Fix Faucet	1 +	1 +	8 =	10 /	1 =
Paint Bedroom	5 +	8 +	1 =	10 /	3 =

Step 5

Divide the COD by the Job Size and review the results:

Feature	User Business Value	Time Criticality	RROE	CoD	Job Size	WSJF
Landscaping	13 +	8 +	3 =	24 /	8 =	3
Fix Faucet	1 +	1 +	8 =	10 /	1 =	10
Paint Bedroom	5 +	8 +	1 =	14 /	3 =	4.6

Our results indicate that we should complete the work in this order:

1. Fix the leaky faucet.
2. Paint the bedroom.
3. Landscape the front yard.

The secret to winning a WSJF is job size. We want to do the smallest jobs first. Our results would have looked different if we split landscaping into several smaller jobs, such as mowing the lawn, putting down mulch, and sweeping off the porch. While the smallest jobs win, don’t fall into the trap of making Features too small. The overhead of managing and maintaining so many Features outweighs the benefits.

What if we disagree with WSJF?

On occasion, there will be fundamental disagreement with the results, and organizations will determine that there isn’t any value in WSJF. When this occurs, it’s important to dig a bit deeper and understand the root cause of the disagreement. You will often find that the organization hasn’t broken down large initiatives into smaller deliverables to enable faster feedback.

WSJF is one way to prioritize the work and works well when there are many factors to consider – if you don’t need to do it, don’t. Often, Product Management has a good sense of priority and can simply order the work based on experience and feedback.

WSJF is one of many prioritization techniques you can use to prioritize the backlog. Leveraging the ART Kanban board with WIP limits is also a natural prioritization method and helps keep backlogs manageable. Whichever method you choose, having a prioritized backlog is critical as you head into PI Planning.

Backlog Preparation for PI Planning

As we discussed in Chapter 7, Release Trains Day-to-Day, the ART executes on a closed loop and, at scale, executes similar events to the team. In the following diagram, we can see that backlog refinement at the team level correlates to our need to prepare the ART Backlog for PI Planning:

Figure 8.4 – Backlog refinement and preparation for PI Planning correlation (© Scaled Agile, Inc.)

One key reminder is that preparing for PI Planning is a continuous process and that ensuring the ART Backlog is ready is a key activity. As a Coach, you may need to encourage the RTE to work closely with Product Management to ensure they have worked with the Product Owners and teams to socialize and refine the backlog before the PI Planning Event. We don’t want to surprise the teams with new Features during PI Planning.

As PI Planning approaches, the ART Backlog should be built out with fully refined Features; many of the stories should also be identified and partially refined. Without this preparation, new ARTs, in particular, will struggle to complete all of the necessary work in the two-day PI Planning Event. As your ARTs mature and the work becomes more familiar to the teams, the amount of pre-PI Planning preparation of the stories may decrease over time.

As we look at the ART Backlog and prepare for PI Planning, the top Features that Product Management shares should be the same prioritized Features that are ready in the ART Backlog.

PI Planning is critical to the ART’s success. We want to ensure the ART has prioritized, sized, and clearly defined work as they go into the PI Planning Event.

Summary

The ART Backlog is critical for the ART and shouldn’t be overlooked. By leveraging the ART Backlog, Kanban can visualize the progress of the Features, ultimately driving success for the ART. We also want to understand the Capacity Allocation of our ART Backlog and prioritize the work to deliver the weighted shortest jobs first, ultimately delivering value quickly through appropriately sized Features.

Further reading

To learn more about the topics that were covered in this chapter, take a look at the following resources:

1. ART Backlogs: https://www.scaledagileframework.com/ART-and-solution-train-backlogs/.
2. Features: https://www.scaledagileframework.com/Features-and-capabilities/.
3. Enablers: https://www.scaledagileframework.com/enablers/.
4. WSJF: https://www.scaledagileframework.com/wsjf/.
5. Planning interval: https://www.scaledagileframework.com/planning-interval/.
6. Splitting stories: https://scaledagileframework.com/story/.
7. Right-sizing your Features: https://scaledagileframework.com/right-sizing-Features-for-safe-program-increments/.
8. Leffingwell, Dean (2011). Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley.
9. Reinertsen, Don (2009). Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing.