In this post I would like to talk about the practice of estimating tasks in hours in the iteration planning. After more than one year applying agile estimating techniques at work, I have changed my mind about this practice, and I would like to share my conclusions.

We started the development with the following SCRUM configuration:

  • Iterations of 4 weeks.
  • The Release Backlog is composed of user stories which are estimated in story points.
  • The Iteration Backlogs are composed of the selected user stories for the iteration, which are decomposed into tasks, that are estimated in hours.

This approach is supported by several books, including the original Scrum book and the superb Mike Cohn’s Agile Estimating and Planning book. The original Scrum proposal recommends 4 weeks as the duration of each sprint (iteration). Regarding to the backlog contents, the original proposal talks about features as the main item for the product backlog, and tasks for the iteration backlog. Features would be estimated in days and tasks in hours.

Mike Cohn elaborated on this proposing to use user stories as the main product backlog artifact, and tasks for the iteration backlog. He proposes to estimate user stories with ideal days or story points, and tasks in hours. It is worth to notice that the user stories technique was popularized by Kent Beck in his seminar Extreme Programming Explained book. In the first edition of the book, Kent Beck proposed to estimate the size of stories with points (1,2 or 3). But in the second edition he advocates for using real time estimates. In the same way, he proposes splitting stories into tasks and says that developers should estimate them, although many XP practitioners prefer not to estimate tasks at all, or even to create stories as small as possible in order to eliminate the need for separate tasks.

After several weeks applying the mentioned approach, I realized that there were some aspects I didn’t like in our planning strategy. The process of splitting stories into tasks and, specially, the estimation of each task was a high time-consuming activity for the project and added little value. I think that this activity was becoming what Lean people call waste:

  • Foreseeing estimations at the task level is, by definition, very inaccurate. It is not worth to think thoroughly about how many hours are you going to spend in implementing some subsystem and its tests. Specially if you do it one, two or three weeks before you do it. You’ll be wrong, because software development is a wicked problem.

  • If you are going to manage inaccurate estimations at the task level, you have added no value to the story point estimations you already have. These can be converted into real time easily using your team speed so, why bother in the extra-effort?.

  • In order to determine the tasks that need to be done for implementing a story, there are two contradictory forces:

    • If you don’t want to get deep in the design (after all, you are in an estimation meeting) you end up with a very similar set of tasks for many stories: design meeting, implementation, testing, documentation’

      Regarding to this, I found very artificial to estimate the hours you spend writing tests and implementing something. Can you separate both activities in a realistic way?

    • If you get deep in the design inside a planning meeting so you can create very specific tasks,

you are mixing two very different activities: design and planning. Each requires a very high amount of energy. I have found far more productive to postpone design discussions for late meetings where people can focus completely in the thing to be designed. When you are in a planning meeting you look at the whole number of stories from a very high point of view.

In my opinion, the main advantage of having tasks estimated in hours is that you can see how many hours are burnt daily in the sprint backlog, so it’s very clear how the team advances each day. However, only with the daily meeting and keeping the stories small you can perceive a good sprint progress information.

While the story-points estimations worked very well for estimating our release planning, I found that splitting and estimation of tasks with hours was very inaccurate and someway artificial.

So we decided to stop splitting stories into tasks (not only stop estimating them in hours, we stopped managing tasks as first-class planning artifacts). We want very small stories so we force ourselves to split them when necessary (while keeping them tracer bullets). And I don’t really miss tasks. Certainly, there are many times where it is useful to write down the high-level tasks that are needed for implementing some story, but we are fine capturing them as informal comments with the story.

In this process of improving our development method, we first used Excel templates for managing our backlogs. After that, we used Agilo: a very nice tool based on trac that can be easily deployed as a VMWare Appliance. It supported perfectly the estimation in story points and hours for the product backlog and the sprint backlog, respectively. When we changed our planning approach we started using Pivotal Tracker. Pivotal Tracker is an amazing tool. Funny enough, I proposed to their creators to have the possibility of dividing stories into tasks and estimating them in hours. Many people liked this feature, which is currently the number 8th in Pivotal Tracker Most popular topics. The first topic was add tasks to a story and they have already implemented it in a very nice and simple way (with no estimations of course).

In sum, in our current process:

  • We have iterations of 2 weeks (we preferred a shorter delivery cycle)
  • We manage user stories as the only planning artifact in our backlogs (release, product and sprint).
  • We use tasks for clarification of some stories, not as a general planning item.