Experienced project managers know the first question clients ask on any new project is "How much?" followed closely by "How soon?"
Whenever the subject of agile project management is discussed, it's inevitable that one question will be asked: "How do you provide the client or sponsors with an estimate when you have no complete requirements document, no signed-off specification, and no ratified schedule?"
Opponents of agile methods, deeply committed to the structured and predictive techniques championed by the Project Management Institute (PMI) and the Software Engineering Institute (SEI) at Carnegie Mellon University, point to this difficulty as the nail in the coffin of agile methodologies.
Even organizations that are eager to try agile methods often raise this question with trepidation. Whenever I write a column about agile methods, this question of estimation pops up in the comments without fail.
Before we explore estimation techniques in an agile environment, let's remember a fundamental fact: Even in highly predictive, mature project environments like those recommended by PMI and SEI, estimating is a serious challenge, and estimates developed (even with thorough requirements and multiple user signoffs) are frequently wrong. I note this so we don't begin our discussion of agile estimating under a misapprehension.
The questions often asked about agile estimating are just as valid when asked about predictive methods. We may have gathered and documented binders full of user requirements and gotten sponsors and stakeholders to sign them in blood, but users will still reserve the right to say "No, that's not it" when we show them our first prototype.
The fact that we've got a 300-step project plan with activities scheduled to the hour doesn't mean that the work will occur as predicted. In short, when we challenge agile proponents to prove that iterative, incremental development methods can be estimated, we shouldn't be surprised if they turn right around and demand to see the spotlessly accurate estimates we've created in our predictive projects.
This is not to deny that there are benefits to crafting a complete specification and project plan up front and using that as a basis for estimating. Especially in projects that are similar to ones we've delivered previously, history can be a meaningful guide and can enable us to derive relatively accurate estimates based on tasks we've done before.
As noted in my previous column, agile methods are most appropriate in innovative projects, which lack this historical record. It's in these inventive projects (without analogies of previous efforts to lean on) that the real challenge of estimation in agile programs emerges. Estimation is a challenge in any project effort, but in these never-before-seen initiatives, it can seem impossible.
In fact, it's not. Some simple concepts can make agile estimating much less intimidating than it seems. The first general principle, which is valid in both agile and predictive project environments, is "don't estimate further than you can see". When we apply an incremental development approach, projects are divided into a series of iterations; each iteration results in the delivery of a working prototype that the client can evaluate and then be modified or expanded.
Most agile techniques call for each iteration to be both time bound and feature bound. Ahead of the development of each iterative prototype, the team and sponsor agree on how much time they'll take to deliver that iteration and which features will be delivered. Under that method, it becomes pretty obvious how to estimate the time required to deliver that iteration; it's the "time-box" (to use the common agile language) that's been established by mutual consent. That time-box is usually established by listing the features expected to be delivered in the iteration at hand and estimating how long it will take to deliver those features.
As an agile project begins, the set of features to be delivered initially is often confined to the most fundamental features required to validate the project concept, with the "bells and whistles" and the more advanced capabilities deferred until later iterations. So, from the long list of features documented as elements of the ultimate product, we select those features for the initial iterations that will demonstrate that the underlying concept is feasible, and that will allow the client to begin the "more of this, less of that" conversation that inevitably occurs when we expose the prototype to the sponsor community.
By limiting the early iterations to this reduced feature set, we make it easier to agree on a time-box for those features. We're only estimating the iteration at hand, with the estimation of future iterations deferred until we've got a clearer idea of how closely our developed prototype matches the customer's vision and expectations. Then we repeat this process, iteration by iteration.
This doesn't answer the dilemma of budgeting for the entire project, which is often what sponsors expect. After all, the purpose of an estimate in the corporate world is to enable the sponsor to set aside a budget for the entire initiative, not just the current iteration.
This estimating task is also not that baffling, either. As iterations are time-bound, entire projects are both time-bound and cost-bound. When a homebuyer asks a construction company to build a house, the obvious first question is, "How much are you willing to spend?" The next question is usually, "When do you expect to move in?" after which the development of plans and features can begin. The client sets the budget that regulates the features that will be included in the new home, from the most humble pre-fabricated trailer to the most luxurious mansion.
This analogy also applies in the agile world. Rather than specifying every feature that the sponsor dreams of and then (often imperfectly) estimating the entire cost from ground-breaking to move-in, the agile developer, like the home developer, starts with the sponsor's available budget and then determines what can be delivered within that budget, and the time-box that the budget implies.
In agile projects, as in projects delivered in a predictive methodology, the developers must set reasonable expectations for the sponsor so they're not expecting the Taj Mahal on a bungalow budget. As TechRepublic member PMP'sicle noted on my last piece, the question in agile development is not "how much will it cost for all these features?" but instead "how many of these features can you include within this budget and time-box?"
Estimating IT development projects will always be a fraught activity; since the technology is complex, users frequently change their minds, and things often don't work out as planned. This is true whether the approach is agile or predictive. In agile engagements, we estimate incrementally just as we develop incrementally, and we do all this development and estimation within the bounds of an agreed budget and time-box that's established in collaboration with the client at the beginning of the effort.
Note: For a thorough investigation of agile estimating, see Mike Cohn's classic book Agile Estimating and Planning.