Planning poker is a consensus estimation technique where every team member privately picks a card representing effort, then everyone reveals at the same time. Consensus comes out of the conversation about the differences, not out of the average.
The simultaneous reveal is the whole mechanism. If people call out numbers in sequence, the first number anchors everyone after it, and the estimate becomes a measure of seniority rather than complexity. When the table turns over at once, there is no anchor.
When the cards disagree, the highest and lowest voters explain what they are each looking at. That conversation — not the arithmetic — is where the value is, because it surfaces hidden assumptions and missing acceptance criteria before the sprint starts rather than halfway through it.
James Grenning described the technique in 2002, during an estimation meeting that was getting away from him. Mike Cohn's Agile Estimating and Planning put the name in front of most of the industry three years later. The Scrum Guide does not require it anywhere — it says only that the Developers size the work. Planning poker is therefore a widely used convention that fits Scrum well, not a rule you are breaking by estimating some other way.
The name comes from the cards and the simultaneous reveal, not from betting. Each player holds a hand of numbered cards, plays one face down, and the whole table turns over together. Nothing is wagered and there is no winner.
An estimate in hours promises a precision nobody has at the moment of estimating.
The same in a room or across six time zones.
Planning poker is an estimation technique for agile teams: everyone privately picks a card carrying a number for the effort of a piece of work, then everyone reveals at the same time. Where the numbers differ the team discusses briefly and votes again, until they agree. Picking privately is what stops everyone converging on the first number said out loud.
The Product Owner presents the item and answers questions. Everyone who will do the work picks a card privately. All the cards reveal at once. If they are close, the number is recorded. If not, the highest and lowest voters explain what they are seeing and the team re-votes. With a little practice each item takes one to two minutes.
Everyone who will do the work: development, QA, and anyone else contributing. The Product Owner answers questions about intent but does not usually vote. The Scrum Master facilitates and stays out of the voting, so they can watch the spread rather than add to it.
Most often the Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21 and 34, almost always with a ? card meaning "I cannot size this from what I have been told". The gaps widen on purpose, because uncertainty grows with size. T-shirt sizes (XS to XXL) and powers of 2 are common alternatives and work just as well.
Ask the highest and lowest voters to explain what they are each picturing — almost always they are looking at different work. Then re-vote. If a second round still splits the table, the story is usually too vague or too large, and splitting it beats settling on a middle number nobody stands behind.