Quantitatively measure Story Points in color





Story Point estimating is a comparison estimating technology, and Story Points are used to represent the relative size for the User Stories. In Perficient when doing Story Point estimating we select one small enough User Story which every individual in team is familiar with and is feeling comfortable to commit to delivering in a short period of time, we make this story a comparison base, 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 much times they size 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 and mature the teams and individuals are. Sometimes even after playing Planning Poker game many times my team members still cannot convert their thinking from giving out hours estimates to the relatively comparison results – they still depend on an invisible “formula” to convert hours to points (view 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 a continuously improving estimating/tracking system, but we really wasn’t able to have many ideas on how to deal with that “formula”, the only thing seems we could do is to emphasize again and again in the planning meetings that we don’t do it, but sometimes it doesn’t work if the team could not find out an quantitative way to compare. If the estimates is something based on the gut feeling, team would rather go back to use hours which would make us feel more comfortable.

Recently we got some ideas accidentally when introducing Agile Estimating 2.0 into our toolbox to replace the time consuming Planning Poker technology. 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 color codes 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 below 3 aspects when comparing each User Story with the base:

Categories.jpg

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:

Story_Card.jpg

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 really exciting thing to me is, it's really cool to use color code not only in Agile modeling but also in Agile estimating, isn’t it?