Bloques y Dependencias de Historias de Usuario

[caof2005]

Hola comunidad...

Estoy en un proyecto con la siguiente situaciön:

- Sprint: 4
- Longitud del Sprint 4: semanas
- Equipo: 5 personas (Incluido yo -Jugando el rol de ScrumMaster y en
ocasiones apoyando a desarrollar criterios de aceptación de las
historias de usuario y parte de la arquitectura).
- Nuestra velocidades hasta le momento han sido:

110 Unidades en el 1er Sprint.
118 Unidades en el 2do Sprint
115 Unidades es el 3er Sprint

Y esperabamos remontar a 120 Unidades en este 4to Sprint.

El problema es que una persona del equipo (no es el product owner)
tomará sus vacaciones 1 semana antes de la última semana del termino
de este sprint y van a durar 10 días aprox.

Evidentemente esto impactará tanto en la velocidad como en las
historias que se construyan.
Adicionalmente, algunas de las historias que tiene asignadas para este
sprint son características que no se completaron en el sprint anterior
y algunas otras son historias totalmente nuevas (programadas para
realizarse en este sprint), de hecho estas últimas nuevas son
servicios base que utilizarían otras historias de usuario que
desarrollarían otros miembros del equipo.

La pregunta es:
Alguien ha tenido alguna experiencia definiendo una estrategia para
resolver este tipo de circunstancias/restricciones?

Lo que no desea el equipo es que se modifique totalmente el contenido
del sprint con otras historias de menor valor para el negocio, aunque
estas fuesen independientes de las programadas y se pudiesen
construir, precisamente porque deseaban mostrar un avance sustancial y
mejorar la velocidad

Tampoco es atractiva la opción de que alguién mas tome su lugar no
porque no se pueda lograr, sino porque subsitituir temporalmente
implicaría incrementar un poco la curva de aprendizaje, lo cual
seguramente disminuiría el promedio de velocidad individual y por lo
tano del equipo, y existe la posibilidad de que las otras historias
que dependen de estas quizas no queden bien (es decir, debido a que
dependen de estos servicios, si el servicio no funciona adecuadamente
las historias no se podrán mostrar y no contarán como desarrolladas <=
resultaría dificil o imposible corroborar que los criterios de
aceptación se cumplieron)

Por otra parte el equipo también tiene la sensación de que si no se
completan las historias programadas, las velocidades registradas
anteriormente no serían reales sobre todo en el último sprint porque
no se completarían todas las características de las historias (que son
realmente las útiles para el negocio).

Cualquier experiencia, idea o sugerencia será bienvenida.

Saludos
Carlos

[David Arturo Cruz Salinas]

Hola!

Una disculpa por la tardanza de la respuesta.

En mi opinión creo que es lógico que sucedan estas situaciones. Las personas toman vacaciones y eso es normal. El hecho de que se ausenten por algunos días es normal que disminuya la cantidad de trabajo que se realiza por equipo. Así que creo que el asunto es meter en el sprint solo las historias que puedan ser construidas por el equipo que estará presente. Y la velocidad entonces no debería variar, ya que si sacaban 110 unidades entre 5 personas, entre 4 personas debían estar por los 88 puntos, pero la velocidad de cada persona debía ser similar. 

Lo que más bien se tiene que platicar con el PO es que es natural que estos retrasos se den porque la gente tiene que descansar tomando sus vacaciones, pero no significa que el equipo esté dando menos. Me parece es más bien una cuestión cultural del PO que tiene que aceptar estas situaciones.

En mi opinión, creo que se puede compensar de alguna manera. Habría que buscar lo que le interesa al PO para encontrar un punto de negociación.

Saludos!

Dx

programmer | drummer | photographer

dequis.blogspot.com

[Carlos Ortega]

Gracias David.

La solución que escogimos fue buscar otras historias independiente dentro de las programadas para el próximo sprint y algunas que estaban semi-independientes en el backlog.

Ha sido difícil la negociación, sobre todo por las expectativas creadas anteriormente y el ritmo que traíamos.

 

Nuestro razonamiento básicamente consistió en que si pasábamos las historias por construir a otro desarrollador, la curva de aprendizaje seguramente sería pronunciada con la posibilidad de retraso o de mal funcionamiento y por lo tanto con la posible afectación de otras historias que dependen de estas.

 

Por otra parte el desarrollador que regresaría de vacaciones ya no estaría dedicado a eso porque otro tomo su lugar, y entonces el mismo también tendría que empezar a analizar otra área que no le sería familiar, nuevamente esto quizás implique una nueva curva de aprendizaje quizás menos pronunciada pero definitivamente la habría.

 

Por eso decidimos mantener este bloque de historias en “stand by” y atacar otras que quizás no representan tanto valor pero que nos permitirán continuar con el avance.

Lo que es cierto, es que desde mi perspectiva, esto no es un problema cultural, sino mas bien cotidiano de administración de recursos y manejo de riesgos,  que como suele suceder ni el líder, el scrum master o el project manager difícilmente podrá vislumbrar este tipo de situaciones al inicio del proyecto, por ende lo tiene que resolver cuando se le presente….… quizás alguien más pueda objetar que la solución es poner en práctica los métodos, recomendaciones, técnicas etc. Que da el PMBoK, sin embargo en la realidad ni el cliente ni el equipo está en las condiciones para construir y dedicar recursos (tiempo, dinero, y personas) en un proyecto ágil en el que la idea es proporcionar valor a la empresa lo más pronto posible.

 

Espero que esta decisión haya sido acertada, al final lo comprobaremos.

 

Saludos

Carlos