Scrum Póker Tips

A la hora de hacer una estimación de historias de usuarios, existen algunos métodos que se pueden utilizar, entre ellos tenemos las tallas de camisetas, puño de cinco, pesos, fichas, la serie de Fibonacci (Scrum Poker), etc.

En realidad, sea cual fuere el método que se elija, tiene que ser uno con el que el grupo se sienta confiado, con el que se identifique y lo entienda completamente, siempre teniendo presente que se lo utiliza para poder evaluar el esfuerzo que requiere cada historia y evitar la mala costumbre de querer evaluar los requerimientos no por esfuerzo sino por horas de trabajo.

En lo personal me gusta utilizar Scrum Poker, no sólo porque puedes usar tu “Poker Face”, sino que es muy sencillo de entender, ya que tiene pocas reglas; es entretenido y todos pueden divertirse mientras trabajan en la evaluación de sus puntos de historia.  

Para poder jugarlo sin contratiempos, sin que se vuelva cansino, ten en cuenta los siguientes tips:

 - El Scrum Master debe ser un buen coach, ya que es él quien debe presidir el Planning Poker y debe poder identificar e interpretar rostros dudosos, de manera que pueda determinar cuándo una historia de usuario requiere mayor tiempo de estimación, para que todos queden satisfechos con el valor asignado.

• El Product Owner también debe estar presente durante el juego, pero no debe interferir en el valor de la estimación de puntos que el equipo decida sobre las historias.  Debe estar presente para esclarecer dudas que puedan surgir sobre los requerimientos de usuarios.
• La estimación de las historias no debe durar más de 2 horas, para evitar excedernos de este tiempo NO se debe hacer un detalle de tareas por cada historia de usuario.
• No pensar erróneamente en que sólo los miembros más experimentados del equipo deban asistir al Planning Poker,  lo correcto es que juegue todo el equipo Scrum y  así fomentar la colaboración y el compromiso por parte de todos.
• Si el valor estimado de una historia es muy alto, a pesar de que el equipo sí entiende perfectamente ese requerimiento, es mejor partir esa historia en varias y evaluar a cada una como una nueva historia.
• Sólo cuando las estimaciones de una historia obtienen valores muy altos y muy bajos simultáneamente, entonces se la debe volver a estimar, explicando las razones por las cuales obtuvo una calificación tan alta y tan baja a la vez.  NO se debe perder tiempo en volver a evaluar una historia cuando la diferencia de estimación no es mucha, el objetivo no es que todos voten con el mismo valor, sino que queden satisfechos con un consenso de estimaciones.

Prueba Scrum Poker junto con estos consejos y comprueba si ayudan a tu equipo y no te olvides pasarlo bien, ya que es un método divertido y colaborativo.