Delivering Value with Agile and #NoEstimates
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
Hi!
Here's my breakdown:
"#NoEstimates is a Twitter hashtag used to discuss the dysfunction that surrounds estimation."
I don't buy this word play. It's like Trump saying that #NoIslam is a hashtag to discuss the dysfunctions that surrounds Islam. Or students saying that #NoMath is a hashtag used to discuss the dysfunctions that surrounds math.
"question whether estimation-driven development is"
I refute such rhetorics. Construct some "evil" made up demon and attack it. What is even "estimation-driven"? It doesn't exist. Unless playing with words. It reminds me of "Make America Great Again": paint a picture of America as somehow not being great anymore. Repeat it and people will start to believe there's something there or even true. It's simply agitation. Not good.
"challenge to the traditional thinking" is the same thing; what is "traditional thinking"? Not my "traditional" at least.
"the role of the product owner to define value."
This seems like some old version of scrum/agile. This is much more of a collaboration for PO, UX, CEO (or whatever) to define value. The dev team are of course welcome to have input.
Then this article tries to cover things that are roughly summarized under the topic "Try Tools Other Than Estimation" like slicing and story maps etc.
This is a strange distinction/dichotomy. Those are of course great tools/approaches. But they can't be categorized as other tools than estimation. They aren't related and doesn't exclude estimates.
And of course, soon enough the article starts to mention estimates:
"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."
And also:
"'How much?' and 'By whom?' and 'When?' are all questions that can be answered by performing calculations"
This article then finishes off the same way it started by creating a made up demon that somehow needs to be fought: "challenge the thinking that estimation is essential". Who even has this thinking? Grab a coffee and sit down and talk to those people in your organization. You'll learn a lot. You'll probably find out the reason why you think these people view estimates as "essential".
Regarding your last request. I've tried and am doing all of those suggested things. One thing's for sure: estimation didn't go away. No one is even viewing it as "other way than estimation".
Best regards,
Henrik
Hi Henrik,
Thanks for your comments:
<strong>"I don't buy this word play."</strong>
I'm not looking to sell a POV on the hashtag. #NoEstimates is a place where a variety of conversations happen about software estimation. There is a wide spectrum of viewpoints represented and narrowing it down to "NO" does not give the hashtag justice. That said, I'd be equally happy if we used #LeanEstimates #AgileEstimation or a variety of similar ideas. I'm more interested in the ideas that are exchanged as opposed the semantics behind a hashtag.
<strong>"I refute such rhetorics."</strong>
"Estimation-driven" development is a neutral statement. Many organizations are setup this way and are very successful. I'm exploring using value to drive conversations as opposed to estimates. But I don't consider any tool or practice "good" or "evil". It's all about how we use these ideas and whether or not we meet the needs of those we are serving.
<strong>"This seems like some old version of Scrum."</strong>
These ideas is still new and relevant. From the July 2016 version of the Scrum Guide: "The Product Owner is responsible for maximizing the value of the product and the work of the Development Team." This is a collaborative game where the CEO all the way down to the Scrum Team have input and collaborate with the Product Owner. However, the PO owns value.
I'm adovacating that people use Agile techniques to collaborate with their customers. It is my belief that by using these tools that organizations can become less reliant on estimation and therefore minimize some of the dysfucnctions that can happen when using estimates to drive work to completion.
Part of adopting a culture of learning is allowing people to challenge their beliefs. During that process, I hope that people take your advice and have a coffee with their customers and get to the root of their needs. Perhaps they will find that estimates are a proxy for deeper concerns.
Thanks again for sharing your comments and experiences with the tools and techniques.
Best Regards,
--Ryan Ripley
You continue to play word games. The hashtag says "no estimates" and that is what it means and that is what it is about. Saying that it isn't really about "no" is strange and points at that there's something else going on here.
Estimation-driven is not neutral. Especially not when combined with the topic "no estimates". It's like a group of students claiming that "math-driven" is neutral while also saying that many schools are math-driven - under the hashtag #NoMath.
It's not defined what "estimate-based" even means. But it's clearly an attempt at creating an evil demon that somehow needs to be fought. Under NoEstimates, "estimate-driven" is clearly something bad. As if it even means anything...
We don't use Scrum. And I'd say that everyone "owns" the value in the sense that they are responsible for materializing it. In the end, it's most likely your customers who defines the value, not yourselves.
(there's an "estimates-based" in my comment. I meant "estimates-driven")
When you say
Management often requests estimates to answer important questions:
Does management NEED these estimates, as well as requires them. In my experience since 1978, it's management prerogative to requires what it needs to manage the business. Estimate are part of the decision-making process in the presence of uncertainty. No uncertainty, don't need to estimate, just measure and decide.
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?
All good questions management asks all the time. We ask them every week. Since we operate in the presence of uncertainty, the answers are provided by estimates - unless you have some other way to make a decision in the presence of uncertainty.
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
And what calculations would be performed to answer those questions that did not involve numbers that are probabilistic? When you're calculating using probabilistic and statistical numbers you are ESTIMATING.
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.
So how do these useful processes operate in the presence of uncertainty? Are all the cards the same size - statistically? No, what the impact on the confidence of the calculated outcome. Story mapping is part of estimating? Didn't know that, since we use Story Mapp as part of our Product Road Mapping process.
Slicing IS estimating. It's baked into project management processes since the late 70's (1975 in fact for first version of MIL-STD-881).
And exactly how are these methods more effective than making an estimate?
Your 4 questions are important to running a successful business. A few comments on them:
1. Where should we invest our limited resources? I believe you are referring to "people" who are not "resources".
2. What team or teams should I allocate to a particular idea? Is work assigned or accepted in an Agile environment?
3. What are the tradeoffs among benefit, the time and effort it takes to deliver, and the cost of delay? At the beginning of a project we are guessing. As we do more work, we learn more about the work. Experiments and budgets - along with rapid feedback - could lead to better answers.
4. How can we coordinate software delivery with other organizations involved? The business and development team work together daily throughout the project. They are by design aligned. However, road maps work great as do forecasts (see below).
Card counting is measureing throughput. With throughput we can get cycle-time. This give us the ability to forecast features and other product backlog items. Is this estimation? Yes, it is a *kind* of estimate. One that changes over time (hopefully updated at the end of each sprint at minimum). I suspect this is not the kind of estimate that you had in mind though...
Slicing in the sense of creating a work breakdown structure (WBS) as MIL-STD-881 describes *is* estimation. However, teams that use a heuristic such as "1 acceptance criteria per story" is slicing work in a much different way than one would to create a WBS. This is the kind of slicing that I am referring to.
How are these methods more effective than making an estimate?
If we are using Agile and #NoEstimates it means that "business people and develoers are working together daily throughout the project."During this time we are refining stories, update the story map, and looking at working software frequently - while hopefully delighting the customer.
I've found that in this type of highly collaborative environment, the conversations shift away from estimates and move towards value and continual improvement.
Thanks for your comments, Glen. I hope my answer are useful.
Best Regards,
--Ryan Ripley
This is an interesting conversation. Henri you seem like you brought your sword and ready to go to battle. Very combative or passionate I guess about this topic. I'm curious why you disagree with this article? From my perspective estimates are always a source issue with any project because people actually care about if you met your estimate or not. Humans are in general very bad at giving accurate estimates so it becomes an issue. So if our human nature is bad prediction than why do we hold ourselves to predicting? Clearly you can see how some people would come to this conclusion as think it's a problem that needs to be solved?
This is a different way of solving that problem that some people think exist. You can't just come in and say the problem doesn't exist and all those people are wrong. They feel the problem all the time so they are coming up with alternatives. You seem to be coming from the angle that estimates are simply a fact of life and there is no alternative. I don't think everyone agrees with that view.
The majority of arguments for NE are based on erroneous principles. Henri, I and several others continually point this out. Ryan provides a platform where those fallacies are rarely a direct response, instead a platform for "fair and balanced" when there can be no balanced discussion when one side has no principles on which to convey their argument
"Informed decision cannot be made in the presence of uncertainty without estimating the outcome of that decision."
This is not an opinion. This is not open to debate. This is not open as a considered alternative. This is a mathematical fact.
Until those conjecturing that decisions CAN be made without estimates - the NE advocates position, there is NO different way. Doesn't matter they "feel" the problem all the time, their proposed solution is fallacious. We know they don[t agree, but this is the behaviors of a "denier" in the same way climate deniers response to the settled sceince of cimate change. They "believe" there is a better way, but have no facts to support that belief, nor are facts necessary to support any belief. It's belief.
As you mention, they "think" it exists, with no evidence of how to get around the fundamental principles of Microeconomics of decision making in the presence of uncertainty. This blog continue top provide a forum for the unsubstantiated conjecture that such a solution does exist, without challenging those making that conjecture to show evidence of it's existence.
Ryan, I have already started using card count instead of velocity because I have seen throughput and cycle time work well as a forecasting model.
But they have a problem, and that is that they assume two things often not present in an Agile project, especially new product development:
1. All cards in the scope have been identified
2. All scope has been broken into #noestimate-sized pieces (namely, fit in a sprint)
In our projects we have many cards that represent very large amounts of complex work. Until the last responsible moment it is not possible to break them down into right-sized cards. And even if we could, the nature of the work is such that new cards, within scope, emerge as we understand the problem we're trying to solve.
As you would expect, the commitment date for full scope tends to recede as the project progresses. It would be nice if our initial forecast was such that this recession still occurred within the confidence window.
But because of 1 and 2 above, I don't see how that's possible. As much as I dislike story points, or feature points, they do permit us to "estimate" very large blocks that we know we need but it's too soon to understand fully.
I'm curious how the #noestimates folks manage this common situation.
Pages