In my article “Why Estimate?
” I discussed getting clarity on who uses estimates and for what purpose, and what estimates are not
for. As discussed, we don’t need to aim for absolutely accurate estimates. So the obvious question is, what in fact are we looking for?
The answer is relative estimation
What is relative estimation?
Let’s start with simple question, “Is 5 big or small?” The answer is obvious: “It depends.” It depends what we are comparing 5 against: If we are comparing against 2, 5 is big; if we are comparing against 8, 5 is small.
Another question pops up: What is “5”? Is it time needed to complete story? No, here 5 is how complex
this story is compared to another story, which the team has already estimated.
This holds good for experienced teams, but what about the team that is doing this exercise for the first time and has no base of comparison? For these situations, it is recommended that teams pick one story that is not too simple and not too complex. Associate a level of complexity, say “2” or “3,” with that story. Now pick other stories, compare them with that base story, assess whether they are more or less complex, and associate a complexity with the stories.
|Aiming at accuracy
||Aiming at the purpose of estimation
|Looking in the solution space
||Looking in the problem space
|Needing in-depth knowledge of code base
||Needing clarity on the problem to solve
|Driven mostly by the individual
||Driven by the team
|Knowledge- and skill-driven
|Need ~80% clarity on how to do it
||Need ~25% clarity on how to do it
|Need effort on prototyping for unknown areas
||No prototyping effort needed
What comes next
Another question pops up regarding predictability, which is how a PO or manager would guess how much the team will deliver in a given sprint/release, so they will plan accordingly. The answer in Scrum/Agile is “story points”
capacity/velocity,” which I will discuss in a later article.