En Scrum, ¿cómo estimar historias de investigación?

Las historias de investigación (llamadas Spikes en términos ágiles) deben ser:

• usado con moderación
• mantenido corto
• estar siempre en caja de tiempo

¿Deberíamos asignar un cuadro de tiempo (tantas horas) para las historias de investigación o una estimación puntual regular?

La estimación puntual regular no se puede utilizar principalmente debido a las siguientes razones:

• los puntos de la historia dan una medida del valor comercial
• los puntos se utilizan para calcular la velocidad del equipo para generar valor comercial
• los picos se inician cuando "hay incertidumbre sobre una historia o el equipo no está seguro de cómo implementarla". Cuando ya existe una incertidumbre, se vuelve irrazonable estimarla en una sesión de planificación de póquer. Se vuelve difícil comparar los tamaños relativos de un trabajo de investigación (actividad desconocida) con una pieza de software en funcionamiento, como la creación de un módulo de carrito de compras (actividad conocida). Un pico lo ayudaría a reducir los riesgos para que pueda comprender / estimar mejor otras historias de usuarios.

Un aumento finaliza cuando ha logrado los resultados deseados o se acaba el tiempo.

Similitudes entre historia y espiga:

• tiene criterios de aceptación (lo que significa "hecho" para este pico)
• añadido a la acumulación de iteración/sprint
• se discuten los hallazgos o se demuestra el resultado del pico al final de la iteración

Diferencia entre historia y espiga:

Spike no entrega productos que se puedan enviar (valor comercial). Como afirman los principios ágiles , el software en funcionamiento es la medida principal del progreso , la finalización de un pico no crea directamente un software en funcionamiento.

TL; DR

¿Deberíamos asignar un cuadro de tiempo (tantas horas) para las historias de investigación o una estimación puntual regular?

Deberías hacer ambas cosas. Un pico (o "historia con picos") requiere tanto un cuadro de tiempo como una estimación del nivel de esfuerzo, y siempre se cuenta como trabajo .

Los picos son solo historias de usuarios especiales

Como afirma una fuente :

Al igual que otras historias, los picos se colocan en el backlog, se estiman y se dimensionan para encajar en una iteración... El resultado de un pico es demostrable, tanto para el equipo como para cualquier otra parte interesada... Y, como cualquier otra historia, los picos son aceptados por el propietario del producto cuando se han cumplido los criterios de aceptación para el pico.

La distinción principal es que una historia con picos está diseñada para reducir el cono de incertidumbre en lugar de ofrecer un incremento que se pueda enviar. Sin embargo, se aplican todos los demás requisitos de buenas historias de usuario y procesos marco.

Por qué los picos deben estimarse con puntos de historia

Scrum y XP tienen que ver con el tiempo de boxeo; por lo tanto, es axiomático que todos los procesos dentro de estos marcos deben tener una duración finita. Sin embargo, la razón para asignar puntos de historia es un poco menos obvia.

El lema ágil de CodeGnome es Ningún trabajo invisible, nunca. Dado que un pico consume tiempo y recursos dentro de un sprint, es esencial que el esfuerzo invertido en el pico sea totalmente visible para el proyecto. La forma de hacerlo dentro de Scrum es asegurarse de que el pico sea:

• enumerados en los atrasos apropiados,
• contado como trabajo para ser llevado al sprint, y
• representado en el gráfico de quemado.

Si bien algunas personas pueden argumentar que asignar puntos de historia a los picos sesgará la velocidad, esto es un malentendido de la métrica de velocidad. La velocidad no mide características, mide capacidad . Específicamente, la velocidad es un promedio final que se usa para estimar la capacidad disponible del equipo para futuros sprints.

Depende del Propietario del Producto priorizar esa capacidad. Equilibrar la entrega de características entregables con otros requisitos del proyecto (quizás menos tangibles) es competencia del Propietario del Producto; rastrear y estimar todo el esfuerzo relacionado con el proyecto en el Product Backlog es el mecanismo esencial para expresar ese equilibrio visiblemente dentro del proyecto.

Esta es una gran pregunta, ya que esto también nos surge mucho.

No hemos hecho nada específico para esto antes, pero creo que tienes razón sobre el tiempo. X cantidad de horas, y luego volver a reunirse. Si están "casi allí" en la búsqueda de respuestas, tal vez haga una nueva historia para la ronda 2 de investigación y así sucesivamente.