Retrospectiva de un compromiso no finalizado.

image

Pueden ser varios los motivos por los que una historia no ha sido finalizada. El Equipo Scrum debe enfocarse en identificar las causas y proponer soluciones, nunca culpables.

Os dejo algunas de las causas más comunes:

  • Incorrecta definición de una historia que ha aflorado en un alcance mayor del esperado. El Product Owner debe poner más cuidado en las definiciones, revisar su conocimiento de producto y asegurarse de que Equipo de  desarrollo ha entendido el contenido funcional de cada una las historias. El Equipo de desarrollo debe procurar no quedar con lagunas de conocimiento. Y el Scrum Master debe desarrollar una estrategia que de comunicación en las reuniones de refinamiento del backlog y de planificación del Sprint que minimice el riesgo de que algo así vuelva a ocurrir.
  • Velocidad del equipo más lenta de lo esperado. Es frecuente en equipos noveles o de reciente constitución. El ScrumMaster debe reconsiderar la velocidad estimada para evitar situaciones como la ocurrida. Es inevitable hasta que se obtiene un conocimiento real de la velocidad de avance.
  • Subestimación de las historias. La subestimación constante marcará una tendencia que el ScrumMaster debe saber detectar y corregir. Debe revisar la Definición de Hecho y definir correctamente todas las exigencias de cara a que el Equipo de Desarrollo no deje ninguna tarea sin evaluar en sus estimaciones, el Product Owner debe colaborar con el ScrumMaster para definir sus necesidades de ‘Hecho’. El Equipo de desarrollo debe tomar conciencia de su postura optimista cuando estima y tratar de adoptar postura más realista.
  • Desconocimiento del alcance de una historia. El Product Owner debe hacer hincapié en la fase de Conversación de las historias, el Refinamiento del Backlog debe ser una constante al menos una vez por semana. Se deben definir más criterios de aceptación y recurrir a una mayor definición de casos de prueba  funcionales de la historia, no limitarse a la prueba básica.
  • Problemas técnicos. El Equipo de desarrollo debe detectar estas situaciones sobre todo cuando en alguna de las historias se requiere el uso de una herramienta o tecnología desconocida. Es la hora de solicitar al Product Owner un Spike que permita profundizar en el conocimiento de dicha tecnología para afrontar con éxito la producción de la historia. El Product Owner debe evaluar el riesgo de afrontar historias con tecnologías desconocidas y el beneficio de determinados Spikes sobre el resto del producto.
  • Incorrecta definición del Definition of Ready. Es posible que se haya planteado una incompleta relación  de las reglas que debe cumplir la definición de listo en las historias de usuario. Todos los integrantes del Equipo Scrum deben revisar la definición, las reuniones de Refinamiento del backlog y la de Planificación del Sprint son cruciales para determinar la correcta.
  • Incorrecta definición del Definition of Done. Si una de las historias requiere un tipo especial de prueba, de implantación o de tecnología, que no se había evaluado, es posible que nos explote en las manos. Para prevenir estas situaciones debemos hacer una relectura de la definición de hecho en la reunión de planificación del Sprint, y corrección si es oportuno.

image

 

Gracias por la lectura, nos vemos pronto.

Óscar R. Onrubia

@OscaRonrubia

Anuncios
Esta entrada fue publicada en Método, Metodologías Ágiles, Scrum y etiquetada , , , . Guarda el enlace permanente.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s