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

10

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.

Eugene
fuente
1
Una pregunta que a menudo me he preguntado y dos buenas respuestas
Matt freake
1
Si siempre cumple con su compromiso, probablemente no sea lo suficientemente agresivo. Con suerte, su precisión mejorará con el tiempo, ya que parte del objetivo de Scrum es mejorar las habilidades de todos para estimar cuánto tiempo llevará una tarea determinada en el mundo real.
keshlam
1
@keshlam eso no es necesariamente del todo cierto. Hay toda una escuela de pensamiento en el movimiento ágil que está tratando activamente de superar las estimaciones tradicionales, reconociendo su naturaleza venenosa potencial.
Stefan Billiet
1
De acuerdo, @StefanBilliet ... pero Scrum tiene la intención de desestresar simultáneamente las estimaciones en lo que respecta al mundo exterior a la vez que mejora la sensación interna de un equipo de cuánto trabajo adicional probablemente puedan realizar cuando.
keshlam

Respuestas:

21

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.

Stefan Billiet
fuente
Entonces, ¿debemos esforzarnos por cumplir con el compromiso en el 99.99% de los casos? Si ese es el nivel de garantía necesaria de que se cumplirá el compromiso, solo nos comprometeremos a la mitad del trabajo promedio que generalmente podemos producir. Entonces supongo que no es 99.99%. ¿Así que qué es lo? 50-70%? 80-90%?
Eugene
@Eugene ¿Por qué necesita un número y quién debe estar seguro? Estoy empezando a tener la idea de que hay alguien en tu organización que te castigaría si no cumplieras tus objetivos de sprint ...
Stefan Billiet
De ningún modo. De hecho, en mi organización a nadie le importa si se cumplió o no un compromiso. Estoy tratando de cambiar eso, porque actualmente no soluciono errores y escribo pruebas porque no hay tiempo para ellas. Me gustaría aconsejar a los equipos que se comprometan a menos para que puedan cumplir con sus compromisos de forma regular. Pero cuanto menos? Si cumplir con el compromiso es una cuestión de vida o muerte, entonces definitivamente se comprometerá a menos que si fuera solo un pronóstico en el que nadie externo confía.
Eugene
2
Por lo que parece, tienes algunos problemas más fundamentales. Debe tener una comprensión del equipo de 'hecho' antes de poder medir el rendimiento en la cantidad de historias que se han convertido en 'hecho'
Michael Shaw
13

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.

Michael Shaw
fuente
4

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.

talboomerik
fuente
2

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.

Bryan Oakley
fuente
De acuerdo. Estaba en un equipo donde al final de cada planificación de sprint, el gerente exigió un compromiso para completar todas las historias para el sprint. Caí en la costumbre de decir "sí" y seguí siendo ágil. Supuse que probablemente lo haría sentir mejor así.
Rob
1
@RobY: Creo que hay espacio para el compromiso en equipos maduros. En mi experiencia, la mayoría de los equipos ágiles no son particularmente maduros, y cualquier OP que solicite un compromiso no es una buena OP. Estaba en un equipo que era bastante sólido con su velocidad y nos sentimos bastante cómodos haciendo compromisos reales cuando era necesario, pero los otros equipos en los que he estado no han sido tan maduros.
Bryan Oakley
Estaba siendo un poco loco. Estoy de acuerdo, generalmente hay un conjunto central de historias con las que puedes comprometerte, pero a medida que te acercas a la velocidad, es un poco menos seguro. Dado que la velocidad es un promedio, entonces, por definición, a veces estarás arriba y a veces abajo. Por cierto, ese mismo gerente nos cargaría con 2x o 3x nuestra velocidad cada vez y luego exigiría un compromiso ... entonces ...;) (Estaba reaccionando principalmente a su primer párrafo, que creo que lo dice muy bien)
Rob
2

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".

Trineo
fuente
Realmente no estoy de acuerdo con esta respuesta. La naturaleza humana es intentar entregar, y puedes apostar tu último dólar a que los equipos reducirán las 'pruebas' para entregar, en lugar de dejar caer la historia. Si siempre está tan cerca de la línea, no realizará las pruebas lo suficientemente exhaustivas y volverá a morder.
Michael Shaw
@Ptolomeo que es donde se requiere disciplina, orgullo profesional y una sólida " definición de hecho ". Eso debería evitar que envíes una mierda. Además, no debería contar algo como hecho si ha cortado esquinas.
Trineo
Eso es mucho más claro en la parte de desarrollador que en la parte de prueba de scrum. No puede tener defectos conocidos porque el probador se centró en probar la funcionalidad principal y no tuvo tiempo para 'un evento aleatorio' que sucedió para exponer el error.
Michael Shaw
2
@Ptolomeo: los equipos técnicamente no pueden "cortar las pruebas" ya que las pruebas son parte de la historia. Si lo cortan, no es diferente a cortar parte de la codificación. Si omite parte de la función codificada, ¿está completando una historia? Del mismo modo, si cortas las pruebas, no estás completando la historia.
Bryan Oakley
Nunca he usado scrum, pero he hecho compromisos y he juzgado si las cosas están hechas. Sería bueno si la definición de hecho es totalmente objetiva, es decir, no hay espacio para que el grupo interprete la definición a la luz de si debe hacerse para cumplir con el compromiso. El lenguaje natural es lo que es, esto parece poco realista. Si está bastante relajado sobre el compromiso y bastante cerca de una definición objetiva, esto no sería un problema. Cuando Ptolomeo dice "la naturaleza humana es tratar de cumplir", en mi esquema eso significa que "la gente no está lo suficientemente relajada sobre el compromiso".
Steve Jessop