Historia de larga duración

TL;DR

Se supone que un artículo bloqueado debe ser inspeccionado y abordado; no pretende ser una piedra de tropiezo perpetuamente inamovible. Si descompone su historia en tareas basadas en el esfuerzo, el elemento "negociable" de los criterios INVEST le permite intercambiar pequeñas dependencias dentro y fuera de su flujo para dejar espacio para un trabajo en curso (WIP) más procesable.

Dividir historias que dependen del tiempo en tareas impulsadas por el esfuerzo

Como los factores externos solo pueden hacer progresos prácticos en la historia cada pocos días, la historia se atasca un poco en la columna de Desarrollo.

En Scrum, la estimación se basa en el nivel de esfuerzo, no en el tiempo. Hay una serie de otras preguntas y respuestas sobre este tema, por lo que no lo extenderé, excepto para decir que las tareas de ejecución prolongada no son inherentemente tareas de alto esfuerzo.

Scrum se basa en el time boxing, por lo que arrastrar una sola historia de Sprint a Sprint es siempre un marco antipatrón. Sin duda, hay casos en los que un esfuerzo iniciado en una iteración no dará sus frutos hasta una iteración futura, pero eso no elimina la obligación de cronometrar sus historias o limitar el trabajo en curso.

Como enfoque pragmático, considere dividir su historia de usuario en historias o tareas que traten el inicio de un proceso como algo distinto de recopilar los resultados o iterar en el elemento de trabajo. Si bien los cortes verticales son un objetivo ágil general, en Scrum el time boxing tiende a producir resultados más consistentes debido a la teoría de colas: los tamaños de lote más pequeños, los límites WIP y las colas más cortas son simplemente más eficientes.

Como ejemplo, en lugar de una "historia" como:

Embiggen el whatchamacallit durante 4 Sprints.

considere dividir la historia principal en historias de Sprint Backlog como:

# Historia
inicial Como miembro del equipo,
quiero iniciar el script de ampliación como un trabajo en segundo plano
para que pueda continuar ejecutándose hasta su finalización.

# Historia de seguimiento
Como miembro del equipo,
quiero revisar el registro de aumento periódicamente
para saber cuándo se termina el guión.

# Collection Story
Como miembro del equipo,
quiero capturar los resultados del script de ampliación
para que esté disponible para otras historias que tengan datos de ampliación como dependencia.

En este ejemplo, es probable que cada historia tenga un nivel de esfuerzo muy bajo. Ejecutar un guión, mirar un archivo de registro o recopilar los resultados completos son tareas pequeñas o tareas que probablemente tengan un tamaño de 0 o 1/2 punto, individual o colectivamente. Esto significa que, si bien las historias/tareas tienen una dependencia lineal (por ejemplo, no puede inspeccionar o usar los datos antes de que se recopilen), cada elemento del trabajo pendiente puede caber en una sola iteración. Además, debido a que no se encuentra en el estado "en progreso" indefinidamente, evita abusar de sus límites WIP.

Intercambio y reordenación de elementos pendientes

En muchos casos, tales historias/tareas pueden quedarse en la cola "Listo" de Sprint o Kanban hasta que alguien las saque. Luego se pueden manejar rápidamente y mover a "Listo" o regresar un poco más abajo en la columna "Listo" para dejar espacio para otras tareas activas en el Sprint. Siempre que su Objetivo de Sprint actual no se vea comprometido al mover una tarea de nuevo a "Listo" o al dejarla sin hacer por completo, este es un enfoque perfectamente legítimo. ¡Los resultados de tu cadena de tareas no son realmente necesarios hasta que tu Sprint Goal depende de ellos!

Ni Kanban ni Scrum evitan que un elemento de trabajo se elimine de los carriles de natación en curso. Mientras se ordena el Product Backlog, un Sprint Backlog o un tablero Kanban representa con mayor precisión un flujo de proceso coherente, no una cola FIFO estricta. Por lo tanto, si bien la regla es que no debe exceder su límite WIP, no hay nada que le impida modificar sus límites WIP o eliminar elementos del flujo en lugar de simplemente bloquearlos indefinidamente. Se supone que se debe abordar un elemento bloqueado; no pretende ser un obstáculo perpetuamente inamovible a lo largo del Sprint o del ciclo de vida del proyecto.

debido a los diversos factores externos

es la causa Eso es lo que hay que tratar.

El Equipo Scrum está formado por un Product Owner, el Equipo de Desarrollo y un Scrum Master. Los Equipos Scrum son autoorganizados y multifuncionales. Los equipos multifuncionales tienen todas las competencias necesarias para realizar el trabajo sin depender de otros que no forman parte del equipo.

La guía Scrum

El contexto es el rey, por lo que sin conocer detalles específicos, una idea rápida (con una referencia que se me ocurre en este momento) es Slicing para aislar las dependencias externas que no se pueden eliminar por completo.

Tradicionalmente, el equipo lleva la historia a través de los sprints hasta que cumple con su definición de hecho (ya sea que se lance a vivir, pase las pruebas de aceptación, lo que sea). No intente asignar algunos de los puntos a un sprint y algunos a otro, manténgalo simple y asegúrese de que cuando termine, todos los puntos se agreguen a esa iteración.

La razón por la que esto funciona desde el punto de vista de la velocidad es porque la velocidad se basa en la velocidad promedio de varios sprints. Tus logros en los sprints anteriores parecerán poco impresionantes, pero cuando asignas los puntos al sprint en el que se completó la historia, el promedio asegurará que los números salgan bien.

Tengo muchas dudas de que esta historia no se pueda dividir, en mi experiencia, la mayoría de las historias se pueden dividir en componentes que duran 5 días o menos.

Idealmente, el equipo debería completar todo lo que acuerden en la planificación del sprint.

¿Algunas cosas a tener en cuenta al ver por qué esta historia requiere tantos sprints para completarse?

• ¿El equipo está haciendo demasiado trabajo?
• ¿Está entrando demasiado trabajo no planificado?
• ¿Es la historia demasiado grande y necesita ser dividida?
• ¿La historia no es importante (y todos la conocen y, por lo tanto, la ignoran silenciosamente) y debería ser abandonada?

Sin embargo, si como usted dice es realmente imposible, entonces no se preocupe demasiado y simplemente reclame los puntos cuando haya terminado.

TLDR

Los números deben resolverse por sí solos, pon tu esfuerzo en averiguar por qué la historia no se completa.