When choosing the largest and smallest stories in a backlog for estimation how does it impact each sprint?

Question

An article I came across suggested that we should pick the largest and smallest story in the prioritised backlog and relatively estimate the remaining stories. This makes sense. However, I was wondering how this works from sprint to sprint? For example, in the next sprint the largest story might be 5 points compared to the 8 point story in the previous sprint and similarly the smallest story might be 1 instead of the 3 from the last sprint. This seems like it can cause the velocity to fluctuate from sprint to sprint.

I feel like I'm missing something fundamental in the way to do this correctly. Looking for the experts to clarify.

Answer 1

The practice you are referring to is commonly called baselining. There are multiple ways of doing it. The one you refer to (smallest and largest) is one way. Another common one is you pick a story that seems fairly middle of the road and make that some middle number (perhaps a 5), then estimate all other stories off of it. You also often do spot-check comparisons of other stories to each other and see if the estimation holds (one that is an 8 and one that is a 13 are both bigger than the 5, but is the 13 bigger than the 8).

Because baselining can often invalidate previous numbers, you wouldn't re-baseline every sprint. I find that doing it once per quarter or release is the most frequent I would - sometimes far less frequently.

As an aside, it's worth remembering that the user story pointing technique was specifically intended to not be an exact science. The purpose was to make it lightweight so the focus moved to the conversation in the act of estimating, not on the estimations themselves. These estimates don't have to be very exact for mid- to long-term forcasting, so minor drift isn't particularly troublesome. We just baseline occassionally to correct any significant drift.

Answer 2

User story sizing is an estimation technique and at the end of the it is not expected to be exact. Comparing user stories while sizing helps team to stick their scale of measuring Small, Medium and Large user stories. and helps generate consistent knowledge to forecast.This is called Relative estimation technique. Relative estimation helps restrict the fluctuating sprint velocity too. An example of relative estimation would be to say, "I think this feature is twice as complex as this other feature." There is no mention of time requirement, just that it is more complex than the other.

You may say that feature B is "twice as complex" as feature A, which is a feature that you have completed. Because feature A took you three weeks, a reasonable guess for feature B would be six weeks