Estimation Isn’t Agile

I don’t believe that estimation should be part of any Agile practice.

One of our managers recently mentioned that we hadn’t met the “contract” that we had “committed” to in our last iteration. This was complete nonsense, because A) we hadn’t made any such commitments, and B) we completed many more story points than the previous iterations (and without inflating story points).


But her language made me come to several realizations. First and foremost, estimates are contracts. Sure, they’re not supposed to be treated as commitments, but they almost always are. And what does the Agile Manifesto say about this? It says that we should value customer collaboration over contract negotiation, and responding to change over following a plan. So it’s pretty clear that treating estimates as commitments is completely counter to the Agile values.

Why does this matter? What benefits do the Agile values bring us? I think the biggest benefit they bring is changing the way that we work, so that we can better deliver value to our customers. Without Agile, we’d just keep working the way we’ve always done things. And that didn’t seem to be working out so well. If we follow the Agile values and principles, at least we’ll have a fighting chance of improving our ability to deliver value.

Ask yourself — have you ever seen a software development project that was on time and on budget? Where the estimates were spot-on? Of course not. For one, we’re terrible at estimating. For another, our plans change — either from external factors, or from what we learn as we go.

Improved Estimation

To me, Agile is also about facing reality — and embracing it. It realizes that we’re terrible at estimating. It realizes that plans change. Most Agile methodologies have some tricks to counteract Hofstadter’s law. Generally, we use relative story points instead of hours, and then use an empirical factor to convert points to hours.

When this works, it is better than any other estimation I’ve ever seen. But it doesn’t work very often. People have trouble with relative estimation. How do you set the basis for what a point means without relating it to actual hours? Affinity estimation could work, but then you have to remember what the basis was. We’ve got a large distributed team, and when we tried this, we couldn’t all remember what the basis was.

Since we couldn’t get affinity estimation to work, we tried changing to perfect hours (only powers of 2). But then people thought of them as time. When we took longer than the estimate on an individual story, managers and team members thought we were taking longer than we should have. So our estimates ended up causing problems.

What Can We Do Instead?

Managers want estimates so that they can have predictability. They want to know when new features will be available. Is there a better way to get what we need?

I believe there’s a better way — prioritization. If you work on the most important thing first, then the most important thing will get done first. We should always be working on the next most important thing.

What if there’s more than 1 thing that’s most important? Then you’ve failed. You’ve failed at logic if you can’t understand that only 1 thing can be most important. You’ve failed at prioritizing the customers’ needs. You’ve failed at project management.


1. Why can’t you just tell us how long it will really take?

Because we don’t know. Because we can’t know. This is the first time we’ve ever implemented the functionality you’ve asked for. If we’d done it before, we’d just use that existing code. As Glenn Vanderburg pointed out in his excellent talk on Software Engineering, we’re not building software, we’re architecting it.

2. But we have to tell our customers what to expect.

Why? Is the product so bad that you can’t keep customers around without leading them on with future enhancements? And why do customers need exact dates? A general roadmap telling them what the priorities for upcoming features should be sufficient.

3. But we have to have messaging about new features.

OK. Then send out that messaging once the feature has made it to Staging. Or even after it’s been rolled out to Production.

4. But we’ve promised these new features to the customers by this date.

Ah, so you’ve made promises to the customer that you don’t have control over. Have you ever heard of “under-promise and over-deliver”? That’s how you create happy customers. Yet you’ve done just the opposite, haven’t you? And then you want to blame someone else.


Estimates are risk. But the risk doesn’t come at the end, when the estimates are shown to be incorrect. The risk was in asking for the estimates in the first place, and placing trust in them. Don’t do it. Don’t promise things that you can’t be sure of.

Embrace this reality. Embrace this uncertainty. Always focus on what’s most important. That’s how you make customers happy.

3 thoughts on “Estimation Isn’t Agile”

  1. As soon as estimation, sizing or velocity becomes a requirement outside of the team, the process is broken.

    If a team uses these internally as a tool for planning how much work they will accept, I have no problem with that – but they should look for opportunities to reduce the time spent on the numbers aspect of planning.

    Teams should question what the manager actually needs, rather than blindly exposing planning numbers.

  2. 2. But we have to tell our customers what to expect.
    Why? Is the product so bad that you can’t keep customers around without leading them on with future enhancements? And why do customers need exact dates?

    A lot of cases when you have to make brand new feature faster than your competitor or you have to meet deadline with other external things (like releasing iOS8, whatever). Or just an example when you are expecting a house will be done before winter comes so you can live in there, but workers didn’t finish it in time. Would you like to have no promises on deadline and make a decisions on each day of life? I don’t think so. Agile is for business, and if doesn’t make a things enhancing income – it doesn’t work.

    What if there’s more than 1 thing that’s most important? Then you’ve failed.

    If you have only one type of customers and one main functionality of the product – then you are right; But when product have several brunches, a lot of functionalities for several customers segment that should be delivered in one time – you can’t concentrate on one thing. Otherwise, your business fails.

    I do understand why Agile can’t answer on question When? But it still doesn’t help with making a business in brutal, full of competitors world J.

Leave a Reply

Your email address will not be published. Required fields are marked *