Task Estimation: Do or Don't?


Lately I've noticed a fair amount of discussion surrounding the utility of task estimation. The question seems to be: is it really useful to estimate the time required to complete tasks, or is it unnecessary and counter productive to estimate such small units of work? If we're already using some form of estimation for stories, is task estimation really all that useful, or is it in fact thinly veiled micro-management?

First, let's be clear about what we mean by task estimation. I encounter two different types of effort-estimation on projects where agile methods or practices are applied:


  • relative estimates, as is usually expressed in [story] points and applied to stories.
  • absolute estimates, as is usually expressed in time (hours or days) and applied to tasks.

These two forms of estimation are not mutually exclusive , and both can prove useful to a development team. But deciding if you need both will require that you examine your team's behavior with regard to work breakdown and managing the pace of the project.

Relative Estimation

Story points are used to estimate the effort, or size as it may be, of user stories and provide us with a means to approximate the effort of those stories in our product backlog. These estimates can be considered both relative and coarse-grained. We say they're coarse-grained because the points do not represent a precise calculation of time; they offer a sense of the magnitude of effort associated with a story. We say they're relative because they're only meaningful when compared to either (a) the point estimate of other stories, or (b) the accumulative points of the stories completed in a prior sprint (i.e. our velocity).

I like to say that this form of relative estimation is usually "accurate though not precise" . What I mean by that is that if you were to examine the history of a project where the backlog of stories had been estimated by a team using story points and some collaborative estimation technique - like planning poker - then more often that not you would find that the medium point items (e.g. 3 or 5) usually took less time/effort than the higher point items (e.g. 8 or 13) and more time than the lower point items (e.g. 1 or 2) - hence the estimates are usually correct or accurate - but also that the amount of time necessary to complete stories that have the same point value differ from story to story - hence the estimates are not precise. For example, stories estimated to have a point size of 3 may require a different number of hours to complete, but usually they're smaller (i.e. take less time or effort) than the stories of point size 5, and usually larger than stories of point size 2.

Story point estimates are very useful, especially when applied quickly and collaboratively, because it provides a means to establish reasonable estimates prior to getting into detailed design and development. Presumably your business must plan, and your product owner will need to have an approximation of what scope can be accomplished by a set release date. Unless your product owner and stakeholders are willing to wait for that approximation until the sprint planning session of the very last sprint, then you're going to need to estimate the effort somewhat early in the timeline. Story point estimates provide a reasonable way to approximate stories early in the timeline without need to break them down into detailed design or initiate their development.

Absolute Estimation

Then there are the fine-grained, absolute estimates. Such estimates are measured in units of time - e.g days or hours - and are usually applied to tasks - those action items that result from the work breakdown of stories. Teams that estimate tasks, typically do so within the sprint planning meeting. Of course, they only identify, and estimate, tasks for no more than one sprint of scope at a time.


It is the latter of these two - the absolute, fine-grained

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.