Planifiación y Estimación
2. Estimar historias de usuario
En este proceso el Dueño de Producto aclara las historias de usuario a fin de que el Scrum Master y el Equipo de Desarrollo hagan una estimación sobre el esfuerzo necesario para desarrollar la funcionalidad descrita en cada historia de usuario.
Puntos de historia
Al hacer estimaciones de historias de usuario, se acostumbra utilizar puntos de historia en lugar de estimar por duración. Los puntos de historia representan el esfuerzo y/o complejidad de una tarea.
Para hacer la estimación, se identifica una historia de usuario de muy poca complejidad / esfuerzo, y a esa historia se le asigna un valor de 1 punto de historia (se convierte en la unidad de comparación). Para las demás historias de usuario, se estima un valor en puntos de historia de acuerdo a la complejidad relativa de esa historia con respecto a la unidad.
Es común utilizar una escala de puntos similar a la serie de Fibonacci: 1, 2, 3, 5, 8, 13, 21. De esta forma, se intenta representar la incertidumbre en la estimación cuando se trata de historias de usuario de mayor complejidad.
Métodos de estimación
Se pueden utilizar numerosos métodos de estimación para estimar historias de usuario. Algunas herramientas importantes son:
1. Planning Poker
Conocido también como Estimation Poker, esta técnica de estimación implementa el consenso para estimar los tamaños relativos de las historias de usuario o el trabajo necesario para desarrollarlos.
En el Planning Poker, a cada miembro del equipo se le asigna una baraja. Cada carta está enumerada en forma secuencial y los números representan la complejidad del problema en términos de tiempo o esfuerzo, según lo estimado por el miembro del equipo. Los miembros del Equipo de Desarrollo evalúan el artículo (tarea o historia de usuario) e intentan entenderlo mejor antes de brindar su estimación para su desarrollo. Después, cada miembro elige una carta de la baraja que represente su estimación para la historia de usuario. Si la mayoría, o todos los miembros del equipo seleccionan la misma carta, entonces el cálculo que indique la carta será el estimado para el artículo. Si no hay un consenso, entonces los integrantes del equipo discuten las razones de la selección de distintas cartas o estimaciones. Después del análisis seleccionan nuevamente las cartas. Esta secuencia continúa hasta que se entienden todas las presuposiciones, hasta que se resuelven los malentendidos o hasta que se llega a un consenso o a un acuerdo.
El Planning Poker promueve una mayor interacción y una mejor comunicación entre los participantes. Facilita el pensamiento independiente por parte de los participantes, evitando con ello el fenómeno del pensamiento en grupo.
2. Puño de cinco
El puño de cinco, o Fist of Five, es un mecanismo sencillo y rápido que se puede utilizar como práctica de estimación, así como técnica general de formación de consenso colectivo. Tras el debate inicial sobre sobre la estimación de un elemento, se les pide a los miembros del Equipo de Desarrollo que voten en una escala de 1 a 5 utilizando sus dedos. Al utilizarse como herramienta de estimación, el número de dedos que se muestran indican el valor relativo de estimación. Los integrantes del equipo con estimaciones atípicas (valores más altos o más bajos) explican al grupo el motivo de su estimación para su análisis. Una vez que el equipo ha debatido, se lleva a cabo otra ronda de Fist of Five o se toma una decisión colectiva.
El valor en el uso de esta técnica no está sólo en lograr un consenso, sino también en el debate, ya que a cada miembro del equipo se le pide que explique el motivo de su estimación. También se les da la oportunidad de expresar cualquier problema o inquietud.
3. Estimación por afinidad
La estimación por afinidad (del inglés: Affinity Estimation) es una técnica que se utiliza para estimar rápidamente un gran número de historias de usuarios con el uso de categorías.
Utilizando notas adhesivas o fichas y cinta, cada equipo coloca las historias de usuario en la pared o en cualquier otra superficie en orden desde la más pequeña hasta la más grande. Para ello, cada integrante del equipo inicia con un subconjunto de historias de usuario de todo el Backlog Priorizado del Producto para colocarse por tamaño relativo. Esta colocación inicial se hace en silencio.
Una vez que todos han colocado en la pared sus historias de usuario, el equipo las revisa y las puede mover según sea necesario. Esta segunda parte del ejercicio incluye discusiones. Por último, el Dueño de Producto indicará en la pared algunas categorías de tamaño. Dichas categorías pueden ser pequeñas, medianas o grandes, o bien, pueden estar enumeradas utilizando valores de punto de la historia (Point Story Values) para indicar el tamaño relativo. Después el equipo reubicará las historias de usuario en dichas categorías en el paso final del proceso. Algunos de los beneficios claves de este método son que el proceso es muy transparente, visible para todos y fácil de llevar a cabo.
Historias del usuario estimadas
Después de que las historias de usuario han sido estimadas por el Equipo de Desarrollo con el uso de las distintas técnicas de estimación analizadas en esta sección, se ponen a consideración para ser historias de usuario estimadas. Se puede utilizar el Relative Sizing o los puntos de historia para estimar el tamaño general de una historia de usuario o característica.
Las historias de usuario se actualizan asignándoles un valor de puntos de historia (o el valor del método de estimación que se haya seleccionado).
Esta estimación no es definitiva: durante el refinamiento del Backlog (conforme se ejecutan los sprints), es posible y hasta recomendable reevaluar los valores estimados de cada historia de usuario.