Remix.run Logo
recursive a day ago

No one's ever been able to explain story points to me without saying something like "Story points are kind of like how long it will take to implement, except it's not that".

So what is it then? All the explanations and examples are in units of time, but with a disclaimer saying that the true nature of story points is not time-based, except for the fact that they can only be explained in terms of time.

Terr_ a day ago | parent | next [-]

IANAScrumlord, but ideally story points are like a foreign currency: It's both normal and healthy for exchange rates to constantly fluctuate, and every country (team) has it's own units for capturing guesswork and confidence and quality/speed mix.

The managerial goal is to take near-past moving average rates (from completed tickets) and use them to forecast near-future expectations. 1.0 of Team Alpha's points might mean 4 hours this week... but anybody who shows up six months later expecting exactly the same rate is foolish, doubly-so if they expect it to be the same across teams, or after a big change in staff or tooling or project.

______

Other musings: Whenever a manager says "my current estimate of the rate is X pts/hr, use that when sizing", I feel it's a mistake. I kills off the intuition you really want to capture. Team members ought to be comparing expected tasks to past tasks.

Also, the goal of "accurate scheduling predictions" exists in conflict with "measure employee output". Trying to use your point-system for one generally harms the other.

tweetle_beetle a day ago | parent | prev | next [-]

I once met someone who refused to engage with leadership using his team's story points as a direct measure of productivity. To make it harder to extract the data and compare against other teams, they moved to using names of animals to represent types of task associated with differing amounts of uncertainty.

I've also seen a supplier who was asked to provide some kind of tracking, where literally nothing existed. Their delivery team produced reports with story points per person, per task, per sprint. Every sprint, every person hit their target month after month after month. They were asked to stop.

koyote a day ago | parent | prev | next [-]

I always see SP a combination of time and risk. I think a lot of people do not include risk in the estimate.

So a story might be estimated at 3SP to implement but there's a high risk that it would blow out (e.g. idea was not fully proven in a PoC, work is in an area that is historically underestimated, reliance on a different team, etc.), so we set it to 5SP to include that risk. Maybe 50% of the time it does get finished in what a normal 3SP would finish in, but at least we've covered the 50% of time it blows out.

Terr_ 12 hours ago | parent [-]

IMO it's best to welcome the addition of a risk premium, because if you don't, it'll creep in anyway, just in a patchy and inconsistent manner.

Over time it becomes "priced in" to the moving average, which is good, assuming that employee instincts are generally valid.

Of course, if someone makes the mistake of trying to peg points to time, they're indirectly creating a kind of inflation: Yesterday's "just in case" premium should not become today's "everything goes well" baseline.

aryehof a day ago | parent | prev [-]

Its a way to say how long it will take without saying how long it will take.