Nexus Framework: Escalando o Scrum para 3 a 9 Equipes

Por Tara Minh · Atualizado em 10 de outubro de 2026

O Nexus é um framework da Scrum.org para aproximadamente três a nove Scrum Teams que trabalham juntos em um único produto. Ele mantém as regras do Scrum e acrescenta apenas o necessário para gerenciar dependências: um Nexus Integration Team, alguns eventos extras e um Integrated Increment compartilhado para o qual todas as equipes contribuem a cada Sprint.

A maior parte da dor de escalar não tem a ver com escrever código mais rápido. Tem a ver com duas equipes mexendo no mesmo módulo, uma terceira esperando pelas duas e ninguém percebendo até o fim da Sprint. O Nexus foi construído em torno desse problema. Ele não pede que você reestruture a empresa. Pede que você torne as dependências visíveis cedo e dê a alguém a responsabilidade clara pela integração.

Fatos principais

• O Nexus foi desenvolvido por Ken Schwaber e pela Scrum.org, e o Nexus Guide teve edições em 2015, 2018 e 2021.
• O Nexus Guide atual (janeiro de 2021) descreve um Nexus como aproximadamente três a nove Scrum Teams com um Product Owner e um Product Backlog.
• O Nexus Integration Team é formado pelo Product Owner, um Scrum Master e um ou mais Nexus Integration Team Members.
• O guia não define time-boxes fixos para os eventos do Nexus. Suas durações são orientadas pelos eventos correspondentes do Scrum.
• A edição de 2021 renomeou o Refinement para Cross-Team Refinement.
• O LeSS cobre 2 a 8 equipes, então os dois frameworks se sobrepõem bastante em número de equipes e diferem principalmente no quanto de mudança organizacional exigem.

O que é o Nexus framework?

O Nexus é um framework para desenvolver e sustentar a entrega de produtos em escala. Ele estende o Scrum de forma mínima. As equipes continuam rodando Sprints, mantêm um único Product Owner e um único Product Backlog e respondem aos mesmos valores do Scrum. O que muda é que o grupo produz um Integrated Increment em vez de vários pouco relacionados, e um pequeno grupo assume a responsabilidade de fazer essa integração acontecer.

A palavra "nexus" significa um ponto de conexão, e o framework trata sobretudo de conexões: entre itens do backlog, entre equipes e entre o que cada equipe chama de Done e o que realmente é entregue em conjunto.

Três ideias carregam a maior parte do peso:

• Um produto, um backlog. Todas as equipes puxam do mesmo Product Backlog, de responsabilidade de um único Product Owner.
• Dependências são o inimigo do fluxo. Elimine-as por meio de refinamento antes da Sprint e acompanhe as que restarem.
• A integração acontece a cada Sprint. O Nexus deve produzir um Increment funcional e integrado pelo menos uma vez por Sprint, e não ao final de uma fase de release.

Papéis no Nexus: o Nexus Integration Team

O Nexus não acrescenta nenhuma nova camada de gestão. Acrescenta uma equipe. Segundo o Nexus Guide, o Nexus Integration Team inclui:

O equívoco mais comum é achar que o Integration Team faz a integração. Não faz. Cada Scrum Team continua fazendo o seu próprio trabalho de integração. O Integration Team coordena, orienta e remove obstáculos, e é responsável por garantir que o Integrated Increment realmente exista e atenda à Definition of Done. Ele também é dono da Definition of Done compartilhada do Integrated Increment. As equipes individuais podem se cobrar um padrão mais rigoroso, mas não mais frouxo.

A composição pode girar conforme o trabalho muda. O guia diz que o lugar de uma pessoa no Integration Team tem precedência sobre sua participação na equipe, desde que as responsabilidades do Integration Team sejam cumpridas, o que é uma forma educada de dizer que o papel vem primeiro quando os dois entram em conflito.

Eventos do Nexus

O Nexus mantém os eventos padrão do Scrum e os envolve com versões entre equipes. Veja como cada um funciona segundo o Nexus Guide.

Algumas observações práticas sobre como esses eventos se desenrolam:

O Cross-Team Refinement é o evento que se paga. Se as suas equipes descobrem na Sprint Planning que a Equipe B precisa de uma mudança de schema da Equipe A, o refinamento falhou. Trate-o como trabalho contínuo, muito próximo do backlog refinement comum, mas com a tarefa específica de identificar e reduzir dependências entre equipes.

A Nexus Sprint Planning é onde representantes das equipes se reúnem para confirmar a ordem do trabalho e a atribuição às equipes, e depois cada equipe faz seu sprint planning normal sobre a sua fatia. O Nexus Sprint Backlog que resulta disso é a visão compartilhada de tudo o que está em jogo.

A Nexus Daily Scrum é para representantes, não para todos. É curta, trata de integração, e seu resultado são ajustes no Nexus Sprint Backlog e nos planos das próprias equipes.

Artefatos do Nexus

O Nexus usa os artefatos do Scrum e acrescenta algumas versões compartilhadas:

O guia usava o termo "Nexus Goal" nas edições anteriores e o renomeou para Nexus Sprint Goal em 2018, para acompanhar a redação do Scrum. Se você ler posts de blog mais antigos, espere encontrar o termo anterior.

Nexus vs SAFe, LeSS, Scrum of Scrums e Disciplined Agile

O Nexus fica na metade mais leve do espectro de escala. Veja como ele se compara às opções com que as pessoas costumam confrontá-lo.

Duas comparações merecem uma frase cada. Frente ao SAFe, o Nexus é o compromisso menor: você não adota uma cadência de planejamento para a empresa inteira, apenas acrescenta uma equipe de coordenação a equipes que já compartilham um produto. Frente ao LeSS, a diferença é o quanto você está disposto a reorganizar. O LeSS pede feature teams e um único Product Owner com autoridade real sobre tudo, enquanto o Nexus pressupõe que você já tem essa base e precisa de ajuda nas costuras da integração.

O Scrum of Scrums é a opção mais leve de todas. É uma reunião recorrente em que representantes das equipes compartilham dependências, e muitas vezes é o que as equipes fazem antes de adotar algo formal. O Nexus pode ser lido como uma versão mais estruturada dessa ideia, com eventos e artefatos definidos e um grupo responsável por trás.

Como começar a usar o Nexus

Esta é uma sequência que acompanha a forma como as equipes costumam adotá-lo.

1. Confirme os pré-requisitos. Você deve ter três ou mais equipes construindo um único produto, um Product Owner e equipes que já consigam conduzir uma Sprint decente sozinhas. O Nexus não conserta uma equipe que ainda não pratica Scrum.
2. Forme o Nexus Integration Team. Nomeie o Product Owner, escolha um Scrum Master e selecione uma ou duas pessoas experientes das equipes como Integration Team Members. Combine o que se espera deles em um working agreement curto.
3. Escreva uma Definition of Done compartilhada. Faça com que ela cubra a integração, e não apenas a conclusão no nível da equipe, de modo que "Done" signifique que funciona junto com todo o resto.
4. Inicie o Cross-Team Refinement. Escolha um horário regular por semana. Percorra o topo do backlog, marque as dependências e fatie os itens até que a maioria possa ser concluída por uma única equipe.
5. Conduza a Nexus Sprint Planning. Escolha um Nexus Sprint Goal, atribua os itens às equipes e monte o Nexus Sprint Backlog com as dependências restantes visíveis.
6. Mantenha um quadro de dependências. Use o template abaixo e revise-o na Nexus Daily Scrum.
7. Faça uma única Nexus Sprint Review e Retrospective. Mostre um Integrated Increment, não cinco demos, e melhore a forma como as equipes trabalham juntas.
8. Inspecione e ajuste. Se os problemas de integração continuam aparecendo tarde, corrija primeiro o refinamento e depois a composição das equipes.

Template: quadro de dependências entre equipes

Copie isto para o seu tracker e atualize todos os dias. É o artefato que as pessoas mais pedem quando começam com o Nexus.

Notas sobre as colunas:

• Precisa de / Necessário para mantém explícita a direção da dependência. Sem isso, os quadros viram listas de preocupações.
• Necessário até deve ser um dia da Sprint, e não um vago "em breve". É isso que é revisado na Nexus Daily Scrum.
• Status só precisa de quatro valores: Não iniciado, Em andamento, Bloqueado, Concluído.
• Risco se atrasar dá ao Integration Team uma classificação rápida do que perseguir primeiro.

Um bom hábito é contar as linhas em aberto na Nexus Sprint Planning e de novo depois do Cross-Team Refinement. Se o número não cai de Sprint para Sprint, o refinamento não está removendo dependências, e a estrutura das equipes é a próxima suspeita.

Exemplos por função

O Nexus nasceu no software, mas a mecânica vale para qualquer produto feito por várias equipes que trabalham em Sprints.

Faça e não faça

Quando o Nexus é a escolha errada

O Nexus é inadequado se você tem menos de três equipes, porque Scrum mais uma sincronização leve já bastam. Também é inadequado se você coordena muitos produtos não relacionados em vez de um só, ou se suas equipes ainda não fizeram o Scrum de uma única equipe funcionar. E se você precisa de financiamento de portfólio, planejamento corporativo e governança pesada, um framework como o SAFe cobre mais terreno. O Nexus leva você de três equipes a nove. Ele não finge ser um modelo operacional para uma empresa inteira.

Se as suas equipes já praticam Scrum e vivem esbarrando umas nas outras perto do fim da Sprint, o Nexus é uma mudança pequena e de baixo risco: nomeie um Integration Team, comece a refinar para dependências e revise um único Integrated Increment em conjunto. Comece por aí e só acrescente estrutura quando o quadro indicar que é necessário.