Nuestro equipo de scrum ha proporcionado estimaciones de alto nivel para el proyecto en el que estamos trabajando durante la reunión de planificación de lanzamiento.
El equipo proporcionó horas estimadas, así como puntos de historia para cada una de las historias en la acumulación de lanzamientos. En base a esto, llegamos a una fecha de finalización y se la comunicamos al cliente.
A medida que ingresamos a Sprints, nos encontramos en una situación en la que las historias en la cartera de pedidos debían descomponerse en varias historias y, como resultado, nuestra fecha de finalización se retrasó y le comunicamos lo mismo al cliente y él estaba de acuerdo con eso. .
También teníamos sesiones periódicas de preparación de la cartera de productos. Pero, cuando entramos en la reunión de planificación de Sprint, la estimación del equipo sobre las historias de usuario cambia nuevamente y nuevamente como resultado de eso, las historias se descomponen y el tamaño de las historias también aumenta; con esto, la fecha de finalización de la acumulación de lanzamiento también teniendo un efecto. Y esto sucedió más de un par de veces para nuestra acumulación de lanzamientos.
¿Dónde nos estamos equivocando? ¿Cómo podríamos rectificar la situación para que el equipo pueda terminar lo que se comprometió con el cliente durante la planificación del lanzamiento O al menos acercarse a lo que se prometió?
Gracias
Tan pronto como dijo "El equipo proporcionó horas estimadas", reconocí un problema aquí. Cuando realiza una gestión de lanzamiento de alto nivel, debe darse cuenta de que incluso aplicar puntos de historia a las épicas es una tarea realmente inexacta y solo se puede usar a grandes rasgos. Tratar de estimar realmente las horas está condenado al fracaso.
Como han dicho otros, sí, parece que su equipo no fue muy bueno en la estimación y que cambiaron las estimaciones muchas veces. Sin embargo, como gerente de producto, creo que una de las mejores cosas de Agile es que trata de aliviar los puntos débiles que surgen al tratar de planificar con mucha anticipación.
Realicé reuniones de planificación de lanzamiento con mi equipo, tanto en el nivel alto de dividir el gran proyecto en épicas y estimarlas (20, 40, 60, 80, 100 eran las opciones), como en el nivel más bajo en los pocos meses consecutivos. hasta el lanzamiento del uso de puntos de historia y velocidad del equipo. Agile nos enseña que nunca sabrá todo lo que se debe hacer para un lanzamiento hasta que esté cerca de ello: esa es la naturaleza del software y trabajar con humanos. Se perderán algunas complejidades, puede encontrar un mes antes del lanzamiento que la función que pensó que estaba perfectamente diseñada realmente necesita algunos criterios adicionales, etc. en qué trimestre espera lanzar,
Esto podría deberse a varias cosas:
Según la descripción que ha proporcionado, sospecho que esperaba demasiado en términos de precisión de una estimación de alto nivel. La única solución a esto es volver al equipo y pedirles que vuelvan a estimar el trabajo restante, brindándole una estimación del caso más probable y del caso más desfavorable. Preséntelos a su cliente y, si son buenos, presione el botón Restablecer proyecto y continúe.
La planificación de versiones es un objetivo de gestión estimado , generalmente basado en estimaciones del nivel de esfuerzo de grandes temas o épicas. Sprint Planning es un compromiso de equipo basado en historias de usuario del tamaño de una iteración. Cumplen diferentes funciones, pero la clave es recordar que las estimaciones no son garantías.
Los cambios de horario no implican necesariamente que sus estimaciones sean intrínsecamente incorrectas. Su objetivo debe ser mejorar la precisión de sus estimaciones, no cumplir objetivos de programación arbitrarios. Sin embargo, mejorar la precisión de sus estimaciones debería reducir las variaciones en su programación basada en estimaciones a niveles aceptables.
La planificación de lanzamiento se trata principalmente de definir hitos y fechas de envío previstas. El cono de incertidumbre siempre es mayor al comienzo de un nuevo proyecto y, por lo tanto, la precisión del plan de lanzamiento inicial debe ser un rango con un intervalo de confianza definido.
Debido a que Scrum es un proceso de desarrollo iterativo, la planificación de lanzamiento debe revisarse en cada iteración. En función de lo que se conoce actualmente al comienzo de cada iteración, la cartera de productos se puede modificar para reducir el alcance o cambiar las prioridades para alcanzar fechas de lanzamiento fijas, o las fechas de lanzamiento se pueden mover para reflejar con mayor precisión el progreso real del equipo hacia lo planificado. liberación.
Hay una serie de ideas centrales detrás del desarrollo ágil, pero uno de los conceptos centrales es la idea de iteraciones que producen "incrementos potencialmente liberables". En otras palabras, si bien es posible que un sprint dado no contenga el conjunto completo de funciones planificadas para un objetivo de lanzamiento determinado, cada sprint debe producir una función funcional, funcional e (idealmente) visible para el usuario que podría lanzarse.
Dicho de otra manera, cada sprint debería dar como resultado un producto que haya generado una cierta cantidad de valor ganado. Si bien es posible que el producto no tenga todas las funciones, es funcional y potencialmente se puede enviar al final de cada sprint. Esto brinda a las partes interesadas la capacidad de convertir el valor ganado en valor de mercado al final de cada iteración, aunque ciertamente no están obligados a hacerlo.
La clave para las implementaciones exitosas de Scrum es reestimar continuamente. Esta reestimación obviamente incluye épicas, temas e historias de usuarios, pero también incluye la reestimación de los cronogramas del proyecto y el alcance de los hitos objetivo.
Se esperan desviaciones de las estimaciones iniciales, y son manejadas por el proceso de inspección y adaptación integrado en Scrum. Sin embargo, si encuentra que sus estimaciones no se vuelven más precisas con el tiempo, entonces necesita:
"Abrazar el cambio" no es competencia exclusiva del equipo de desarrollo en Scrum. También es responsabilidad del propietario del producto y las partes interesadas adoptar todos los cambios necesarios en el alcance, el cronograma, los recursos, las fuerzas del mercado y otras realidades que se necesitan para garantizar que el proyecto tenga éxito o fracase antes de tiempo.
Apegarse a un plan hecho hace meses o años, sin hacer un balance de dónde está ahora el proyecto , es una de las formas más comunes en que los proyectos fallan. La agilidad no garantiza el éxito; solo espera que la visibilidad y la transparencia del proyecto permitan a las partes interesadas tomar decisiones bien informadas.
En Scrum, enseñamos a los equipos a no asumir "Riesgos" donde no les corresponde hacerlo. Su equipo hizo su mejor estimación al principio y, a medida que pasa el tiempo, usted y el cliente se dan cuenta de que la capacidad de estimación del equipo es muy mala.
La primera pregunta que le voy a hacer al OP es, ¿qué mitigación de riesgo tenía él/ella en caso de que un equipo probablemente estimara incorrectamente? Creo que está muy bien aceptado que los equipos técnicos son malos en la estimación, independientemente del método.
El siguiente es si ha estado rastreando la tasa de trabajo (velocidad) de los equipos en comparación con la estimación original. Independientemente de la técnica que utilice, la velocidad es, en última instancia, una relación que se aplica a las estimaciones originales. Por ejemplo, la tendencia indica que el equipo tarda un 72 % más de lo estimado. Por lo tanto, aplicar una velocidad a la estimación original debería darle una indicación de la fecha objetivo "real".
Scrum no dicta oficialmente cómo deben estimar los equipos y cómo se debe realizar la planificación de lanzamiento. Sin embargo, hay varios patrones probados que funcionan.
Principios básicos
Prepare su cartera de productos a un nivel en el que el equipo tenga una intuición de lo que se debe hacer. Esto debe hacerse muy rápidamente y sin un análisis completo.
Luego, el equipo debe estimar todos los PBI con una escala relativa utilizando puntos de la historia o tallas de camisetas (la mediana puede ser el doble de grande que la pequeña). Teóricamente, un PBI que es un 2 debería requerir aproximadamente el doble de esfuerzo/tiempo que un 1.
Cuando se crean nuevos elementos, el equipo también debe estimarlos. El equipo aún debe estimar en comparación con la escala original y no tener en cuenta su rendimiento y herramientas mejorados; hacer esto da como resultado una relación aplicada a la velocidad que le dará resultados débiles.
Cree tareas en la planificación de sprints para ayudar al equipo a concentrarse en cómo entregar el PBI. Si realmente desea estimar tareas, puede hacerlo, pero a menudo encuentro que esto no agrega mucho valor.
Simplemente haga un seguimiento de cuánto trabajo ha entregado el equipo en un sprint, es decir, el equipo logró completar 42 puntos de historia en el sprint. Esta es su velocidad.
Por lo tanto, si tiene 450 puntos restantes en su cartera de productos, le llevará once sprints completarlos (450/42 = 11, redondeado hacia arriba).
Educar a la gerencia y PO que el equipo da un tiempo ESTIMADO y NO REAL
Como Scrum Master, su desafío es ayudar al equipo primero a estabilizar su velocidad y luego a mejorarla reduciendo el desperdicio.
Me parece que estás haciendo un scrum en cascada y ahí es donde te encuentras con problemas. Su "fecha de finalización" debe ser el final de su sprint. No se debe comprometer nada más allá de eso. Parece que estás tomando un conjunto gigante de historias a través de múltiples sprints y comprometiéndote con fechas muy lejanas para completarlas todas. Eso es cascada y sin una planificación y un diseño iniciales de estilo cascada, verá exactamente el problema con el que se está metiendo.
En el mundo perfecto de scrum, el tiempo es fijo, las historias son ajustables. Esa "fecha de finalización" no debería cambiar, solo la cantidad de historias comprometidas y solo durante la planificación del sprint. Si está en medio de un sprint y resulta que sus estimaciones no fueron las correctas, llame al propietario del producto y negocie la acumulación de sprint en función de la nueva comprensión. Eso podría significar volver a colocar las cosas en la cartera de productos, intercambiar historias o, en circunstancias extremas, abortar el sprint y comenzar de nuevo. Si está siguiendo Scrum, un aborto completo de un sprint solo debería retrasarlo una semana o dos. No está mal en comparación con la cascada, donde problemas similares pueden retrasarlo meses.
Una de las premisas básicas de las metodologías ágiles es darnos cuenta de que somos malos estimando y que cuanto más lejos se está de la estimación, más incorrecta suele ser. Ese es un punto importante detrás de hacer sprints cortos (de 2 a 3 semanas). Tan pronto como comience a dar estimaciones comprometidas que están a meses de distancia, volverá a la cascada y necesitará planificar y diseñar como una cascada.
Brett Maytom PST
Todd A. Jacobs