This content is part of the Essential Guide: A guide to working with Agile and DevOps methods
Problem solve Get help with specific problems with your technologies, process and projects.

Agile estimation techniques: Here's how to do it right the first time

To estimate or not to estimate is the question. And expert Jennifer Lent asks author Johanna Rothman for her best advice on estimating just enough to make the customer happy.

There's a fundamental problem with Agile estimation.

Figuring out what a software team will deliver -- and when -- eats away at valuable project time and doesn't necessarily result in accurate estimates. That makes the "No Estimates" approach compelling for a lot of software pros, but not their customers. Customers just want to know when their software will be ready.

I got to talking about the Agile estimation quandary with Johanna Rothman, author of Predicting the Unpredictable: Pragmatic Approaches to Estimating Cost or Schedule. As the title suggests, her approach is practical. I like it because it offers a middle ground between spending too much time on estimates and refusing to do them at all. I'd sum it up like this: Do some estimating, but not too much; build trust by showing the customer what you have done so far and what you will do next.

Here's some of the Agile estimation advice she shared with me in a recent phone conversation.

Agile estimation: What's it for?

How you approach Agile estimation depends on what, exactly, you want to estimate. Rothman said, for sequential, not parallel, projects, what the boss typically wants to know is, "When will you release the first value?" To answer that question, develop a product road map that states, "We'll do this feature here, this feature there, this feature here." It might not be perfect, but it gives the customer a feel for what will be done when, she said. The more specific you are, the more useful your estimate is.

For example, if you're building a transaction processing website, specify that the first deliverable will be the payment feature and then fill in further details. The first payment deliverable, for example, will support PayPal; further releases will let customers use the payment processor Stripe, and so forth. "You want to get started, to get something out there," Rothman said.

Agile estimation: Release criteria

When more than one project is in play, an Agile estimate aims to answer a different question: When will you finish this project and start the next? "There is pressure to get the first project done, and pressure to complete a second project as well," Rothman said. In an ideal world, you have sufficient resources to run the projects in parallel with two different teams. But when you don't, Rothman emphasizes the value of establishing release criteria, in addition to developing the roadmap of deliverables.

Here's her definition of the term release criteria: "How little can we do -- in the best possible sense of the word?" For example, release criteria for the transaction processing website include -- among other things -- the ability to process payments (some payment types now, others later) and adequate search capabilities. The idea is to release a minimum viable product, so you can move on to the next development project. "We don't need to do everything [at once]. We commit for little bit for now, and say what we need to do later," Rothman said. "Search works for now, and [going forward,] we'll update search with new features and performance."

Building trust

At the heart of Rothman's "we'll do this now and that later" approach is the idea of building trust between the software team and the customer. Rothman recommends doing demos every two weeks that show how a feature is implemented. "Senior management gets more confident [when you show them what you're doing]," she said. Often, management is satisfied with the team's progress and will not demand detailed Agile estimates for each feature.

But what if they do? "You have to take two weeks -- or a month -- and do a discovery project," she said. That involves identifying the full feature set and estimating a delivery date for each one. If management wants to see that level of detail, they have to allocate the time to make that happen, she added. "They don't like to do that." But until a team breaks down stories into smaller parts -- and figures out what's really involved in delivering each feature -- it's impossible to come up with reasonable Agile estimates, Rothman said.

Do you do estimates? How's it working for you? Let me know!

Next Steps

There's estimating, and then there's wild-ass guessing

Is it time for a new Agile manifesto?

What does "real Agile" really mean?

Dig Deeper on Topics Archive

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

When you're estimating, what time-saving techniques work for you?
As a senior security consultant and former CFO with over 35 years of security experience, I've seen more and more security risks created in application development since the advent of agile in 2001.  While at first I was not sure if it was or was not the fault of agile, over the years, companies who practice agile in most development projects have indeed incurred higher security debt while those who use hybrid approaches are much less likely to build security dept.  This debt must be repaid with interest.  While agile is great for some small projects, just as Microsoft's SDL states, a heavier weight and documented approach is generally required for larger projects and systems.  For those who doubt it, read Microsoft's SDL in full and pay that debt.
I have seen the same (and at about the same number of years experience). I believe a large part is simply due to the explosion in scope and scale.

As far as the Microsoft SDL, most of that has been declared obsolete by Microsoft. The entire MSF (Microsoft Software Foundations) has been retired.

With respect to "agile", I am curious as to which of the 12 principles or 4 value comparison's you think could potentially be "at fault".  If instead you are talking about some of the questionable (I am being nice) practices done in the name of agile, that is a different situation.
Often the situation of estimating is derailed due to a project expected to delivery within unrealistic timescales to fit senior management / customer agreements. So you are given a date and told to estimate to that date.
Some good information. But there are so many scenarios in the real world that require "more".

I do a fair amount of work where there are hard time frames that have to be committed to months in advance [you must test A,B,C during a three day window the lab.  You need to schedule this time - which will be 2-4 months out - today!]

What I have found to be a reliable approach is to estimate very small things, LOTS of very small things. Even if individual items are way off, the aggregate can be quite accurate. If there are deviations, then one is in a position to do fine-grained adjustments to priorities to hit the narrow window successfully.