The Case for #NoEstimates

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.