Estimating in points that are basically a Fibonacci sequence keep estimation precision limited and avoids implying false guarantees. Yes, in the end the chosen stories are based on summing to a number of points that is roughly equivalent to what the team has achieved per-sprint in the recent past, so in that sense it is ultimately estimating days in the end. But again, for whatever psychological reason, people seem to be more realistic about the variance in actual delivered points per sprint, as opposed to when you try to measure things in hours or days. The points imply more of an estimated goal than a deadline guarantee, which helps keep both team expectations and management expectations more reasonable.
tl;dr: Psychology.
> and people tend not to be overly optimistic and forget to account for things like sickness, meetings, etc.
> But again, for whatever psychological reason, people seem to be more realistic about the variance in actual delivered points per sprint, as opposed to when you try to measure things in hours or days. The points imply more of an estimated goal than a deadline guarantee, which helps keep both team expectations and management expectations more reasonable.
> people seem to be more realistic about the variance in actual delivered points per sprint, as opposed to when you try to measure things in hours or days
Okay I think I'm with you. In my team, the PM pre-calculates the number of available days in the sprint per developer before taking any estimates, factoring in planned holidays and estimates of sickness and meeting time, and adjusting for seniority. I guess points are kind of a crude way of doing the same thing.
Right. But you sound awfully judgmental in saying "crude". I'd call it robust, and not trying to produce some kind of false over-precision. In other words, appropriate to the task at hand.