Leadership optimize

Comparing traditional and agile project management estimation techniques

Rick Freedman compares task-based (traditional PM) and feature-based (agile PM) estimation techniques. He also discusses how the agile estimation technique addresses the human element in estimates.

In my TechRepublic column, "Estimating the Unknown," I noted that when organizations migrate from traditional to agile project management, one of the most challenging elements of transition is often the change in estimation techniques.

Comparison of estimation techniques

Estimating in traditional project management is usually task-based. The project manager, with the help of the team, develops a work breakdown structure (essentially a list of tasks), and then the subject matter experts take a stab at estimating the number of hours each task will take. Estimating in agile project management is typically feature-based, by which I mean that entire features, such as "find a flight-by source and destination city," are estimated in their entirety.

In addition, while traditional, task-based estimating attempts to forecast an absolute number of hours for a task (or, at best, a range of hours), feature-based estimating is more focused on relative size of features, a sort of "small, medium, large" scale that refrains from attaching an absolute time prediction to each task.

Why bother switching estimation techniques?

Often, when I coach teams in their transition to agile, the question they ask me about switching from task-based to feature-based estimating is "Why bother?"

Why bother, they ask, when we're all so familiar with task-based estimating, and our managers are accustomed to it? Why bother, when, after all this time, my team has finally gotten pretty good at it, and our estimates are usually fairly accurate? What exactly is the benefit of making the painful migration from the known to the unknown and from the predictive to the speculative?

Traditional project management

Let's go back to our traditional planning scenario. Once the team has developed its task-based estimate, that estimate typically doesn't change throughout the project. The actual time will change, as reality intrudes on our idealized estimates; this creates the familiar delta between planned and actual hours that can cause project managers to spend inordinate amounts of time accounting for the difference, explaining it to the client, and adjusting project plans, as tasks slip and delays cascade through the plan.

In traditional project management, plans and estimates are typically made once, in a "big bang," front-loaded approach, and the rest of the project is spent adjusting to reality. Project managers, rather than working with their team to facilitate their creativity, to navigate obstacles, and to provide leadership and mentoring, are often found tucked away in an office somewhere, adjusting Gantt charts and task lists to conform to the reality of development.

Agile project management

In agile environments, every iteration is an opportunity to reconsider the plan and adjust to reality for the next iteration. It's the realization of the famous aphorism that "a good plan now is better than a perfect plan tomorrow." By creating a plan and estimate that's good enough to get started with now, and with the realization that an accurate and predictive plan is an impossibility, we begin the march toward presenting a working product or prototype to the client immediately and enabling the project manager to play her proper role of leadership rather than that of project bureaucrat.

The central reason why it is important that agile planning be done at the feature level rather than the task level is that stakeholders and sponsors don't care about tasks and often don't understand what they mean. They are often seen as an impediment to transparency and communication rather than as an aid.

Stakeholders and sponsors pose a great danger of focusing the client on the granular details of the work rather than the business functionality required and can lead to unproductive, circular arguments that distract from the project and the atmosphere. I've gotten embroiled in numerous useless arguments with clients regarding task-level estimates:"Why is it going to take 6.5 hours to build the racks...last time it took 5.5 hours?"

Task-level decomposition also drives the project manager to manage at the task level rather than at the business-feature level, further diluting her role as a leader and facilitator and turning her into a foreman, counting "units of production" rather than results.

Not only do we estimate at different levels of granularity regarding the features we deliver, we also plan at different time levels as well. Many agile practitioners talk of the "planning onion," with planning by day at the center, expanding out to planning at the iteration, release, and project level. The daily meeting, an integral element of agile practice, allows teams to plan in a very granular manner for the results that they plan to deliver that day, and, due to its immediacy, estimates for this work are much more likely to be accurate.

As we move further and further toward the horizon and as the work becomes more ambiguous, unknown, and prone to change, our planning is necessarily less precise. We don't waste a lot of time planning, in artificial precision, for work that may never get done and that we really can't estimate well anyway, since it holds so much uncertainty and mutability. "Estimating only what we can see" is realized in this multiple-time-horizon process and can save us, and our clients, from many hours of unrealistic predictions regarding project elements that can't be known.

Obstacles to transitioning to new estimation techniques

The biggest obstacle to transitioning to new estimation techniques, in my experience, is the fact that clients, sponsors, stakeholders, and PMO officers have a high degree of comfort with traditional task-level, absolute-hour estimations. They usually recognize that they're not really accurate and that the project plan will need to be adjusted continuously; they also acknowledge that many projects managed traditionally still come in over budget and past due. Still, change is always difficult, and familiarity can breed comfort rather than contempt. For these project sponsors, I often walk through the following scenario.

Let's suppose that I'm building a data center with three experts: a facilities expert, a server expert, and a virtualization expert. I write a task plan that includes tasks for building and installing the racks, for building and installing the servers, and for virtualizing those servers.

To build my estimate, I'll ask each subject matter expert for their opinion on the time required. The facilities expert may respond by saying, "It'll take 20 hours," giving her best guess and not building in any risk or contingency hours. The server expert, drawing on previous experience, may think, "It'll take me 20 hours, but I'll double that and say 40, since I don't want to be embarrassed like the last project, when we got stuck with a DOA server that sucked up lots of extra time." The virtualization expert may think, "It might take me 60 hours, but I'll say 40 because I want to impress on the team how smart and competent I am."

Now multiply this process by the 10 or 20 subject matter experts that a complex project can require, with each applying, not a dry technical calculation, but an emotional response that incorporates their desire to appear competent, to avoid embarrassment, or to hit a preconceived date imposed by the project manager or client. It's pretty easy to see that while traditional estimating may be perceived as familiar and safe by many clients and PMOs this simple exercise is actually fraught with emotion, ego, and many other nontechnical elements that can render the result meaningless.

Does agile solve this problem?

Agile project managers and practitioners recognize human elements (emotion, ego, and desire) exist and by iteratively, incrementally planning and building the product that the client needs, we incorporate what we learn from every iteration in the plan for the next one, thus creating self-correcting, self-regulating plans and estimates that are based in reality. This concept of reality-based estimation and development, which enables the client to continuously correct our course and the team to constantly correct our plans and estimates, is at the heart of the agile philosophy.

About

Rick Freedman is the author of three books on IT consulting, including "The IT Consultant." Rick is an independent consultant and trainer, working, through his company Consulting Strategies Inc., to help agile teams and organizations understand agile...

14 comments
Tony Hopkinson
Tony Hopkinson

dependant on lifecycle, just a change in what you are estimating. It's an informed guess based on known information +/- a guess on contingency. All agile does is theoretically increase the amount of information you have before guessing by narrowing the scope of the task and starting with a more defined requirement. I've seen them be stupidly wrong in every lifecycle. It's the foolish desire to confuse estimate with actual twhen aiming at a randomly dodging target that is the real problem.

Kam Guerra
Kam Guerra

I propose an Agile- methodology. That's Agile minus the daily 2 to 3 hour status meeting and the prep and follow-up time that incurs.

pfarrjam
pfarrjam

Wow Rick, your strong bias toward an agile estimating approach is clearly evident, but I wouldn't recommend throwing the baby out with the bath water just yet. One of the issues my organization deals with is setting and managing expectations for project delivery, and we've been adopting SCRUM and other agile development techniques for a while. This has made the developers happy, but we continue to struggle with delivering applications our customers want within a timeframe they can accept. Products need to be delivered - period. The vagaries of scope, schedule, cost, and quality have to be managed one way or another, and high quality project managers have done a great job of leading projects to successful outcomes that please both the development teams AND the customer. Unfortunately the high quality PM's that can accomplish these feats of strength and agility are relatively few and far between, leaving the miserable masses to struggle through ambiguous requirements, unrealistic schedules, laughable budgets, and ultimately no way to predict or control the quality of the product. A good PM can adjust their tools to meet the needs of the customer and the development team. I personally feel that traditional project management approaches will work fine with a spiral development model. I was doing project management 20 years ago and successfully developing with a spiral model (or incremental if you wish) - I just made each turn of the spiral another phase of the project with a customer checkpoint (for scope, budget, and schedule negotiations) at the end of each phase. I set the expectation and managed it - pretty basic stuff. Good article, and I'm sure it will provoke more thought in the PM community.

DittoHeadStL
DittoHeadStL

We've been trying to switch to Agile at our company. The biggest problem that I can see is that executive management still wants a reasonable estimate of when the product wil be ready for delivery, and at what cost. Why? They need to figure out how much they can charge for the product based on customer benefit, when that revenue will be available for budgetary reasons, and whether we should just forget about it if the cost outweighs the revenue. I think Agile is great for some projects. The Chrome browser is a good example. I imagine that it was probably an Agile project. Early on, it was very bare bones and no frills. Since then, it has grown quite a bit, due in great part to user feedback. This is what Agile is all about and it works great when building a product that the customer can use for free. LOTS of people will try it when they don't have to pay anything, and they'll give suggestions for improvement. Unfortunately, we still charge for our software and while we've tried to have customer reps on planning and review boards, they don't want to invest any time unless they're certain they'll buy, and even then very little of their time is provided. So we're limited to our own experiences and maybe some customer Q&A results, but we wind up building a fairly feature-rich product in 1.0. In some cases, we've built features that are never used. We're working to minimize that through more customer involvement. But in the end, we have to do things the traditional route so that the company can plan for the results. The "try it for free" model hasn't yet made it here.

robin
robin

Doing the work to create the products is what takes the resources, effort, and duration. Size of the product is the biggest determinant of how much it will take to create it and must be coupled with effort and duration per size unit. All estimates are based upon extrapolating from some presumably known reference to the target being estimated. Thus, estimates will be accurate to the extent (1) the references are suitably similar, (2) there is an appropriate sizing of reference and target that enables meaningful scaling (such as small, medium, and large), and (3) what it actually took to do the reference is known. Estimating based on the product rather than the tasks is called ?top-down estimating.? It is widely used, especially by those who mistakenly presume their position at the top of the organization somehow imbues them with the ability to estimate top-down. Top-down estimates are notoriously incorrect, because they fail on one, two, or often all three of the above criteria. Moreover, top-down estimates almost always fail in one direction?woefully underestimated schedules and budgets, which turns out to be the primary reason why projects come in late and over-budget. Mature agile development top-down product estimates are more accurate for three reasons. (1) They are estimating small pieces of work, which reduces the amount of variance in the reference-to-target criteria and is what bottom-up task-based estimating does too. (2) Through trial and error, mature agile shops have learned to create similarly sized products which predictably can be created in roughly the same effort and time as prior products. This is not new, magic, or rocket science. For instance, your dentist knows very reliably how long a filling takes; and your auto mechanic knows very reliably how long an oil change takes. Both know the times are those required to do the requisite tasks; and more time will be required if additional tasks turn out to be needed. (3) Agile uses time-boxing, which doesn?t promise to deliver the product in the allotted time but rather promises only to deliver the parts of the product that have been finished in the allotted time. Furthermore, by calling its rework ?refactoring? and declaring refactoring to be a virtue rather than rework, agile has an added way of falsely appearing to make good estimates--avoiding accurately matching actuals to estimates.

petersaddington
petersaddington

Great post on how traditional project management techniques involving estimation at the task level needs to change when we move to an agile environment. Often well seasoned developers don't find this too hard to do, and in my experience, are much more willing to do it at the feature level - because this allows any stakeholder to see how long a particular feature will take, not the nitty-gritty pieces of it. Some would say that moving to agile is just a dumbing down of estimation (moving from granular task estimation to feature level). Other thoughts? Best, Peter Saddington www.whitebarrel.com/blog

PMPsicle
PMPsicle

We should start calling you Robin Hood. Estimation is not budgeting. And has only the most rudimentary relationship to implementation methods (Agile version = Est. x F1 & Waterfall = Est. x F2 & RAD = Est x F3). Bottom line folks ... there is a 5 times (that's 500%) variation depending on who you have doing the work. Estimations are W.A.G.s up until the time that the team is assigned. Then they become guesses. And until you know exactly what you are going to deliver and how they are at best 50-100% off! (that's after detailed design in Waterfall and after delivery in Agile for those of you who haven't figured it out yet.) Waterfall delivers what's asked for with a budget variation. Agile delivers on budget with a delivery variation. Pick the one that meets the situation and go with it. Stop pretending you get something for nothing!

manojvp
manojvp

Hello pfarrjam, I was surprised to see your statement "we've been adopting SCRUM and other agile development techniques for a while. This has made the developers happy, but we continue to struggle with delivering applications our customers want within a timeframe they can accept." Can you elaborate on this statement? What I have seen in my experience is that agile practices still take the same amount of time to finish the actual work but surely makes my customers happy. They see that they can "play" with the product and provide actual feedback earlier in the process. They didn't have to wait until the UAT at the end. Now they have more control over the product that we are building. Moreover, we are delivering actual working product every iteration; that make us capable of delivering the initial increment of the product if they want to. Well, that's my experience. Please tell me your circumstance where your customer was not happy with agile practices. Curious! Manoj http://theguidingstar.com/

Tony Hopkinson
Tony Hopkinson

and a dose of reality. That fixed cost they want before they start is a fiction. It's either based on wild ass guesses, or through spending so much effort making an accurate estimate you've all but done the work anyway without a budget based on teh need. Worse still what eally happens is someone see a revenue and them massages the estimates to make it appear viable. I've lost count of the number of times I was asked to change my estimates so a project could be afforded.

Tony Hopkinson
Tony Hopkinson

Confusing estimates with actuals is something that still plagues us. Even if scope is rigidly controlled ( fingers, toes and eyes now firmly crossed), estimates are made when you have the least information about what you want to do. You don't have to be Einstein to realise the further on you get, the less meaningful they are. To take your dentist analogy a bit further, while doing a filling, they notice that some of your teeth are a bit less than straight, and some what discoloured. So you come out from under with gleaming straight overbite, a big bill an you've missed your next appointment.... It's agile's (well iterative really) ability to make that sort of behaviour explicit that makes it powerful. It operates :p in the real world not some fantastist's Gann chart. In terms of manufacturing an estimate, I see no impact from choice of lifecycle. One of the biggest failings I see is the idea that there is some best lifecycle, you should look at the project and choose a lifecycle that will help you manage it, not manage to squeeze the project into a chosen lifecycle.

CarryAnne
CarryAnne

People who understand how to get things done, naturally gravitate towards a "spiral" or iterative process, because it keeps the focus on controlling what you can reasonably foresee and validating your direction with your customer. Anything and everything else is an illusion. If you believe your business wants the illusionary waterfall estimate, enlist them as your on stage partner performing a new and better trick - the Release Plan. And quote General Dwight Eisenhower, "Plans are useless, but planning is invaluable." BTW: Agile DOES do task planning, but only a few weeks out, at a time, in the Sprint Plan, which occurs after the coarser, long-range feature planning in the Release Plan.

Tony Hopkinson
Tony Hopkinson

Well put. You always know when our industry has once again meandered off the path of reason. !This is the best way...." Stop listening at the first . Initial assumption incorrect, rest of piece irrelevant bollocks, usually designed to sell something to a lose well at golf person at a Gartner coffee group.

PMPsicle
PMPsicle

That doesn't fit into the hype and need to be close minded ... just because you're right is no need to point out that agile always meets it's budget ... but doesn't necessarily deliver anything of value. While waterfall always delivers value but doesn't necessarily meet the budget. No one wants to hear that you've got to choose the correct method for the situation. That sounds too much like work! :D

Tony Hopkinson
Tony Hopkinson

correct. I'm afraid there are near as many muppets claiming your profession as there are mine now, proportionately anyway....