Planificación de lanzamiento ágil

Digamos que la velocidad de mi equipo es 50 y para el próximo lanzamiento, necesitamos completar 500 puntos de historia de usuario. La duración de mi sprint es de 2 semanas. Entonces, si dividí 500 por 50, necesito gastar 10 sprints para completar el trabajo (alcance completo).

Pero las partes interesadas solicitan completar el mismo alcance (500 de historia de usuario) antes de esa línea de tiempo.

¿Qué tipo de pasos se pueden tomar para superar esta situación?

¿Por qué las partes interesadas quieren que el mismo alcance se entregue más rápido? (Aparte de que son tacaños impacientes, eso es)
Se está realizando un evento de marketing planificado antes de que completemos el lanzamiento, por lo que las partes interesadas deben completar el lanzamiento antes de ese evento.

Respuestas (2)

Hay una suposición horneada en la que debe hacer los 500 puntos de alcance para satisfacer las necesidades del usuario. En Scrum, lo primero que haríamos es desafiar esta suposición. Al centrarnos en satisfacer las necesidades en lugar de hacer el trabajo, a menudo podemos encontrar soluciones más simples o identificar cosas que realmente no se necesitan.

Ahora, hay otras dos preguntas aquí:

  • ¿Cómo puede un equipo ser más rápido?
  • ¿Cómo voy más rápido de lo que puede ir un equipo?

Para ayudar al equipo a ir más rápido, el equipo debería tener una retrospectiva y buscar mejoras en cada sprint. Sin embargo, cualquier forma de trabajar alcanza un nivel máximo de eficiencia y hay que cambiar los enfoques de trabajo para sacar más velocidad al equipo. Esto es genial, pero también es peligroso. Cualquier cambio en la forma de trabajar ralentizará al equipo mientras se adapta y es posible que no lo haga bien la primera (o la segunda). Esto debe hacerse en un momento en que los equipos puedan absorber una desaceleración para mejorar la velocidad más adelante.

También podemos añadir equipos. Agregar personas a un proyecto es complejo. Uno pensaría que si un equipo estuviera completando 50 puntos, dos completarían 100, pero no lo harán. Tienen los gastos generales de trabajar juntos, sin mencionar que hay un tiempo de aceleración y ralentizarán al otro equipo durante ese período. Una vez más, esto tiene que hacerse con cuidado.

Agregando a la respuesta de Daniel:

Es peligroso asumir que no agregará historias durante un período de 10 sprints.

Esto podría suceder por varias razones:

  • Los comentarios recibidos en sus revisiones de sprint pueden convertirse en reelaboración o trabajo nuevo
  • Es posible que los problemas técnicos solo se vuelvan evidentes cuando comience a trabajar en las historias.

También vale la pena señalar que la velocidad puede disminuir o aumentar. La enfermedad es solo una de las muchas causas potenciales de esto.

Comprometerse a entregar todo antes de la fecha límite podría convertirse fácilmente en una marcha de la muerte .