Una vez que hemos arreglado el backlog y tenemos una dirección relativamente clara de lo que se debe hacer a corto y largo plazo, ¿cómo decidimos qué incluir en cada Sprint? ¿Quién toma esa decisión?
Parece que las metodologías ágiles permiten que el equipo decida, pero ¿qué sucede si el equipo juega demasiado seguro y no se compromete ?
La holgura es esencial, pero un exceso de ociosidad derrochadora no lo es. El verdadero liderazgo es ser capaz de notar la diferencia.
El propietario del producto prioriza la cartera de productos, pero solo el equipo de desarrollo puede estimar historias. El equipo usa estas estimaciones, junto con su velocidad estimada, para determinar cuánto trabajo debe aceptarse en cada Sprint.
Esto solo parece un problema si se toma una visión limitada. El proyecto tiene hitos, fechas de publicación y otros objetivos que se pueden comparar con el progreso actual a intervalos periódicos. Si el equipo no está encaminado para cumplir con los objetivos de gestión necesarios, este es un buen material para los diálogos organizacionales y las retrospectivas del equipo.
Tenga en cuenta, sin embargo, que simplemente decir que el equipo no se está comprometiendo lo suficiente no es lo mismo que tener un equipo que tiene grandes cubos de capacidad disponible sin usar. El objetivo con Scrum es el desarrollo sostenible, lo que requiere cierta cantidad de holgura en el proceso. Depende del equipo y la organización llegar a un entendimiento de cuánta holgura es necesaria y cuánto es "desperdicio" (por ejemplo , muri , muda o mura ) en el sentido Lean de la palabra.
Recuerde, el 100 % de utilización no es el objetivo. Si el equipo ya está trabajando a su ritmo sostenible óptimo, es posible que deba examinar las expectativas, los procesos, los recursos o el alcance de su proyecto para encontrar otras formas de abordar las limitaciones de su sistema.
Parece evidente que tienes un problema de confianza con tu equipo.
No puede decir que un equipo no se compromete a menos que no esté de acuerdo con su planificación de capacidad. ¿Estimas la capacidad de sprint? Si cree que sus equipos pueden entregar más puntos, ciertamente puede argumentar eso en la reunión de planificación, sin embargo, no puede esperar que la opinión de una persona se considere la estimación "correcta". Es un esfuerzo de equipo.
Eres parte del equipo y tienes algo que decir.
Si cree que el equipo está trabajando de manera ineficiente, perezosa o simplemente tiene ideas concretas sobre cómo el equipo puede mejorar su velocidad, el lugar correcto para hacer estas sugerencias es una retrospectiva de sprint y ciertamente no una reunión de planificación. Me aseguraría de que se produzcan retros (si es que no lo han hecho ya) y de que allí se manejen tus dudas sobre la eficiencia del equipo.
La clave para no tener este tipo de problema está en determinar correctamente las estimaciones. Una forma de tener estimaciones razonables es tomar estimaciones de cada experto en el campo y razonar por qué él o ella piensa así. A partir de entonces, tomando todos los puntos en consideración, estime un marco de tiempo en consenso. Por ejemplo, si hay tres miembros para encargarse de los servicios web, los tres deben explicar las razones para estimar la misma tarea. Teniendo en cuenta las opiniones de cada miembro, a la tarea se le asigna un marco de tiempo objetivo por unanimidad.
El equipo decide. El propietario del producto no puede decidir esto. El propietario del producto solo prioriza. ¿Cómo decide el equipo? Primera vez solo una suposición/sentido común. Historial de segunda vez (sprint) (20 %) + suposición (80 %). Historial por tercera vez (40 %) conjetura (60 %). Y llega un momento en que decide la historia (90%) y el sentido común (10%). Esto es lo mejor que podrías conseguir.
Sugerencia: en la reunión de planificación del sprint, mantenga lista 1 historia de usuario adicional; de lo contrario, es posible que se necesite otra reunión del equipo para incluir una nueva en el sprint (si el equipo termina más rápido).
En mi opinión, los siguientes factores deciden las historias que se incluirán en cada sprint.
De hecho, es la decisión combinada de PO y el equipo de desarrollo la que decide las historias que se incluirán en cada sprint.
Brett Maytom PST