Are you brave enough not to estimate your tasks?

Marcin Niebudek

I think tasks estimation and tracking progress based on story task estimates almost always leads to tasks becoming pseudo user stories within large and overestimated real stories.

When estimating stories we encourage developers to use points and to show only relative size within the whole set of stories. I think it’s much harder to do with specific, usually technical tasks – you start judging between activities of different type, for example implementing some component and designing user interface. In other hand estimating tasks quickly falls back into estimating in man-hours and might lead to tracking people instead of real progress.

Surprisingly when implementing our tool we found the feature request “Tasks estimation” to become the most wanted one, while we want to encourage our users to rather split stories into smaller functional parts and use tasks for stories as some kind of to do list for developers.

So what works for you? Why do you want or need to estimate tasks within stories?

For project tracking? You can track stories. The story is done when all tasks are done. When you have small stories you don’t need to wait long for visible effects even if you iteration is a month long. For making sprint/iteration burndowns? You can do it successfully with stories, but again you need them to be small functional parts not epics. If you have two big stories for one month then agreed, you burndown made of stories won’t look any helpful.

Or maybe somewhere down there you need those man-hours and strict task assignments for your manager/boss? So are you brave enough not to do that :-)?


5 comments

  1. Wade -

    Ok, I’ll bite…. Estimating tasks allows the team to determine what will fit within the iteration (or at least provide a confidence factor). Having said that I agree that if the stories are broken down into small enough fragments then the estimate on the story itself would be sufficient providing that it is less than 2 days. At this level of detail the difference between tasks and stories are blurred. What makes a task a task and a story a story when the scope of work is less than a day?

    I was previously a believer in tracking tasks per team member via some agile mgmt tool, but experience tells me now that there is little value in that.

    Did I waffle enough in that response? :)

  2. Marcin Niebudek -

    Well… Planning what will fit in the iteration can be done based on story points and team velocity. You basically need only to assume something for the first iteration or for the first 2-3, but then you adapt to your team’ velocity after each finished iteration.

    Story is always a functionality, a goal to achieve from a user point of view. Task is just a developer’s activity. So even for user stories with 1.0 pt or even 0.5 pt you can have tasks such as:

    * add fields X and Y to the article form,
    * design calendar icon
    * test it in IE
    * test it in FF
    * test it in Opera

    when the story for example tells only that “As an blog author I want to set a custom post publishing date and time”.

    As for a confidence factor… I agree – task allow you to verify if your story estimation is ok. You might have thought that the story X will be a “2″, but after braking it into tasks you see that it must be “3″ or even “5″, because just now you’ve realized that its much more work to be done. So I don’t argue with using tasks – no, no! I use them. I just don’t estimate them and don’t track them. I track stories.

  3. Rowan Bunning -

    Re the difference between a story and a task, how about this? A story is a representation of a requirement and is not implementation-specific or action oriented whereas a task is an implementation-specific action to deliver on a requirement.

    A guideline that I use is that stories should represent something of meaning to the customer for which business value can be identified. If stories are broken down into items that less than two days then I find that they lose significance to the customer. Also, the Product Owner may have difficulty prioritising such small fragments of a meaningful business requirement.

    Tasks are “inch-pebbles” that provide frequent updates on progress within the context of requirements that are meaningful to the customer. How does that sound?

  4. James Pak -

    Coming from both Agile and Waterfall experience, I prefer estimating based on tasks because I find that it’s often the small details in these tasks that throws off estimates. When developers estimate a task, there are often an implicit assumptions on how the application will behave that is not verbalized. For example, the estimate may assume that sorting of search result is based on the entire search result, and not sorting just the current result page.

    BA should document assumptions along with the task estimates so that both the developers and business owners are better aligned. I also try to create some sort of a model of the software that demonstrates how it will behave.

    When creating a product road map early in the project, it is probably necessary to estimate based on stories instead of tasks since most of the details are not available. In such cases, in my opinion, the user stories should include examples of similar feature that already exists. i.e. the user story should say “User can search and see search results, like Goggle search results.” This helps everyone to share more similar expectations on the final product.

    In my experience, estimates are most often wrong not because the developers underestimated the complexity, but rather estimate including vision of the feature that was fundamentally different from the business users. Having examples and models at the earliest phase of development as possible helps avoiding that problem.

  5. Are You Brave Enough to Let Go? « tinyPM Team Blog -

    [...] time ago I wrote a post “Are You Brave Enough Not To Estimate Your Tasks“. Looks like we still need some bravery in another area… Task [...]


Leave a Reply