Strategic

The bottom level of the LVT contains strategic initiatives that are broken down into stories that incorporate the product ideas described in Chapter 6, Building a Product Mindset. In our experience, for most organizations only 10 to 20 percent of the work is strategic. Most portfolios consist of mainly the other three types of work listed under BAU.

Business as Usual

Every organization has legacy systems. The older your organization, the larger the investment in those legacy systems and they consume significant delivery capacity. We refer to this non strategic work as BAU, and break it down into three main types—small enhancements, defects, and technical debt.

First, an important governance question for BAU work is, “Do we use an LVT?” The answer is, “It depends.” There are advantages and disadvantages to either approach. The advantage of putting BAU items on the LVT is that your entire workload will be depicted in one place and you can see how BAU work impacts strategic work. The disadvantage of putting BAU items on the LVT is that when you try to map all of your BAU work, you will have a significantly larger tree. Moreover, much of it cannot be directly mapped to your business strategy, as that strategy usually does not specify maintaining your current capabilities.

Imagine how you might try to map the small enhancements to various corporate reporting systems into an LVT. Some changes might be driven by your desire to understand a part of your business better—to pursue a new market segment, or to improve the efficiency of a business process. These could be incorporated into the goals and bets that describe that strategy, but many of them likely are not really clearly called out in your business strategy, and don’t have a home in the LVT. In that case, you need to “invent” groupings of this work to represent them in the goal–bet–initiative structure of the LVT, thereby obscuring strategic clarity.

Depending on the nature of your organization and the portfolio size, you might accept these tradeoffs. If your company is like most of the large organizations we have worked with, the incorporation of BAU in the LVT actually defeats the purpose of the tool, so you need another way of handling it. Let’s first describe the various types of BAU work, and then outline an approach to managing and prioritizing it.

Types of BAU Work

BAU can span a range of work types and time commitments. While a number of terms are used to categorize this work, the three used in this chapter are small enhancements, defects, and technical debt. These are shown in Figure 7-2, together with strategic work, to provide a total view of a team’s workload.

Capabilities

This book has focused on narrowing a wide range of opportunities to your specific goals using the LVT. However, there are two related types of capability development—business and technical. An example of a business capability would be an order fulfillment process, whereas a technical capability would be building a technology platform. BAU business capabilities are improved by intermittent small enhancements, whereas technical capabilities are enhanced by activities such as skills training. So you might have a strategic opportunity goal that is partially supported by enhancing a business capability, which in turn is supported by a new technical capability. An enhancement to a business capability would generate a delivery story to be prioritized, while a technical capability would be incorporated by assigning a percentage of the team’s effort to an improvement activity.

Combining Strategic and BAU Portfolios

As mentioned earlier, most organizations spend more than 80 percent of their capacity on BAU work. Many portfolios of work will never include any strategic work at all. Our accounts receivable portfolio is a good example: Rarely will a strategic initiative change the fundamental business capability of AR. For the sake of clarity, let’s imagine your innovative colleagues came up with a strategic initiative that required changes to AR. You generally want to keep strategic initiatives separate from BAU items, but occasionally smaller strategic items can be managed in the BAU portfolio. When this happens, how do you manage this work? In which portfolio does it belong?

One approach to combining strategic and BAU portfolios that works well is the concept of reserved capacity. In our AR BAU portfolio example, if some strategic work is likely, you could reserve some of the money (capacity) invested in the AR budget for strategic work, as depicted in Figure 7-3. This approach maintains a consistent budget for operational expenses, but allows for a small amount of potential strategic work. These funds can be used only for small strategic initiatives in the AR BAU portfolio. The reserve capacity should be taken into account when establishing targets for the MoS of the AR BAU portfolio. If no strategic work is required, the team is expected to use that capacity to generate value through BAU. Larger strategic initiatives should be handled in an LVT portfolio and prioritized using the process defined in Chapter 5.

Traditional Solutions

In the past, many IT organizations divided work into new projects and maintenance. Defects, new feature additions, infrastructure updates, and other small changes were handled by the maintenance group. Individuals often worked on these small changes by themselves. Further, the more experienced and skilled people wanted to work on projects and not “cleanup” work, which left less experienced staff destined to work on maintenance. Maintenance work was usually high priority, so quick fixes that increased technical debt often became the norm. Because new-project teams didn’t have to worry about the long-term consequences of their work, and because the project schedule and costs usually drove that work, quality (including testing) often suffered.

Many teams we have worked with have tried various techniques to deal with these challenges. Setting aside a portion of the team’s capacity for this type of work is one common approach. This approach definitely helps eliminate the negative impact on the planned work schedule—or does it? We would argue that all you have done is to guarantee that you deliver less planned work every iteration.

Here is an example. You might understand from your performance data that, on average, you have 8 story points of defect repairs every iteration. You reason that if your team burns at 30 story points⁴ per iteration, you can commit to delivering only 22 points of planned work in each subsequentiteration. You would be correct if you really had 8 points of defect repairs in the next iteration. But what happens if a really bad bug is uncovered and 16 points are needed to handle it? You want to squash that nasty bug, but you don’t have the budget to do so without giving up some planned work. You are back in the same prioritization quandary. Now think about the opposite scenario—when you don’t have any defects to deal with. You have excess capacity and could accept another story, but this may set the wrong expectation about your ongoing value-generating capacity.

4. Story points are an activity measure, not a performance (MoS) measure.

One reason that organizations often separate their planned and unplanned work backlogs is because they have no method of comparing the various types of work for prioritization. We are often asked, “How do I compare a new feature request with a bug?” You use an understanding of customer and business value to guide you.

A Better Way

Transparency and giving teams substantial decision-making authority are better ways of managing this problem. Having a visible backlog that includes all types of work (strategic, BAU, and technical capabilities) gives the team, product specialist, and customers situational awareness. This is a good foundation for a collaborative effort to prioritize work. A stakeholder with a new idea can see what else is on the team’s plate when bringing up that new idea. In our experience, this often influences the quality of the ideas that are added to the backlog. One way this happens is through demand shaping, in which stakeholders with new ideas look at the existing backlog before they add to it. They might decide that their requirement is already satisfied by an existing story. Regardless, when the inevitable discussion of “when can I have it…” comes around, the stakeholder and the product specialists are likely to be more understanding of each other’s position. Working this way reduces uncomfortable conversations, and instead makes them more collaborative and productive.

Because you have organized your portfolios by outcomes and have good measures of success, you can apply relative value prioritization techniques similar to those described in Chapter 5. By scoring the relative impact using MoS and the relative effort, all types of work can be compared. In addition, each category (e.g., strategic, BAU) needs decision-making guidance. While the LVT goals are articulated, you may need to work on this guidance for other types of work.

A point about defect repair work: Some teams have struggled with how to apply this approach. They say something like, “This is a bug; it doesn’t add any value.” We would argue that if it is a bug, then it must be preventing some value from being realized. If that is indeed the case, then fixing the bug should unlock that value. If it truly doesn’t make any difference to your MoS, then that work will end up at the bottom of your priority list, and rightly so.

Technical debt is another type of work that has historically been difficult to prioritize. Thinking about tech debt in terms of the value that it prevents you from realizing helps puts this cost in perspective. If your product goal is to deliver a continuous stream of value, then technical debt reduction becomes important because doing so enhances both speed and adaptability over time.

There is no magic formula for making prioritization decisions. Balancing between working on initiatives, products, BAU, staff capabilities, and technical debt depends on reasonable value analysis and a collaborative decision-making frame of mind. This process can be enhanced by certain practices, effective judgment, and escalation procedures. Moreover, while you try to push as many decisions to the autonomous delivery teams as possible, you can’t push them all. Sometimes managers and executives have perspectives that team members don’t. Sometimes major spending decisions are necessary. Pulling all these components into an integrated, prioritized backlog is challenging, but ultimately worth the effort.

Component Strategies

The team needs guidance for each component of its portfolio. For strategic stories, you can obtain the most comprehensive strategy information from the goals, bets, initiatives, and MoS. For technical debt, you can use the asset or asset class strategies discussed in Chapter 2, Tech@Core. For defect repair, you have business capability-based MoS. And, finally, you have the articulated product strategy described in Chapter 6. Teams that have, and understand, these goals have a solid basis on which to make prioritization decisions. Those that don’t are doomed to flounder around trying to prioritize components without guidance.

Let’s consider an example of how this guidance can impact decision making. If your executive team stresses that strategic components have a very high current priority, they might also add that enhancements should be very limited for a time. At the same time, you might emphasize technical debt reduction so as to improve delivery speed and adaptability while the new product is being built.

You have bet and initiative strategies that provide detail-level guidance. For example, by knowing and understanding a bet-level hypothesis, the team has an incentive to give higher priority to stories that will quickly prove or disprove that hypothesis.

Relative versus Absolute Value

We have emphasized, particularly in Chapter 5, our preference for a relative (rather than absolute) prioritization process. A relative process is much faster than spending time calculating concrete numbers that are often based on suspicious assumptions. Relative prioritization also enhances your ability to include intangible factors in your deliberations. No matter what techniques you use, the final prioritized backlog—at any level—boils down to a collective judgment.

The final factor that favors relative prioritization is the quick feedback that brings you back on track if your team’s judgment takes a brief leave of absence. When your feedback loop is many months in duration, the tendency is to spend far too much time analyzing to get everything right the first time. Your real goal should be to get everything right the last time.

Doing Less

We have encountered organizations in which the Portfolio Management Office processes many, many requests for projects, and its denizens dutifully go about defining the requests, calculating ROI, and adding them to a large backlog. Sometimes the low-priority items stay on the backlog for years. The hours spent calculating costs, prioritizing, and reprioritizing these items can be staggering, representing a large sunk cost. We’ve seen backlogs with 1000 projects, of which maybe 100 have a chance of ever being funded. How do you avoid all this wasted effort in EDGE? Demand shaping, delaying detail, and quick quartiling.

If requesters can throw new work into the hopper on a whim, without consequence, then the backlog will inevitably grow. In contrast, if the product team has a good understanding of the items on each workflow and on the backlog, they will be less likely to add to that backlog. Keeping undesirable items off the backlog in the first place by evaluating all items—whether for LVT plan or technical debt—keeps the teams from wasting effort.

Delaying detail is another way to reduce work effort, if not demand itself. In the example with a backlog of 1000 items, suppose demand shaping reduced this backlog to 600 items. Should you then develop story-level details for all 600? No. If your velocity was 10 stories per iteration developing details for all 600 would be wasted effort. Detailing enough for two or three iterations of delivery should, in most cases, be sufficient.

Quick quartiling is another way to do less. Rather than prioritizing all the items on your backlog, try breaking that list into quarters or even thirds first—labeled, for example, “must,” “high,” “moderate,” and “low” priority. Again, it’s a way to move through the prioritization process faster. Don’t do work you don’t need to—do less!

Team Prioritization

A key reason that the prioritization approach advanced in this chapter works is that it is conducted by a collaborative, self-sufficient, autonomous team. If the organization lacks a high degree of collaborative decision making, teams are not self-sufficient with broad knowledge, and teams lack the autonomy to make most prioritization decisions, then the practices in this chapter won’t work well. The Agile Manifesto states, “Individuals and teams over process and tools.” The skills, abilities, and experience of team members are the source of good judgment. Using this same prioritization process without the essential elements of a self-sufficient,⁵ autonomous team will lead to problematic results.

5. Self-sufficient autonomous teams have members from product, IT, IT operations, and other knowledge areas.

Team judgment is needed because items in your workflow may have different MoS. If an item from the LVT plan has an MoS of customer clicks whereas an item from the BAU list uses DSO, that inconsistency makes prioritization tricky. In the case of items with different MoS flowing into the process, relative ranking of value using the collective knowledge of the team works much better.

There is also an impact on prioritization when you organize by product rather than by project orientation. Traditional project-organized teams emphasized speedy feature delivery without giving much attention to the other components, particularly if maintenance was then handed off to another team. They had little incentive to “balance” components. In a product-centered team, the product specialists are as responsible for balancing priorities among components as the tech staff are. They have to live with the long-term consequences of their decisions, as does the tech staff.

Work-in-Progress

The ideas of monitoring and restricting work-in-progress (WIP) have had a large influence in the agile, lean, and Kanban communities. It is a waste of time to prioritize 300 items on a team’s backlog when the team delivers only 10 items per iteration. The introduction of new items or changing priorities will alter the sequence in your backlog over time. As shown in Figure 7-4, restricting the number of items flowing from the unprioritized to the prioritized boxes will save time. The size of the two boxes reflects this reality. Limiting WIP appears to be easy—but it’s not. It takes a lot of discipline to limit workflow to the capacity of the team. It means saying “Not yet” to customers.

Value and Effort Scoring

This section brings together all of the prioritization factors just described. This value and effort scoring is the last step in assigning priorities to the various components. The section in Chapter 5 on value and effort scoring provided the basis for setting priorities for the different types of work. A story is an increment of work that delivers value to the customer at the end of an iteration. While a technical debt item may be different from a small enhancement item, we will still utilize stories to describe these smallest units of work. This is the lowest level at which teams will establish priorities. Following are four practices you can use for prioritizing stories, presented from the simplest to the most complex. All of these practices involve the whole delivery team in the process. Value scoring again gives us a way to compare very different components and prioritize them.

Moderately Simple: Direct Value Assignment

The next step in simple to complex ways of assessing priority is to assign a numeric value to a story and possibly an effort number. As mentioned in Chapter 5, you might use a gross measurement scale such as “Low, Medium, High,” or T-shirt sizes (S, M, L), or Fibonacci numbers (1, 2, 3, 5, 8, …). Because stories are often similar in size (they do not have the size range of bets, for example), you may not want to estimate an effort number. Figure 7-5 shows an assignment matrix using both value and effort. In this approach, the priority is not calculated, but rather assigned by the team as it looks over the matrix. You would not bother to take the time to calculate the value/effort (V/E) ratio if effort was not used.

Escalation Processes

Although you want teams and product owners to understand the total scope of work that the team has on its backlog to make prioritization decisions, there will be times when external factors or management needs dictate that organization leaders need to engage in priority setting. Having an escalation process in place will help the teams understand which prioritization decisions they can make and which ones need leadership input.

Sometimes teams will have difficulty sorting through the relative priorities among the four components. While you try to have value measures for each item, it is sometimes difficult to decide, for example, whether a BAU enhancement or a technical debt story has more relative value. No matter how jelled a team, there will inevitably be situations in which differences of opinion between team members can’t be reconciled. For example, a product person may feel the pressure of new features, whereas the technical staff may think a technical debt reduction should have higher priority.

This may be the point at which a well-functioning autonomous team and a team that’s not quite there take different approaches. The latter team may think they are at an impasse, so they escalate the decision to management. Given that the well-functioning team has the appropriate mix of product and technical members, they should be able to handle a very high percentage of difficult prioritization decisions. Of course, there will always be situations where decisions will need to be escalated to higher management levels.

Imperfect Prioritization

When prioritizing backlog items, it is all too easy to think that a particular set of priorities is fixed. But this is an adaptive process that uses relative, not absolute, measures, so priorities will likely change from time to time.

Of course, no process is perfect when people are involved. You may argue that the process proposed here isn’t perfect—and we would be the first to agree. But remember the story of two hikers in the woods upon encountering a grizzly bear. One hiker sat down and quickly put his running shoes on. “You can’t outrun a bear in those shoes,” said his companion. “I don’t have to outrun the bear,” the first hiker said, “I just have to outrun you.” Our approach to prioritization doesn’t have to be perfect; it just has to be better than your competitors’ processes.

Remember that all the processes in EDGE are agile, meaning that there are short iterations of doing, followed by reflection and learning, and then by adapting quickly. Even if you get the priorities wrong, you get to adjust them in a short time period. Quick reaction to resolve mistakes provides a safety net for those mistakes and manages risk.