There’s been a lot of discussion in the agile community about whether we should estimate work. The #NoEstimates movement has grown up around simplifying sprint planning through proper backlog grooming, including the breakdown of bigger stories into smaller bites. While that’s a good tactic for achieving feedback quicker, it provides an incomplete picture of the final product. Instead of asking whether we should estimate, better questions may be, “What should we estimate when we are using agile methods, and what choices will we make based on those estimates?”

Combining Features into Consumable Value

Agile methods emphasize value and quality. Backlogs are prioritized and stories are developed in priority order. The team only “counts” a story if it’s complete, it’s been tested, and we all agree it’s done. At the end of each sprint, the highest-priority functionality that the team has had time to develop is working, so the software is “potentially shippable.” But to complete a story within a single sprint, broader epics and stories must be broken down into developer-sized bites—parts of the story that can be completed in a short timebox.

These techniques allow the iteration review to accomplish its primary purpose: getting feedback on the software completed so far so that we can see what we’ve learned and what needs to change. This prepares us to develop another chunk in the next sprint, making progress on software that will deliver value to users.

Of course, an inevitable consequence of breaking stories into developer-sized bites is that these smaller pieces may not have all the features users will need. Until enough of the higher-level epics and stories are developed to make the software useful for its intended purpose, users cannot consume the software.

For example:

• ATM software that lets you put in your card and enter your PIN but doesn’t dispense money
• Payroll software that can compute paychecks but can’t print checks or make direct deposits
• An airplane that can take off but not land

The individual bites, while useful for review and feedback, are not consumable by themselves. Over several iterations, the bites combine into a consumable meal. Consumable value is a collection of stories that provide enough value to satisfy users, and it cannot be forced into a timebox.

Keeping the “Viable” in Your Minimal Viable Product

Eric Ries popularized the term minimal viable product. The related concept, releasing in small batches, is valued by many agile organizations. But thinking of work as “the smaller, the better” works only up to a point, which is why Ries didn’t simply call it “minimal product.” The product must provide consumable value. What is viable depends on your customers, your competition, and your goals for the product.

Because it might take multiple sprints to deliver consumable value, it’s worthwhile to estimate what it will take to deliver that value—that is, it makes sense to ask, “What consumable value do we expect to achieve, what duration and cost should we plan for, and how likely is it that the plan will succeed?”

This is very different from iteration or sprint planning, where the primary question is “Given where we are now and the backlog we have in front of us, what developer-sized bites should we include in the next timeboxed sprint?” The backlog items may need relative size estimates to help make that choice, but that is for a fundamentally different purpose from an estimate to achieve consumable value.

The purpose of estimates based on consumable value is to help make overall decisions, some of which must be determined before development of specific stories even starts. These include:

• Where should we invest our limited resources? Most companies have many good ideas for new and enhanced software—usually more good ideas than resources to carry them out. Choosing which ideas to invest in requires balancing the benefits to be delivered against the resources and time they will take to produce.
• What team or teams should I allocate to a particular idea? There’s usually a complex tradeoff among the time it takes to realize benefit, the resources applied, and the risk of meeting that plan.
• What are the tradeoffs among benefit, the time and effort it takes to deliver, and the cost of delay? Delaying delivery is detrimental, but if we reduce the scope too much to speed up delivery, we reduce the consumable value. Multiple estimates that show how options for scope would affect time to delivery allow us to make informed choices, yielding plans that are both minimal and viable.
• How can we coordinate software delivery with other organizations involved? Software development is rarely an island. Other organizations have to plan based on when they can expect value from the delivered software.

Estimating to Reach Your Goal

We used to think we knew exactly what and how to estimate: We would turn a proposal into a project and estimate the required duration and effort. This was based on the classic notion of a project being a temporary endeavor, with a definite beginning and end, to create a unique product. But software development is hardly ever that delineated. How your company organizes software development work depends on many factors.

Maybe you are developing internal systems for your company and promote changes through several levels of testing, then put them into production. Or you may develop software to sell to your customers, periodically releasing major versions with innovative features or minor fix packs and bundling several innovative features into an annual release. Perhaps you are a systems integrator whose customers desire new or enhanced software, and you bid for that business. Maybe you practice continuous deployment and push out updates of your software to your subscribers when they become available.

Some of these approaches are like classic projects, and others are much less so. The relationship between delivering consumable value and “a temporary endeavor with a definite beginning and end” is more tenuous now than portfolio planners used to think. Some say that was always so, but we’re now explicitly recognizing that in our methods.

Considering delivery can take so many forms, how can you make decisions about what to invest in? The specifics depend both on your business and your methodologies, but in all cases you can set a goal for a collection of features that will provide consumable value, and estimate what it takes to reach the goal.

You will no doubt have multiple ideas for such goals, including variations on what is simultaneously minimal and viable, and you can have multiple estimates for each, trading off time and cost. This gives you information to make decisions about which goals to invest in, where to apply resources, how to plan related initiatives, and the other decisions you need to make.

Your goals should be specific enough to estimate and make decisions about. “Improve the user’s experience” may be your vision, but it is too vague to determine concrete steps. On the other hand, don’t fall into the “big upfront requirements” trap. You do not need to define the details of all the features in order to make decisions about your goals. Using agile methods to allow those details to emerge will help you build the right product.

It’s important to realize that features come in all sizes. They may be very specific (send email confirmations whenever the shipping status changes), they may be higher-level (revamp the reporting capabilities), or they may be anything in between (allow a car rental to be added to hotel reservations). Consumable value, after all, is in the eye of the eventual consumer, and that should determine your company’s business goals.