¿Con qué frecuencia debe un equipo Scrum cumplir con su compromiso Sprint? [cerrado]

El compromiso es una promesa, y a todos nos han enseñado que debe cumplir sus promesas. ¿Pero es realista mantener el compromiso de cada Sprint? A veces las personas se enferman, a veces se demuestra que el enfoque técnico es incorrecto y hay que repensar todo, a veces, durante las discusiones posteriores con el propietario del producto o los usuarios, comprende que la función debe ser muy diferente de lo que se pensó originalmente.

Sé que la Guía oficial de Scrum ahora usa la palabra "pronóstico" en lugar de compromiso, probablemente para abordar estos problemas.

Entonces, mi pregunta es con qué frecuencia los equipos de sus organizaciones mantienen su compromiso y si le gusta este enfoque o si desea cambiarlo.

Gracias.

No se trata tanto de con qué frecuencia un equipo debe "cumplir sus promesas".
Se trata más bien de investigar por qué un equipo tendría problemas para cumplir sus compromisos.

Si es una intervención piadosa, eso realmente no importa. Pero si descubre que con frecuencia necesita volver al tablero de dibujo, porque su enfoque técnico es completamente incorrecto, o que el PO sigue cambiando de opinión, o que las historias no son lo suficientemente claras al comienzo de un sprint, entonces usted Necesito investigar por qué.

No cumplir con un compromiso de sprint es un síntoma; debes estar interesado en la causa raíz.

Si todo está bien, entonces será normal que los equipos cumplan con sus compromisos de scrum. Deben estar funcionando lo suficientemente frío como para hacer frente a interrupciones a pequeña escala, razonables y probables, como una enfermedad de un día, emergencias de cuidado infantil, etc. Si no puede, entonces, en mi opinión, los sprints se han comprometido demasiado y se están ejecutando demasiado calientes para su bien a largo plazo como equipo.

Si los sprints no se entregan constantemente, entonces Scrum ha cumplido su promesa de hacer visibles los "problemas". Los problemas pueden incluir no tener tareas definidas adecuadamente, experiencia insuficiente en el equipo o una cultura de gestión de intentar continuamente entregar en exceso, y por lo tanto constantemente quedarse corto.

De cualquier manera, la solución es identificar la causa raíz y solucionarlo, en lugar de azotar más a los desarrolladores.

Los equipos que siempre están "cerca" de cumplir sus compromisos están fallando de una manera más seria. Puede estar seguro de que no están realizando suficientes pruebas.

Personalmente, creo que si a nadie en la organización le importa cumplir su compromiso, no está hablando de un compromiso. Necesita dos socios para hacer un trato y formar un compromiso.

Un compromiso de sprint es algo que debería poder mantener, teniendo en cuenta todas las "variaciones normales". Puede leer mi publicación de blog sobre conceptos básicos de planificación ágil si desea saber más sobre lo que quiero decir con variaciones básicas. Y como dijo Stefan , no cumplir con su compromiso es un síntoma, no la enfermedad.

Después de cada sprint, tiene un momento para inspeccionar la velocidad real de ese sprint y adaptar su "velocidad promedio" a eso (como se explica en la publicación mencionada anteriormente ). Si su velocidad sigue bajando, corra tras sprint, comenzará a ver patrones que pueden ayudarlo a detectar la causa real de esto. Esto podría ser demasiado trabajo no planificado (por ejemplo, pequeñas tareas urgentes, errores en el código en el que está trabajando, cambios en los criterios de aceptación durante el sprint, ...). Todos estos datos deben ser rastreados, probablemente por el maestro scrum para ayudarla a descubrir qué patrones hay allí. Eso ayudará al equipo a idear acciones durante la retrospectiva.

Mi perspectiva es que los equipos no se comprometen. Podría decirse que ni siquiera están haciendo un pronóstico. El pronóstico se realiza antes de que se planifique el sprint; el pronóstico es que, en promedio, alcanzarán su velocidad. Eso significa que a veces harán algunos puntos más que su velocidad, a veces harán un poco menos.

Si está haciendo menos de su velocidad de forma regular, su velocidad disminuye para reflejar eso. El pronóstico por lo tanto cae también. Si sigues sacando más historias de las que tu velocidad histórica dice que puedes hacer sprint tras sprint, no es un fallo en la ejecución, es un fallo en la planificación. Conoces tu velocidad, así que no deberías traer más puntos de los que la historia dice que puedes lograr.

Para responder a su pregunta específica, de las tres organizaciones en las que he usado scrum, solo una rastreó las métricas de "omitir el compromiso" con el tiempo. Para esa compañía, los equipos generalmente alcanzan su pronóstico alrededor del 85% del tiempo.

Si no cumple con su compromiso, entonces debe reducir su velocidad. Si siempre lo cumple, debe aumentar hasta que falle a veces.

El problema es ¿qué tan mal fallas? Siempre debe estar cerca. O lo haces con un poco de holgura o fallas solo un poco. Esa es una meta saludable para cualquier disciplina, tiempos de carrera, levantamiento de pesas, etc. Idealmente, la cantidad promedio de trabajo realizado en un sprint debe ser una distribución normal alrededor de su velocidad.

Lo que es más importante es la tendencia a largo plazo en su velocidad. Si cada semana agrega 15 puntos de historia a su velocidad pero solo logra 10 más que la semana anterior, ¿es realmente algo malo? En algunos lugares consideran estos "objetivos de estiramiento".