Como Scrum Master, ¿cómo manejar las expectativas de gestión sobre la entrega de puntos de la historia?

Problema: me nombraron Scrum Master para un nuevo equipo y la expectativa de la alta gerencia (CTO) es que nuestro equipo debe entregar más de la capacidad de SP que actualmente podemos entregar de manera realista .

Esta expectativa de SP se basa en estimaciones anteriores (hace más de un año). Mucho ha cambiado desde entonces. La aplicación se ha vuelto más compleja desde entonces, hay nuevos desarrolladores y algunos desarrolladores se fueron.

La alta gerencia ahora trajo a un nuevo desarrollador y esperan que eso ayude a la velocidad, pero les dije que la velocidad disminuirá y solo después de un tiempo aumentará. También deben considerar el estrés de los evaluadores.

¿Cómo abordar tal situación con la alta dirección?


Más antecedentes sobre mí y lo que he probado:

  • Fui Scrum Master durante un año en otro proyecto
  • Trabajé con el equipo para desglosar historias más grandes porque cuando trasladaban una tarea de un sprint a otro, siempre era grande.
  • Fue con una velocidad más baja que se basa en la última velocidad y sprints.
  • Elimine los impedimentos y actúe como el maestro de scrum (el equipo pensó que pueden hacerlo ellos mismos) en áreas como la planificación, stand up's, etc.
  • Promover la programación en pareja (No se menciona en scrum pero ayudó mucho al equipo)
  • Hice retrospectivas adecuadas (como lo menciona Esther Derby)
Hola Ruan, reestructuré la pregunta para que sea más amigable para la comunidad. Siéntete libre de expandir algo que creas que se pasó por alto (o de revertirlo por completo si me falta el punto que querías plantear).

Respuestas (3)

Estás haciendo lo correcto y actuando como debería hacerlo un Scrum Master.

Parece que es posible que necesite hacer algo de entrenamiento, explicando al equipo, a la gerencia y a las partes interesadas cómo funciona Scrum.

Intente respaldar todo lo que pueda con evidencia, como citas de The Scrum Guide , de artículos y publicaciones de blog en sitios web de confianza.

También sería bueno obtener el apoyo de otros defensores ágiles en su organización. Parece que se necesita una cantidad considerable de educación.

Educar a su equipo Scrum es particularmente importante, ya que también deberían rechazar el comportamiento anti-Scrum del resto de la organización.

No estoy seguro de si ayudaría, pero una analogía que uso a menudo es comparar la velocidad con tu tiempo en una carrera de 5 km. (crédito donde se debe, adopté la analogía de Mike Cohn) Es solo observable. Si piensas, "Simplemente correré más fuerte", simplemente te quemarás al principio de la carrera y probablemente obtendrás un tiempo más lento. En su lugar, puedes tomar medidas que creas que mejorarán tu tiempo (diferente respiración, mejor dieta, diferentes estiramientos, etc.) y luego observar cómo afecta tu tiempo después de la próxima carrera.

La velocidad funciona exactamente igual. Si solo trato de aumentar mi velocidad a través de la fuerza de voluntad, voy a disminuirla sin darme cuenta o (porque es más fácil jugar que el tiempo) podría crear la ilusión de un aumento. En su lugar, necesito tomar medidas como mejorar la colaboración, eliminar la deuda técnica, realizar pruebas automatizadas, etc. y luego observar cómo afectan mi velocidad en los siguientes sprints.

Estoy de acuerdo con Barbaby Golden, y me gustaría agregar lo que ayudó cuando quería mostrar el impacto de cambiar los equipos con frecuencia:

  • Muestre a la gerencia la velocidad que se logra en los últimos X sprints para mostrar lo que pueden hacer, respaldada con números reales

  • Verifique cuándo los desarrolladores se fueron o se unieron y vea si hay un cambio notable en la velocidad en ese momento para mostrar cuál es el impacto.

Para mí, esto ha funcionado, uso el informe de sprint en Jira para crear una descripción general de los últimos 20 sprints (fue mucho trabajo), pero pude convencer a la gerencia sobre el impacto de cambiar el equipo constantemente.