Task Estimation: Do or Don't?

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 estimate applied to tasks - that seems to be in question.

In my point of view, task estimates have two useful functions: they encourage reasonably sized tasks, and they set daily expectations among the team members. More on exactly what I mean by that in a moment. But first I want to clarify that I am not suggesting that task-level estimates are an absolute necessity, indispensable, or even useful to everyone. It really comes down to how much your team needs or values these two functions. Let's look at each one.

Reasonably Sized Tasks

First, estimation encourages tasks to be sized reasonably. I try to encourage teams to strive for a work breakdown that results in tasks that require effort in the range of a couple of hours to a couple of days. I consider tasks of this size to be reasonable because I, as a team member, ScrumMaster, or even casual observer, can see when something is getting out of hand. I can see it quite easily and within only a few days, without having to monitor the minutia of everyone's work. If something is estimated to take a couple of days and there's no sign of completion on the horizon in 3 days then I can ask "is there a problem?", "do we need to consider another approach?" or "can someone help?". By wanting to know if something is getting out of hand, have I designated myself singular owner of the project? No, not at all; as a member of the Scrum team I have the right and the responsibility to know when lack of movement on something is snowballing out of control. Further, I've always believed that the daily stand-up (aka Scrum meeting) helps us keep our finger on the pulse of the project. That's only true if there's something pulsating - that is, there are tasks being completed each day. That requires that we keep our tasks in the range of a couple hours to a couple days. Too small, and the work breakdown itself, as well as managing the information, becomes a considerable amount of effort, and it creates noise that can obscure real information. Too large, and we don't know until the last minute (i.e. the end of the sprint) when tasks - our approach to solving a problem - are in jeopardy and could benefit from some collective scrutiny/discussion. For a team that intuitively lands on tasks that are sized reasonably, this particular purpose for estimation may not hold much value. But until your team hits its stride, task estimation may help develop that intuition.

Setting Daily Expectations

Second, by estimating tasks in time, we set daily expectations among our team. That is, we let people know when a task should be reported as complete; of course, allowing for a reasonable margin of error. If tasks are not estimated, then hearing someone say "I've not completed my task" or "I'm still working on ..." doesn't have any meaning at all because it could very well be a very large (multi-day) task. On the other hand, if we do estimate our tasks in units of time, then we know as the person is speaking about that task if it is within its proximity of its estimated time allotment, or if its already in trouble and deserving of a little help.

Recommendations

So should you and your team do both forms of estimation? Or more specifically, is task-estimation worthwhile? That depends on whether or not you see value in these two functions: keeping tasks within particular size range, and helping to set and manage daily expectations. Frankly I've found that task-estimation to be very useful in the early stages of learning agile development. But, it is just as true that over time, as improved skill and intuition help us stay within a reasonable range for task size, the practice becomes less important. But [agile] development is not about following one formula. It's about finding what works for you right now, and adapting to change - including changes in your own personal development.

About the Author

Tim Snyder is a Product Development Coach and co-founder of Gemba Systems LLC. He and the coaching staff at Gemba Systems help their clients learn to minimize waste and maximize the throughput of business value. Tim and his family reside in Coppell, TX.