Feature definition typically occurs at the start of product planning today. Much of the frustration from missed development schedules arises from unrealistic expectations of predicting feature content within a fixed release schedule. Features even appear on multiyear roadmaps. Features are likely to stay around as a planning element despite the epics and user stories used in the Agile world. A feature is an increment of functionality that represents value for the business side. Project managers track features. Customers and sales teams expect them. Agile needs to incorporate a feature model that creates value without imposing constraints early in product planning.

The Investment model raises the level of schedule commitment above features to the Investment level. Feature‐level commitments will not be eliminated but can be reduced. There are valid reasons for feature‐level commitments. For example, features may be driven by regulatory requirements. Or customers may not accept your product without features provided by competitors' products, or even allow you to participate in a Request for Proposals (RFP). Feature commitments should be made on a case‐by‐case basis and kept to a minimum. Committing to specific features reduces engineering content flexibility needed to meet Investment timeboxes.

Product managers need to dig deeper to understand the need for a feature‐level commitment. The demand for a specific feature and schedule should always be questioned. Is it because someone thinks it's a good idea, or is it necessary to sell the product? The more specific features requested, the lower the likelihood of meeting Investment schedules.

Investment stakeholder value analysis discussed in Chapter 6 provides an alternative to the feature‐level planning used by most organizations today. However, at some point, an Investment is likely to be decomposed into feature work packages familiar to product and project managers. This chapter includes a method for feature content planning that provides high probability of completion within the Investment timebox.

7.1 Avoiding the Feature Pit

Chapter 6 introduced the truck fleet management example I have used in seminars. For the first exercise, the group is broken down into small teams to define features. Nobody questions starting at that level because that's what most of them are used to. The point is to demonstrate that focusing on features obscures value.

The assignment results in a flurry of activity. The person tasked with writing down the feature list usually can't keep up with the flood of ideas from their team. Nobody asks for additional clarification of the scenario, like whether the focus is long‐ or short‐haul trucks, or whether the market is domestic or international. Nobody thinks about constraints by different country regulatory authorities or unions. The teams jump into defining features with little information about the market.

I have to cut off the discussion at some point. There appears to be no end to the great ideas for features. It takes a few minutes for the buzz of the room to dissipate because they are having so much fun. I then tell them that the exercise is complete and all they need to do now is prioritize the features in a product backlog for their Agile teams. I tell them they could bring in a truck driver as a product owner to help them come up with even more features. They now suspect they've fallen into a trap. They have taken the narrow perspective of adding functionality for users of the software. Almost all the features focus on the truck driver. Then I ask if truck drivers will have a major say in the purchase of their product. The room goes quiet.

Feature examples:

• Identify the truck stops with the highest food ratings on the driver's route.
• Immediately reroute the truck to the nearest rest stop.
• A communication channel to talk with other company truckers.

Nobody would argue that these are useful features. However, are they the features that will maximize Investment value? It turns out that none of the features creates value for the key decision‐makers who would purchase the application, such as the VP of operations. The head of operations is going to look at how the product reduces operational costs.

My observation is that Agile has shifted focus from value to functionality. I fully embrace the power of Agile to translate user needs directly into great software solutions with epics and user stories. However, as we now understand from stakeholder value analysis, users are often not the people making purchase decisions, and building the solution in small increments of user needs causes Agile teams to “miss the forest for the trees.”

More often user stories are disguised functionality or feature requests that make teams think they're actually “doing Agile.” I've seen stories like:

As a user I want a drop‐down menu to select the account.

Or even more blatantly:

As a user I want a new feature that …

Teams are reinforced for demonstrating user functionality in the sprint review, not for creating value. Using Investments as a first step in Agile planning ensures that value is established first and user stories relate directly to that value.

Melissa Perri in her book, How to Avoid the Feature Trap [1], affirms the observation that features defocus value:

The build trap is when organizations become stuck measuring their success by outputs rather than outcomes. It's when they focus more on shipping and developing features rather than on actual value those things produce.

The Investment model quantifies “value” in terms of income. The minimum feature set to attain that value can then be defined, with a trade‐off between additional functionality and backlog Weighted Shortest Job First (WSJF) rank. Adding features increases cycle time and reduces WSJF, so we want to strive to define the smallest feature set that enables an Investment to achieve its financial objectives.

7.2 Feature ROI

T‐shirt sizing was introduced previously to calculate Investment WSJF. T‐shirt sizing can also be used at the feature level to allow financial comparisons of features, even among different Investments.

T‐shirt sizing of features within an Investment is a useful process in itself. I've found that there is tremendous value in bringing together product management and engineering for the exercise. It facilitates discussion and common understanding that can result in significant increases in value and lower development costs. Conversations go along the lines of:

Product manager: “Why is the effort so high for that feature?”

Engineer: “Because you wanted a completely different report layout from what our report engine currently provides.”

Product manager: “I didn't think it would make that much difference. What if we went back to a traditional report format?”

Engineer: “That would reduce the effort from ‘XL’ to ‘L.’”

The business value in traditional T‐shirt sizing is subjective. It's determined by product management and can be based on numerous factors, like revenue, competitive positioning, or market penetration. Often, it's just based on strong opinions. With the Investment model, T‐shirt “value” becomes more specific. It is the degree to which a feature contributes to Investment income.

T‐shirt weighting points can be used to determine relative contribution of a feature to Investment income. Features should be compared within the scope of an Investment. That's much easier than trying to assign business value to hundreds of features sponsored by different product managers.

We can prioritize features within an Investment based on relative Return on Investment (ROI) contribution. Consider the AccuWiz Quick Close Investment comprised of three features as shown in Table 7.1, each weighted with a T‐shirt size based on relative contribution to Investment income. Assume T‐shirt sizes of XS, S, M, L, and XL correspond to point values of 1, 2, 3, 4, and 5, respectively. The “relative contribution” can be calculated by dividing the point value of a feature by the sum of the points. For example, the relative contribution of the Outstanding Purchase Orders feature in the table is 2/10 = 20%. Assume the Quick Close Investment generates $700K of income in the first three years. Income of 0.2 × $700K is attributed to this feature.

T‐shirt sizing based on relative effort can be used to estimate feature development costs, assuming an average labor rate for the Investment. This will allow us to calculate ROI on a feature basis. Table 7.2 assumes development cost of $500K and apportions cost contribution using the same point weighting method.

Table 7.3 calculates three‐year ROI for each feature.

The ROI value is meaningless as a separate value because all features are released with the Investment. If a feature could be released separately to generate income, it would be an Investment that could be prioritized by WSJF. The ROI calculation should be viewed as a weighting factor that indicates the relative importance of including that feature within the Investment to maximize ROI.

ROI can be used to prioritize features. Recall that we need to have feature contingency to meet Investment cycle time targets. The lowest ROI features should be dropped from the Investment if burndown projections show that all features cannot be completed by the target date.

The ROI calculation example raises the question, “Why should we include Outstanding Purchase Orders in this Investment?” The next question is, “What would the Investment income look like if we didn't include the Outstanding Purchase Orders feature?” In many cases, the marginal benefit of including a feature is not justifiable. Or perhaps there is a way to reduce the functionality of Outstanding Purchase Orders to increase its relative ROI? The feature ROI view can move us closer to the Minimum Marketable Feature Set (MMFS) and shorter cycle times.

You may be wondering why we are not prioritizing the features by WSJF within an Investment. This would require cycle time forecasts at the feature level throughout the development cycle. Features are not timeboxed, so cycle time estimates vary. The ROI method provides a way to ensure that features with the highest contribution to Investment ROI are prioritized higher without having to estimate individual feature cycle times.

We can also compare the value of features from different Investments in the backlog to determine the relative priorities of features for an entire P&L center. In this case, we compare the Workflow Enhancements Investment, which is the next Investment in the AccuWiz backlog. The Workflow Enhancements Investment will be delayed by the development of the Quick Close Investment. Therefore, the three‐year income forecast for Workflow Enhancements is based only on the income that still falls within the three years. For example, an Investment with a linear income ramp that generates $300K over three years might contribute (2.5/3) × $300K = $250K with a delay of six months caused by the development of the Quick Close Investment. Table 7.4 shows feature three‐year ROI based on income of $250K.

The ROI values of Investments 1 and 2 reveal feature priorities in Table 7.5.

The combined ranking promotes a discussion on features proposed by the Investments in the backlog. For example:

• Should the Outstanding Purchase Orders feature be dropped to accelerate the Workflow Enhancement Investment?
• Could any of the higher‐value features be released as separate Investments?
• Can the effort of any of the features be reduced to increase its ROI contribution?

These questions may lead to a decision to drop the Group Queues feature. It may be possible to release Quarterly Delay Scenarios or Invoice Reconciliation Automation as separate Investments. Or the Group Queues feature functionality may be scaled back. The focus is on releasing higher value faster.

7.3 Summary

• Product management and project management plan and track in terms of features because they represent an increment of benefit recognized by stakeholders.
• Investment feature commitments should be minimized to account for Investment estimation variance to support timeboxing.
• Product managers and engineers have long histories of moving immediately to the feature level when planning products.
• T‐shirt sizing has been a useful exercise to foster collaboration between product management and engineering to define higher value with less development effort.
• Investments provide a way to relate features to financial value.
• A T‐shirt sizing method can be used to prioritize feature value contribution in terms of relative ROI.
• Product management should determine what the Investment income profile would look like without lower ROI features.
• Feature ROI can be compared across Investments, allowing product management to make decisions on features to drop or resources to transfer.
• The greatest benefit of the feature ROI calculation is the questions and discussions raised to get closer to the MMFS.

Reference

1. 1 Perri, M. (2018). Escaping the Build Trap: How Effective Product Management Creates Real Value. O'Reilly Media.