A long story short (a true story)
There is this Developer doing his thingy in his cubicle, one day, a Project Manager comes up to him and says; “Hey, you know that project we’ve been talkin’ about?”
Developer replies; “um.. yeah! I know.”
The PM continues; “You know what… we would really really like to get it done in this August, coz’a this and this and this and that… can we do that?”
and the Developer thinks a lil bit… and says; “Yeah… I think its possible... I think we can do that... you know… there might be a lil bit’a work… but I think we can do that.”
The PM was so excited and runs off to a meeting… they makes decisions about spending thousands and millions of dollars and resources based on a freaking 15 seconds estimation that Developer did.
The consequences are pretty severe if you mess an estimate. Many developers get scolded for messing estimates. Many developers’ credibility was shocked coz they messed the estimates. Many developers were tribute losing their job to messing an estimate.
If you are a Developer, you might agree with me at least 100% in all three things. But if you are a Project Manager or a Delivery Manager you might think that this is a bit offensive, but please don't take this personally. This is just what I see from a Developer’s point of view. Well, its becoz, you often asking to;
What does projects under schedule pressure do to Developers? In Drive, the author Daniel H. Pink says that, when you get the pressure involved or a reward involved, your mind goes into a kind of a transaction mode. And the problem solving part of the brain is kind of turned off. So your puzzle solving or the problem solving skills actually affected. This is the way our mind works.
Biggest paradigm shift
A convincible lifecycle of an estimate would be Size, Effort, Data, and Schedule. The biggest paradigm shift that people have in trying to get better in estimating, is to Learn to think in Size. What you need for Sizing is an Unit and a Measure.
People have enjoyed certain amount of success trying to solve this puzzle for quite a while using various kinds of matrix such as counting the Line of Code, Function Points, Pages of Requirements, Screens or Web Pages etc. but its been in the last few years I have actually seen a method that I think that might actually work and that’s Story Points.
Always keep in mind to re-estimate when there is more visibility on where are you are heading. Here are some simple steps to start loving Software Estimates :)
- Information required: Approved Business Requirements.
- Multiple people estimate separately, then meet to review and revise.
- Cone of uncertainty applied: (-50%, +100%).
- This is only an Estimate only.
- Re-estimate after Detailed Requirements Phase.
You can apply these steps on any software development method you like.
More readings;
- Drive: The Surprising Truth About What Motivates Us by Daniel H. Pink
- Software Estimation: Demystifying the Black Art by Steve McConnell
- Agile Estimating and Planning by Mike Cohn