Scrum: cómo llevar una historia de usuario parcialmente completa al siguiente Sprint sin sesgar la acumulación

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

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

Decidimos que es esencial mantener registros precisos de las historias de usuario que hemos implementado, ya que éstas forman la base de nuestras pruebas, documentación de soporte y notas de lanzamiento, que excluyen la opción B.

A continuación, nos dimos cuenta de que era esencial poder realizar la planificación del sprint con precisión, 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 que podamos planificarlos correctamente en los sprints posteriores. Con el tiempo, la acumulación de productos 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 registro e informe.

La opción A es un curso de acción comúnmente recomendado. No otorgue puntos por completar la historia del sprint anterior y volver a mover la historia a la cartera de productos, donde se vuelve a priorizar. Calcula tu velocidad (y otras métricas) en función de las historias de usuario completadas y el valor agregado. Cuando comienzas a planificar para el próximo sprint, tomas las historias de mayor prioridad en función de su valor (lo que podría incluir o no la historia sin terminar, si las prioridades comerciales han cambiado). Cuando estime la historia, incluya el trabajo que ya se ha hecho al tener en cuenta la nueva cantidad de puntos de 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 fundamentada, pero hizo demasiado trabajo para el sprint (por ejemplo, la historia realmente valió 3 puntos, pero el problema radica en el hecho de que logró 15 puntos en la historia cuando solo deberías haber bajado 13). Es una suposición potencialmente peligrosa si no confía en su capacidad para realizar las estimaciones, pero podría funcionar según el equipo y el proceso.

Sin embargo, menciona que esto "estropeará los informes de la cartera de productos". El Backlog del producto debe ser dinámico de todos modos, con el orden y las estimaciones de cada historia cambiando a medida que se comprende más sobre la tecnología, el sistema, los requisitos y el cliente. Por lo general, lo que se informa de la acumulación de productos es la cantidad de historias de usuarios y la cantidad total de puntos de historia. Se debe esperar que estos cambios cambien a medida que cambien las prioridades, se agreguen nuevos requisitos, se eliminen los requisitos no válidos y se obtenga más información.

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, es todo o nada.

Así que cambiamos toda la historia sin terminar al siguiente sprint y todos sus puntos de historia se agregarán a la velocidad del próximo sprint. Las velocidades se igualan a lo largo del tiempo y tomamos un promedio de los pocos sprints anteriores como referencia para determinar las velocidades futuras estimadas.

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

Opción C

Las historias incompletas regresan a la cartera de productos, sin que se cambien los puntos. Cuando se planifica el próximo sprint y qué se puede hacer, la discusión debe incluir el hecho de que gran parte del trabajo ya está realizado. Si el equipo decide que puede encajarlo en el sprint, entonces entra, con su número original de puntos. Si no, se queda en el backlog. Hecho. Los puntos se otorgan al sprint en el que se completó la historia.

Si le ayuda, puede realizar un seguimiento de una métrica separada de "trabajo restante" por historia de usuario, de modo que si, al final del sprint, la historia no está completa, el trabajo restante restante se puede anotar en la historia y factorizado al momento de planificar su inclusión en un sprint posterior. Pero incluso entonces, no alteres el valor en puntos de la historia original.

Si su herramienta de informes no puede manejar la opción A de manera precisa, me quedaría con la opción B a menos que no tenga ninguna esperanza de usar sus métricas.

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

editar: Esto supone (ya que creo que el OP estaba asumiendo) que el trabajo casi completo no se ha derribado en prioridad y que llegar a la recompensa en el 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 restante casi completa es lo suficientemente valioso como para continuar simplemente a menos que algo haya cambiado drásticamente. La pena de cambiar de contexto a menudo no vale la pena cambiar el orden.

Hacemos un seguimiento del tiempo empleado en la iteración de sprint para el uso de mayúsculas (horas quemadas en las tareas relacionadas con una historia de usuario), y movemos la historia del usuario puntual si el objetivo de la orden de compra es mantenerlo en movimiento durante la próxima Sprint, dejando puntos iguales.

Si el objetivo del PO es mover algo más hacia arriba en su lugar, entonces simplemente pondríamos la historia sin terminar en el registro y haríamos lo que quisieran. Dejar la estimación original de puntos es mi recomendación, porque si tuviera la costumbre de morder más de lo que podría masticar, en cada carrera, estaría "completando" los puntos de la historia en una carrera que no estaba completamente hecha y limpia. artículos probados

Si quisiera dejar algo en el sprint, señaló, o tuvo que enviar, pensaría que determinaría un punto de división dentro de la historia original, al que llegó al punto de finalización y se comprometió Esa pieza más pequeña para tu iteración. Luego, el resto se podría volver a apuntar y colocar en el backlog. Esa sería una oportunidad para volver a estimar porque estuvo de acuerdo con su equipo para dividir la historia en partes.

  

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

No creo que las opciones A a C sean buenas, principalmente porque (creo) que 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 determinado subió o bajó.

Cuando se define una historia de usuario, debe tener criterios de aceptación. Si se hace no en los criterios de aceptación, el equipo simplemente no gana ninguno de los puntos. Si la historia está terminada (es decir, codificada, probada y aceptada por el P.O.), el equipo obtiene todos los puntos.

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

Al igual que M. Cohn en su libro, tiendo a tener una preferencia por 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 va a terminar siendo otro juego de adivinanzas ... y no olvides que ya tienes la inicial estimar lejos. Probablemente sea mejor usar el método más simple y obtener todos los puntos una vez que se hayan completado.

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

  

Generalmente estoy a favor de una postura de todo o nada para contar la velocidad: si se hace una historia (codificada, probada y aceptada por el propietario del producto), el equipo gana todos los puntos, pero si hay algo en La historia no está hecha, 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 asuma 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 menor de lo esperado porque no tienen crédito por completar parcialmente una historia. Sin embargo, en la segunda iteración, su velocidad será mayor que la esperada 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 aumentó o disminuyó en una iteración determinada.

¹ 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 funcionara bien en absoluto. (Ya no lo hacemos ... imagínense) Este es especialmente el caso porque se supone que las historias se estiman como como un equipo , pero si solo una persona está trabajando en ello, será más difícil para el equipo saber cuánto ha completado realmente un individuo . Agile está más interesado en la velocidad promedio de un equipo que en lo "bonito" que se ve un sprint en particular.

Dicho esto, el autor hace menciona que la asignación de puntos parciales puede considerarse si es poco probable que el equipo aborde el trabajo restante en la próxima 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 necesitarían igualar la estimación original ...

² Ditto, p.66

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

  

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

³ Ditto, p.67

Espero que esto ayude.

La primera pregunta es: ¿Qué significa un Punto de Historia? Si define un punto de la historia como "¿Cuánto trabajo se realiza la ingeniería", cualquier respuesta será suficiente? Sin embargo, si define un punto de la historia como "¿Cuánto valor se entrega al negocio", entonces es importante no dar crédito hasta que una historia se complete al 100%, se acepte y se entregue 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 medibles, d ) no es una comprensión lo suficientemente profunda de las tareas o dependencias para completar la historia, e) subestimó el esfuerzo para probar la historia, f) bajó demasiados puntos de la historia, o g) ... inserte su razón aquí ...

El objetivo de Agile es ser flexible y, al mismo tiempo, predecible. La mejor manera de ser coherente, en mi opinión, es averiguar qué salió mal sin modificar las estimaciones originales de la historia.