Task Estimation: Do or Don't?


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.


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

AgileConnection is a TechWell community.

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