¿Cómo hacer que historias de usuario afectadas por más de un equipo funcionen?

Equipos coordinándose en una historia de usuario
Cortesía de Pixabay

Si miramos la técnica de calidad INVEST que aplicamos a las historias de usuario, sobre todo los criterios Independent y Small, veremos que éstas están pensadas para ser construidas por un solo equipo dentro de uno de sus sprints.

Una historia de usuario excelente cumple con los 6 criterios, y una buena historia de usuario puede que solo cumpla con la mayoría de ellos. A veces buenas historias de usuario no son independientes y requieren de más de un equipo.

Y es justamente en este punto donde, a través de este post quiero, arrojar algo de claridad sobre como tratar estas historias que Jann Thomas denomina cross-team-stories o historias que cruzan equipos.

Una historia que cruza equipos consta en realidad de dos partes: la parte de la historia de usuario que permanece con el equipo que la identificó, y la historia de usuario que va al equipo que la completa. La propiedad/responsabilidad de ambas historias recae en el equipo que la ha identificado. La propuesta del flujo de la historia entre equipos sería la siguiente:

1. Durante una planificación del sprint, o una PI Planning, un equipo identifica una historia de usuario con una parte que debe realizar un equipo diferente.
2. El equipo que la identifica la divide en dos, una historia de usuario para cada equipo.
3. Representantes apoyados por, o directamente los Propietarios del Producto de los respectivos equipos, negocian la prioridad y el alcance de la historia que ha de construir el otro equipo.
4. El equipo que construye la parte planifica la historia en su sprint. El equipo que la ha identificado planifica su historia en el sprint adecuado teniendo en cuenta la planificación del otro equipo, sea el siguiente sprint o uno posterior.
5. Una vez finalizada la historia por parte del segundo equipo, el equipo que la ha identificado la integra y valida junto a la suya.

Lo que realmente estamos haciendo es una gestión de resolución de dependencias, que mientras no finalice deberemos de visitar en las reuniones de Scrum de Scrums.