There’s been a lot of interesting thoughts around estimating in Agile teams that I’ve read and even talked about over the years, it normally comes down to whether estimation should be done or not.

In my experience, the answer to this question should be decided upon by the team, if the team is new to Agile then I would strongly suggest using estimation.

What can estimation data be used for?

The main benefit I've seen for using planning poker to estimate user stories is the discussion that follows when a wide range of different estimates are shown by the development team members. However, if a team did not estimate but still used the time to have such discussions then estimation could be considered a waste.

Another useful outcome of estimating product backlog items (PBI’s) is for the team to gather empirical data in order to understand what is reasonable when committing in our sprint planning sessions.

I’ve also used it to track team cadence so we can try and predict when certain features can be released, by averaging velocity over 5 sprints and then using this data to work out when the team is likely to complete the PBI’s based on the estimations for each PBI of an epic or feature. This is particularly useful when creating or updating product roadmaps.

Estimation scales

I’ve worked on Agile teams that wanted to estimate in time, some other teams used complexity scales and others didn’t estimate at all.

In my experience estimating in time is very difficult and is usually wrong, for this reason I normally discourage teams from using this technique. I have found that using complexity scales over time become pretty stable and as long as team members don’t change often they are reliable.

Using complexity to estimate in story points works well in my opinion, here are some tips that I’ve found useful when asking a team to use this method of estimation:

  • Create a ‘base card’ for reference – this should be agreed on by the team as a whole and used to help estimations in planning sessions when needed.
  • Decide on a scale as a team i.e. Fibonacci scale
  • Use previously completed cards to validate estimations when needed.
  • Use planning poker in planning sessions to get to an estimate as a team.

When would a team decide not to estimate?

In my experience estimation is really useful metric for things like sprint burndown or helping to plan when a feature might be released because we can use the empirical data gathered over previous sprints. So, when would a team decide to not estimate?

If your team is not faced with pressure to understand how long a new feature or project might take then you could argue there is really no need to estimate PBI’s as the data collected by doing this will have no use to anyone.