Me doy cuenta de que el tamaño de la acumulación de un producto variará con cada proyecto. Pero suponiendo que un proyecto sea lo suficientemente grande como para requerir un período de tiempo significativo, ¿existe alguna investigación o estadística sobre los rendimientos decrecientes en términos de refinar historias y epopeyas?
En la respuesta de Zsolt: https://pm.stackexchange.com/a/6715/2730 Mencionó que los últimos 2/3 de la acumulación cambiarán en el futuro.
Esto parece estar en línea con la idea de Agile y Scrum. Me pregunto si hay un punto en el que es mejor consolidar esas historias en solo épicas, hasta el momento en que puedan estar en sprints en un futuro cercano.
¿Cuál es un buen tamaño para un backlog, en relación con la velocidad de los equipos?
¿Tiene sentido consolidar las historias existentes en épicas, si no se va a trabajar en ellas durante un período de tiempo significativo? (Asumiendo que la epopeya tendrá el mismo conocimiento de las historias originales)
Esta pregunta surge de nuestro caso específico. Tenemos casi 400 historias y completamos un promedio de 5 por sprint, en sprints de 2 semanas. Esto se debe principalmente a que el impulso inicial en scrum fue obtener todas las historias posibles en la cartera de pedidos, en lugar de formar épicas y dividirse a medida que se descubrían las verdaderas necesidades a través de la iteración.
Obviamente, afecta nuestra capacidad para administrar las próximas historias, creando duplicados, navegando a través de cientos de historias posiblemente irrelevantes o simplemente incorrectas en el proceso. No podemos actualizar las historias a medida que se obtienen nuevos conocimientos, lo que hace que dediquemos más tiempo a adivinar el significado y el propósito de las historias en lugar de iterar.
Sufrimos de una falta de priorización. Sin embargo, creo que la gran cantidad de historias está causando que el propietario del producto y las partes interesadas no quieran invertir tiempo en priorizar. Se siente muy gallina y huevo.
Espero encontrar alguna información que pueda usar para sugerir consolidar un gran número de historias en epopeyas, para desglosarlas más tarde, cuando la necesidad real de las epopeyas sea en un futuro cercano (4-8 sprints).
No existe un estándar real sobre la acumulación de productos. Hay demasiadas variables en lo que es esencialmente el plan estratégico de la empresa. La única orientación común que existe tiene más que ver con la eliminación de un retraso. Es "si un elemento ha estado en la cartera de pedidos más de X (generalmente un año o dos años), entonces elimínelo. Si era realmente importante, se agregará nuevamente".
Con 400 historias de usuarios individuales, tiene aproximadamente dos años de trabajo pendiente. Sin embargo, por lo que dice, parece que su "registro pendiente" no es muy profundo. Listo, puede ser recogido por el equipo de desarrollo y ejecutarlo. Aquí existe un estándar comúnmente aceptado de que la parte superior de la cartera de productos debe tener 2 o 3 sprints de historias que cumplan con la definición de "listo", donde el equipo de desarrollo puede recogerlas y ejecutarlas. Podría trabajar primero en esta disciplina, si es posible enfocándome en la preparación del trabajo pendiente en el 20 % superior del trabajo pendiente.
Para tratar de controlar la acumulación de productos, sugeriría dos soluciones, una proactiva y otra reactiva. Recomendaría hacerlos en el siguiente orden.
Mapeo de afinidad (reactivo): básicamente un nombre elegante para "ponerlos en Epics". Sin embargo, el ejercicio es importante. Querrá un facilitador (scrum master, gerente de proyecto imparcial, etc.) Imprima esas 400 historias de usuarios en papel físico. Obtenga una gran pared abierta y pegue todas las historias de usuarios en la pared de un lado (incluso en otra pared). Luego, como grupo, empiecen a sacar historias y ponerlas en la pared. El objetivo es empezar a agruparlos. Sin embargo, no hay una lista preestablecida de categorías, las categorías surgirán de cómo las personas las agrupen. A medida que crecen estas categorías, cree notas adhesivas para etiquetarlas. Es posible que encuentre que algunas historias encajan en diferentes grupos (si esto sucede, puede engañar a la historia o juntar los dos grupos para que la historia los abarque).
Cuando haya terminado, tendrá un orden y una agrupación naturales de las historias. Estas son tus epopeyas. Al hacer esto, no termina con asignaciones arbitrarias, termina con categorías que tienen sentido para todos. Como resultado, también obtendrá una idea de las dependencias.
Pode el árbol de productos (proactivo): Conteneo.co ofrece ejercicios de colaboración que las empresas pueden usar para casi cualquier cosa, desde la planificación estratégica hasta las retrospectivas. La mayoría tiene versiones en línea y fuera de línea.
Pode el árbol de productos es un ejercicio para mapear los horizontes de lanzamiento y lo que es importante en esos horizontes. La versión corta (vaya al sitio de Conteneo para obtener instrucciones adecuadas) es que tiene un mapa de pared grande que se parece más o menos al contorno de un árbol. Para el cuerpo del árbol, diseñe varios anillos concéntricos (una diana) y asigne estos horizontes temporales (próximo trimestre, seis meses, próximo año, etc.).
Tome sus categorías del último ejercicio y colóquelas en "manzanas" (pueden ser solo notas adhesivas). También crea de diez a veinte "manzanas" en blanco. Todas las manzanas se ponen en la pared al lado del árbol. El ejercicio es entonces el acto de poner las manzanas en el árbol donde tienen sentido en el horizonte temporal. Las manzanas en blanco permiten la creación de nuevos conceptos y temas. Las raíces también son importantes, representan la infraestructura requerida o las dependencias externas. Puede terminar colocando manzanas aquí para rastrear estas dependencias.
Espero que ayude.
Usando el principio justo a tiempo, asumiendo que usa historias simplemente como elementos de trabajo tangibles que el equipo consume, y que no usa su cartera de productos para reflejar su hoja de ruta del producto...
El backlog de tamaño "bueno" mínimo garantiza que su equipo nunca se quede sin trabajo en ningún momento durante el ciclo de vida de la iteración.
Si su equipo tiene una velocidad de X que generalmente varía hasta Y puntos de historia, intente mantener un trabajo pendiente preparado que siempre tenga al menos X + Y puntos de historia. Todo más allá de los puntos de la historia X+Y se puede representar como una epopeya de nivel superior.
Al permanecer en el nivel épico después de que se cumpla con su totalidad en las historias, reduce el desperdicio que se produce al preparar historias que probablemente cambien en el momento en que se introduzcan en una iteración.
Por ejemplo, un equipo con una velocidad de 70, que se sabe que entregó hasta 100 durante una iteración, debe tener un backlog preparado con un mínimo de 100 puntos de historias que se puedan extraer en cualquier momento.
Después de los ~100 pts, se pueden preparar historias adicionales según sea necesario a partir de épicas en su backlog justo a tiempo a medida que las historias se incorporan a una iteración.
CLo
Joel Bancroft-Connors
CLo
CLo
Joel Bancroft-Connors