Spotify Scrum, PBIs e VSA: como seu backlog passa a refletir o código

Segunda parte da série “Da Arquitetura Legada ao Time que Entrega”. No artigo anterior, mostramos a jornada do Clean Architecture para o Vertical Slice Architecture. Agora, a pergunta é: como essa mudança de código muda a forma como o time trabalha?

Existe uma tensão silenciosa em quase todo time de desenvolvimento que usa Scrum.

De um lado, o Product Owner escreve PBIs pensando em valor de negócio: “Como cliente, quero aprovar pedidos em lote para economizar tempo.” De outro, o desenvolvedor abre o repositório e enfrenta uma estrutura que não tem nenhuma relação com esse PBI, camadas técnicas, services genéricos, repositórios compartilhados.

O resultado é uma tradução constante. O que o negócio chama de “aprovar pedidos em lote” precisa ser mapeado mentalmente para: qual controller, qual service, qual repositório, qual migration. Essa tradução acontece em cada planning, em cada refinamento, em cada PR.

Com Vertical Slice Architecture, essa tradução desaparece. E quando ela desaparece, algo interessante acontece com o time.

O modelo Spotify como pano de fundo

Antes de falar de PBIs e código, vale alinhar o contexto de time que já usei do meu lado, porque o modelo Spotify muda o significado de autonomia.

No modelo Spotify, a unidade básica é o Squad: um time pequeno (tipicamente 5 a 8 pessoas), multidisciplinar, com ownership claro sobre um domínio de produto. Squads são agrupados em Tribes (tribos), que compartilham contexto de produto. Dentro da tribo, Chapters reúnem pessoas com a mesma especialidade técnica (todos os devs backend, por exemplo) para compartilhar práticas e padrões.

A intenção é que cada squad consiga entregar de forma independente, sem depender de outros times para fazer seu trabalho avançar.

O que isso tem a ver com arquitetura? Tudo.

Se o código é organizado por camadas técnicas e diferentes squads precisam mexer no mesmo CustomerService, a autonomia do modelo Spotify é teórica. Na prática, existe um gargalo compartilhado disfarçado de arquitetura.

VSA quebra esse gargalo. Cada squad passa a ter ownership não só de um domínio de produto, mas de um conjunto de features, e cada feature vive em um slice isolado.

O problema do PBI que não encontra o código

Vamos usar um exemplo concreto. Imagine um squad responsável pelo domínio de Pedidos num e-commerce B2B.

O backlog tem PBIs como:

• Aprovar pedido manualmente
• Aprovar pedidos em lote
• Cancelar pedido com motivo
• Reenviar pedido cancelado
• Exportar pedidos do mês

Com Clean Architecture, onde fica o código de cada um desses PBIs?

Servicos em CleanArquitecture

O OrderService tem ApproveOrder, ApproveBatch, CancelOrder, ResendOrder, ExportOrders, e mais quinze outros métodos que foram aparecendo ao longo do tempo. Todos os PBIs do squad vivem no mesmo arquivo.

Quando dois desenvolvedores trabalham em PBIs diferentes da mesma sprint, eles inevitavelmente editam o mesmo arquivo. Conflito de merge. Revisão cruzada obrigatória. Dependência invisível entre tarefas paralelas.

Com VSA, o mapeamento é direto:

Quebra de pasta em vertical slices

Cada PBI tem um slice. Cada slice tem uma pasta. Dois devs trabalhando em PBIs diferentes nunca tocam o mesmo arquivo.

Como isso muda o planning e o refinamento

Quando a estrutura do código reflete a estrutura do backlog, o planning ganha uma propriedade valiosa: estimativa por isolamento.

No modelo antigo, estimar um PBI exigia prever o impacto em camadas compartilhadas. “Essa feature mexe no OrderService, que é usado por 8 outros lugares, alguém sabe o que pode quebrar?” A estimativa virava uma análise de risco disfarçada de story points.

Com VSA, a conversa muda:

*“Esse PBI vai criar um novo slice ApproveOrder. Handler, validador, response. Meia tarde de trabalho pra um dev mid, um dia se incluir testes.

Não vamos nem entrar na tese de IA e VibeCode… , pelo menos ainda não :))”*

A estimativa reflete o trabalho real, não o risco de impacto colateral.

Refinamento orientado a slice

Uma prática que adotamos: durante o refinamento, além de descrever critérios de aceite, o time define o contorno do slice, quais arquivos serão criados, quais entidades de domínio serão usadas, se haverá comunicação com outros contextos.

Isso não é um documento técnico formal. É uma conversa de 5 minutos que termina com algo assim no comentário do PBI:

Quando o dev pega o PBI, ele não começa do zero. Ele começa com um mapa.

Autonomia real: o squad que não precisa pedir permissão

No modelo Spotify, autonomia é o objetivo. Mas autonomia sem isolamento é ilusão.

Um squad só é verdadeiramente autônomo quando pode entregar uma feature do início ao fim sem depender de outro time para:

• Revisar código em arquivos compartilhados
• Fazer merge de mudanças em camadas comuns
• Aguardar liberação de um service que outro squad também usa

Com slices por feature e ownership claro por domínio, cada squad passa a ter um território de código que é só seu. O squad de Pedidos mexe em Features/Orders/. O squad de Clientes mexe em Features/Customers/. A sobreposição é mínima e, quando existe, é intencional, não acidental.

O Chapter como guardião do padrão

Aqui entra o papel do Chapter no modelo Spotify.

Se cada squad escreve seus slices de forma independente, quem garante que todos seguem o mesmo padrão? Quem define como um handler deve ser estruturado? Quem decide quando um comportamento transversal (logging, autenticação, validação) deve virar um behavior compartilhado?

Essa é a função do Chapter técnico, os arquitetos e devs sênior de todos os squads que se reúnem para alinhar práticas. No nosso caso, o Chapter definiu:

• Template de slice: todo novo slice segue a mesma estrutura de arquivos
• Behaviors padrão: logging, validação e tratamento de erro são behaviors registrados globalmente, não responsabilidade de cada handler
• Regras de comunicação entre slices: um slice nunca chama outro diretamente, se precisar de dados de outro domínio, usa uma query ou um evento

Isso mantém a autonomia dos squads sem criar anarquia de padrões.

Boarding de PBIs com VSA: o fluxo na prática

Vamos ver como fica o ciclo completo de um PBI num squad que usa VSA e o modelo Spotify.

1. Product Backlog Item entra no refinamento

O PO traz: “Quero que o comprador consiga cancelar um pedido já aprovado, desde que ele ainda não tenha sido faturado, informando um motivo obrigatório.”

O squad discute e levanta:

• Regras de negócio (pedido aprovado, não faturado)
• Motivo obrigatório (validação)
• Efeito colateral (notificar o vendedor)

2. O contorno do slice é definido

O squad vê esse esboço no refinamento. Não há surpresa na implementação.

3. O dev pega o PBI e cria o slice

Pasta criada, arquivos criados, testes escritos. Nenhum arquivo compartilhado foi modificado. Nenhum outro dev foi impactado.

4. PR pequena, revisão focada

A PR tem 4 arquivos novos dentro de Features/Orders/CancelApprovedOrder/. O revisor sabe exatamente o que está analisando, não precisa entender o estado global do OrderService para dar um feedback qualificado.

5. Deploy independente

Como o slice não mexe em nada compartilhado, o risco de regressão é mínimo. O squad consegue fazer deploy com confiança, e, se necessário, reverter apenas aquele slice.

Métricas que mudaram depois da adoção

Depois de três meses usando VSA com o modelo Spotify, medimos algumas coisas:

Lead time por PBI caiu de uma média de 4,2 dias para 2,8 dias. A maior parte da redução veio da eliminação de espera por merge e de conflitos em arquivos compartilhados.

Taxa de regressão pós-deploy caiu de 18% para 6%. Slices isolados significam que uma mudança tem um raio de impacto previsível.

Satisfação do squad no retrospectivo melhorou no quesito “sei o que preciso fazer para entregar minha tarefa”, de 3,1 para 4,4 numa escala de 5.

Não é mágica. É consequência natural de alinhar a estrutura do código com a estrutura do trabalho.

PBIs mal definidos ficam mais visíveis

Um efeito colateral interessante do VSA: um PBI vago se torna impossível de transformar em slice. “Melhorar a gestão de pedidos” não tem contorno claro, você não consegue definir um comando nem um handler para isso.

Isso força conversas mais precisas no refinamento. O PO precisa ser específico. O time aprende a rejeitar PBIs sem critério de aceite claro. A qualidade do backlog melhora como consequência direta da arquitetura.

O que ainda requer atenção

Features que cruzam domínios

Nem todo PBI é simples. Às vezes, uma feature como “Aprovar pedido” precisa verificar o crédito do cliente (domínio de Clientes) e atualizar o estoque (domínio de Estoque), dois contextos distintos, com donos distintos.

A regra que adotamos é clara: o slice de Pedidos é o responsável pela orquestração. Ele pode consultar outros domínios via query, mas não invoca diretamente o handler de outro domínio. Quando precisa disparar uma ação em outro contexto, emite um evento e delega ao squad responsável o tratamento do efeito colateral.

Essa decisão tem um nome bem estabelecido na literatura de arquitetura: é o dilema entre coreografia e orquestração, central no padrão SAGA, que trata exatamente da comunicação entre domínios internos e externos em sistemas distribuídos.

Coreografia

Na coreografia, não existe um “chefe” central. Cada Bounded Context (BC) reage autonomamente a eventos que já ocorreram em outros contextos: ele sabe quais eventos lhe interessam e age assim que um evento relevante chega.

Como se comunica:

• Por meio de eventos de domínio (ex: PedidoAprovado, EstoqueBaixo).
• Cada contexto publica eventos em um barramento ou message broker; quem precisa saber, escuta e age.

Implicações de responsabilidade: A responsabilidade fica distribuída, cada BC é dono da sua própria reação. Isso reduz o acoplamento, pois um BC não precisa conhecer quem vai consumir seu evento. A contrapartida é que o fluxo completo do processo fica implícito: não há um único lugar no código onde a sequência toda esteja documentada.

Exemplo concreto: O contexto de Pagamento publica PagamentoConfirmado, o contexto de Estoque escuta, reserva o produto e publica EstoqueReservado, o contexto de Entrega escuta e cria o pedido de logística.

Orquestração

Na orquestração, criamos um componente chamado orquestrador (ou saga orquestrada): um serviço técnico que conhece exatamente a sequência de passos e quem deve executar cada um. Ele chama os outros BCs via comandos, aguarda respostas e decide o próximo passo.

Como se comunica:

• Por comandos síncronos (HTTP/gRPC) ou assíncronos com padrão requisição-resposta.
• O orquestrador mantém o estado do fluxo em banco de dados ou memória durável.

Implicações de responsabilidade: A responsabilidade fica centralizada. É fácil responder perguntas como “em que ponto do fluxo o pedido está?”, pois o orquestrador controla tudo. O custo é o acoplamento: os BCs precisam saber responder a comandos do orquestrador, que pode se tornar um ponto único de falha ou gargalo.

Exemplo concreto: O orquestrador PedidoWorkflow chama o BC de Pagamento, depois o BC de Estoque, depois o BC de Entrega. Se um passo falha, ele decide compensar o processo (rollback).

Um exemplo do mundo real

Em uma empresa de serviços financeiros em que trabalhei, o squad de Fundos de Investimentos enfrentava exatamente esse cenário. Ao registrar uma Ordem de Aplicação ou Resgate, era necessário comunicar o squad de Posição Consolidada, responsável pela verdade única do dado de Saldo.

Ou seja: para esse PBI, além do fluxo trivial interno, havia uma comunicação por eventos entre squads. A decisão de usar coreografia aqui foi natural: o squad de Fundos publicava um evento (OrdemRegistrada, ResgateEfetuado) e o squad de Posição Consolidada escutava, processava e atualizava o saldo de forma autônoma, sem que os dois squads precisassem se acoplar diretamente.

Nota: No artigo 3, esse tema voltará, mas em um contexto diferente, o de Team Topologies e Bounded Contexts.

Onde estamos

A combinação de VSA com o modelo Spotify não é uma receita a ser seguida cegamente. É uma resposta a um problema específico: times que querem autonomia real, com código que suporte essa autonomia.

O que descobrimos é que arquitetura e modelo de time não são decisões separadas. Uma influencia a outra. Quando o código é organizado por features e o time é organizado por domínios, as duas estruturas se reforçam, e o resultado é um squad que sabe o que está entregando, sabe onde está o código, e consegue se mover sem pedir permissão.

No próximo artigo, vou ir um nível acima: como a forma que os times se organizam entre si, usando Team Topologies, começa a alimentar naturalmente o DDD, mesmo quando o time não sabe que está praticando DDD.

Se você usa o modelo Spotify ou algo parecido no seu time, me conta nos comentários: como é hoje o mapeamento entre seus PBIs e o código? A estrutura do repositório reflete o backlog?

<- Artigo anterior: Por que saímos do Clean Architecture, e o que encontramos no caminho

Próximo da série -> Team Topologies como atalho para o DDD que seu time nem sabe que está fazendo