Congratulations! You’ve finally convinced the team that relative story point estimation is a great way to move forward and you’re now ready to jump into your first planning poker session. So where do you start? What’s a 1-point story? What’s a 3-point story? What’s a 13-point story? Your team is looking to you and this process is almost as new to you as it is to them.
One simple way that I’ve seen used to help set these initial values is to find a small story in your product backlog and somehow obtain a general group agreement that it’s in fact a 1 point story. From there you would work your way down the list of stories and allocate 2 points for a story that is roughly double the 1 pointer, 5 points for every story that’s roughly double a 2 pointer and so on. There’s nothing wrong with this approach but you have to bear in mind that your team is new to this process, which means that you really want to try and reduce as much ambiguity and subjectiveness as you can. Any estimation by nature is already ambiguous so the last thing that we want is to add more fluffiness to the mix. It is for this reason that I use an approach that offers the team something more tangible to help build their estimation building blocks and base foundation.
A different approach
Just because the team is starting a new method of estimation it doesn’t mean that the old time based estimations should be treated like a bad dream and quickly forgotten. At some stage in the past, work got done. Cases, issues, bugs, features – whatever they were or whatever you used to call them were completed and the team had some idea of how long it took to do that work (perhaps this time was even documented *gasp*). The idea is that we use a subset of this historical work to create a mapping between these known quantities (old completed work) to these funky new story point values. So the process goes something like this:
1) Create a set of time buckets that map to the relevant story point values (personally I drop the 20, 40, 100 values to keep things simpler, faster and tighter). The buckets that I use are as follows:
Feel free to modify the ranges for each point value as appropriate. The important thing is to ensure that as the point value increases, the range between the upper and lower values for the bucket needs to become more significant (i.e. it shouldn’t be linear). This is due to the fact that there is more uncertainty involved when dealing with larger stories and this needs to be acknowledged.
2) As a team, we go through our previous work and determine (either through documentation or memory) how many total man hours each old feature took. Remember this includes all necessary tasks to move the feature to a state of ‘Done’ i.e. development, review, test design, test execution, deploy etc.
3) Based on the story point time buckets, we then categorize the old features based on the times we identified in step (2) i.e. old “Feature XYZ” now becomes a reference story with a point value of 8.
4) We continue going through our old work until we have a corresponding feature for each value in our planning poker deck i.e. “Feature A” = 1 point, “Feature B” = 5 points. These become our reference stories.
Here comes an important point. Once we’ve calibrated the points using our old work, I throw away the time calibrations and replace them with the reference stories instead. We can now start playing planning poker with the new user stories by comparing them to the reference stories as opposed to the buckets that we set earlier. It’s tempting to leave the time buckets up there and continue estimating based on those ranges but that’s not what we want. If we keep the time buckets up on the board, we’re just disguising the old time based method of estimation in story point clothing; we end up wasting time trying to break the new stories down rather than simply comparing their size to the reference stories (which is much, much faster). If anyone asks for the old time calibrations, fake amnesia and tell them you can’t remember what they were and the only thing you DO remember is that the calibration is complete and they should be comparing the stories, not trying to estimate time. The exception to this is if someone new joins your team and is unfamiliar with the reference stories, they’ll get to use the time buckets as their training wheels for a session or two.
Not over quite yet…
If you’ve followed the shortcuts above, you should feel pretty satisfied that you’ve completed your first planning poker session relatively unscathed and that your first sprint is underway. But you’re not done yet. There are still some minor tweaks that you should do.
In Scrum, you are guided to capture all tasks’ remaining time on a daily basis (and this of course is reflected within the daily burndown chart); but what I like to also track are the hours of work actually completed on each user story. Once a user story is finished, I add up the hours worked to see how close we were to the original calibration time bucket (OK, so I might have thrown away the calibration hours in the planning session but I always have a copy at my desk ☺).
If the story went fairly smoothly but it actually fell into a 13 point bucket instead of the 8 (that was originally estimated) I’ll adjust it for the sake of reference and use it as an example of a 13 point story for any future product planning or grooming sessions. I simply do this to ensure that the estimation foundations remain solid and that we’re not building an estimation model on top of a house of cards (pardon the pun).
I also make it a point to tell the team why I’m asking them to track their hours completed (and not just the time remaining). It’s important that they don’t feel like their individual performance is being measured. They need to know that I do it to inspect and adapt the estimation process going forward and that it’s not about micro-management.
So there you have it. You’ve recycled your historical work to give you a basis for relative estimation with story points. If you found this technique helpful or if you have an alternative method please post your comments as I’d love to hear from you.
Share on LinkedIn
Share on Twitter
18