Effective Estimating — Scoring (Story) Points For The Team

I’ve been lucky enough to work in many great teams, even luckier to have had the opportunity to help shape some of those teams from the beginning.

A topic of debate is often ‘how do we want to estimate’, story points or days? Developers mostly like points as they can be quicker to estimate, but PO’s tend to prefer days as you can use days in reports and this feels more accurate. To help find a solution everyone is happy with, I want to share some thoughts:

  • Common Ground
  • Days vs Points
  • Best of Both Worlds
  • TL;DR : Summary

Common Ground

When thinking about estimating, whether it’s days or point, there are some common ground we can agree:

  • It’s about complexity, not time
  • It’s just an estimate.
  • Time Taken/Remaining Should be Monitored

It’s About Complexity, Not Time

We can not predict the future; we don’t know how much time will be spent off sick, in meetings or suffering the morning after last nights ‘team-building’.

This means whether you give an estimate or in days or points, both should represent the complexity or effort it will take to finish the task. Any consideration for time spent not completing the task should be dis-regarded.

It’s Just An Estimate

We will get it wrong, so let’s not worry too much about it. The estimate is important, but I wouldn’t spend too long trying to get it perfect.

Estimating is difficult. Discussing whether the task is 3 or 5 days/points can get heated and take time. Keep it short by picking the highest estimate and move on. If ‘unknowns’ prevent this, document them and do not estimate; instead, set aside time to investigate (i.e. one day Spike) these unknowns.

Time Taken/Remaining Should be Monitored

Monitoring is often forgotten, but it’s important to understand how much time is left on a project. What features are left to build and how long before the MVP will likely be delivered.

There are costs involved in building things, we should understand where our money goes. This isn’t restricted to the overall project, but also on per task basis. Creating new tasks as the project goes on is bound to happen, e.g. ‘redesigns’, ‘bugs’, ‘feature creep’ and ‘third-party tasks’ etc. Understanding these (often hidden) tasks/costs will allow us to identify problems and improve our process/estimating in the future.

Days vs Points

Days

If all distractions are eliminated, how long would it take to complete the task (time in days)?

When I first started developing, and many years later, I estimated in days. I learned to increase my estimate to try and take into account of what I saw as feature creep. My bosses then told me they always doubled my estimates because, well, I was crap at it!

When estimating, we spend much longer debating ‘time’. This is to make sure we’ve thought of every possible eventuality, so that the estimate is as accurate as possible.

Another problem with estimating in days is that it is often misrepresented. It sounds like that we are committing to a time frame and a possible delivery date. Communication to people who are not so close to project then understand these estimates as dates.

If days are to be used, we must not forget we can’t predict the future and these days are just estimates.

Points

On a (Fibonacci) scale of 1 to x, how complex is this tasks?

I have worked in teams that use points, and it took some getting use to. What is a point anyway? Points vary between teams and can take time to be consistent.

Points sound flimsy and to the developer, taking time to estimate using something so flimsy can feel like it’s not even worth taking the time to do it. Also, how can we communicate using points, What reports are written in points!?

This is a misunderstanding of what points are. By themselves, they mean very little. It’s not until you get a history of when points are completed do we start to understand what they really mean in terms of estimating.

Best of Both Worlds

Captain Picard — Star Trek: Best of Both Worlds

My experience has been that we can have speed and accurate reporting. This is how teams I’ve worked in have achieved this:

  1. Break up tasks: Analyse the tasks at hand. If a task feels big, then break it up into multiple tasks.
  2. Have an estimating session: Estimate multiple tasks in the same meeting — Estimating a single task, out of context, makes it more difficult to understand the scope of each task.
  3. Compare Tasks: Pick two at random and sort in order of complexity. Continue picking more tasks and keep sorting. It’s ok if some are equal.
  4. Dish out points: You should now have columns of tasks. Number them using the Fibonacci sequence. The Sliding scale of Fibonacci bakes in an understanding of ‘risk’.
  5. Review: Is there anything missing? do any cards need to a tweak? can a column be dropped?
  6. Monitoring: Monitor how many points are completed each week/sprint. Also record how many points are being created and categorise these new tasks. This will allow us to understand how many points we complete a week (velocity) and why extra time may be needed. Week-by-week we should be able to see an updated prediction for the project.

TL;DR : Summary

The majority of time is normally taken up when comparing tasks, but since we’re no longer talking about time, or even points, the discussions tend to be much shorter. You may feel this lack of discussion means a lack of accuracy, but the discussion would have already taken place (when breaking down tasks). Plus, Accuracy comes from the final step, Monitoring. Monitoring real progress will help create much more accurate predictions and reports.

Further food for thought

Magic happens when all tasks are consistently broken down so they are roughly the same size. Equally sized tasks mean they all have the same estimate. No need to assign points or days, reducing time spent in meetings even further. Just count tasks and use this data to communicate progress 🎉

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.