Cómo rastrear criterios de aceptación incompletos en JIRA

Tengo una pregunta sobre los criterios de aceptación incompletos en un sprint.

Se dice que una historia de usuario está completa si se cumplen todos los criterios de aceptación. Puede haber múltiples criterios de aceptación para cada historia de usuario. Es posible que algunos criterios de aceptación no puedan completarse debido a un desarrollo incompleto o tardío. Por lo general, clonamos la historia de usuario y la movemos al siguiente sprint para su seguimiento. Sin embargo, existe la posibilidad de que se completen algunos criterios de aceptación y otros no. Así que este proceso es difícil de rastrear.

¿Tiene alguna solución para realizar un seguimiento de las tareas incompletas en el próximo sprint?

Respuestas (4)

Por lo general, clonamos la historia de usuario y la movemos al siguiente sprint para su seguimiento.

No hagas eso.

La historia no está terminada . Si lo pones en Listo y lo clonas, tu velocidad se verá afectada. Parecerá que completó el trabajo, cuando no lo hizo. Esto hará que sobreestimes en el futuro, porque los informes de velocidad muestran erróneamente que eres capaz de completar más trabajo del que realmente puedes.

existe la posibilidad de que se completen algunos criterios de aceptación mientras que otros no.

Así que agregue columnas/estados que representen los criterios de aceptación. Solo muévalo a la columna Listo más a la derecha una vez que se hayan cumplido todos los criterios. Si el Sprint finaliza y la historia aún no ha terminado, simplemente déjalo . JIRA debería moverlo a su Product Backlog automáticamente al finalizar el Sprint.

Posteriormente, deberás evaluar la historia con normalidad en la Reunión de Planificación del Sprint. Vuelva a estimar/volver a priorizarlo como de costumbre.

¿Deberíamos mover las historias incompletas a la cartera de productos?

Sí.

Esto subestimará los puntos en [el sprint donde no se completaron las historias].

No. No completaste el trabajo. Lograste 0 puntos de historia para esa historia. Por lo tanto, su gráfico de trabajo pendiente mostrará que la historia no se ha quemado.

Esto es correcto.

En lo que respecta a Scrum, una historia que está terminada en un 90 % no proporciona ningún valor comercial y, por lo tanto, se trata igual que si estuviera terminada en un 0 %. Su velocidad solo debe tener en cuenta la cantidad de puntos de historia Terminados que puede completar en un Sprint.

Solo asegúrese de volver a estimar la historia antes de incluirla en un nuevo Sprint. Si una historia original de 13 puntos está terminada en un 90%, solo debería ser 1 punto para el nuevo Sprint.

Gracias sarov por tus valiosos puntos. Estoy realmente confundido al mover las historias de usuario incompletas a la cartera de productos. Es posible que ya dediquemos algo de tiempo a esa historia incompleta y pasar a la cartera de productos subestimará los puntos en el sprint en particular. No estoy seguro de haber entendido tu respuesta. Dejame explicar. Supongamos que estamos en el sprint 12 y algunas historias no están completas. ¿Deberíamos mover las historias incompletas a la cartera de productos? Esto subestimará los puntos en el sprint 12. Básicamente, estoy tratando de entender las mejores formas de rastrear estas situaciones en JIRA.
@JithinAntony Se recalculan todas las historias sobre la cartera de productos. Lo que importa es la cantidad de trabajo restante para entregar la historia, no la cantidad de esfuerzo invertido previamente en ella.
Me tenías despierto hasta 'reestimar'. La velocidad solo es útil como medida a lo largo del tiempo. No vuelva a estimar. Estoy de acuerdo con Mike Cohn. Enseño a todos los equipos a no reestimar ya que, lo que efectivamente ha hecho, es desaparecer 12 puntos del alcance del proyecto y su historia de referencia está desordenada. Solo mi opinión, pero no me importa si los 13 puntos se capturan en Sprint A, B o C o incluso D. En el transcurso de 5 Sprints aparecerán en alguna parte. Eso es lo que cuenta. Velocidad en el tiempo. Si tenemos 10 historias en total. Los 13 puntos. Y todos ellos están incompletos... y reestimados...
..de repente, su proyecto se ha reducido a 10 puntos desde 130. (Un ejemplo extremo, pero ilustrativo, no obstante). puede esperar un hiperdoodle cada 10 puntos!"
@Venture2099 No, porque la velocidad no es una medida de productividad o valor. Está pensado como una medida predictiva de cuánto trabajo se puede entregar en una sola iteración. El truncamiento y la reestimación generalmente producen resultados más útiles que las funciones de suavizado complejas y con un costo cognitivo más bajo. Llevar las estimaciones hacia adelante suele ser una forma de dar cuenta del esfuerzo realizado, o un intento erróneo de tratar la velocidad como una medida del valor entregado. Las personas razonables pueden estar en desacuerdo sobre las prácticas ágiles, pero el marco Scrum requiere una nueva estimación en los límites de Sprint.
Tendremos que estar en desacuerdo sobre esto; Simplemente no me alineo con esa opinión. ¿Dónde pide la reestimación el marco de Sprint? Dice volver a estimar SOLO si se cancela un Sprint. Esa es la única vez que se requiere una reestimación en la Guía Scrum. Dice "A medida que se realiza o completa el trabajo, el trabajo restante estimado se actualiza", pero si lo seguimos estrictamente, entonces el equipo de desarrollo debería volver a estimar las historias todos los días y posiblemente cada hora. ¿Dónde quieres trazar la línea? Lo dibujo en punto final de reestimación. Me siento cómodo con mi enfoque y lo considero Scrum.
"La velocidad no es una medida de productividad o valor. Está pensada como una medida predictiva de cuánto trabajo se puede entregar en una sola iteración". Precisamente _ Es por eso que, dado que tomamos la velocidad como un promedio móvil de 5 Sprint, no importa si los 13 puntos se consumen en Sprint A, B, C, D o E. Lo que ha hecho es reducir artificialmente la velocidad al desaparecer 12 puntos de esfuerzo Si mi equipo entrega 20, 21, 25, 7 y luego 31 puntos, me siento cómodo con que su velocidad promedio sea de 21 puntos.
Si tuviera que eliminar mágicamente 12 puntos de la iteración final debido a la nueva estimación, entonces su registro de velocidad se convierte en 20, 21, 25, 7 y... 19. Lo cual no es un reflejo de todo el esfuerzo y la complejidad invertidos en 5 Sprints.
@Venture2099 ¿Qué harías en la siguiente situación?: Historia de 10 puntos. Hazlo a medias en el Sprint 1. En la reunión de planificación del Sprint 2, date cuenta de que hay una mejor manera de hacerlo que invalida la mitad del trabajo que has hecho y también requiere más trabajo. En general, el trabajo restante ahora es de 7 puntos. ¿Cuántos puntos le pondrías para Sprint 2?
Además, esto se está haciendo un poco largo, ¿debería moverse al chat?
Marcaría la historia como rechazada (perdería los 5 puntos c'est la vie) y luego escribiría una nueva historia con los nuevos criterios de aceptación (después de todo, no hay puntos por valor incompleto e inédito). Pero su ejemplo ocurre rara vez, si es que ocurre alguna vez. Mi ejemplo es una de las cosas más comunes que ocurren en el marco de Scrum y afecta a los foros de Scrum.

Como se refiere a sprints e historias de usuarios, asumiré que está utilizando el marco Scrum.

Dentro de Scrum, no existe tal cosa como una historia de usuario parcialmente completa. Se puede hacer una historia de usuario, en cuyo caso se han cumplido todos los criterios de aceptación y la definición de hecho, o no se puede hacer la historia de usuario.
Cuando, al final de un sprint, algunas historias no se completan, esas historias deben moverse en su totalidad a la cartera de productos para volver a planificarlas junto con el resto de la cartera.

Una vez que el equipo piensa que una historia de usuario está hecha, es cuando se debe verificar que se hayan cumplido todos los criterios de aceptación.

Si es frecuente que tenga historias de usuarios con criterios de aceptación parcialmente completados y ese conjunto parcial de criterios de aceptación por sí mismo proporciona valor al negocio (es decir, tiene un mejor producto para mostrar a sus partes interesadas), entonces podría ser que sus historias se pueden descomponer aún más en historias más pequeñas.

Si este es el caso, le recomendaría que intente dividir esas historias hasta que ya no sea posible agregar valor con solo un subconjunto de los criterios de aceptación.

+1 por publicar historias en las que no se han cumplido todas las CA y generar una nueva historia de usuario para cubrir el resto del trabajo... *si* el trabajo es publicable y tiene valor en su estado actual.

Recomiendo establecer una función para denotar los criterios de aceptación hechos de los criterios de aceptación no hechos en cada tarjeta. Esto se puede hacer simplemente usando cursiva, negrita, coloreado, casillas de verificación, etc. para ayudar a separar qué criterios de aceptación se cumplen de los criterios de aceptación que están incompletos. Una vez que se cumple una parte de los criterios de aceptación, alguien del equipo debe actualizar la tarjeta para visualizar de alguna manera que la parte ha sido satisfecha. Esta información puede y debe visualizarse e inspeccionarse en el scrum diario para ver qué trabajo debe considerarse a medida que su equipo avanza hacia su(s) objetivo(s) de sprint.

Totalmente de acuerdo con la respuesta de Sarov re: no marque Historias como terminadas si no lo están.

Considere también si sus Historias son demasiado grandes. ¿Se requieren todos esos criterios de aceptación para la entrega mínima de esa Historia? Tal vez considere hacer las Historias un poco más pequeñas. Obtendrá más "hecho" en cada caja de tiempo de Sprint y seguirá entregando un producto valioso.

Cómo rastrear criterios de aceptación incompletos en JIRA
RespuestasAquíPolítica de privacidad1y, 5v