Noté (en nuestra empresa) que Scrum Masters tiene uno de los enfoques:
Comience con métricas y trabaje para mejorar los números: por ejemplo, surge una nueva historia de usuario durante el sprint, el equipo puede rechazarla porque afecta la velocidad. Entonces, el proceso de toma de decisiones se centra en las métricas y cómo esa acción influirá en las métricas y el rendimiento del equipo.
Comience con valor y concéntrese en aumentar el valor: por ejemplo, aparece una nueva historia de usuario en un sprint, qué tan importante es esa historia de usuario para el producto (o valioso) => la decisión se toma completamente en base a esto. Las métricas afectadas son irrelevantes, siempre que sepa por qué ocurre el delta.
Comience con el proceso y concéntrese en la mejora del proceso: por ejemplo, surge una nueva historia de usuario, colocarla durante el sprint interrumpirá el sprint y probablemente reducirá el rendimiento general, por lo que el equipo decide dejarlo fuera (incluso si la historia aumentaría el producto). value) y hacerlo en el siguiente sprint.
Mis equipos y yo combinamos 2 y 3 (si el valor es alto, lo agregamos al sprint). Pero vi un enfoque en 1 mucho, por ejemplo.
Así que mi pregunta es: ¿en qué te enfocas? ¿Cómo tomas tus decisiones y cuáles crees que son los inconvenientes de elegir solo uno u otro?
Responderé esto de manera más general porque no soy un tipo ágil. Está llegando a un problema sistémico con los conceptos de métricas y es que puede terminar recompensando y promoviendo el comportamiento incorrecto mientras extingue el comportamiento deseado. Nuestra cultura, al menos en los EE. UU., está muy "orientada a los resultados". Cuando tienes esta mentalidad de que solo importan los resultados, lo que intentaste hacer es relevante, entonces terminas con métricas de tipo de resultados y los comportamientos que te llevan allí son los que prevalecerán, y el riesgo podría ser el comportamiento que describiste o incluso peor, como algo ilegal.
En mi opinión, es muy miope crear tus métricas de esta manera. Eso no quiere decir que deban existir algunas métricas de tipo de resultados, pero creo que también debería haber otras métricas que se prueben con el comportamiento.
En mi opinión, el proceso y el valor están vinculados. Entonces, si su enfoque del proceso es de mejora continua, aprendizaje constante, etc., entonces creo que se maximiza el valor del producto que se produce para el cliente. Entonces, para responder a su pregunta, mi enfoque sería una combinación de su 2 y 3, tal vez con más enfoque en 3 primero con la suposición de que sigue el valor.
Esta es una gran pregunta, ya que no es una preocupación poco común.
¿Qué son las métricas? Una forma de medir algo. Por supuesto, deben ser valiosos; si no, deja de coleccionarlos. Si las métricas son la base de las decisiones del equipo, entonces existe una oportunidad de mejora. Esa es una señal de alerta de que las prioridades no están donde deben estar para el negocio y/o el equipo. Recuerde el manifiesto: "El software que funciona es la medida principal del progreso".
¿Qué es un Sprint? Un evento de tiempo limitado para crear enfoque y limitar el riesgo. Si se introducen nuevos trabajos (o incluso se considera su inyección) con especial regularidad, entonces existen preocupaciones. ¿Cómo se enfoca el Equipo de Desarrollo en el pronóstico y la Meta del Sprint del evento de Planificación del Sprint? ¿Cómo afecta eso al riesgo?
¿Qué dice The Scrum Guide sobre la modificación del Sprint Backlog durante el Sprint?
Idealmente, una vez que el Product Backlog se establece en Sprint Planning, los elementos solo deben agregarse o eliminarse si pertenecen al Sprint Goal y no afectan la calidad del Incremento.
Si algo es realmente tan crítico que amerita cambiar el plan, entonces hay factores a considerar.
Dado que cada Sprint tiene menos de un mes de duración, generalmente no hay una gran pérdida de valor por convertirlo en el elemento más alto en el Product Backlog para su inclusión en el próximo Sprint. Tal vez se necesite más refinamiento para que esté Listo, así que asegúrese de tener eso en cuenta al ajustar el Sprint actual.
El Product Owner es el único que puede cancelar un Sprint. El Equipo Scrum debe organizarse a sí mismo, así que tenga una conversación. Comprenda todos los riesgos tanto para los elementos actuales de Sprint como para el nuevo elemento. Las disrupciones afectan al producto ya las personas. (ver "Los procesos ágiles promueven el desarrollo sostenible".)
En términos más generales, con respecto al título de la publicación: la mejora (producto, aprendizaje, procesos) es más importante que las métricas.
Como Scrum Master, mi objetivo es ayudar al equipo a mejorar.
Cada equipo es diferente. A algunos les gusta centrarse en las métricas. Otros son apasionados por el valor comercial.
Mi trabajo es ayudarlos a lograr el éxito con cualquier herramienta o enfoque que elijan. También puedo ofrecerles alternativas cuando corresponda, pero siempre se trata de una decisión del equipo.
Sarov
david espina