A wrong emphasis on task estimation
From discussions over the last few months i realized that quite a lot of agile teams have a high emphasis on task estimation. So far i am very much in doubt of the benefits task estimations will give to a team. In fact i come to believe that a high emphasis on task estimation will do more harm than good and is the first step into micromanagement. Especially if your team does full blown task estimation including reporting on time spent on task and estimating the time remaining. That does not mean teams shouldn’t do task estimations but they should have a clear idea why they are doing it and what they want to get out of it. Teams usually try to get out two things from task estimation: capacity (velocity) of the team and tracking iterations (eg. iteration burn down charts). But both things can be achieved by other agile concepts which an agile team (should) apply anyways: velocity through story estimation and iteration tracking through a physical story wall. Hence it is questionable if task estimation is needed at all.
Deriving team velocity out of task estimation is very dangerous and gives a wrong impression of real velocity over all iterations. The concept of velocity only works if the team sticks with the initial estimates and has a common base line and scale for all iterations. Estimating in time does not give the team a common base line regardless if the team uses hours, days or ideal days. What is an ideal day? Did i really spend the same amount of hours for the last four-hour-task? How do i take pairing or pair swapping into account? Estimating in time is flawed and is raising many questions as people interpret time quite differently.
In addition there is a hidden effect when estimating with time. As the team progresses through the project it acquires more and more knowledge. This knowledge is reflected in better estimates which is of course positive. But it also means that velocity from iteration N is not comparable with iteration N-1 because there is no common base line. What is achievable in one ideal day/hour shifts with the increasing knowledge of the team. This effect does not happen if estimation is done relatively and the team sticks to the base line from the first estimation session of the project. Estimation still gets more accurate with gained knowledge but with a relative scale a task will be inserted more accurately within this scale.
Would it help to estimate your tasks relatively by size like stories (and call it gummy bear points)? It might work if you stick to the base line you created in your first iteration. A one gummy bear point task from iteration one is always the same size as a one gummy bear point task from any other iteration. I’ve never been on a team where tasks were estimated relatively so i can’t really tell if this approach would work.
The other purpose of task estimation is tracking the progress of an iteration. Though it is important to track iteration progress it is much more important to track project progress. A completed story is the unit that delivers value to the product. Hence the focus should be to find out how much stories a team can finish in one iteration instead of tasks (the real velocity). Tracking completed stories on a project scale (via a story burn down chart) together with story velocity will give a team the ability to predict the projects end date. Task estimation simply fails to add visibility of progress on a project scale. Don’t get me wrong here. I still think that breaking down stories into tasks in iteration planning can still be valuable. But why putting in the extra effort to estimate tasks when the stories are already estimated? Especially if the team operates in short (and prefered) two week iterations.
A key success factor for task estimation to become redundant is to follow the INVEST principle for all stories by heart. Teams can introduce N-1 analysis iterations to have stories as close as possible to INVEST before they are played in an iteration.
For iteration tracking a physical story wall including all current tasks is absolutely sufficient. With a short look every team member can see if progress of the current iteration is healthy or not.
One very bad thing i experienced when emphasizing to much on tasks is that the team loses sight of stories as a whole. Particularly if tasks are split into the horizontal architectural layers of the software. There is a high risk that integration problems will arise and tasks will bounce more often between “test ready” and “testing failed” then they need to. Every team member should understand the vertical slice of the system which the story represents and see it as a whole.
I strongly believe we can live very well without task estimation in agile projects. Most of the estimation effort should be put into story estimation to enable project tracking. Thus in alignment to the pattern of the agile manifesto:
Project and story tracking over iteration and task tracking
Tags: Estimation
August 4th, 2008 at 4:09 am
You are right as long as you don’t require the team to commit on the iteration/sprint. If you want the team to commit on the iteration/sprint, the team normally needs tasks estimated in hours.
see http://blog.mountaingoatsoftware.com/?p=15
Stefan
August 4th, 2008 at 9:57 pm
Not necessarily. From my experience you can still commit to an iteration goal and don’t do task estimation. Though Mike Cohn has a point that story velocity bounces up and down but so will iteration capacity too. At the end estimates are just estimates and story estimates are good enough. Once a team commits to play a story the work will take as long as it takes. Estimates don’t get better by applying more estimates. They get better by having good stories following the INVEST principle through enough just-in-time analysis. It’s the information and knowledge at hand which determines a good or bad estimate. And having the team together for estimation to hear and level out all assumptions.
From my opinion there are two situations where task estimates are still helpful:
- teams new to agile and inexperienced with relative estimates and INVEST. Once the team has a thorough understanding of these principles task estimation becomes more and more obsolete
- long iterations like the standard 30 days Scrum. Some teams struggle to plan for such long iterations thus task estimation can give the team a better understanding of capacity. An alternative is to introduce two week iterations. It is easier to look just two weeks ahead and instead of wasting time in long iteration planning meetings the time is better spend on delivering working software. Even one week iterations work but i am more comfortable with two week iterations.
I just like to emphasize that, whether you do task estimation or not, story estimation and story tracking is much more important. I have seen teams which solely relied on task estimation and had no visibility of project progress at all.
August 5th, 2008 at 4:49 am
Defining tasks and estimated them (in hours) as the result of actual analysis of the story. The Story level estimate is little more than a seat of the pants feeling about how big the story is. So the accuracy of the two cannot and should not be compared.
IMHO, the estimates of task time are most useful for monitoring the progress through the sprint. The estimates are updated and charted daily to reflect the team’s belief on how much time is remaining for the sprint. This number should be going down as days pass, but if it is not, this is sign of an impediment which must identified and resolved.
Without tasks and task estimates, monitoring progress through the sprint becomes guesswork — been there, done that, thank you, not again.
I do think accuracy in estimating is overrated. Estimates should give us a ball park figure for time and costs. Hitting the target on time and budget is a matter of staying focused and keeping your eye on the ball of making a great product within the resources available.
Cheers
Peter
August 5th, 2008 at 9:38 pm
Hi Peter
Absolutely! Accuracy in estimates is overrated. If estimates are accurate it’s not an estimate anymore
That’s why i am suggesting story estimates are good enough even for iteration monitoring and tracking. In my opinion the best tool to monitor progress through an iteration is a physical story wall. The wall can still include tasks for stories, they are just not estimated. The movement of cards on the wall will tell everyone if an iteration is doing well or not. How much undone work is on the left side of the wall? How much completed task are there on the right side? How many tasks are hanging somewhere in the middle and why? How many really completed stories by passing all acceptance tests are on the far right sight? The wall tells the team much more than a task burn down chart. At the end of an iteration all that counts are completed stories.
By far the worst thing about task estimation and having the culture of updating them everyday is effectively introducing micromanagement. Unless it’s driven by the team itself to improve selecting the right capacity for iterations. Otherwise it’s a direct expression of mistrust into the capabilities of the team self organizing their own work.
Re-estimating every day also strips away the possibility to use task estimates for iteration capacity. The concept of velocity does not work when re-estimating partially completed tasks or stories.
Cheers
Kai