Scrum: cómo llevar una historia de usuario parcialmente completa al próximo Sprint sin sesgar el trabajo atrasado

Estamos usando Scrum y ocasionalmente descubrimos que no podemos terminar una historia de usuario en el sprint en el que se planeó. En el verdadero estilo Scrum, enviamos el software de todos modos y consideramos incluir la Historia del usuario en el próximo sprint durante la próxima sesión de Planificación de Sprint. Dado que la historia de usuario que estamos transmitiendo está parcialmente completa, ¿cómo la estimamos correctamente en la próxima sesión de Sprint Planning? Hemos considerado:

a) Ajustar el número de Puntos de historia para reflejar solo el trabajo que queda para completar la Historia de usuario. Desafortunadamente, esto arruinará el informe de la acumulación de productos.

b) Cierre la historia de usuario parcialmente completada y genere una nueva para implementar el resto de esa característica, que tendrá menos puntos de historia. Esto afectará nuestra capacidad de ver retrospectivamente lo que no completamos en ese sprint y parece un poco lento.

c) No se moleste con aob, y continúe adivinando durante la planificación de Sprint diciendo cosas como "Bueno, esa historia de usuario puede ser X puntos de historia, pero sé que está 95% terminado, así que estoy seguro de que podemos encajar".

En mi equipo actual hacemos c).

La velocidad debe explicar las cosas que el equipo realmente terminó en el sprint. Algo que no se entregó no tiene valor para el cliente, por lo que no contamos ningún punto por ello, es todo o nada.

Entonces cambiamos toda la historia inacabada al siguiente sprint y todos sus puntos de historia se agregarán a la velocidad del próximo sprint. Las velocidades se igualan con el tiempo y tomamos un promedio de los pocos sprints anteriores como referencia para determinar las velocidades futuras estimadas.

La opción A es un curso de acción comúnmente recomendado. No otorga puntos por completar la historia para el sprint anterior y volver a mover la historia a la cartera de pedidos del producto, donde se vuelve a priorizar. Calcula su velocidad (y otras métricas) en función de las historias de usuario completadas y el valor agregado. Cuando comience a planificar el próximo sprint, tomará las historias de mayor prioridad en función de su valor (que podría incluir o no la historia inacabada, si las prioridades comerciales han cambiado). Cuando calcule la historia, incluya el trabajo que ya se ha hecho al factorizar la nueva cantidad de puntos para la historia.

Por supuesto, una opción alternativa (y mi preferencia) sería usar el número estimado original de puntos de la historia, que es algo que he hecho en el pasado. Esto supone que su estimación fue buena y bien fundada, pero que realizó demasiado trabajo para el sprint (por ejemplo, la historia realmente valía 3 puntos, pero el problema radica en el hecho de que redujo 15 puntos de historia cuando solo deberías haber tirado 13). Es una suposición potencialmente peligrosa si no confía en su capacidad para realizar las estimaciones, pero podría funcionar en función de su equipo y proceso.

Sin embargo, usted menciona que esto "arruinará los informes de la cartera de productos". La cartera de productos debe ser dinámica de todos modos, con el orden y las estimaciones de cada historia cambiando a medida que se entienda más sobre la tecnología, el sistema, los requisitos y el cliente. Por lo general, lo que se informa del Product Backlog es la cantidad de historias de usuarios y la cantidad total de puntos de historia. Se debe esperar que cambien a medida que cambian las prioridades, se agregan nuevos requisitos, se eliminan requisitos no válidos y se aprende más información.

Pensar demasiado en esto hace que parezca más complicado de lo que es ... En realidad es bastante simple:

Opcion C

Las historias incompletas vuelven a la cartera de productos, sin cambiar los puntos. Al planificar el próximo sprint y lo que se puede hacer, la discusión debe incluir el hecho de que gran parte del trabajo ya se ha realizado. Si el equipo decide que pueden encajarlo en el sprint, entonces entra, con su número original de puntos. Si no, permanece en la cartera de pedidos. Hecho. Los puntos se otorgan al sprint en el que se completó la historia.

Si es útil, puede realizar un seguimiento de una métrica de "trabajo restante" por historia de usuario, de modo que si, al final del sprint, la historia no está completa, el trabajo restante estimado se puede anotar en la historia y tener en cuenta cuándo planeando su inclusión en un sprint posterior. Pero incluso entonces, no modifique el valor en puntos de la historia original.

Si su herramienta de informes no puede manejar la opción A con precisión, entonces elegiría la opción B a menos que no tenga la esperanza de usar sus métricas.

En algunos casos, puede hacer la opción B Y no sesgar lo que significa cerrar al reducir el alcance de la tarea anterior que está a punto de cerrar y solo crear una nueva tarea para el alcance que queda. Esto hace que la historia tenga más sentido semánticamente y generalmente indica lugares en los que debería haber considerado desglosar aún más la tarea. A veces esto no es posible o lógico y simplemente tiene una tarea que es tan grande o se encuentra con ese nivel de problemas.

editar: Esto supone (como creo que estaba asumiendo el OP) que el trabajo casi completo no ha sido eliminado en prioridad y que llegar al resultado del esfuerzo anterior lo mantiene lo suficientemente alto en la lista para continuar trabajando. Sé que algunas tiendas no hacen esto, pero la mayoría de los lugares en los que he trabajado consideran que terminar una tarea de sobra casi completa es lo suficientemente valiosa como para continuar, a menos que algo haya cambiado drásticamente. La pena de cambiar el contexto a menudo no vale la pena cambiar el orden.

Dado que la historia de usuario que estamos transmitiendo está parcialmente completa, ¿cómo la estimamos correctamente en la próxima sesión de Sprint Planning?

No creo que las opciones de la A a la C sean buenas, principalmente porque lo que (creo) debería ser más importante con respecto a la velocidad de un equipo es su velocidad promedio y no si la velocidad de un sprint subió o bajó.

Cuando se define una historia de usuario, debe tener criterios de aceptación. Si hay algo en los criterios de aceptación se no hace esto, entonces el equipo simplemente no gana cualquiera de los puntos. Si la historia está hecha (es decir, codificada, probada y aceptada por el PO), el equipo obtiene todos los puntos.

Esto funciona bien cuando el equipo se enfoca en su velocidad promedio en lugar de en la velocidad de un sprint dado.

Al igual que M. Cohn en su libro, tiendo a preferir un escenario de todo o nada. Después de todo, tratar de estimar si has completado 5 puntos de una historia de 8 puntos, o tal vez solo 6 o 7 terminará siendo otro juego de adivinanzas ... y no olvides que ya obtuviste la inicial estimar muy lejos. Probablemente sea mejor seguir el método más simple y obtener todos los puntos después de que realmente se haya completado.

Citando a M. Cohn de su libro¹ (mi énfasis):

Generalmente estoy a favor de una postura de todo o nada hacia la velocidad de conteo: si se hace una historia (codificada, probada y aceptada por el propietario del producto), el equipo gana todos los puntos, pero si algo en la historia no es hecho, no ganan nada. Al final de una iteración, este es el caso más fácil de evaluar: si se hace todo, obtienen todos los puntos; Si falta algo, no obtienen puntos. Si es probable que el equipo tome la parte restante de la historia en la próxima iteración, esto funciona bien. Su velocidad en la primera iteración es un poco más baja de lo esperado porque no obtuvieron crédito por completar parcialmente una historia. Sin embargo, en la segunda iteración, su velocidad será más alta de lo esperado porque obtendrán todos los puntos, aunque se haya completado algún trabajo antes del inicio de la iteración.Esto funciona bien siempre y cuando todos recuerden que estamos interesados ​​principalmente en la velocidad promedio del equipo a lo largo del tiempo, no en si la velocidad saltó hacia arriba o hacia abajo en una iteración dada.

¹ Estimación y planificación ágiles , reestimación de historias parcialmente completadas, p.66

Mi equipo había intentado previamente asignar puntos parciales, a pesar de algunas objeciones, y no creo que haya funcionado bien en absoluto. (No hacerlo más ... imagínense) Este es especialmente el caso porque las historias se supone que para obtener estimado como un equipo , sin embargo, si sólo una persona está trabajando en ello, va a ser más difícil para el equipo de saber cuánto ha completado realmente un individuo . Agile está más interesado en la velocidad promedio de un equipo que en lo "agradable" que se ve un sprint en particular.

Dicho esto, el autor hace mención de que la asignación de puntos parciales se puede considerar si el equipo es poco probable que abordar el trabajo restante en la siguiente iteración. En este caso, el equipo estimaría el trabajo restante y lo dividiría en nuevas historias de usuarios con el tamaño que consideren que deberían tener. Como el autor menciona²:

Las estimaciones combinadas no tendrían que ser iguales a la estimación original ...

² Ídem, p.66

La mejor recomendación para el equipo es dividir las historias a un tamaño suficientemente pequeño para evitar este tipo de problema³:

Sin embargo, las dos mejores soluciones para asignar puntos para historias incompletas son no tener historias incompletas y usar historias suficientemente pequeñas para que el crédito parcial no sea un problema.

³ Ídem, p.67

Espero que esto ayude.

Me sorprende que no haya una respuesta directa a esto. ¡Esperaba un coro de "opción D, tonto"!

Como no parece que nos falte nada obvio, pensamos que esta es una de esas decisiones que cada equipo necesita tomar por sí mismos en función de cómo quieren trabajar y qué métricas son más importantes para ellos.

Decidimos que mantener registros precisos de las historias de los usuarios que hemos implementado es esencial, ya que estos forman la base de nuestras pruebas, documentación de soporte y notas de lanzamiento, lo que descarta la opción B.

Luego nos dimos cuenta de que poder realizar la planificación del sprint con precisión era esencial, lo que descarta la opción C.

Por lo tanto, hemos concluido que la opción A es adecuada para nosotros. Vamos a volver a estimar los puntos de la historia para cualquier historia que completemos parcialmente en un sprint para poder planificar adecuadamente en los sprints posteriores. Con el tiempo, el trabajo atrasado del producto informará ligeramente la cantidad de puntos de historia que hemos implementado, pero esto será un problema menor que cualquiera de las otras opciones y podría resolverse cambiando nuestro mantenimiento de registros e informes.

Hacemos un seguimiento del tiempo que pasamos en la iteración del sprint con fines de capitalización (horas gastadas en tareas relacionadas con una historia de usuario), y movemos la historia de usuario puntiaguda si el objetivo de la OP es seguir transportando durante el próximo sprint, dejando señala lo mismo.

Si el objetivo de la OP es mover algo más en su lugar, simplemente pondríamos la historia inacabada en la cartera y haremos lo que quisieran. Dejar mi estimación original de puntos es mi recomendación, porque si tuvieras el hábito de morder más de lo que pudieras masticar, cada sprint, estarías "completando" los puntos de la historia en un sprint que no estaba completamente hecho y limpio. Artículos probados.

Si quisieras dejar algo en el sprint, puntiagudo, o tuvieras que enviar, creo que determinarías un punto de corte dentro de la historia original, al que llegaste al punto final, y comprometerías esa pieza más pequeña para su iteración Luego, el resto podría volverse a señalar y dejarse caer en el trabajo atrasado. Esa sería una oportunidad para volver a estimar porque acordó con su equipo dividir la historia en partes.

La primera pregunta es ¿Qué significa un punto de historia? Si define un punto de la historia como "Cuánto trabajo realiza la ingeniería", cualquier respuesta servirá. Sin embargo, si define un punto de historia como "Cuánto valor se entrega a la empresa", entonces es importante no dar crédito hasta que una historia esté 100% completada, aceptada y entregada al 100%. La modificación de los puntos de la historia después de un sprint basado en lo que se completó solo ocultará el problema real: a) no había una comprensión clara de la historia, b) la historia estaba demasiado definida, c) la historia carecía de criterios de aceptación mensurables, d ) no una comprensión lo suficientemente profunda de las tareas o dependencias para completar la historia, e) subestimó el esfuerzo para probar la historia, f) eliminó demasiados puntos de la historia, o g) ... inserte su razón aquí ...

El objetivo de ágil es ser flexible y predecible. La mejor manera de ser coherente, en mi opinión, es descubrir qué salió mal sin modificar las estimaciones originales de la historia.