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.
User Comments
Ryan, thank you for taking the time to put some thoughts out here around the idea of agile estimation. It’s a hugely important topic with a wide range of opinions and a wide range of misinformation. Here were some things that stood out as I read through your post.
First and foremost, I think it’s important to separate value from estimation. Estimation can figure into value, but in and of itself, estimation does not define the value of an item of work. Value is a purely customer/product owner defined metric.
The product owner, as the steward of the strategy to deliver a product/project, must constantly, with the input from the development team, stakeholders and customers, evaluate what is the most valuable thing that a team can work on at any given moment. The team can recommend what they think is most valuable, but ultimately, the one held accountable for the actual business value of the product is the product owner. Defining how large or small something is serves a separate function than does identifying its business value.
The other thing to keep in mind is that in an agile project, scope IS the variable element. This is absolutely key in fulfilling the goal of the project. Why? Because things will be found that weren’t initially thought of and other things will become less important once the product owner and team complete work items and deliver a valuable working.
This means, that a lot of the items that were “estimated” will fall out of scope. The most successful teams are those teams that can continue to split work into smaller stories of value and provide the product owner with the option to prioritize the most valuable story. This constant pruning and choosing will yield a product with lots of value while the less valuable stories will remain in the backlog, not in the product.
So with those two things set, we can look at estimation. The activity of estimation is typically thought of as a time tedious time consuming task to arrive at the best guest of effort to accomplish a given task. If we break this activity down it might include some of the following work, (just a hypothetical):
·
In waterfall, most likely the entire body of work is estimated
·
Meetings with the development team to ensure understanding of the ask (this is typically 1-2 members of the team as it would be impractical to include the entire team)
·
A review of any provided documentation
·
One or more developers outlining the thought through steps of what should happen
·
Application of an hours/efforts estimate to the work
·
Add in percentages for QA and UAT
·
Pad the estimate a little for the unseen
Some things to keep in mind with these estimates:
·
It’s only as good as those doing the estimating
·
It assumes that the solution outlined by the estimates is the best solution
·
It assumes that nothing will change
·
It was developed in a silo (little collaboration)
·
This takes someone away from value producing work
·
Typically this estimate will be wrong, and there will be no fundamental alteration in how estimates are generated
It wouldn’t be uncommon to have this estimate work completed for any one of the following scenarios.
·
A prospective customer has requested a proposal for an outlined software system. The sales team needs to get an estimate back to the customer.
·
The management team is aligning full time employees to upcoming projects and needs an estimate to evaluate who can work on what projects and for how long.
·
The organization needs to purchase media buys for an upcoming software release, they’ve requested an estimate from the development team so they can lock the purchase in six to eight months in advance.
One of the things to first notice about these scenarios is how the estimates are tied to concrete choices to be made in space and time by the organization. This is a crucial point; we’ve just taken something with little basis in certainty and tied our business decisions and outcomes to the validity of this estimate. And, here’s the thing; ESTIMATES SUCK!!
My estimates suck, your estimates suck, their estimates suck; everyone’s estimates suck. So why on earth would we hitch our business horse to something that we ALREADY know sucks?
Knowing that our estimates suck, we can begin to introduce some flexibility into our estimates and begin to call them forecasts. Knowing that there is variability in our forecasts, we could begin to alter out mindset to allocate fixed teams for a fixed time period and apply our variability to the depth of feature implementation across our product or project. Said another way, we could fix the cost and the time frame and focus teams on continually breaking upcoming work into ever smaller valuable units of work; providing our product owner with the ability to prioritize the important work allowing the least important work to fall down the backlog. This ensures we deliver on the epic and feature level functionality, without being tied to potentially project killing stories.
Although estimation in general is a waste, it supports us in building quality software by helping us to determine acceptable units of work and creating metrics we can used to forecast the future based on our past success or failure in estimating. Through this lens, it can support our continuous improvement.
If estimation is useful for product quality and value, how much time should we spend on it? Remember we suck at is, so let’s spend as little time on estimating as possible. Teams can use techniques such as relative sizing, affinity sizing and planning poker to quickly estimate story points. The days of spending weeks to months to estimate are long gone as it simply hasn’t proven more valuable then actually producing working software.
Pages