Home » Metrics » How to do agile estimation the right way

As organizations and teams mature their agile practices they are often faced with new questions. Leaders might ask, “Can you tell me when the feature we prioritized will be done,” or “Can you share with me a list of features that are likely to be done over the next few months?” A product owner might ask, “How expensive and complex is this enhancement,” and the operations team might want to know, “Can you squeeze in these defect fixes in the next sprint?” … Many agile tools measure team velocity, or how much teams can get done in a sprint, and teams will want to define, measure, stabilize, and ideally increase their velocity. More advanced teams often want to look at their overall performance across many sprints: Are they delivering higher quality when they work on lots of small stories, or just a few big ones?  … Agile estimation requires you to come up with a methodology on how a team should develop consensus on the estimate. You might hear about planning poker, the bucket system, affinity mapping, and other estimation techniques. In my work, I usually empower teams to decide how they will work together to come up with their estimates, but I do provide some guidelines. Estimates should reflect on the effort and complexity of the issue being worked on and should account for everyone’s work. InfoWorld,  August 29, 2018, How to do agile estimation the right way. Image: Black Pepper Software Limited

What made me fall in love with Scrum was … velocity.  Someone was using objective data to see how well they were performing.  Perfect, I thought. Someone finally accepted that the complex methods rarely meet, let alone exceed, simple numbers, such as averages and then they put it into a cogent software development method.  Maybe an agile approach is OK after all, I recall thinking, except for that pair programming thing.

So then, what happens when we need to estimate the overall effort?  A whole bunch of Scrum sprints needed to put a product out the door?  I kept looking for the recommended method but never saw anything that looked different than the classic approach of getting people together and deciding based upon their individual work estimates.  Ugh.  Certainly, that hadn’t worked well in the past, at least nowhere I had developed or managed or researched.

What had worked for us?  Velocity or better stated the methodology behind velocity, the average.  It always drove people crazy that I’d advocate averages or I’d simply use averages on my projects.  The first sign that the averages were better than the complex, Monte Carlo, regression lined, dynamically programmed, wisdom-of-the-crowds estimates, was that it was always longer than the duration produced by these more complex methods.  The other notable characteristic of the average was that it was always right in the middle of times it actually took us to complete our last projects.  Why that would surprise anyone, was always a mystery to me. Especially as we had regularly missed our delivery dates by typically 20-50%.

When I saw this article’s title, I happily clicked on it looking to see how someone had probably shown how to use a velocity type measurement for the project as a whole and how they had improved their estimating and now they were consistently hitting their deadlines. Nope.  Instead, it looked like the classic “try these things, I’m sure they’ll work” along with no mention of how it had worked for the author.

Compare with ‘Let’s try this’ is not a metrics plan

When management or experts would argue that the average was too simple, I would suggest that they use their desired method and also compute the average and then track both of these estimates together.  It would be hardly any effort to do that, but it was amazing how often — just about always — that the reaction was that they were not going to do that.   One would think they would want to do that to show me up and shut me up, but no one ever took that opportunity.

See also Is your estimation on steroids? and Your average is powerful!

Is your other project estimations as objectively based as your Scrum sprint velocity?




Thank you for sharing!

Leave a Reply

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

Name *
Email *

This site uses Akismet to reduce spam. Learn how your comment data is processed.