Recently I’ve been working on a greenfield project for a CMS website to replace a temporary site that was thrown together quite quickly. As part of this we held a discovery phase which enabled the team to establish user need, some very high-level technology explorations and create a backlog to estimate cost and size. The next stage of the project was to start building something which meant we needed to take our backlog and estimate it.

I encourage team to estimate in story points in order to make their sizing quick, relative and most importantly away from units of time. With new teams or teams new to Scrum this can be quite a challenge and can take a bit of explanation and trial and error. In this particular instance it became apparent pretty quickly that we weren’t just estimating the size of the items in the backlog. With each discussion and estimation of a story or epic we were exploring the backlog as a team, asking questions, throwing ideas into the mix and breaking stories down. This gave every team member a greater knowledge of the stories and really helped the team communicate.

I’ve used this technique with well established teams and it has helped give teams a look into the future of upcoming work and tasks (not too far mind, only the next two to three sprints).  I also encourage Product Owners to have their backlog board of things to estimate visible and next to the team’s scrum board, this helps with anyone being able to see the next items and discuss them.

Here are a few tips i’ve found for estimation:

  1. Do it often – Spend some time estimating for future sprints in each sprint. It helps as mentioned above get a greater collective feeling for the items in the backlog but also avoid turning up to sprint planning with a raft of un-estimated stories which can drain time from the planning meeting.
  2. Do it in manageable chunks – I try to keep estimation sessions to a maximum of one hour. Any greater than this and I find people’s concentration wanes. If you need larger sections of estimation (helpful at the start of a new project or release schedule) then try to ensure breaks are included to give people time to reflect and refresh themselves. I’ve found doing this with lunch in between can really help
  3. Do invite the whole team – The immediate reaction to this is what will it cost taking the whole team out for an hour but I feel it actually adds value and saves money in the long run. I’ve experienced teams where the senior dev may be asked for an estimate and the rest of the team dont agree or feel they’ve been left out. Equally having your entire team and the skills that may encompass (test, dev, UX, design, BA) gives insight into their particular challenges in their skill area for each story. In my experience teams that do this tend to end up with silo stories and have stories split across each discipline as opposed to vertical slices of functionality throughout the product.