Looser Approaches to Predictability

The discussion so far has been based on a pure predictability approach. At some point in the project, the organization wants to be able to predict the exact combination of cost, schedule, and functionality that will ultimately be delivered—without changing any of them very much. The need for this level of predictability is common in some industries and comes up only occasionally in others.

The more common need I see is for a looser level of predictability that allows for ongoing management control of cost, schedule, functionality, or all three. As I’ve written previously, many times the role of estimation is not to make a pin-point prediction but to gain a general sense of whether this general type of work can be completed in that general time frame (McConnell, 2000). This is not really “prediction,” because the entity you’re predicting keeps changing. It’s really a combination of prediction and control. Regardless of how it’s characterized, it can meet the organizational need for “predictability” and it can be an effective way to conduct a software project. Agile practices provide good support for this loose predictability.

Loose predictability during top-level budget planning

Some Agile coaches recommend using the larger story point values of 21, 40, 100—or the larger Fibonacci numbers such as 21, 34, 55, and 89—for top-level budget planning, even if they are not used for detailed estimation. For reasons already described, using those numbers in that way is not valid from a strict prediction point of view. From a looser pragmatic point of view, using numbers in that way can serve a useful purpose. The organization just needs to be aligned on what those larger numbers mean.

Use large numbers as proxies for risk

You can assign numeric values to epics (or other large items such as themes, features, and so on), recognizing that each use of a larger number adds a little bit more risk to your predictability. Review the ratio of points from detailed stories vs. points from epics. If 5% of your points are from epics, there’s not much risk to your overall predictability. But if 50% of the points are from epics, risk to predictability is higher. Depending on how important predictability is to you, that might matter or it might not.

Use epics as budgets, when predictability is needed

Another approach to estimating epics and other large items is to use numeric estimates and treat those numbers as budgets for detailed work in each area. For example, if you’re using a Fibonacci scale and the team estimates an epic as 55 story points, from that point forward you treat the 55 story points as the allowable budget for that epic.

With the epic-as-detailed-budget approach, when your team refines the epic into detailed stories, it is not allowed to exceed the 55-point budget for that epic. Your team will need to prioritize its more detailed stories and choose those that provide the highest business value within the 55-point budget.

This kind of approach is common in other kinds of work. If you do a kitchen remodel, you’ll have a total budget for the remodel, and you’ll have a detailed budget for cabinets, appliances, countertops, hardware, and so on. The detailed budget approach works equally well for software teams. It provides the organization with a feeling of predictability, one that is achieved through the combination of predictability and control.

From time to time the team will blow its budget—in the example, it won’t be able to deliver the essence of the intended functionality within the 55-point budget. That will force a conversation with the business about the priority of the work and whether it’s worth extending the budget. This kind of dialog is healthy, and story point assignments facilitate it. It might not provide the same level of predictability that strict-predictability approaches do, but it might be acceptable or even preferable if you value incremental course corrections more than you value pure predictability.

Predicting delivery dates for a combination of core feature set and additional features

Some organizations don’t need predictability of 100% of a feature set. They need assurance that they can deliver a core feature set within a particular time frame, and they can be opportunistic about the features they deliver beyond that.

If the team we’ve been using as an example needs to deliver a core feature set of 1,000 story points, it can predict that it will complete that core feature set after about 20 sprints (40 weeks). That leaves a capacity of about 6 sprints or 300 story points for the remainder of the year. The organization can make long-range commitments to its customers about the core features, while still leaving some capacity available to deliver just-in-time functionality.