Planificación de Sprint impulsada por la capacidad

Recientemente asumí el cargo de Scrum Master de un equipo.

Planeo implementar la planificación de sprints impulsada por la capacidad.

El desafío es que tenemos varias Historias de usuarios (que deberían haberse clasificado como Tareas IMO) que se han trasladado a múltiples sprints.

Digamos que tengo 3 "Historias de usuario" que se han extendido en al menos 3 sprints continuos debido a su naturaleza monolítica, la vaguedad de los requisitos y la inevitable expansión del trabajo.

¿Mi primera tarea sería reunir al PO y al equipo para dividir este tipo de historias de usuarios durante la preparación?

Parecería que el primer paso para implementar la planificación de sprint impulsada por la capacidad sería preparar la acumulación de elementos que se ajusten al ideal INVEST, de modo que podamos encajar adecuadamente los elementos en la capacidad.

¿Estoy en el camino correcto?

¿Por qué crees que estas historias "monolíticas" deberían haber sido clasificadas como tareas? Las tareas son siempre más pequeñas que las historias.
@Llewellyn, simplemente por definición. Los elementos no proporcionan valor directo al usuario, es decir, como DevOps, me gustaría agregar otro servidor para ayudar con el equilibrio de carga, siempre he clasificado como Tareas con subtareas si es necesario.
@MarkSaluta "Como DevOps" ni siquiera es una historia. DevOps quiere que le paguen. Esa es su historia. Pueden vivir una vida súper feliz sin equilibrar la carga. No escriba historias de "Como un caballo quiero tirar del carro al mercado". El caballo no quiere eso. En su lugar, comience a escribir historias de "Como comerciante".
@nvoigt Diría usted entonces: Como usuario, me gustaría que la pantalla del producto se cargara un 50% más rápido, para poder pagar más rápido. Una subtarea de eso podría ser agregar otro servidor para ayudar con el equilibrio de carga. Ese sonido sobre la derecha?
Claro, eso suena bien.
@MarkSaluta Solo asegúrese de que el equipo de desarrollo sea el que corte la historia y que el corte esté bien explicado al PO, de manera que puedan proporcionar una visibilidad acordada de las tareas realizadas al final del sprint.

Respuestas (3)

Creo que está en el camino correcto al desglosar los elementos de trabajo. Esto es lo que puedes hacer

Opción 1: si las historias de usuario se basan en "necesidades comerciales", no las divida más. Pero cree tareas significativas a partir de las aportaciones del equipo. Según la disponibilidad de cada miembro del equipo, cree tareas que se puedan lograr en 1 sprint. Asegúrese de que la "Definición de Listo" para las tareas y la historia del usuario se defina en las reuniones de preparación de acuerdo con el propietario del producto.

Opción 2: Crear "Características" basadas en "intención comercial". Cree historias de subusuarios basadas en la "capacidad" del equipo. Cada equipo de sprint puede dimensionar las historias de usuario. Asegúrese de que durante la preparación, el equipo defina los criterios para "medir el progreso" de la historia del usuario. Por ejemplo, si el equipo decide el tamaño de la historia de usuario = 10 puntos. El equipo está de acuerdo en que todos los días pueden hacer un progreso de 0,5 puntos, luego puede seguir fácilmente el progreso del trabajo diariamente.

Espero que esto ayude.

Tu enfoque es bueno.

¿Mi primera tarea sería reunir al PO y al equipo para dividir este tipo de historias de usuarios durante la preparación?

Valdría la pena pasar un tiempo entrenando al equipo para entender por qué sus historias necesitan mejorar.

Además, como Scrum Master trato de evitar decir cosas como:

"Planeo implementar la planificación de sprints impulsada por la capacidad".

"... mi primera tarea sería reunir al PO y al equipo".

En su lugar diría:

"Recomendaré al equipo que pruebe la planificación de sprints basada en la capacidad"

"...mi primera tarea sería recomendar al equipo que se reúnan y explicarles por qué sería útil".

El tono que usa un Scrum Master cuando se dirige al equipo es importante. Es un papel de líder de servicio en lugar de un papel de gestión .

Gracias por eso. Es un gran recordatorio y algo a tener en cuenta todos los días.

Si se extendieron porque los requisitos eran demasiado vagos y el trabajo se expandió, entonces diría que el equipo no fue lo suficientemente diligente para refinar los criterios de aceptación.

Diría que los saque del sprint y cambie su estado a "aprobado" desde donde sea que esté ahora (comprometido o listo o lo que sea). En ese momento, haga que el equipo de entrega y las partes interesadas trabajen juntos para ver qué se puede eliminar para entregar algo en un sprint y definir los criterios de aceptación. Tal vez una historia aún va más allá de un sprint, pero intente establecer criterios de aceptación entre todas las personas involucradas para que:

  • Los desarrolladores saben qué hacer y pueden transmitir el progreso fácilmente a través de tareas extraídas de AC
  • Los probadores saben qué probar cuando les llega. Es posible que pueda implementar en un entorno de prueba y decir "oye, ¿puedes echar un vistazo? Creo que he terminado los criterios 1, 2 y 3". Ayudará al desarrollo y al control de calidad a trabajar juntos y brindará transparencia al progreso del equipo.

Tenga cuidado con simplemente "rebanar". Siempre que sea posible, asegúrese de que una historia brinde valor comercial y no sea solo parte de algo más grande que tenga valor comercial (para ser entregado quién sabe cuándo)

Planificación de Sprint impulsada por la capacidad
RespuestasAquíPolítica de privacidad1y, 0v