Dimensionar un backlog completo usando puntos de historia

Soy PM en un gran proyecto de varios años con una considerable acumulación de trabajo implementando Scrum en ciclos de lanzamiento de 4 semanas. Realizo sesiones semanales de preparación del trabajo pendiente con el equipo del proyecto y los propietarios de negocios clave para revisar las historias de usuario en el trabajo pendiente, dividir las historias de usuario más grandes (épicas) en otras más pequeñas que el equipo del proyecto puede comenzar a implementar en el sprint y dimensionar estas historias de usuario más pequeñas. utilizando puntos de la historia.

El uso de puntos de historia asociados a una historia de usuario es un concepto bastante nuevo para el equipo y solo se ha implementado en los últimos 6 meses del proyecto (que comenzó hace 1,5 años). Por lo tanto, todo el backlog no está dimensionado en puntos de historia.

Inicialmente, mi objetivo era presentarle al equipo los puntos de la historia y establecer una reunión periódica para que el equipo dimensionara las historias de usuario en el backlog para que se acostumbraran y, por lo tanto, se volvieran más eficientes (leer más rápido) en el dimensionamiento. Sin embargo, el equipo se ha estancado en términos de la velocidad a la que se dimensionan las historias de los usuarios y, al ritmo actual, estimo que tomaría hasta otro año dimensionar todo el trabajo pendiente.

¿Es este un buen enfoque para dimensionar un backlog completo (que es muy grande) con el equipo del proyecto? ¿Cómo puedo avanzar con esto de una manera que acelere el proceso? Si no es una buena idea, ¿cuál es el mejor enfoque para este proceso?

Respuestas (4)

Por lo general, no es una buena idea verificar con frecuencia todo el trabajo pendiente con todo el equipo. Los últimos 2/3 de la cartera de pedidos cambiarán en el futuro y verificar estos elementos solo hará perder el tiempo al equipo y generará discusiones innecesarias sobre problemas futuros que pueden no implementarse en absoluto.

El enfoque recomendado es que el propietario del producto verifique todo el backlog y lo mantenga en forma, y ​​prepare la mayor cantidad de historias de usuario que el equipo pueda manejar en 2 o 3 sprints. El resto permanece en una especie de estado desconocido o borrador.

El propietario del producto puede convocar una reunión periódica en la que se discuta todo el trabajo pendiente y el equipo proporcione una estimación aproximada de todo el trabajo pendiente. Si el sprint tiene una duración de 2 semanas, esta reunión se convocará una vez cada dos meses. Esta reunión da una visión general de todo el progreso y proporciona. Ejecutar esta reunión es un poco diferente de una reunión de planificación de Sprint, porque es más larga, debido a la cantidad de historias de usuarios y no hay un desglose de tareas. Si surgen impedimentos o problemas, el Propietario del producto los resolverá. Esta reunión a menudo se denomina Reunión de planificación de lanzamiento (puede haber algunos buenos artículos al respecto en el sitio de Scrum Alliance).

Suponiendo que 2/3 de la cartera de pedidos no tiene tamaño, ¿cómo usa los puntos de la historia para pronosticar la finalización del proyecto total? (Para su información... esencialmente, estamos usando SP de la manera que menciona para pronosticar los próximos 2 sprints de trabajo, pero me preguntaba cómo se traduciría esto en un pronóstico completo del proyecto)
No debe usar los puntos de la historia para hacer pronósticos, porque no tienen nada que ver con el tiempo. Por supuesto que lo hacen en el papel, pero en la vida real están más cerca de la complejidad.
Estoy interesado en escuchar más sobre su perspectiva aquí. Inicialmente, mi objetivo era establecer la velocidad promedio (en SP) por sprint del equipo y luego usar esto como una métrica de pronóstico contra el resto del backlog (suponiendo que también se mide en SP). ¿Estás sugiriendo una forma diferente de abordar esto?

Las historias en las que se trabajará en el próximo sprint deben estimarse con mucho más rigor que las historias programadas para muchos meses. Algunas personas llaman a esto planificación de "onda rodante".

Así es como he estimado todo el backlog en el pasado:

  1. El Product Owner identifica las historias y las prioriza.
  2. Antes de que comience un proyecto, el PO y 1 o 2 técnicos dedican 10 segundos por historia a la estimación. Literalmente, solo una conjetura del título de la historia. No es muy preciso, pero lo suficientemente preciso dado que la mayoría de las historias se modificarán de alguna manera antes del desarrollo, y muchas ni siquiera se programarán.
  3. Al comienzo del proyecto, todo el equipo estima las historias candidatas para el primer sprint y, posiblemente, el siguiente (si hay tiempo).
  4. Durante un sprint, tómese un tiempo para que todo el equipo calcule con más detalle el próximo lote de historias candidatas para el siguiente sprint. (Esta reunión tiene un límite de tiempo de 1 hora).
  5. Vuelva a estimar las historias si es necesario durante la planificación del sprint.

Recuerde que Scrum es adaptativo en lugar de predictivo : no debe esperar estimaciones muy precisas para el trabajo que es más de uno o dos sprints en el futuro. El tipo de precisión que obtiene del enfoque anterior aún le permite dibujar gráficos de trabajo pendiente (o trabajo pendiente) de la acumulación de productos para dar una idea de la fecha de lanzamiento.

Un par de preguntas: 1-a menudo, el tamaño del SP es una entrada para la priorización, ¿cómo prioriza la OP si no se dimensiona la acumulación? 2-¿Cómo se realiza la quema de lanzamiento de esta manera si el SP en las historias de usuario cambia con el tiempo? Tal vez no lo esté entendiendo bien, pero asumí que el SP adjunto a una historia de usuario no debería cambiar a menos que haya información significativa que cambie la comprensión fundamental de lo que representa la historia desde una perspectiva de funcionalidad (es decir, - es realmente una historia diferente en este caso).
Hola, 1. El PO prioriza inicialmente por el valor del cliente, pero puede volver a priorizar cuando se realiza una estimación del esfuerzo. 2. El quemado de versiones se actualiza regularmente. Si el SP cambia, también lo hace el gráfico.

Realmente creo que la estimación de puntos de la historia debe limitarse a las tareas que planea incluir en los próximos dos o tres sprints. Intentar más que eso solo hará perder el tiempo a su equipo. Cuanto más lejos en el futuro intente predecir, más incertidumbre habrá. Así son las cosas, ya sea usando Scrum o cualquier otra metodología.

¿Entonces qué hago? Por defecto, las nuevas historias de usuario tienen el valor de punto de esfuerzo promedio de las historias de usuario completadas. De hecho, te sorprendería bastante lo precisas que son las predicciones hechas con este valor, especialmente si eres bueno para dividir tus epopeyas en los fragmentos del tamaño correcto. Solo asegúrese de no caer en el hábito de dejar este valor. Calcule los puntos de esfuerzo con el equipo durante la planificación del sprint (o siempre que lo haga normalmente), pero concentre sus esfuerzos en la parte superior de la cartera de pedidos.

Veo el valor de tomar el valor del punto de esfuerzo promedio de las historias completas para las nuevas. Esto es algo que nunca había pensado antes, ¡gracias! ¿Cómo maneja una gran acumulación de elementos al comienzo del proyecto (o en mi caso, un proyecto que tiene una gran acumulación existente pero no estaba dimensionando las historias de usuario con puntos de historia)? Estas no son nuevas historias de usuarios y, dado que se formularon al comienzo del proyecto, la suposición de que las historias de usuarios se dividen en tamaños más o menos similares puede no ser válida.
Dependiendo de lo que esté utilizando para administrar su trabajo pendiente, las ediciones masivas pueden o no ser posibles. Si lo son, sugeriría seguir usando el valor promedio y simplemente actualizar todo el trabajo pendiente a la vez. ¿Preciso? No realmente... ¿Más preciso que nada? Sí. Solo asegúrese de que su equipo siga revisando el "valor predeterminado" de las próximas historias de usuarios de forma regular.
Aparte, esto no es algo que personalmente quisiera implementar. Preferiría que los puntos de esfuerzo estén en blanco, que contener un valor predeterminado. Ofrecí este consejo basado en su pregunta que parecía implicar que deseaba/necesitaba valores para toda su cartera de pedidos.

La estimación de afinidad podría ser una técnica apropiada para usar aquí. Esencialmente, coloca todos los elementos de su trabajo pendiente en fichas y pide a su equipo que los coloque en una pared en orden de tamaño relativo (por ejemplo, los elementos más grandes a la izquierda y los más pequeños a la derecha). Está creando un continuo de tamaños de puntos de historia. Luego, puede crear líneas divisorias para representar sus diferentes valores de tamaño (1, 2, 3, 5, 8, etc.) y obtener el acuerdo de que los elementos están en una agrupación adecuada.

Esto se describe con más detalle en las siguientes publicaciones de blog:

Dimensionar un backlog completo usando puntos de historia
RespuestasAquíPolítica de privacidad1y, 0v