Story Point estimation is a comparison estimation approach, where Story Points are used to represent the relative size for the User Stories. At Perficient when doing Story Point estimation, we select one small User Story which every individual on the team is familiar with and feels comfortable to commit to delivering in a short period of time, and make this story a comparison base. We assign a small Fibonacci number (e.g., 2 or 3) to this story, and we then assign Fibonacci numbers ( 0.5, 1, 2, 3, 5, 8, 13, 20, …) to the rest of the User Stories based on the ‘feeling’ of how many times bigger they are compared to the base Story.
In the past 2 years I’ve been practicing Story Point estimating with various teams, and it was quite common that the team gets confused on how to objectively compare the Stories with the base one no matter how experienced or mature the teams and individuals are. Sometimes even after playing Planning Poker, many times my team members still cannot convert their thinking from giving out hours estimates to the comparison results – they still depend on an invisible “formula” to convert hours to points (see my previous post: How Story Points in Scrum can reveal more than hours tracking to see why this doesn’t work).
That is not the right way to go if we really want to pursue continuously improving our estimating/tracking system, but we really weren’t able to come up with many ideas on how to deal with that “formula”. The only thing it seems we could do is to emphasize again and again in the planning meetings that we don’t do that, but sometimes it doesn’t work when the team could not find a quantitative way to compare. If the estimates is based on the gut feeling the team would rather go back to use hours to make themselves feel more comfortable.
Recently we had some new ideas come up accidentally when introducing Agile Estimating 2.0 into our toolbox to replace the time consuming Planning Poker approach. This is an improved Story Point estimating technology using Fibonacci Numbers too (see my previous post Agile Estimating 2.0), and there is one step in this new approach which allows the team to categorize different factors which impact the estimates using different colors. E.g., if we feel that “technical complexity” is going to impact our estimates, we assign a color to this aspect and tag all the User Stories having high technical complexity with this color.
I realized that this is actually a way we quantitatively measure Story Points. If we use different colors for the categories they provide a straightforward way to support the team to compare the User Stories with each other. Below is one example:
I consider the following 3 aspects when comparing each User Story with the base:
For the given User Story my estimate is that it has 3 times of Acceptance Tests, twice technical complexity and the same level of dependencies comparing with the base:
So, as a result, I decide for this User Story, thinking from the ATDD perspective, basically its size is three times of the base, and considering the higher technical complexity level which impacts half of my implementation I’ll scale up 50% for the size. Since the base story sizes 2 points, I’ll easily get a number by this formula: 2 x 3 x 1.5 = 9. And since 8 is the closest Fibonacci number to 9, my final estimate goes to 8.
Thus as an individual team member finally I got a better quantitatively measured Story Points estimate. And another thing that is really exciting thing to me is it’s possible to use color not only for Agile modeling but also in agile estimating. Cool isn’t it?
Pingback: Introduce Story Type into your User Story Estimation | Multi Shoring