6

Often we hear people wanting estimates to be within 10% even if the dev team has not been hired yet and you have no idea about their productivity. This results in techniques such as fat and burn (add fat burn if you are under) being applied.

To truly get a 10% estimate on a piece of software work what needs to be in place? It does not need to be the entire project at 10% but how much pre-work is required to get there so at least the build can be within 10%.

The idea is that if some one is asking for a 10% threshold on estimates of a development cycle we can talk about related overheads and risks.

  • 3
    As an aside; any software estimation that comes in directly within 10% of the original estimate tells me that the development team were actually responding to market and customer feedback on a regular basis and the Project/Product Owner was ruthlessly prioritizing and cutting scope. If you are telling me that the scope didn't change and they delivered a year long project estimated up front within 6 weeks of the target date I will call that project leader a liar. – Venture2099 Mar 4 '16 at 14:55
  • 10% of what? Scope, Time, or Resources? – Pittsburgh DBA Mar 4 '16 at 16:00
  • 1
    If a project has a scope change and you are comparing results with the original baseline before the scope change took place, you are not doing it right. A scope change yields a change in both time and cost and you cut a new baseline. If you have scope change without a change in time or cost, even with a change control board, then you have scope creep packaged nicely, not a well functioning change control process. – David Espina Mar 4 '16 at 20:56
  • I've added some details tohopefully clarify the question. – user1605665 Mar 5 '16 at 20:17
12

The software project, already completed (and even then your historical data might be off by more than 10% depending on how you tracked it). Note: this is not a joke.

See https://en.wikipedia.org/wiki/Cone_of_Uncertainty

5

Jeff has nailed it exactly.

I have a short presentation on Slideshare that talks just about Scope vs Schedule and the accuracy of estimates.

The only way to know when you will be done is to start the work and measure your velocity. Estimates are guesses, nothing more. You need velocity in order to get accuracy.

2

Terms are important here. Estimates should always be a probabilistic range and your work should always--save for extraordinary, infrequent examples--fall within the range. Planning values, or targets, are discreet values within this range. I don't really know the value of trying to have a goal to be within plus or minus 10% of your planning values because, if your work results in falling anywhere between plus or minus 3 standard deviations in the estimate, you are dealing with largely random variables in most cases (at least you will not be able to reliably determine if your result was caused by random or special cause) and trying to achieve a smaller range such as the 10% you are trying to control random noise.

The only way to truly achieve such a tiny variance in work results, you would have to choose your planning values on the fat side of the curve, such as P80 or P90 or higher, and then slow your work velocity to hit it. You will be out of business in no time.

2

Software development has inherent uncertainty. The two biggest contributors to this are requirement changes and technical risk. There was a seminal paper by Fred Brooks on this in the 1980s called No Silver Bullet.

If you want to achieve an up-front estimate within 10% then you would need to eliminate much or all of this inherent uncertainty.

As an example, you could have a project that repeats the exact same technical approach as previous projects and with the same team members. You would also need to restrict any kind of requirement changes and not elicit feedback as this could also potentially result in change.

The question you have to ask yourself is would there be any value in a project that eliminates all uncertainty? Would this ever happen in the real world and would it deliver a product that people actually wanted?

  • This answer is the closest to what I was looking for, what are some specifics that would need to be in place to show what is needed? – user1605665 Mar 21 '16 at 21:43
  • Specifics? An up-front, detailed specification with an agreement that there would be no variation from it. You would also have to drop any requirements that involved significant technical risk. Plus you would need to get a guarantee of stability of the team doing the work. But as I said in my answer, it would be very hard to do this and deliver real business value. – Barnaby Golden Mar 21 '16 at 22:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.