Estimating the delivery date for a software application can be notoriously difficult. Miscalculations of 100% or more are surprisingly common. Let’s examine a couple of possible situations.
1) You’re working in a software-as-a-service environment like Salesforce.com or Microsoft Dynamics. The stakeholders want to know how long it will take to add a simple feature. You ask a few questions, indicate where the risks lie (if any), then offer an estimate (probably not more than a week or two).
Barring interruptions, the chances of delivering on time are high. Even if you don’t deliver exactly what the stakeholders envision, it will likely take only a day or two to fine tune the solution.
2) Now imagine your team needs to build a custom software application. You might use Java, C#, C++, Ruby, PHP, or Perl. There might be software components from prior projects that you can leverage but they’ll likely need some rework. You’re asked to estimate a delivery date.
You ask questions and identify risks but the real issue is the lack of business requirements, use cases, or epics. All you have is a description. You might even have a product vision statement, but that’s unlikely.
The team will have to rely upon its experience. Familiarity with the software tool set and the type of application being requested will help in scoping the solution. Of course, the stakeholders need an immediate answer so they can establish a budget for the project. No time for detailed analysis. Now the fun begins.
Assume the team brainstorms for a day or two and estimates that 5 people can deliver the software in 6 months. Six months is about 130 business days. Multiply by 5 people to get 650 person-days or 5,200 person-hours.
Ideally, the team should offer an estimate range rather than a single number. 5,200 hours becomes an official estimate range of between 4,000 (80% of 5,200) and 6,500 (125% of 5,200) hours. (The 80% and 125% numbers are only examples. Smaller or larger values will apply in different situations.) The team also offers lists of assumptions and risks.
Do you see the problems here?
Scenarios like the above play out every day in companies around the world. The stakeholders offer an over-simplified description of what they want. Then they ask, “How soon can we have it?”
High-level, broad-based software estimates are almost worthless. For a large, complex system, an estimate of X hours may translate to a range of X/2 (50%) to 4X (300%). You read that correctly — from one half to four times the estimated effort. Where’s the value in such a wide ranging estimate?
Of course, there’s rarely sufficient time to produce an accurate estimate — a narrow range. Such an estimate may take anywhere from a couple of weeks to a few months depending upon the situation complexity. Everyone wants instant answers and rapid delivery. There’s no time to do it right.
What should you do? Go agile!
Tell the business stakeholders what they want to hear. You can deliver the software anytime they want — as long as they are willing to scale the feature set to align with the timeframe. Once the initial feature set is delivered (on time, by definition), features will continue to be added through a series of incremental releases. When money runs out, the project is over and there’s little or no waste.
Everybody wins. And luck isn’t a critical success factor.
Using Agile the delivery date is not the flexible part but what you deliver.
Delivering / planning the same set of features using classical planning method gives you a very unprobable end date but the same happens when you want to deliver these same features using agile. The positive part of Agile is than after each partial delivery the remaining set of features is reevaluated so the decision to stop development is taken earlier having in most case a working product, although not the one you started for.
Exactly. Business value is frequently evaluated and adjusted. The project can end whenever the business feels they have received the value they want.
From my experience, using Agile to deliver software doesn’t address any of the estimation issue, nor does it fix the need for an up front budget. In most cases, the team still has a budget, and still the project is based on some sort of estimate. The main advantage of Agile is you find out more quickly if your estimates are behind so far, and there for get a better idea of how much your team is accomplishing. This only gives you the chance to better prioritize which features you drop to meet a schedule or budget, which is VERY useful.
Truth be told, you can’t just ship software that is incomplete whenever in an agile cycle. The UI & product needs to make some sense to a user. A random collection of modules isn’t good for the user. I do think it helps users to customize. I worry that people believe budgets and estimations MIGHT go away because they switch to some form of Agile, but that just doesn’t match any real world experience I’ve had, now on my 11th agile project. You have the same managerial games, but now at least there is some real team data coming in with which to inform others with so that they can make wise decisions sooner. Or pout about what they aren’t getting for longer, depending on the maturity of the management team. I prefer those who treat the team well and make the wise decisions over those who pout, browbeat the team, and demoralize them, but you can’t always know in advance which project you are on until their fantasy product doesn’t appear surrounded with glittery butterflies.
You’re exactly right. In the end, there is no perfect solution to managing budget, time, quality and features. Every approach has it’s pluses and minuses. Some people are uncomfortable letting anything float. They want all aspects of the project agreed to and locked down in advance. It doesn’t work. There must be flexibility somewhere. I strongly believe that feature set is the best place to allow that flexibility.
Thanks Vin for spelling it out. We can’t hear the truth too often.
In response to Lanette:
Well said (and LOL)!
I’ve been leading and participating in technology projects for over 25 years. Having used both Agile and more traditional project frameworks, I’ll vote for Agile since as you note there’s feedback from the team, and you give the key stakeholders a chance to adjust (or pout).
I’ve never seen a project completed (on time or otherwise) just because management demanded, coerced, or threatened the team. Even when a project ‘savior’ came to rescue and resusitate, that individual typically was given authority to do all the things the team was suggesting from day one.
Agile provides a framework which, among other things, puts an emphasis on delivered value. I’ve led a number of projects which could have delivered value in increments, but ‘failed’ as stakeholders demanded an all or nothing delivery. Often they got nothing, or the value was reduced considerably by going over schedule/over budget.
Comments are closed.