The Case for #NoEstimates

[article]
Summary:

The #NoEstimates movement isn't really about no estimates. It’s about working in a sufficiently agile way that you don’t need estimates. When you break down your work into smaller chunks, you provide more value by delivering working product than you do by estimating. What would it take for you to work that way?

If you are agile—and especially if you’re using Scrum—you likely know the problems of estimation. You can avoid those problems if you adopt the #NoEstimate approach.

You may have seen or heard of the #NoEstimate hashtag on Twitter. It’s not really about no estimates. It’s about working in a sufficiently agile way that you don’t need estimates. When you work that way, you provide more value by delivering working product than you do by estimating. What would it take for you to work that way?

You would have to deliver small, valuable chunks of work every day, or more often. That would mean that the product owner has enough feedback from the product development team to understand how to make those stories small enough, or that the team works with the product owner often enough to write small stories together.

Story Development and Delivery Requires Feedback

For many agile teams, the stories come from the product owner, or PO. The team estimates and provides that estimate or commitment to the PO.

At the demo, the team shows what they completed since the last demo. There is one part of the feedback the team owes the PO: if this story took longer than one day, how much longer it took.

When the PO learns how long the story took, she understands the complexity of the story. That’s feedback.

POs need to learn to see working product all the time, not estimates. When the PO sees working product, many of the estimate “needs” disappear.

#NoEstimates Changes the Needs for Estimation

When POs and the teams see working product every day or more often, teams don’t need to estimate the end of the project or what they can complete in an iteration. They count the stories. That is a good approximation to what they can complete in a timebox or until the end of the project.

#NoEstimates changes the need for blame, also. Whom would you blame if a story is too big? The PO? The team?

When teams work with POs to make all stories about one day (or less) in duration, there is no need to blame anyone.

That leaves us with the gross estimate to understand the project’s relative size. If you have one-day stories, you probably don’t have them all at the beginning of the project. On the other hand, if you realize what it takes to break a feature set (or epic or theme) apart, you might be able to use a little prediction to see the potential duration of all the feature sets.

That gross estimate is useful for the value assessment also, and teams don’t have to estimate for an iteration.

Making Stories Small Is a Challenge

I won’t lie. Making one-day (or smaller) stories is a challenge for many teams and POs.

Here’s one way to think about this problem: You have to do the work, one valuable chunk at a time, anyway. Why not try to break apart the value into small chunks?

When I teach this in my workshops, the POs and the teams all are concerned. They have no way to think about making stories this small. When they try it with guided practice, they learn how.

Aiden, a lead developer, discussed how his team learned in a software as a service application:

We first tried this in the workshop and were almost able, as a team, to finish one story in one hour. We realized what we needed to do in the next story, and we did finish that in an hour. Practicing made all the difference.

How were we going to do this in our application when you left? We have architecture concerns, testing concerns, technical debt up the wazoo. We weren’t sure, even though you suggested some ideas in the workshop.

We decided we needed more flexible architecture. We tried your “take three very small features, implement them first, and see what happens with the architecture” approach. I was nervous about that because I am responsible for the architecture.

We tried three small features, each of which we did in less than a team day. They were really small. We had to get our PO to come visit us at what he called “off times.” But, every time he gave us feedback, he simplified the rest of the stories. I would never have believed that. He eliminated several that would have made our architecture more complex.

We finished the rest of the feature set. We had originally estimated it as an 8. We ended up doing almost two weeks of that feature set, which would have made it a 13. We had no idea how complex two of the stories were. One story took us two days, and another took us three. But, because all the other stories were not more than one day, we made up the time. We were on target—something we haven’t been in the entire two years we’ve been doing Scrum.

We changed from each person taking his own story to pairing or swarming on stories. We made each very small piece valuable. We stopped trying to determine the architecture up front and letting it evolve. I still have trouble with that. But we are going in the right direction. We are getting results from our agile project now.

#NoEstimates Guides You to Better Practices

Because Aiden’s team was tired of missing all their estimates and commitments, they tried #NoEstimates. Because they wanted to work without estimation, they changed their practices to fit their team better.

Could they have done this without #NoEstimates? Sure. But they had been attempting to do agile for two years, and even with their retrospectives, they had not seen the value they expected.

#NoEstimates is not the goal. Better product development is the goal. If #NoEstimates helps you think about the way you work differently, maybe you can try it.

If you still need to estimate, never provide a single-point estimate unless you have built in a lot of wiggle room. You know that the requirements will change. And, unless you break your stories down into very small chunks, you will guess wrong.

Good luck.

User Comments

16 comments
Henrik Ebbeskog's picture

Nice post!

But I'm confused. Why go through the effort of calling it #NoEstimates?

Estimates (as defined in dictionary): to give or form a general idea about value, size or cost.

Reading this: "teams don’t need to estimate the end of the project or what they can complete in an iteration. They count the stories. That is a good approximation to what they can complete in a timebox or until the end of the project." That's estimating.

And when counting stories, I'd still like to say "Hey, I don't think that story fits inside this sprint". Isn't that estimating?

I don't understand the need to call this "no estimates" when it's actually full of estimates.

Otherwise, I love the approach. And it's actually exactly how we work. Though we call it estimating :)

Kind regards

April 22, 2015 - 1:06pm
Johanna Rothman's picture

Hi Henrik, the question is this: Do you want to spend time estimating or delivering? The NoEstimate approach says, "We will deliver on a continuous basis. You can change what we do at any time. Our product is always releasable, so you can make the business decision to release at any time.

If you do work in iterations, you can then count the stories, and have a good approximation for what you can accomplish in a sprint. You give the example of "I don't think this story will fit..." The question is this: Is that because you have more than 10 stories (or whatever number you normally have), or is that because the story is too large? If too large, you are definitely estimating. That's not a problem. However, if you want to deliver continuous value, does that story need to be broken down? 

The idea in NoEstimates is that you never have such large stories. You always deliver value every day. 

I can't tell from your description if that is what you do. I'm glad that what you do works for you.

 

April 22, 2015 - 2:24pm
Henrik Ebbeskog's picture

Hi! Thanks for response!

When in "maintenance mode" we tend to work like that. We always work on small improvements/adjustments and usually always have something to deliver. Like daily. And what we have is almost always valuable.

But it's quite specific scenario. And far from applicable to everyone. But that's OK.

I see it like this; *everything* we do that is of value, to those paying us, can't be broken down (and still be of value). I think that correlates well with my own personal life as well. No one can remodel my kitchen in one day. It can't be broken down so that I feel I have something valuable. I'm not pleased until I have my kitchen. Same goes for software, it's not that special. We're still just solving ideas/needs/problems.

And when we're building completely new things, it isn't valuable until the customer have its capability. Usually they're not really interested until we're almost finished. And I can't blame them. Value is far from always breakable into daily chunks. The kitchen metaphor matches here as well.

And even if it was; "daily" is an estimate. Otherwise, why daily? Why not every second, or millisecond? Seems impossible right? That's because we estimate that "daily" is enough to always deliver something. Even though the estimates are implicit and informal, it's still estimating. And being explicit, transparent and honest is usually always better. Because suddenly someone have expectations, and you better get those expectations out there for scrutiny.

Kind regards

April 22, 2015 - 4:27pm
Johanna Rothman's picture

HI Henrik, a couple of key points:

  1. You are correct. You cannot remodel a kitchen in one day. And, software is not construction. When we remodel, we often find valuable work to deliver to a client at least once a week, if not every day. (We had a huge reconstruction project on our new house last year. We did see deliverables almost every day. Sometimes, those deliverables were destruction. Sometimes, construction. The question is: What do we deliver, and is it useful to estimate or deliver? 
  2. You are also correct with the "why not deliver more often?" When I teach or coach teams, I help them learn what it's like to deliver every hour. That so far out of their norm, that they cannot imagine it. When they can imagine it, because they have done it, that changes their ideas about what value is and how to deliver it.

As I said, NoEstimates is not about the lack of estimation. It's about your ability to provide value as opposed to detailed estimates.

Thanks for commenting.

April 23, 2015 - 7:54am
Henrik Ebbeskog's picture

Hi!

Thanks for clearing things out! I totally agree about your points. Though I still don't get the hashtag. Delivering every hour is still an estimate :) And we always want to have a sense of total cost (I guess you did too, when you remodeled the kitchen). And having a sense of how much is left of the all-in work is valuable too. Having a tight feedback loop and continously showing progress and focusing on providing tiny bits of value doesn't remove that need. I think we can (and should) focus on continously delivering value *and* give an idea of how much is left.

#NoDetailedEstimates is perhaps a better name? But why do detailed estimates? Or #JustEnoughEstimates? Or even better, a name that tells what it is (or what one does), instead of what it isn't (or what one doesn't do). Maybe #ContinousValueProviding?

Oh well, that's just me. I'll learn live with it :)

Kind Regards

April 23, 2015 - 8:54am
Glen Alleman's picture

As well you're not developing and deploying the current ACA enrollment system in a day, or intergating SAP with three of your legacy systems, or building the GPS III ground system, and actually much of anything that has an "enterprise" or "software intensive systems" charatcteristic. 

Agile is used in all those domains, but the Estimate to Completer and the Estimate At Completon are business needs not necessarly the needs of the developers. 

No Estimating, while applicable in some domains has yet the define what those domains are. It is suggested form the advocates that it is applicable in a wide range situtations, wityhout actually confirming that from those paying for the work.

April 23, 2015 - 12:52pm
Johanna Rothman's picture

Hi Glen. You are correct in a number of areas:

  • There is no one approach that will work for all development. None at all. (That's why I don't like the term "best practices.")
  • Your domain matters. Your customer matters. I spoke briefly in this article about a gross estimate. In the previous article, How Do Your Estimates Provide Value? I talked about a gross estimate, where you provide an estimate to the best of your ability for what your customers need. There are many products where your "minimum indispensable feature set" is quite large. Providing an estimate for that MIFS can be a great idea.

NoEstimates are not for all teams and all projects, even if they are agile. 

However, these facts are true:

  • Agile is about change. If you estimate the entire product backlog, and you don't implement that entire backlog because you have enough value earlier, is that an estimation problem? (I don't know. I have seen this especially for large programs or long projects.)
  • If you are agile, and you spend more than two hours estimating for an iteration, I assert that the team is spending too much time estimating. They would do better to deliver value instead of estimating. The stories are too large. The team can't produce value every day.
  • If teams continue to estimate projects not yet started, and that prevents them from completing the product they are working on, that's a problem. I have a client where every month, the teams re-estimate projects they have not yet started. I suspect you would agree with me that this is not a good use of the team's time.

If the tag NoEstimate gets people thinking about how to produce value each day, that's a good thing. NoEstimates may not work for a gross estimate. Many organizations want a reasonable guess (estimate) of what they will invest to see their first (and maybe, last) value. But spending even 10% estimating in an agile project instead of delivering? That does not make sense to me.

I wrote about measurements that might be more useful than detailed estimates: Why Managers Ask for Estimates and What They Need to Know. I am not trying to trivialize this problem. 

BTW, I am not suggesting agile is the only right way to do projects or programs. In many cases, I recommend staged delivery, because the product backlog is not going to change for much of the project/program duration. You can still see features form, although you might not have internal releases.

Your context matters.

April 23, 2015 - 2:49pm
Henrik Ebbeskog's picture

"If the tag NoEstimate gets people thinking about how to produce value each day, that's a good thing."

That's great! But, that's not my experience. When I get questions about what NoEstimates is, it's always related to "How does one work without estimates?" (or similar). And I admit that it was the intitial feeling I got too. And when I talked to my CEO he was almost a bit upset (almost).

So I'd have to disagree, that is not what the tag gets people to think about. And if you have to start by explaining that the tag isn't what it is - it's not a good start for a conversation. So, no, the tag actually - and originally - means "no estimates". But up to this day, no one has provided info on how to work without estimates. The only pushback has been that it's not "never estimates". It's just that it's also never "never estimates" :) Because estimates are ubiquitous and fully normal (both in personal life and in business). Just because we do implicit estimates doesn't mean we aren't doing them.

Estimate: "to give or form a general idea about value, size or cost".

So, question remains: how do you make decisions without having a general idea about the impacts (value, size or cost) of the choices you're deciding among?

If NoEstimates = "Think about how to produce value each day" it's a really weird name/tag :) 

April 24, 2015 - 5:28am
Johanna Rothman's picture

Henrik, maybe you have not been in "estimation hell," where people spend many hours trying to decide how much they can do for the next sprint. Or, where management wants a +/- 10% estimate for the project, so people have to estimate in detail. Or, where the team never meets their sprint commitment because they can't estimate anything. Everything is all too large.

Instead, the #NoEstimate tag is about the discussion of "how do we provide value so we don't have to estimate"? Maybe it's a strangely named tag. And, it gets people talking about how to not have to estimate.

April 27, 2015 - 7:54am
Henrik Ebbeskog's picture

No, I haven't really been there. But of course, I can recognize parts of it. It's called poor management, and has nothing to do with estimating and the value of doing it *healthy* (this is referred to as Sturgeon's law; "90% of everything is crud").

Actually, what I see are false dichotomies, black-and-white mindset, Sturgeon's law, etc. And I'm certain it's because of the name of the tag. What we say makes us think likewise. The words we use matters.

I see it in your reply as well. The word "instead" is used. It's not about "instead". I.e a false dichotomy. We can provide value *and* estimate. Why should we talk about how to not estimate? Why such drastic actions? "We suck at this! We must stop." What if we said the same thing about programming? "We suck at JavaScript! We must stop use it."

Something that is valuable to the people paying us for the work we help them do. And yet, no one has provided info on how to do make decisions without having a general idea about the impacts of the choices we're deciding among. And how should dates and "deadlines" be set? Should we just stop and let team "provide value until someone is satisfied"? Who would agree working like that, with no sense at all of what the goal is?

The thing is: plans matter. But boneheadingly following a plan is just as equally bad as not having a plan at all. A healthy plan that we adjust continuously when we get new information. Having a healthy discussion about expectations and needs.

May 1, 2015 - 10:13am

Pages

About the author

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.