Five fallacies of estimations in software development
Having been working as a software developer for over a decade, I’ve heard many misconceptions about estimations over the years. Sometimes they generated a heated argument, other times were overlooked or falsely accepted as a truth. I’m no project manager, but let’s try to debunk some of these from a developer’s view!
“Someone should do the estimations, so the team can work uninterrupted.”
Estimations done together is a waste of resources, right? Wrong. Estimations done as a team improves information sharing and creates a better understanding of the tasks ahead. It also elevates team motivation by giving a sense of perspective and a common understanding of what lays ahead.
“Story points are so arbitrary, just estimate in man-hours instead.”
Having estimations in man-hours provides a better understanding of our progress, right? Wrong. The very same task can take wildly different time depending of the person who gets assigned to it; or even for the same person, depending on the weather / motivation changes / time of the day. Story points are not arbitrary, life is. We better reflect the reality of things in our estimations than lie to the client and ourselves about it.
“Story points are independent of time.”
SP is all about complexity; so a dull maintenance task should be zero points, right? Wrong. Story points stand for the size of the task, regardless of its nature. Like for distance, it equals velocity by time:
story size = team velocity × development time
While we have a unit for distance, there’s none for development work — that missing unit is what we call Story Point. The trick is, when planning, we have no idea of velocity nor time, but we need to estimate the distance anyway.
“I think this is a 5 SP task, moving on…”
Quick estimations are good estimations, right? Wrong. When estimating, the goal is to find a common understanding of our future tasks so our estimates can be more precise. Discussing a story in detail can reveal missing details or even wild misconceptions. Every 5 minutes spent on discussion can save 1 hour on development. Do not miss this opportunity by rushing your team estimations!
“Scrum poker is a waste of time!”
Planning poker is just a toy of scrum masters, right? Wrong. A well-mediated estimation can reveal important aspects from anyone in the team. Shy colleagues can often bury important considerations, if not asked directly. The most junior developer can bring the freshest ideas and viewpoints, drastically changing the estimate of even lead developers, if revealed.
This is, of course, just my personal take on the matter. What are your experiences about estimations in your workplace? Let us know in the comments!
