Lowel Level Estimation

Lower Level Estimates

As mentioned in another blog I believe we used to struggle with mid-term estimation. One area I feel we are really strong is the short term estimation and so I thought it was worth sharing what we do for this as it may aid others.

We use story points to comparatively estimate the complexity of stories. We then calculate our weekly velocity (the average number of story points completed in a week or two week period).

When we have completed our estimates for the relevant stories, if our average was 5 story points a week, we would drag the highest priority stories into our current backlog until we have a total of 5. We then start a ‘sprint’ in jira, although this is only for reporting purposes of what we expect to complete that week. We deploy throughout the week so we don’t hold back features for anything like a bi-weekly deployment and we don’t want people rushing code in to meet an arbitrary commitment of sprint end date

In order to aid this process we have the above information to hand in our war room

The bottom part of the screen shows our previous stories to improve the accuracy of our comparative estimates. The cards can be clicked to bring up previous stories which were given that value. This means you can quickly look through 3’s or 5’s to decide where you think the story you are currently estimating sits. We use cards as the picture to remind us to use the ‘planning poker’ theory (not letting individual devs lead estimates by asking everyone to estimate on the count of three).

We estimate in Fibonacci numbers as we feel this helps us to estimate at a decent level of accuracy. We don’t feel that if you are estimating the difference between a 5,6,7,8 at that level it’s hard to do so accurately at such a granular level. If stories are this high an estimate then we do look to see if they could be more appropriately split

We also highlight some metrics on this screen. These include:

• Our average velocity
  
• Average number of days it takes to deploy one story point. Not that time is never a consideration in the estimation process (as we are estimating complexity) but this may be interesting to the product owner
  
• How many of the story points in the current sprint were completed as expected during the previous week. This is just highlighted for awareness for discussion in retrospective sessions and hoping to add a little ‘gamification’ to proceedings
  
• Finally we show a graph of average velocity over time
  

This process ensures we can have a relatively high confidence in the short term planning (also aiding reporting) with minimum cost in getting this information. It also means we instantly know the impacts if we need to add something urgent to an ongoing sprint

I hope this helps. Feel free to comment, share and discuss

Chris Watkins