¿Cómo usar Story Points, si las historias de usuario son completamente diferentes?

Story Points (SP) es una buena medida, que permite estimar User Stories.

SP ( a mi entender, es una nota importante ) es conveniente porque es relativo y no está relacionado con el tiempo. Todas las estimaciones se basan en la comparación con una base común. Pero, ¿y si dos historias tienen bases completamente diferentes?

Para simplificar, busquemos un ejemplo que no esté relacionado con ningún área específica. Como cavar un hoyo.

Supongamos que se necesitará 1 SP para cavar un pozo de un metro de profundidad. En consecuencia, necesitamos 2 SP para hacer un pozo de dos metros de profundidad. Muy conveniente. No nos importa nuestro equipo. Si tenemos una pala, entonces 1 SP se asignará a 1 hombre-día. Si tenemos una excavadora, 1 SP se asignará a 1 hora-hombre. Pero un foso de dos metros de todos modos nos llevará el doble de tiempo que un foso de un metro.

Todo está bien con la excavación de pozos. Pero, ¿y si la siguiente historia es "atrapar un elefante"?

  • ¿Deberíamos hacer una estimación con otra base (relacionada con elefantes)? En ese caso, tendremos dos tipos de Story Points, que serán absolutamente diferentes.

  • O, si sabemos que 1) atrapar un elefante nos llevará 1 hombre-día 2) todavía usamos una pala para cavar, ¿deberíamos estimar esta historia del "elefante" en 1 SP? Esta sugerencia suena absolutamente mal para mí. Pero lo escribí porque en mi práctica la gente usa esta opción en la mayoría de los casos.

  • O, tal vez, simplemente entiendo mal el concepto de Story Points.

Esta es una muy buena pregunta. Pero en mi humilde opinión, no tiene respuesta porque Story Points no es un enfoque científico consistente para la estimación.
Demostrar de manera científica que solo lo que es científico correcto es correcto @ChrisBrettini.
Y "no consistente"... ¡eso no es cierto!

Respuestas (3)

No se le puede culpar por estar confundido. Es muy común que las organizaciones intenten hacer coincidir directamente los puntos de la historia con una medición del mundo real. Esto anula exactamente el propósito de usar puntos de historia (y por qué no me gusta Poker Planning para hacer estimaciones).

Un Story Point en términos simples es un número que le dice al equipo qué tan difícil es la historia. Difícil podría estar relacionado con la complejidad, las incógnitas y el esfuerzo. Nunca tuvo la intención de reemplazar una estimación basada en el tiempo. En cambio, ágil (Scrum, XP, etc.) reconoce que la estimación basada en el tiempo es defectuosa y la evita. Por ejemplo, un flujo de estimación clásico basado en el tiempo se vería así:

  1. Un ingeniero piensa que le llevará tres días. Entonces, para estar seguro, dice una semana.
  2. Al jefe del ingeniero le preocupa que pueda ser más complejo o que haya demoras en las dependencias, por lo que demoran dos semanas.
  3. El administrador del programa obtiene las evaluaciones de todos y, asumiendo que los ingenieros subestiman (oye, ¿cuándo fue la última vez que se envió un proyecto con todos los elementos originales del PRD?), agregan un error del 10 % al cronograma.
  4. Luego, siguiendo las mejores prácticas estándar de gestión de proyectos, se asigna a todo el proyecto un margen de programación del 20 %.
  5. Luego, la alta gerencia sabe que la gerencia ejecutiva no entenderá un programa de mejor caso/peor caso, simplemente agregan el 20% de reserva y lo convierten en la fecha oficial de lanzamiento.
  6. Por último, la ley de Parkinson entra en acción y el trabajo se expande para adaptarse al tiempo disponible. "Oye, tenemos 12 meses completos hasta que enviemos, ¡no tenemos que tener el código completo durante nueve meses ahora!"

Las estimaciones de Story Point funcionan mejor cuando son relacionales. No está tratando de estimar cuánto tiempo llevará. En cambio, está tratando de averiguar si la Historia A es más o menos compleja que la Historia B.

Veamos tu ejemplo anterior:

  • Cavar un hoyo de 1 m: bien entendido y sin sorpresas. El equipo le da con confianza 3 puntos.
  • Excavar hoyo de 2 m: aproximadamente el doble del trabajo de un hoyo de 1 m. Todavía bien entendido y sin sorpresas. 5 puntos.
  • Atrapa un elefante: Wow, no tenemos ninguna experiencia en esto y eso requerirá mucho equipo especializado. Definitivamente más esfuerzo que cavar un hoyo de 2m. También hay muchas incógnitas, por lo que el equipo apuesta por un 13.
  • Debido a que atrapar un elefante es tan nuevo, es posible que incluso creen un "pico" de investigación para enviar a alguien a investigar cómo atrapar un elefante.
Entonces, supongamos que tenemos tres historias de usuario. La historia más fácil la estimaremos en 2 SP, la historia un poco más difícil la estimaremos en 3 SP y, finalmente, la historia más difícil será 5 SP (el siguiente número de Fibonacci después de 3). Pero fundamentalmente no sabemos qué haremos más rápido: primer y segundo piso juntos o tercer piso.
A pesar de que estas historias (1+2 frente a 3) tienen la misma suma de puntos de historia, la implementación de las dos primeras y la última historia puede llevarnos un tiempo diferente porque, en realidad, no sabemos el valor para cuál historia es más difícil que otro. Solo sabemos el hecho de que estas tres historias tienen diferentes dificultades. Entonces, comparar o agregar puntos entre sí no tiene sentido.
¿Te entendí bien?
Esencialmente sí. Recuerde, el propósito de estimar es determinar cuánto trabajo puede hacer el equipo en un sprint. Esto funciona sobre el agregado. En una buena implementación ágil, mide las historias completadas, no los puntos de la historia y mide la variación de la velocidad, no la velocidad en sí misma (la velocidad es una medida interna del equipo). No dude en enviarme un ping directamente si tiene más preguntas.
Joel, gracias por la buena explicación de Story Points. Decidí intentar usar camisetas para medir historias. Como lo entiendo ahora, esto es absolutamente lo mismo que los Puntos de Historia de Fibonacci. Pero con las camisetas no tendré muchas ganas de hacer cálculos con ellas =)
El tamaño de la camiseta es la medida de entrada a la estimación. La gente puede poner sus manos alrededor de él muy fácilmente. Una buena eleccion. Incluso si pasa a una estimación más detallada para el equipo, en el futuro (lo cual recomiendo), el tamaño de la camiseta es excelente para la planificación a nivel de cartera.
@Joel, estoy confundido acerca de su punto "mide las historias completadas, no los puntos de la historia y mide la variación de la velocidad, no la velocidad en sí". ¿Eso significa que conocer el SP promedio completado por sprint de mi equipo no es bueno para ayudarlos a saber si el próximo sprint está inflado? Tengo mucha curiosidad por esto.

Como dijo Joel, los SP no son una medida del mundo real. Simbolizan el esfuerzo necesario para completar una historia de usuario.

Al ser independientes de una unidad, se pueden aplicar a todo lo que requiera esfuerzo . Debido a esta definición imprecisa, a menudo se recomienda usar el número de Fibonacci para marcar un mayor esfuerzo.

Me ayuda a imaginar botellas de sudor creadas por el equipo necesarias para completar la historia. Siéntase libre de introducir una imagen más conveniente :)

Gran visual, Tobías. :)

En mi aprendizaje académico, siempre me dijeron que primero aceptara la carta del cliente por razones de gestión de cambios de acuerdo con PMBOK. Luego mire los hitos y calcule estos. Estos te ayudarán a decidir cuántos sprints necesitas. Luego vas y obtienes las historias de los usuarios. Estos forman la acumulación de productos donde se preparan las historias de los usuarios y el usuario las prioriza. Si estas historias están fuera del alcance de la carta del proyecto inicial, se le indica al usuario y se llega a un compromiso o acuerdo. ¿Esto ayuda? Creo que puede estar insinuando la gestión del cambio. Pido disculpas si he malinterpretado la pregunta. Esta es solo una vista de alto nivel de mi implementación de la gestión ágil de proyectos. Creo que primero se necesita una buena carta y un plan para ver la finalización exitosa del software y un usuario satisfecho.

Si está tratando de encajar ágil en un proceso de cascada más grande, así es como se hace comúnmente. También es uno de los principales lugares donde escuchamos que "scrum está fallando". En ágil, un producto está terminado cuando tiene suficiente valor para el cliente. Eso podría ser después de tres sprints, podría ser después de doce.
¿Cómo usar Story Points, si las historias de usuario son completamente diferentes?
RespuestasAquíPolítica de privacidad1y, 1v