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.
- 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.