En un sprint (#1) decidimos tareas e historias de usuario. Una de las tareas que pensamos en 6 horas resulta ser difícil debido a la complejidad técnica. La complejidad era tal que no podemos estimarla ni en medio del sprint. Todos sabíamos que podemos intentar arreglarlo con el plan A, si no, entonces el plan B, si no, entonces el plan C. Después de cada ejecución del plan, revisamos y diseñamos el plan D, E, F. Eventualmente, la historia del usuario comprometido se extendió al siguiente sprint (#2).
Ahora, bajo la misma historia de usuario, en el sprint n.° 2, en otra tarea, el desarrollador notifica debido a cambios frecuentes en los requisitos, el código NO está en buen estado. Por lo tanto, también debe optimizarse. Entonces, el desarrollador realizó la optimización bajo las mismas tareas, lo que obviamente llevó tiempo y la historia del usuario se derramó en el sprint n.º 3.
En el sprint n.º 3, hubo errores para la misma historia de usuario que se solucionaron a tiempo y el sprint n.º 3 salió bien.
No veo ningún problema de rendimiento O trabajo no realizado correctamente por los desarrolladores. Pero nuestros 2 de 3 sprints muestran 1 historia de usuario derramada dos veces y, por lo tanto, esos sprints son rojos.
Ahora mis preguntas: P. ¿Qué salió mal en la gestión de nuestros sprints? P. ¿Qué medidas deberíamos haber tomado para que nuestros dos primeros sprints fueran ecológicos? P. ¿Cómo manejar la alerta lanzada por el desarrollador sobre la calidad del código?
Una última pregunta genérica, hacer sprint VERDE, ¿es el objetivo único y total del equipo?
Una última pregunta genérica, hacer sprint VERDE, ¿es el objetivo único y total del equipo?
Absolutamente no.
El objetivo principal (no necesariamente el único, dependiendo de a quién le pregunte) del Equipo es proporcionar valor al cliente .
Lo que describe como 'VERDE', terminar todas las historias de usuario de un sprint (supongo, según su pregunta) es un indicador útil para esto, pero no un objetivo de reemplazo válido. Considere la situación en la que escribe un montón de historias agradables y de aspecto encantador. Todos se completan a tiempo con un código maravilloso y de calidad. Y luego se lo muestras al cliente y te preguntan por qué te molestaste con eso, porque todo es inútil .
¿Completaste las historias de tu Sprint? Sí. ¿Proporcionaste valor a tu cliente? No.
P. ¿Qué salió mal en la gestión de nuestros sprints?
Ha proporcionado un contexto insuficiente para responder eso, o incluso para responder si algo salió o no significativamente mal. Pregunta a tu Equipo. Tráelo a colación en la Retrospectiva. Pero tenga en cuenta que debe evitar las preguntas capciosas: "¿Qué creen que hizo que el Sprint saliera mal?" no es una gran pregunta para hacer cuando su equipo no estaba pensando que todo salió mal en primer lugar.
P. ¿Qué medidas deberíamos haber tomado para que nuestros dos primeros sprints fueran ecológicos?
Evalúe las historias más a fondo antes de aceptarlas en el Sprint. Si es necesario, haga picos (piezas de trabajo breves, exploratorias, a menudo desechables) para obtener más información sobre ellas. A veces, sin embargo, las cosas pasan desapercibidas, y no es el fin del mundo.
P. ¿Cómo manejar la alerta lanzada por el desarrollador sobre la calidad del código?
Ha habido otras preguntas sobre este tema, tanto aquí como en Programmer's Stack Exchange. Baste decir que la calidad es importante para el mantenimiento posterior del código, pero el valor no se puede sacrificar por completo para lograrlo. Aquí hay un punto de vista interesante sobre este tema.
Entonces, para resumir, asegúrese de medir y luchar por las cosas correctas. Cumplir con todas sus historias de usuario en cada Sprint es una buena métrica , pero no debería ser su objetivo principal . Eso siempre debe ser para aportar valor a sus clientes.
Su pregunta se centra mucho en esta historia en estos tres sprints, pero no ha hablado sobre el resto de sus procesos o contexto, por ejemplo, cuánto más trabajo hubo en el sprint, qué tan importante fue la historia de fallas repetidas para el cliente, cómo maneja la preparación de trabajos pendientes, etc. Creo que la respuesta a su pregunta se encuentra en ese contexto más amplio, así que ese es el contexto en el que hablaré sobre cómo podría haberlo manejado.
La complejidad y la incertidumbre encontradas en el primer sprint suenan lo suficientemente llenas de incógnitas como para haber fallado en esa tarea fuera del sprint y haberla devuelto a la cartera de pedidos para una mayor preparación y repriorización, en lugar de continuar dedicando tiempo y esfuerzo del sprint a algo que era tan incierto. Dependiendo de qué más se planeó para el sprint, tal vez eso signifique que todo el sprint habría fallado, o tal vez signifique que completaríamos el otro trabajo antes y seguiríamos adelante.
"Sprint green" no es el único valor. "Falla temprano" es otra: porque libera sus recursos para reagruparse y planificar antes de volver a intentarlo.
Dependiendo de su proceso, una vez que la historia vuelve a la lista de pendientes, tal vez obtenga un análisis y una revisión más cuidadosos como parte del proceso de preparación. EG, si no acepta historias en sprints a menos que estén "listas", entonces la experiencia en el primer sprint demostró que pensó que estaba listo, pero en realidad no lo estaba. Durante ese trabajo de prepararlo, es muy probable que también note que el código está en mal estado (como se notó en el sprint 2) porque dio un paso atrás para pensar en ello.
Or, perhaps your process is that you generate an additional story, "Do a spike to figure out a viable approach", which must be completed before the original story is "ready" and thus would be done in a sprint on its own, with the original story done in the subsequent sprint. Or maybe that's a new task on the original story, which obviously increases the scope of the original story, so it can all be done in the same sprint but that reduces the capacity to get other work done in that sprint.
A final caveat: if my customer was telling me "This is the most important story & you must get it done no matter the impact on anything else", then I might have failed the entire sprint immediately, and started a new one that contained only that story, so the whole team could swarm on it.
Savaratkar
Bart van Ingen Schenau