As an undergraduate student, I was amazed to know that there are software estimation formulas like COCOMO. I studied them, solved the problems in class but did not understand their impact on real-life projects or how to apply them in my projects.
When I join the industry I didn't know how to estimate my tasks. Formulas were of no help. This problem was most pressing:
a) When my superior (many times not adept in programming) asked me about the estimates for a software feature. I gave heroic answers which I regret later.
b) When I want to compare my productivity to other developers. I worked alone for a few years and I want to benchmark myself with the outside world and wanted to know if I work at the same pace as others.
So I laser-focused myself to learn about software estimation and read almost all top books on software estimation.
Reflecting on my experience with multiple projects and running a few experiments I know better than before (I wanted to write ‘I crack the code’ but let me be modest).
One key finding of the software estimation was refreshed when reading recently about the estimation method in SCRUM. The phrase: “story point estimates have no value outside the current team” catch my attention and motivated me therefore I am writing this email.
The basic unit of work in SCRUM is a story and team members collectively decide the estimate for the story on a scale. This estimate is called story points. This estimate is relative to that team. Another team might choose different story points for the same story. Because every team has a different skill level.
This is unique to software estimation and it is the critical mindset when working with software estimates. It is relative. There is no formula like Newton’s equation where you put in some parameters and it spits out the result.
Estimation is one of the areas where software engineering differentiates from other fields. The GANTT chart approach does not help here :).
So, are software estimation formulas useless? I use them after the completion of a project and measure the deviation. I have tuned them for my team (again 'relative') to get tolerably close estimates.
Top comments (1)
The key point here is that story points are relative, but also they do not map linearly, quadratically or otherwise to time.
Also just because a team can complete 45 story points average does not mean they can do 3, 13 point stories an 8 and a 1 because you need too measure the maximum point story that a team can complete in a sprint, again this will be team specific and sprint length specific, so measure that too, any stories above this level MUST be broken down as they not not scoped, or understood enough to be done within one sprint....