A guide to working with Agile and DevOps methods
A comprehensive collection of articles, videos and more, hand-picked by our editors
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."
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!
There's estimating, and then there's wild-ass guessing
Is it time for a new Agile manifesto?
What does "real Agile" really mean?