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 e

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.