---

O que são coordenação e planejamento entre equipes? A resposta pode surpreender você!

Scrum of Scrum

Depois de estudar o capítulo anterior, é natural perguntar como coordenar essas diferentes equipes Scrum para que trabalhem juntas com eficiência.

É uma pergunta válida, e também procuramos respondê-la.

Reuniões Scrum of Scrum

As reuniões Scrum of Scrum se parecem com as reuniões Daily Scrum. Porém, nas reuniões Scrum of Scrum, o foco não é o trabalho de cada membro, mas as próprias equipes Scrum.

O Scrum of Scrums é uma prática opcional de coordenação, não um evento formal adicional do Scrum. As equipes podem escolher encontros diários com duração máxima de 15 minutos; quando o contexto exige mais coordenação, uma sessão de 30 a 60 minutos é outro exemplo. Elas devem avaliar se o formato é útil.

Exemplos de perguntas de coordenação

• O que a equipe fez ontem?
• O que a equipe planeja fazer hoje?
• Há algum impedimento que atrapalhe ou retarde o progresso da equipe?

Essas respostas devem, evidentemente, abordar as histórias de usuário e interdependências que também afetam outras equipes.

No padrão histórico de coordenação descrito aqui, um Chief Scrum Product Owner e um Lead Scrum Master podem facilitar juntos as reuniões Scrum of Scrums. São títulos organizacionais opcionais, não responsabilidades adicionais do Scrum. Como alternativa, um deles pode assumir a moderação dessas reuniões, ou ambos podem alternar essa responsabilidade.

Reuniões conjuntas de Sprint Review

Reuniões conjuntas de Sprint Review com todas as equipes Scrum não são obrigatórias, mas podem ser muito benéficas. As equipes continuam precisando cumprir o propósito da Sprint Review. Equipes que trabalham no mesmo produto inspecionam seu resultado integrado junto às partes interessadas; sessões locais separadas não são uma duplicação obrigatória do evento.

Participam das Sprint Reviews conjuntas os representantes das equipes Scrum e o Product Owner responsável pelo produto compartilhado. As partes interessadas também participam da inspeção do resultado.

As equipes Scrum também podem alternar seus representantes conforme suas preferências. Um facilitador designado, como o Lead Scrum Master opcional deste exemplo, pode ajudar a tornar a Review conjunta eficaz.

As Sprint Reviews conjuntas permitem que todas as equipes Scrum demonstrem seus Incrementos de Produto em condições de entrega ao Product Owner responsável, aos contatos de apoio ao produto e às partes interessadas relevantes.

Assim, as Sprint Reviews conjuntas cumprem dois propósitos:

1. Todas as equipes Scrum passam a ter uma visão alinhada da situação atual do projeto como um todo.
2. Todas as equipes Scrum recebem feedback sobre seu trabalho e podem considerá-lo nas próximas reuniões de Sprint Planning.

Sprint Retrospectives conjuntas

Assim como as Sprint Reviews conjuntas, as Sprint Retrospectives conjuntas não são obrigatórias, mas podem ser muito benéficas.

As Sprint Retrospectives conjuntas não substituem as retrospectivas que cada equipe Scrum precisa realizar.

Participam das Sprint Retrospectives conjuntas representantes das equipes Scrum. Cada equipe pode decidir alternar seus representantes.

As Sprint Retrospectives conjuntas podem ser facilitadas por um coordenador designado, como o Lead Scrum Master opcional deste exemplo. Essas reuniões buscam identificar e aproveitar oportunidades de melhoria na forma como a organização ampliada do projeto utiliza o framework Scrum.

Todos os problemas cuja resolução exija atenção e colaboração de várias equipes Scrum (saiba mais sobre Várias Equipas Scrum) devem ser destacados nessas reuniões. Os caminhos para resolvê-los precisam ser planejados, agendados e acompanhados.

Planejamento entre equipes: o Product Backlog global do Scrum

Quando várias equipes trabalham no mesmo produto, compartilham um Objetivo do Produto e um Product Backlog sob a responsabilidade de um único Product Owner. Esta lição chama essa visão compartilhada de Product Backlog global do Scrum. Contatos de apoio ao produto e equipes podem ajudar a refinar seu conteúdo, mas a responsabilidade permanece com esse Product Owner.

Backlogs específicos das equipes

Quando necessário, as histórias de usuário do Product Backlog global podem ser divididas em histórias mais específicas para cada equipe.

Esses detalhes podem ser mantidos em visualizações de trabalho de cada equipe e, depois de selecionados, no respectivo Sprint Backlog. Essas visualizações remetem ao Product Backlog compartilhado, em vez de se tornarem Product Backlogs com prioridades independentes para o mesmo produto. Essas referências ajudam as equipes Scrum a compreender o papel de suas histórias de usuário no panorama geral do projeto e o valor que entregam ao cliente.

Agendamento de Sprints

Num projeto Scrum distribuído, existem duas opções para sincronizar o trabalho das diferentes equipes Scrum.

• Sprints síncronos
• Sprints assíncronos

A primeira é utilizar Sprints síncronos. Neles, todas as equipes começam e encerram seus Sprints no mesmo dia.

Os Sprints síncronos costumam ser a abordagem preferida, pois facilitam a comunicação e a coordenação das equipes Scrum.

Sprints síncronos

Outra opção é utilizar Sprints assíncronos. Nesse caso, os Sprints não começam nem terminam no mesmo dia. A vantagem dos Sprints assíncronos é que os rituais Scrum de cada equipe não precisam ocorrer todos no mesmo dia. Isso pode permitir que o Product Owner e os contatos de apoio à coordenação participem dos eventos de Sprint Planning, Sprint Review e Sprint Retrospective de outras equipes Scrum e as apoiem quando solicitado.

Quando uma equipe presta serviços a outras, os Sprints assíncronos oferecem uma vantagem adicional.

Sprints assíncronos

O cenário mostrado no desenho acima esclarece isso: o trabalho da Equipe A (fornecedora) precisa ser integrado às entregas da Equipe B (principal). Com Sprints assíncronos, a Equipe A pode encerrar seu Sprint antes da Equipe B. Assim, a Equipe B pode receber as entregas da Equipe A e integrá-las ao próprio trabalho antes de encerrar seu Sprint.

Estimativas de esforço

As equipes podem escolher uma convenção comum de dimensionamento, como pontos no estilo Fibonacci ou tamanhos de camiseta, quando isso ajuda o planejamento conjunto. O Scrum não exige essa prática, e um ponto ou a velocidade de uma equipe não são automaticamente comparáveis aos de outra.

Quando uma convenção comum for útil, aplique-a consistentemente no Product Backlog compartilhado, preservando a responsabilidade dos Desenvolvedores pelo dimensionamento.

As estimativas das equipes de componentes exigem atenção especial. Elas costumam prestar serviços às histórias de usuário das equipes por funcionalidade. Portanto, devem receber o apoio e os esclarecimentos necessários durante suas próprias reuniões de Sprint Planning e estimativas.