La principal ventaja de los Story Points en Scrum
Si los Story Points son al fin y al cabo una unidad de medida para el tiempo (esfuerzo), ¿por qué no usar directamente horas o días? ¿Por qué se necesitan los Story Points?
La razón principal de los Story Points
Evaluar los Product Backlog Items con Story Points tiene varias buenas razones. Sin embargo, hay una razón principal que es completamente suficiente para justificar los Story Points. Tiene que ver con el Rey Enrique I, que reinó de 1100 a 1135. Antes de su reinado, existía la medida de longitud "yarda", que era tan larga como la distancia desde el pulgar extendido hasta la nariz de una persona. Imagina la confusión que esto causaba. Al fin y al cabo, la distancia era diferente para cada persona. Un día, el Rey Enrique decidió que una yarda siempre debía ser tan larga como la distancia desde su pulgar extendido hasta su nariz.
Esto era práctico para él. Pero también para todos los demás, porque ahora había una unidad de medida fija. Para cada individuo, una yarda (la longitud del brazo del rey) era quizás un poco más larga o más corta que su propio brazo. Así, todos tenían una unidad de medida uniforme.
Estimación relativa con Story Points
Con los Story Points ocurre lo mismo. Al igual que las yardas inglesas, los Story Points permiten que miembros del equipo con diferentes habilidades hagan una estimación relativa de forma conjunta.
También se puede usar otro ejemplo: imagínate que quieres ir a correr con alguien. Tú llevas un ritmo bastante alto, pero la otra persona es más lenta. Señalas un camino y dices: "Tomemos este camino, necesitaremos 30 minutos". Pero tu compañero de carrera, cada vez que ha corrido ese camino a su ritmo, ha necesitado 60 minutos y te lo dice. Entonces discutís: "30". "60". "30". "60". Pero eso no os lleva a ninguna parte. Podríais llegar a un compromiso y acordar 45 minutos. Sin embargo, eso sería lo peor que podríais hacer, porque ahora tenéis una estimación que no aplica a ninguno de los dos. En lugar de acordar 45 minutos, vuelven a discutir: "30". "60". "30". "60".
En algún momento le dices a tu compañero: "Vale, el camino tiene 5 km. Yo lo corro en 30 minutos". Y él responde: "Es cierto, el camino tiene 5 km. Pero yo necesito 60 minutos".
El problema es que ambos tenéis razón. Tú realmente puedes correr el camino en 30 minutos, pero tu compañero necesita 60 minutos. Dar una estimación conjunta no funcionará, ya que ambos trabajan o corren a velocidades diferentes.
Sin embargo, si se usa una unidad de medida más abstracta – en este caso kilómetros – se puede llegar a un acuerdo. Acordáis que el camino tiene 5 kilómetros. La única diferencia es cuánto tiempo necesita cada uno.
Conclusión – Consenso con diferentes velocidades de trabajo
Los Story Points cumplen el mismo propósito. Con su ayuda, personas con diferentes habilidades y velocidades de trabajo pueden llegar a un consenso. En lugar de un corredor lento y uno más rápido – como en el ejemplo anterior – también se pueden imaginar dos programadores con diferente productividad:
Al igual que los corredores, los programadores pueden ponerse de acuerdo en que una determinada User Story reciba 5 Story Points (en lugar de 5 km). El más rápido de los dos quizás piensa que solo es un día de trabajo para él. El algo más lento, en cambio, cree que necesita dos días. Sin embargo, pueden ponerse de acuerdo en 5 Story Points, ya que la cantidad de puntos en la primera historia puede elegirse libremente.
A partir de esta primera estimación, todas las demás para las historias siguientes pueden derivarse. Si el más rápido estima que necesitará dos días para la siguiente historia (el doble que para la primera), le da 10 puntos. El programador más lento quizás piensa que necesita cuatro días (también el doble que para la primera), entonces también le da 10 puntos.
Y así es como los Story Points – al igual que la longitud del brazo en la historia del Rey Enrique – ayudan a diferentes personas a llegar a un consenso.
Este texto proviene del blog de Mike Cohn y fue traducido al alemán por nosotros.
Crear una estrategia de producto
Planning Poker
=> El momento adecuado para el Planning Poker
