Anti-patterns of agile estimation

For software projects to be delivered, intense planning and progress tracking are being done in an iterative fashion. Estimates of stories are a means to do the planning keeping in mind yesterday’s weather and tomorrow’s forecast. There are ample number of agile estimation techniques performed and the intent of this article is to cover the basic principles and anti-patterns in software projects.

Basic principles:

1. Estimations should come collectively from the team without any bias
2. Estimations should happen only when all the contains for the story are available and clear for the team
3. Estimation session is a part of planning activity and need not be performed when the story is in a flight mode

Anti-patterns:

#Scenario 1: Frequent re-estimation of stories is an anti pattern

A story estimated by a team to be “Medium” size is already in development. Due to some technical changes, the developers are requesting to re-estimate. Should the re-estimation happen?

Actually not. Estimations are only for planning an iteration/sprint before the start. So, there is no point in going ahead with a re-estimation when the story is already in development.

#Scenario 2: Do not change estimates for the sake of effort accounting after the story is done

A story estimated by a team to be “Medium” size was completed and agreed to Definition of done after a very long time. Should we change the estimation based on actual extended time to be accommodated to the burn up charts/planning tools?

Not required. Estimations serve as a north start for planning. So, there is no point changing the estimates based on actuals after definition of done is achieved.

#Scenario 3: Estimation should not be done only by a selected set of developers

Due to time crunch, the estimates of the stories are given by two senior developers from the team. The actual complexity seems to be different from the estimations already provided. Was the approach to estimations right in the above scenario?

Definitely not. Estimates are done based on complexity and should involve possibly every developer in the team (irrespective of experience). Every team member who has a say on the definition of done, should be a part of estimation. If not then there are very high chances of underestimation/overestimation, which can lead to a less approximated planning.

#Scenario 4: Do not estimate based on time/effort to complete

A story to be achieved the definition of done will take 10 working days to complete is the estimation given by the team? Is this the right approach?

This cannot be a right way to do estimations. Estimations should happen based on complexity and not on effort/time. Effort/time for one person can differ from another to complete a story. To avoid re-estimations it’s always better to relatively size based on complexity.

Entire team is responsible for estimating without bias

#Scenario 5: Do not get into a rabbit hole during estimation

Discussing the intricate technical details and architecting the story during the estimation session sometimes helps in understanding technicalities but more at times the team feels lost. The time consumed to do detailed estimations is also high. Can the team still stick to the same approach?

Not really. If the team gets into discussing dependencies and technical details, then we are into a rabbit hole. Team would be unable to process the information and hence estimation sessions should be time-boxed activities and not a place for architecting the story.

#Scenario 6: Estimations should happen with all the stakeholders in the team

Developers are the only stakeholders in a team to do the estimations? Can we proceed with the same approach?

It’s always better to consider the estimations based on complexity with all the stakeholders involved in the story. This will lead to a more accurate planning and context sharing within the team.

To conclude:

Coming back to the title of the article, agile estimates are only for planning and adapt to change at any instance of the project. Estimations are time-boxed activity where we size the stories relatively to be used for planning and coming up with the velocity of the team. Keep it simple! Keep it moving and choose what best works for the team.

Happy learning!

Cheers:)