Summary
#NoEstimates is a challenge to the traditional thinking that estimation is essential to agile development. Ryan Ripley believes there are more interesting tools 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. Learn some other ways to deliver value to your customers.Delivering Value with Agile and #NoEstimates
articleBy
|
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.
About The Author
Community Sponsor
User Comments
11 comments
|
February 2, 2017 - 2:39am EST
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
|
February 2, 2017 - 11:12pm EST
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
|
February 3, 2017 - 12:51am EST
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.
|
February 3, 2017 - 1:42am EST
(there's an "estimates-based" in my comment. I meant "estimates-driven")
|
February 2, 2017 - 2:20pm EST
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?
|
February 2, 2017 - 11:33pm EST
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
|
March 17, 2017 - 10:57am EDT
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.
|
March 18, 2017 - 7:55pm EDT
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.
|
March 18, 2017 - 8:12pm EDT
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.
|
August 18, 2017 - 6:05pm EDT
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.
|
April 22, 2018 - 4:04pm EDT
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.
Not specified
Lets Hang!