Agile: Planing – Is Estimating Necessary?

This article is for the experienced agile software development team. The techniques described here should only be used if the team has demonstrated a very high level of accuracy in their ability to estimate tasks and have done so over a long time.

In the XP world, Post-It notes or small paper cards are used to capture requirements in the form of Stories. A Scrum team can use the Product Backlog and Sprint Backlog in much the same way. The thinking is that because the area on the card is so small and the story requires a certain level of detail, the task can be completed within a relatively short timeframe.

In an experience team, the stories will begin to have a relatively uniform 'bigness'. Some teams will write stories to the 2 to 4 hours level, while others may gravitate towards a size of 4 to 8 hours. By the process of generating these stories, the team will have subconsciously done some form of estimation and will iterativly break it down into a size where they are comfortable to begin implementation.

Removing the Planning Poker or estimation meetings may save only a few hours an iteration, but on a team of 10 people, this seemingly small task becomes very noticeable. By removing estimatation and using empericial data for planning, the team simply picks items off the top of the pile and implements them with the confidence that they will maintain a predictable velocity.

This of course puts extra pressure in other areas of the agile process:

• The team MUST update the time used on a task on a daily basis. Preferably while they are working on the item. It is easy to use an automated tool for this - on check-out, start the clock; on check-in, stop the clock.
• In Scrum, the ScrumMaster would have to do some work to look at the statistics before attempting such a technique. For example, analysing how many user stories on average result from a product backlog story; correlation between complexity, estimated time and actual implementation time
• Tool support to extrapolate the progress of the project. As the team is no longer estimating, there is no sense of a completion date. For this technique to work, it must be clear that the status of the project is being generated from empirical data (the facts) and not from an individual with an Excel speadsheet.

Again, this is for an experienced team where the story size becomes relatively uniform and they are very disciplined about keeping the daily statistics up to date. So if the team is running smoothly, estimation exercises are some techniques that can be removed from the agile process.