Simply, #NoEstimates is a Twitter hashtag used to discuss the dysfunction that surrounds estimation. The conversations question whether estimation-driven development is the clearest way to delivering value to customers. #NoEstimates is a challenge to the traditional thinking that estimation is essential.
As an agile coach, I believe there are more interesting tools than estimation available to help us determine what value is and when we could realize it, while still staying aligned with the businesses and customers we serve.
Minimum Viable Product and Value Delivery
The first principle of the Agile Manifesto is a commitment to value delivery: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
There is a lot to unpack here:
- Satisfying the needs of the customer is our highest priority
- We achieve our highest priority by delivering valuable software early
- Alignment is maintained between the customer and team by delivering valuable software frequently
The Scrum agile framework uses the role of the product owner to define value. The product owner defines epics and stories for a product, which are then decomposed and refined by the Scrum team at regular intervals as they learn more about the product through delivery and feedback.
During this process, stories will get sliced small enough for a team to deliver them during a sprint. But slicing the story to the point of not adding value to a product is cutting too deep. Vertical slicing requires standards and discipline.
When it comes to making a minimum viable product (MVP), we have to remember the viable part. This can be a version of the product that helps us learn more about our problem, customers, or software. But it is not the same as “the right version of our product to ship to production.”
Agile is inherently iterative. We are continually learning about and refining our product. We create space for emergence by taking small, incremental steps. Keeping the MVP in mind helps us adhere to the first Agile Manifesto principle and deliver early.
Try Tools Other Than Estimation
A story map is the big-picture view of the product. It is a highly visible artifact that keeps the customer and the agile team aligned on what the overall product should look like at a given moment in time.
Epics are laid out across the top of the story map, with the smaller stories to achieve the desired outcomes of the epics broken down below in priority order. A horizontal line running across the story map designates what is essential (above the line) and what can wait for future releases (below the line).
As a team improves at slicing its work into valuable stories that can be delivered within a sprint, the size of stories tends to normalize over time. With similar-sized stories, we can simply count the number of cards completed per sprint.
If you look at the number of cards completed per sprint and the number of cards above the line left to complete in order to get to your MVP, you can do simple math to derive the number of sprints you think you need to ship your product.
Because an agile team is often composed of three to nine cross-functional team members, you can again do simple math to determine how much the team costs per sprint. This is your burn rate. Multiply the burn rate by the number of months you’ve forecasted to ship the product, and you have both a cost and duration.
For example, take a team of five people at a cost of ten thousand dollars per week. This team finishes five stories a week. Our story map shows that we have fifty stories left to complete our MVP. This means we have ten weeks of work remaining, so we need to invest a hundred thousand dollars to potentially hit this deliverable.
Is this method perfect? Nope. Will the math change? Certainly. But it is likely accurate enough for now, and it will get more accurate as the project progresses and the team learns more about the product and how to deliver it.
Answering the Difficult Questions
Management often requests estimates to answer important questions:
- Where should we invest our limited resources?
- What team or teams should I allocate to a particular idea?
- What are the tradeoffs among benefit, the time and effort it takes to deliver, and the cost of delay?
- How can we coordinate software delivery with other organizations involved?
However, I do not believe these questions (and the underlying needs) are best served by an estimate. Our goal is to delight our customers. Invest in the features that make that happen. “How much?” and “By whom?” and “When?” are all questions that can be answered by performing calculations and collaborating with the customer.
Organizational collaboration is best served by being transparent with impacted business partners and involving them in your project activities. Transparency and collaboration tend to breed trust and cooperation.
A key goal of #NoEstimates is to challenge the thinking that estimation is essential. Story mapping, card counting, story slicing, cost flattening, and other agile techniques are cheaper and more effective ways to meet the needs of our customers and the demands of our business partners. Try some of these ideas out during your next sprint and let me know in the comments what worked and what didn’t.