7

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?

7
  • 1
    Can you please explain a bit more what do you mean by in sprint planning 1x 8p story is not the same as 8x 1p stories. In terms of efforts, both would require the same efforts to complete. Aug 20, 2014 at 5:46
  • 1
    @AzizShaikh: in our estimates, 1x 8p ≠ 8x 1p. I agree that in a textbook scrum they 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 8 tooltips". Any suggestions how I can phrase it to make it more clear?
    – Oleg
    Aug 20, 2014 at 6:20
  • 1
    You may edit the question and add the same I agree that in a textbook scrum they 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 8 tooltips" Aug 20, 2014 at 6:37
  • Regarding 1x 8p ≠ 8x 1p, I guess the team should revisit its estimation. Maybe you are giving high estimates to the smaller stories, for example, adding 8 tooltips should be estimated to be 1 story point on the whole. Aug 20, 2014 at 6:39
  • This may not be wrong. Stories have overhead, so 8 1-point stories will generally take more man-hours than 1 8-point story. Story points measure relative complexity, not time.
    – Todd A. Jacobs
    Aug 20, 2014 at 13:15

1 Answer 1

2

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.