Agile estimation: story points, planning poker and velocity
Agile teams usually estimate in units other than hours, most often story points, by comparing items with each other. Velocity is the total of the estimates for the stories finished in an iteration, and the team uses it to plan how much to take on next.
Story points and relative estimation
The Agile Alliance glossary says agile teams generally prefer to estimate in units other than man-days or man-hours, and that story points are probably the most widespread unit. In relative estimation, the team compares items or groups them by similar difficulty instead of estimating each one in absolute units of time. Tee-shirt sizes are a non-numeric variant.
The glossary gives the main benefit as avoiding false precision and avoiding confusing estimates with commitments. It also warns that estimates carry uncertainty, are not commitments, and may be updated up or down when new information arrives.
Planning poker
In planning poker each member holds numbered cards. The Product Owner explains a story, everyone picks a card in private, and all cards are shown at once. The people with the highest and lowest estimates explain their reasoning, and the team may vote again.
The format keeps sessions moving, draws on quieter members, and brings risks into the open. The glossary warns against forcing a consensus number, because wide early spread shows how uncertain the team is.
Velocity
Velocity is the sum of the estimates of the stories completed in an iteration. Partly done stories count for nothing: two finished 2-point stories plus a 3-point story that is 80% done give a velocity of 4. If velocity stays roughly steady, the team can forecast how many iterations the remaining work needs.
The glossary calls velocity a measurement made after the fact. Individual velocity is meaningless, and comparing velocity between teams is not meaningful because teams estimate differently.
Who sizes the work in Scrum
The Scrum Guide says the Developers who will do the work are responsible for sizing Product Backlog items. The Product Owner may influence them by helping them understand trade-offs but does not set the size.
At Sprint Planning, the Developers' forecast is more confident the more they know about their own past performance, their upcoming capacity and their Definition of Done. A team that has run three Sprints should use its own record, not an industry benchmark or another team's velocity.
Where the exam catches people
Believing the Product Owner or a manager can set an item's size: the Developers doing the work size it.
Believing velocity can be compared across teams or per person: it belongs to one team and is not comparable.
Believing a partly finished story adds to velocity: only completed stories count.
Believing an estimate is a commitment: estimates carry uncertainty and should be updated as more is learned.
Believing planning poker must end in agreement: forcing consensus hides how uncertain the team is.