Cuando en alguna de las empresas que acompañamos observamos que tienen varios equipos Scrum que colaboran conjuntamente en el desarrollo de un producto, sin una estructura definida, sabemos que el desastre está a punto de caerles encima.

Por tanto, en Autentia sabemos que es importante que estos equipos se coordinen y para ello es imprescindible que se facilite un evento de planificación, donde de forma estructurada se interprete la información del Product Backlog. Además, este Product Backlog debe estar lo suficientemente refinado para que se pueda hacer un plan para el próximo Sprint. 

Cuando ocurre esto, se puede optar por escalar aplicando Nexus. Puedes encontrar más información sobre el Escalado de Scrum con Nexus en el siguiente artículo de Roberto Canales: Scaled Scrum con Nexus.

Uno de los principales eventos que se dan en Nexus es el Nexus Sprint Planning cuyo propósito es crear un plan para el próximo Sprint y todos los equipos Scrum dentro del Nexus. Esta reunión se lleva a cabo coordinando todo el trabajo entre los equipos Scrum que forman parte del Nexus, tratando de eliminar las dependencias existentes.

Entre las actividades que se realizan en el Nexus Sprint Planning están:

• • Validar el Product Backlog.

• • Formular el Nexus Sprint Goal.

• • Cada equipo Scrum realiza su propio Sprint Planning.

Un ejemplo práctico para clarificar el evento a todos aquellos pocos familiarizados con Nexus y el evento Nexus Sprint Planning sería:

1.- Los equipos Scrum revisan los Product Backlogs Items (PBIs) tal cual están desde la última vez que se hizo un Refinamiento y si fuera necesario harían cualquier ajuste necesario a estos. A esta sesión sólo es necesario que acuda un representante de cada equipo Scrum, no siempre será la misma persona sino aquella que pueda aportar más valor en el refinamiento de los PBIs.

2.- Posteriormente se realiza la formulación del Nexus Sprint Goal, el cual se cumplirá a lo largo del Sprint mediante la implementación de los PBIs realizada por los diferentes equipos Scrum que integran el Nexus.

3.- Una vez que se comprende el Nexus Sprint Goal, cada equipo Scrum llevará a cabo su Sprint Planning de forma individual, donde cada equipo obtiene su propio Sprint Backlog. A medida que identifican dependencias con otros equipos, trabajarán con estos equipos para minimizar o eliminar las dependencias. Es aquí donde entra en juego el Cross-Team Refinement Board.

El Cross-Team Refinement Board (en español Tablero de Refinamiento entre equipos) es una técnica de visualización del trabajo, donde se muestran sólo los PBIs con dependencias existentes entre los equipos que forman el Nexus. 

Este tablero juega un papel fundamental en la sesión de Refinamiento que aclaremos es obligatoria en Nexus; debido a que el Refinamiento se centra en descomponer los PBIs lo suficiente como para que los equipos puedan entender qué trabajo podrían entregar y en qué secuencia en los Sprints venideros. Además, como indicamos anteriormente, nos centraremos en eliminar o minimizar las dependencias entre los equipos.

Antes de empezar a descomponer y secuenciar el Product Backlog es necesario que se debatan qué equipos tienen las habilidades necesarias para afrontar qué trabajo. Puede darse el caso (y se dará) de que existan especialistas que no están en todos los equipos. 

Ahora sí, los equipos pueden entender los PBIs y descomponerlos.

Flujo de trabajo y secuencia en los próximos dos Sprints

Una vez identificado y secuenciado el trabajo de los próximos Sprint, toca visualizar y gestionar las dependencias. Lo primero será identificar nuestras categorías de dependencias, que podrían ser:

• • Secuencia de construcción, puede ser que un PBI no pueda ser completado hasta que su padre lo esté.
  • Skills/Especialistas, sólo determinadas personas pueden completar un PBI.
  • Externas, el padre está siendo desarrollado por alguien externo al Nexus.
  • Software.
  • Dominio.

Aunque normalmente se simplifican indicando sólo 3 categorías: hardware, software o externas. En cualquier caso, identificaremos cada categoría con un color diferente, por ejemplo:

Dependencias

Las dependencias se muestran con una flecha ya que muestran la relación de dependencia padre-hijo. De forma adicional, para el tablero kanban empleado por cada equipo, desde Autentia promovemos que se emplee en la tarjeta padre la tarjeta hija con dependencia y viceversa, mediante el uso de diferente sistemas de visualización (gomet, post it pequeños, etc.)

En el ejemplo anterior que hace referencia a un tablero Kanban de un equipo del Nexus se muestran varias dependencias. Por una parte, tenemos al PBI (33) en Testing que tiene anexado un post it pequeño verde con el ID (40). Este post it indica que el PBI (33) es necesario que se construya para continuar con el PBI (40) que está In Progress. Por otro lado, el PBI (40) tiene anexado un post it pequeño magenta con el ID (33) indicando que está siendo bloqueado por el PBI (33), mientras no se construya el PBI (33) no podré construir el PBI (40).

Además, en el ejemplo anterior tenemos el PBI (60) en la fase In Progress que tiene anexado el post it magenta con el ID (95). Este indica que el PBI (60) está bloqueado y no se puede construir hasta que no se construya el PBI (95). Pero el PBI (95) no está en el tablero, por tanto se asocia con una dependencia con otro equipo identificada en el Cross Team Refinement Board.

Las dependencias en el tablero resaltan claramente una relación de trabajo entre al menos dos PBIs. Obviamente, cuantas más flechas mayor será el número de PBIs dependientes. Por tanto, permite a los equipos determinar cuáles serán los problemas a enfrentar en un futuro y proporciona una vía para iniciar conversaciones y eliminar o minimizar esas dependencias.

En más detalle:

Una flecha horizontal representa una dependencia entre PBIs dentro del mismo equipo. En el ejemplo anterior para el Team A en el Sprint +1 se estará construyendo un PBI (5) que será necesario para poder construir el PBI (9) en el siguiente Sprint.

Una flecha en diagonal representa una dependencia cruzada entre PBIs de equipos diferentes en distintos Sprint. Un equipo en un Sprint está construyendo un PBI que es necesario por otro PBI que se va a desarrollar en un posterior Sprint por un equipo diferente. En el ejemplo anterior lo podemos ver entre el PBI (5) del Team A y el PBI (10) del Team B. También, entre el PBI (4) del Team D y el PBI (11) del Team C.

Una flecha vertical representa una dependencia cruzada entre diferentes equipos dentro del mismo Sprint. Un PBI que se está construyendo en el Sprint es necesario para poder construir un PBI de otro equipo en el mismo Sprint. En la medida de lo posible, esta situación se debería evitar.

Por último tenemos las dependencias externas, debido a que son dependencias que proceden de fuera del Nexus, normalmente no tienen un identificador. En el ejemplo existe una dependencia externa sobre el PBI (12) del Team D. Son las más difíciles de resolver ya que su eliminación puede ir más allá del control del Nexus.

Conclusión

Para finalizar, indicar que la finalidad del tablero Cross Team Refinement Board es coordinar las actividades de todos los equipos Scrum dentro del Nexus y sobretodo que los equipos de Desarrollo resalten las dependencias y gestionen el flujo de trabajo durante el Sprint. Es muy importante destacar que en este tablero no se representa otro tipo de trabajo que no tenga dependencias. Por tanto, cada equipo debe trasladar estas dependencias a su propio tablero Kanban de trabajo. Normalmente, en Autentia usamos gomet o post its más pequeños de diferente color.