Eight Points for One Team Is Two Points for Another Team | Hacker News Reader

Eight Points for One Team Is Two Points for Another Team

lloydatkinson.net

2 pointsidealmedtech5 comments

As I tell my teams, the actual points don't matter and getting the points "right" doesn't matter. What really matters is that we apply a consistent rubric to estimating the magnitude of the work. If there's anything more than 10 seconds of discussion on a lower vs. higher number, err on the higher side. Estimating does at least make everyone consider confidence that product/behavior questions are answered, and risk & complexity of building/testing/shipping.

As a pointy-haired boss, I want these things so I can roughly ascertain how much work big things are relative to each other, and get an idea of roughly how much work can get done in some sufficiently large window that average velocity for a team has meetings. Velocity and points are never, ever, ever compared across teams, set as a target, or reported as some performance metric.

That said, if a team was averaging 30 points a sprint, with a standard deviation of 20 (not even sure that's possible, but you get the gist) that'd be a sign to me that something is amiss. When I have seen this, it's usually be a sign that stories weren't truly "ready" to work, due to unclear requirements, underestimating technical complexity, unexpected absences, etc.

End of the day, because the estimates are used to figure out what fits in a sprint, which is a unit of time, they’re time estimates. Just all in team-specific currencies that have a fuzzy exchange rate with time.

Management wants to extract maximum labor from their workers they encourage this fuzziness and second guessing as a way to manipulate their teams into thinking it's their fault or working extra hours to satisfy unreasonable management demands.

This is true for all parts of agile as practiced - it's micromanagement by another name.

I don't think that's the intent, but that's definitely how I've seen it implemented, either through spending lots of time comparing velocities, trying to optimize burndowns, or making equivalencies like 1 point = 1 day (that company also allowed estimating at the 1 hour granularity).

That said, when done well, I think there are benefits to elements of Agile, but one really has to buy in to the fact that average velocity or similar metrics far more useful for looking at what might be delivered in several months, not what will be delivered in 2 weeks.

It _can_ be done right, but I think that's the exception and not the rule.

Yes, perhaps I should have been harsher in my article. I strongly agree with you.

Reply on news.ycombinator.com