---

¿Qué son la coordinación y la planificación entre equipos? ¡Puede que te sorprenda!

Scrum of Scrums

Después del último capítulo de este curso, es lógico que te preguntes cómo coordinar esos equipos Scrum para que colaboren con eficiencia.

Es una pregunta razonable y también hemos intentado responderla.

Reuniones de Scrum of Scrums

Las reuniones de Scrum of Scrums se parecen a la Daily Scrum. Sin embargo, aquí el enfoque no está en el trabajo de los miembros individuales, sino en los propios equipos Scrum.

Scrum of Scrums es una práctica opcional de coordinación, no un evento formal adicional. Los equipos pueden elegir una duración diaria de 15 minutos; si el contexto requiere más coordinación, una sesión de 30 a 60 minutos es otro ejemplo. Deben inspeccionar si el formato resulta útil.

Ejemplos de preguntas de coordinación

• ¿Qué hizo ayer el equipo?
• ¿Qué prevé hacer hoy el equipo?
• ¿Hay algún impedimento que pueda obstaculizar o ralentizar el progreso del equipo?

Estas respuestas deben abarcar las historias de usuario y las interdependencias que también afectan a otros equipos.

En el patrón histórico de coordinación descrito aquí, un Chief Scrum Product Owner y un Lead Scrum Master pueden facilitar conjuntamente las reuniones de Scrum of Scrums. Son títulos organizativos opcionales, no responsabilidades adicionales de Scrum. También puede moderar las reuniones uno de ellos, o pueden optar por turnarse en esta tarea.

Reuniones conjuntas de Sprint Review

Las Sprint Reviews conjuntas con todos los equipos no son obligatorias, pero pueden resultar muy beneficiosas. Los equipos deben seguir cumpliendo el propósito de la Sprint Review. Quienes trabajan en un producto inspeccionan conjuntamente el resultado integrado con las partes interesadas; las sesiones locales independientes no son una duplicación obligatoria del evento.

En las Sprint Reviews conjuntas participan representantes de los equipos y la Product Owner responsable del producto compartido. Las partes interesadas también participan en la inspección del resultado.

Los equipos Scrum también pueden rotar a sus representantes según sus preferencias. Una persona designada para facilitar la sesión, como el Lead Scrum Master opcional de este ejemplo, puede ayudar a que la revisión conjunta sea eficaz.

Las Sprint Reviews conjuntas permiten a todos los equipos mostrar sus incrementos de producto entregables a la Product Owner responsable, a los contactos de apoyo del producto y a las partes interesadas pertinentes.

Así, las Sprint Reviews conjuntas cumplen dos propósitos:

1. Todos los equipos Scrum comparten una visión del estado actual del proyecto global.
2. Todos reciben comentarios sobre su trabajo y pueden tenerlos en cuenta al realizar sus próximas Sprint Plannings.

Sprint Retrospectives conjuntas

Al igual que las Sprint Reviews conjuntas, las Sprint Retrospectives conjuntas no son obligatorias, pero pueden resultar muy beneficiosas.

Ten en cuenta que no sustituyen a las Sprint Retrospectives que debe celebrar cada equipo Scrum.

En las Sprint Retrospectives conjuntas participan representantes de los equipos Scrum. Los equipos pueden decidir rotarlos según su criterio.

Puede facilitarlas una persona designada para coordinar, como el Lead Scrum Master opcional de este ejemplo. Estas reuniones buscan identificar y aplicar mejoras en la forma en que la organización global del proyecto utiliza el marco Scrum.

Todos los problemas que requieran la atención y la colaboración de varios equipos Scrum (consulta más información sobre Varios Scrum Teams) deben destacarse en estas reuniones. Es necesario planificar, programar y seguir los pasos para resolverlos.

Planificación entre equipos: el Product Backlog global de Scrum

Cuando varios equipos trabajan en el mismo producto, comparten un Product Goal y un Product Backlog bajo una única Product Owner responsable. Esta lección denomina a esa vista compartida Product Backlog global de Scrum. Los contactos de apoyo y los equipos pueden ayudar a refinar su contenido, pero la responsabilidad sigue siendo de esa Product Owner.

Backlogs específicos de cada equipo

Cuando sea necesario, las historias del Product Backlog global de Scrum pueden dividirse en historias más específicas para cada equipo.

Estos detalles pueden mantenerse en vistas de trabajo específicas de cada equipo y, una vez seleccionados, en sus Sprint Backlogs. Tales vistas remiten al Product Backlog compartido y no se convierten en Product Backlogs del mismo producto priorizados de forma independiente. Estas referencias ayudan a los equipos Scrum a comprender la función de sus historias de usuario en el conjunto del proyecto y el valor que aportan al cliente.

Programación de Sprints

En un proyecto Scrum distribuido hay dos opciones para sincronizar el trabajo de los distintos equipos.

• Sprints síncronos
• Sprints asíncronos

La primera es utilizar Sprints síncronos. Todos los equipos comienzan y terminan sus Sprints el mismo día.

Los Sprints síncronos suelen ser la opción preferida porque facilitan relativamente la comunicación y la coordinación del equipo Scrum.

Sprints síncronos

La otra opción es utilizar Sprints asíncronos, que no comienzan ni terminan el mismo día. Los Sprints asíncronos tienen la ventaja de que no todos los eventos de los distintos equipos deben celebrarse el mismo día. Esto puede permitir a la Product Owner y a los contactos de apoyo a la coordinación participar en los eventos de Sprint Planning, Sprint Review y Sprint Retrospective de otros equipos y apoyarlos cuando lo soliciten.

Cuando un equipo presta servicios a otros, los Sprints asíncronos ofrecen una ventaja adicional.

Sprints asíncronos

El esquema anterior ilustra un buen ejemplo: el trabajo del equipo A, proveedor, debe integrarse en las entregas del equipo B, principal. Con Sprints asíncronos, el equipo A puede cerrar su Sprint antes que el B. Así, el equipo B puede recoger sus entregas e integrarlas en su propio trabajo antes de cerrar su Sprint.

Estimaciones del esfuerzo

Los equipos pueden elegir una convención común de estimación, como puntos de estilo Fibonacci o tallas de camiseta, si ayuda a planificar conjuntamente. Scrum no lo exige, y los puntos o la velocidad de un equipo no son automáticamente comparables con los de otro.

Cuando una convención común resulte útil, aplícala de manera coherente en el Product Backlog compartido, manteniendo la responsabilidad de los Developers sobre la estimación del tamaño.

Hay que prestar especial atención a las estimaciones de los equipos de componentes. Suelen prestar servicios para las historias de los equipos de funcionalidades. Por eso deben recibir el apoyo y las aclaraciones necesarios durante sus propias Sprint Plannings y estimaciones.