What are the benefits and challenges of using planning poker for user story estimation?

Planning Poker, also known as Estimation Poker, is a version of the Wideband Delphi technique to estimate the relative sizes of User Stories, or the effort required to create them.

Planning Poker is a consensus-based Agile planning and estimating technique used to evaluate product backlogs by estimating the time and effort required to complete each initiative. This approach helps streamline planning and minimize risk.

I would like to add, there this works best in a non-digital environment with eye-contact. As everything already is digital, it can be helpful do to the planning poker in real world setting.

In Planning Poker, each team member draws a deck of cards with numbers indicating the difficulty of a job. They separately rate the amount of work required. If everyone agrees on one card, that estimate is used. If not, they discuss and re-estimate until an agreement is found. This technique promotes teamwork, communication, and individual thinking in order to remove group biases while generating accurate task estimations.

The biggest benefit of planning poker is the common understanding that a team gains through conversation. Another indirect benefit is a reminder that every item is owned collectively, thereby giving the team a stake in the item.

One of the benefits is getting more accurate estimates. Another benefit is initiating discussions in the team which may help to better understand the user stories.

We used this in every backlog grooming, because it helps planning and is also fun activity for team mates to force collaborative thinking and discussions.

None whatsoever. Estimate using days/hours like normal people and factor in additional time according to unknowns and possible risks.

It simply balances group thinking and individual thinking to estimate relative sizes of User Stories or the effort required to develop them.

Un desafío que he enfrentado en esta nueva normalidad es que el Planning Poker se realiza tradicionalmente en persona, donde los miembros del equipo pueden leer fácilmente el lenguaje corporal y tener discusiones francas. Esto es algo difícil de replicar virtualmente, lo que lleva a malentendidos y una menor participación. Otros desafíos tienen que ver con miembros nuevos del equipo, que pueden no estar familiarizados con la secuencia de Fibonacci o el concepto de dimensionamiento relativo, lo que conduce a estimaciones bastante inexactas. Además, en algunos equipos, uno o dos miembros pueden presionar a otros para que se ajusten a sus estimaciones, lo que dificulta la discusión abierta y las evaluaciones honestas.

The biggest challenge I have encountered is the teams not being willing to spend much time on estimation. Most of the technical teams prefer adding an approximate estimation rather than having a dedicated estimation session.

The biggest challenges I see is that the estimation is still an estimation. Depending how you communicate the estimation and the nature of your stakeholders, this could lead to wrong expectation, e.g. conflict about not meeting "informal deadlines" that were derived from the estimates.

It is really time consuming especially with larger teams or complex tasks as people may see task complexity differently, causing disagreements , varying experience levels can make it hard to agree on estimates. And one major issue is Estimates might not always be spot on, leading to planning issues.

Una de las técnicas que uso y promuevo en Planning Poker es que si las votaciones de todos en el equipo son secuenciales y peque?as, por ejemplo, 1, 2 y 3 o 2, 3 y 5, de inmediato seleccionamos el voto central, es decir, 2 y 3 en los ejemplos anteriores. Esto es así porque en general el voto del equipo converge hacia un número dado. Es importante recordar que el objetivo de las estimaciones relativas no es lograr una precisión extrema, sino más bien hacer una proyección de lo que podría completarse durante el sprint que está por comenzar. Esto funciona para historias de usuario peque?as, a elaborar en un sprint. No es una técnica adecuada para épicas, digamos ya cuando hay estimaciones de 13 puntos o más si usamos la secuencia de Fibonacci.

Ensure everyone understands the user stories or tasks before the session begins,compare estimates and discuss reasons for differences. Reveal cards simultaneously to avoid bias and record estimates and revisit them as work progresses to refine future estimations.