Aligning story points' value

Question

We've ended up with non-linear weighing of our points. I worry this makes reporting velocity data erroneous. Background:

1. A fairly traditional deck is used: ?, 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, and ∞
2. Only the low end of the scale is ever used for story estimates, we rarely go over 5 points and only had one thirteen-pointer.

3. The point value is inconsistent across stories of different size. That is, one-pointers use "lighter" points and eight-pointers use "heavier" points:

   • 1p: add tooltip text to a couple of icons; format date&time strings
   • 3p: create new user role and specify their permissions; automatically create a new case in CRM whenever certain actions are performed
   • 5p: watchlist functionality; filtering functionality on several facets
   • 8p: integrate with a third party provider and introduce a persistence layer to cache their responses

In a textbook scrum 1x 8p and 8x 1p should require same effort, in fact this is exactly what I'm trying to achieve! However in our estimate examples provided, "integrating with a third party" is a lot more difficult than "adding a tooltip... 8 times". So in our sprint planning 1x 8p ≠ 8x 1p.

How can our team break the "anchoring" to this estimating practice? What's the best way to flag up and approach this concern?

Answer 1

Keepin mind that estimating story points is about getting the most benefit per effort expended. We know that estimates are not going to be correct, however we also know that no amount of extra effort will make them ever correct. So Scrum tries to optimize the effort by choosing a simple and easy method to get relatively good estimates.

I think the questions in your case are:

1. is the assumed skew in your estimates going to affect your velocity strongly enough to make release planning unreliable?
2. if so, how to correct it?

Re 1,

• (As you noted too) story points give a relative, not an absolute estimation, thus e.g. doubling the story points for each item would double your velocity value as well, but none of this affects your team's actual speed, i.e. how much they can actually complete per sprint.
• "Underestimating the relative size of bigger stories" can also be put as "overestimating the relative size of smaller stories".
• Bigger tasks obviously affect velocity stronger than smaller tasks.

From these, my conclusion is that as long as

• the skew in your estimation is consistent per item size (i.e. you under- or overestimate items of the same size more or less the same way), and
• the deviation of the average size of items between sprints is not big (i.e. you don't have one sprint with mostly huge items, then the next full of small items),

the calculated velocity value may indeeed come out as smaller than "ideal", however since the bulk of tasks are correspondingly underestimated, the two errors will more or less cancel each other out. So in the end you will fit more or less the same number and size of items in your sprints either way.

Re 2, if you are still concerned, you should first of all devise some measurements to verify whether there actually is any noticeable error in your release plans. If so, you should raise the issue on the next retrospective to work out a solution together with the team.