Nexus Framework: cómo escalar Scrum de 3 a 9 equipos

Por Tara Minh · Actualizado el 10 de octubre de 2026

Nexus es un framework de Scrum.org para aproximadamente de tres a nueve Scrum Teams que trabajan juntos en un mismo producto. Mantiene las reglas de Scrum y añade solo lo necesario para gestionar las dependencias: un Nexus Integration Team, algunos eventos adicionales y un único Integrated Increment compartido al que contribuye cada equipo en cada Sprint.

Gran parte del dolor al escalar no tiene que ver con escribir código más rápido. Tiene que ver con dos equipos que tocan el mismo módulo, un tercero que espera a ambos y nadie que se dé cuenta hasta el final del Sprint. Nexus está construido en torno a ese problema. No le pide reestructurar la empresa. Le pide hacer visibles las dependencias desde temprano y dar a alguien una responsabilidad clara sobre la integración.

Datos Clave

• Nexus fue desarrollado por Ken Schwaber y Scrum.org, y la Nexus Guide ha tenido ediciones en 2015, 2018 y 2021.
• La Nexus Guide vigente (enero de 2021) describe un Nexus como aproximadamente de tres a nueve Scrum Teams con un Product Owner y un Product Backlog.
• El Nexus Integration Team está formado por el Product Owner, un Scrum Master y uno o más Nexus Integration Team Members.
• La guía no fija timeboxes para los eventos de Nexus. Sus duraciones se guían por los eventos de Scrum equivalentes.
• La edición de 2021 cambió el nombre de Refinement a Cross-Team Refinement.
• LeSS cubre de 2 a 8 equipos, por lo que ambos frameworks coinciden en gran medida en la cantidad de equipos y se diferencian sobre todo en cuánto cambio organizacional exigen.

¿Qué es el Nexus framework?

Nexus es un framework para desarrollar y sostener la entrega de producto a escala. Extiende Scrum de forma mínima. Los equipos siguen ejecutando Sprints, mantienen un único Product Owner y un único Product Backlog, y responden a los mismos valores de Scrum. Lo que cambia es que el grupo produce un Integrated Increment en lugar de varios poco relacionados entre sí, y un pequeño grupo asume la responsabilidad de lograr esa integración.

La palabra "nexus" significa punto de conexión, y el framework trata sobre todo de conexiones: entre elementos del backlog, entre equipos y entre el trabajo que cada equipo da por Done y lo que realmente se entrega en conjunto.

Tres ideas sostienen la mayor parte del peso:

• Un producto, un backlog. Todos los equipos toman del mismo Product Backlog, que pertenece a un único Product Owner.
• Las dependencias son el enemigo del flujo. Elimínelas mediante refinamiento antes del Sprint y dé seguimiento a las que queden.
• La integración ocurre en cada Sprint. El Nexus debe producir un Increment funcional e integrado al menos una vez por Sprint, no al final de una fase de lanzamiento.

Roles de Nexus: el Nexus Integration Team

Nexus no añade ninguna capa de gestión. Añade un equipo. Según la Nexus Guide, el Nexus Integration Team incluye:

El error de interpretación más común es creer que el Integration Team hace la integración. No es así. Cada Scrum Team sigue haciendo su propio trabajo de integración. El Integration Team coordina, orienta y elimina obstáculos, y es responsable de que el Integrated Increment realmente exista y cumpla con la Definition of Done. También es responsable de la Definition of Done compartida del Integrated Increment. Los equipos individuales pueden exigirse un estándar más estricto, pero no uno más laxo.

La composición puede rotar a medida que cambia el trabajo. La guía dice que el lugar de una persona en el Integration Team tiene prioridad sobre su pertenencia a un equipo mientras se cumplan las responsabilidades del Integration Team, que es una forma cortés de decir que el rol va primero cuando ambos entran en conflicto.

Eventos de Nexus

Nexus conserva los eventos estándar de Scrum y los complementa con versiones entre equipos. Así funciona cada uno según la Nexus Guide.

Algunas notas prácticas sobre cómo se desarrollan:

El Cross-Team Refinement es el evento que se gana su lugar. Si sus equipos pasan el Sprint Planning descubriendo que el equipo B necesita un cambio de esquema del equipo A, el refinamiento falló. Trátelo como trabajo continuo, muy relacionado con el refinamiento del backlog habitual, pero con la tarea específica de detectar y reducir las dependencias entre equipos.

El Nexus Sprint Planning es donde los representantes de los equipos se reúnen para confirmar el orden del trabajo y la asignación a los equipos, y luego cada equipo realiza su planificación del sprint habitual sobre su parte. El Nexus Sprint Backlog que resulta es la vista compartida de todo lo que está en juego.

El Nexus Daily Scrum es para representantes, no para todos. Es breve, trata sobre la integración y su resultado son ajustes al Nexus Sprint Backlog y a los planes de los propios equipos.

Artefactos de Nexus

Nexus usa los artefactos de Scrum y añade un par de versiones compartidas:

La guía usaba el término "Nexus Goal" en ediciones anteriores y lo renombró Nexus Sprint Goal en 2018, para coincidir con la terminología de Scrum. Si lee publicaciones de blog antiguas, espere encontrar el término anterior.

Nexus frente a SAFe, LeSS, Scrum of Scrums y Disciplined Agile

Nexus se ubica en la mitad más ligera del espectro de escalamiento. Así se compara con las opciones con las que suele sopesarse.

Dos comparaciones merecen una frase cada una. Frente a SAFe, Nexus es el compromiso más pequeño: no adopta una cadencia de planificación para toda la empresa, sino que añade un equipo de coordinación a equipos que ya comparten un producto. Frente a LeSS, la diferencia es cuánto está dispuesto a reorganizar. LeSS exige equipos de funcionalidades y un único Product Owner con autoridad real sobre todo, mientras que Nexus supone que ya tiene esa base y necesita ayuda con las costuras de la integración.

Scrum of Scrums es la opción más ligera de todas. Es una reunión recurrente donde los representantes de los equipos comparten dependencias, y suele ser lo que los equipos hacen antes de adoptar algo formal. Nexus puede leerse como una versión más estructurada de esa idea, con eventos y artefactos definidos y un grupo responsable detrás.

Cómo empezar a usar Nexus

Esta es una secuencia que se ajusta a cómo los equipos suelen adoptarlo.

1. Confirme los prerrequisitos. Debe tener tres o más equipos construyendo un mismo producto, un Product Owner y equipos que ya puedan ejecutar un Sprint decente por su cuenta. Nexus no arreglará a un equipo que aún no hace Scrum.
2. Forme el Nexus Integration Team. Nombre al Product Owner, elija un Scrum Master y escoja a una o dos personas con experiencia de los equipos como Integration Team Members. Acuerde lo que espera de ellos en un breve acuerdo de trabajo.
3. Escriba una única Definition of Done compartida. Haga que cubra la integración, no solo la finalización a nivel de equipo, de modo que "Done" signifique que funciona con todo lo demás.
4. Inicie el Cross-Team Refinement. Elija un horario regular cada semana. Recorra la parte superior del backlog, marque las dependencias y divida los elementos hasta que la mayoría pueda terminarlos un solo equipo.
5. Ejecute el Nexus Sprint Planning. Elija un Nexus Sprint Goal, asigne elementos a los equipos y construya el Nexus Sprint Backlog con las dependencias restantes a la vista.
6. Mantenga un tablero de dependencias. Use la plantilla de abajo y revíselo en el Nexus Daily Scrum.
7. Realice una única Nexus Sprint Review y Retrospective. Muestre un solo Integrated Increment, no cinco demos, y mejore la forma en que trabajan juntos los equipos.
8. Inspeccione y ajuste. Si los problemas de integración siguen apareciendo tarde, corrija primero el refinamiento y después la composición de los equipos.

Plantilla: tablero de dependencias entre equipos

Copie esto en su herramienta de seguimiento y actualícelo a diario. Es el artefacto que más piden las personas cuando empiezan con Nexus.

Notas sobre las columnas:

• Necesita de / Lo necesita mantiene explícita la dirección de la dependencia. Sin ella, los tableros se convierten en listas de preocupaciones.
• Fecha límite debe ser un día del Sprint, no un vago "pronto". Es lo que se revisa en el Nexus Daily Scrum.
• Estado solo necesita cuatro valores: No iniciado, En curso, Bloqueado, Hecho.
• Riesgo si se retrasa le da al Integration Team una clasificación rápida de qué perseguir primero.

Un buen hábito es contar las filas abiertas en el Nexus Sprint Planning y de nuevo después del Cross-Team Refinement. Si la cifra no baja de un Sprint a otro, el refinamiento no está eliminando dependencias y la estructura de los equipos es la siguiente sospechosa.

Ejemplos por función

Nexus nació en el software, pero su mecánica se aplica a cualquier producto hecho por varios equipos que trabajan en Sprints.

Qué hacer y qué evitar

Cuándo Nexus es la opción equivocada

Nexus no es adecuado si tiene menos de tres equipos, porque Scrum más una sincronización ligera es suficiente. Tampoco lo es si está coordinando muchos productos no relacionados en lugar de uno, o si sus equipos aún no han logrado que Scrum funcione a nivel de un solo equipo. Y si necesita financiamiento de portafolio, planificación empresarial y gobernanza pesada, un framework como SAFe cubre más terreno. Nexus lo lleva de tres equipos a nueve. No pretende ser un modelo operativo para toda una empresa.

Si sus equipos ya ejecutan Scrum y siguen tropezando entre sí cerca del final del Sprint, Nexus es un cambio pequeño y de bajo riesgo: nombre un Integration Team, empiece a refinar las dependencias y revise juntos un Integrated Increment. Comience por ahí, y añada estructura solo cuando el tablero le indique que hace falta.