APRENDER. PRATICAR. EVOLUIR.O produto como unidade de decisão
No exemplo fictício Atlas, uma equipa constrói o adaptador de pagamentos e outra a interface de reconciliação. Os utilizadores precisam de um saldo correto, não de duas demonstrações separadas. Antes de discutir coordenação, clarifica se as equipas trabalham realmente no mesmo produto: utilizadores, resultado pretendido e fronteira do serviço. Para o mesmo produto, o Scrum Guide prevê Product Goal, Product Backlog e Product Owner comuns. A especialização em componentes não cria por si só produtos diferentes. Um objetivo como “reconciliar um tipo de pagamento sem duplicações” ajuda a avaliar uma fatia completa. Uma lista de números de tickets não explica essa intenção. Se a evidência tornar o objetivo obsoleto, torna explícita a decisão de o abandonar antes de avançar para o próximo. Não mantenhas um objetivo antigo apenas para evitar discutir promessas anteriores. O Scrum Master ajuda a tornar as opções e responsabilidades compreensíveis.
Verificar o conjunto e conservar os controlos
No Atlas, o adaptador repete um evento após timeout e a interface duplica o saldo. Ambos os testes locais passaram. A qualidade do produto continua por demonstrar. As equipas do mesmo produto precisam de uma Definition of Done comum e de verificar que as partes funcionam juntas. Uma norma organizacional aplicável é um mínimo; a dificuldade de executar um teste pode justificar melhoria da ferramenta ou uma fatia menor, não a sua dispensa unilateral. Distingue também qualidade e autorização de release. Num cenário em que a Definition of Done está cumprida mas a aprovação de mudança continua pendente, comunica as duas condições. A Sprint Review não cria um gate obrigatório de release, mas esta regra não elimina os controlos externos aplicáveis. Não inventes um procedimento BNP Paribas a partir do exemplo: os critérios, autoridades e dados aqui apresentados são fictícios e servem para praticar a decisão.
Negociar uma fatia e esclarecer incerteza
No segundo exemplo, o Product Owner quer uma melhoria em três dias e os Developers estimam seis. A diferença inclui uma regra de exceção ainda desconhecida. O Scrum Master não deve escolher quatro dias para encerrar a conversa. Facilita o acesso ao interlocutor que conhece a regra, identifica o trabalho dependente da resposta e ajuda a discutir uma fatia menor. O Product Owner pode esclarecer resultados e compromissos; os Developers que executam dimensionam o trabalho. Refinement pode ocorrer quando a aprendizagem é útil, sem esperar pela próxima sessão habitual. Uma fatia completa de um tipo de pagamento permite observar utilização mais cedo do que interfaces de dez tipos ainda sem integração. Especialistas podem colaborar sem que cada pessoa domine todos os componentes. Inclui APS na análise do comportamento em produção: uma passagem administrativa não elimina a necessidade de aprender com defeitos recorrentes nem dá ao facilitador autoridade para mudar escalas de suporte.
Oficina de integração Atlas
Organiza um ensaio de 30 minutos com Product Owner, representantes das duas equipas, APS e observador. Usa apenas o caso fictício do saldo duplicado. Dedica cinco minutos a definir produto, utilizador e objetivo. Nos dez seguintes, cada equipa revela os seus critérios locais e o grupo identifica a falha de integração. Usa dez minutos para desenhar uma fatia completa, evidência de qualidade, dependências e decisão de release ainda pendente. Reserva cinco minutos para debrief. Entrega uma folha com o objetivo comum, critérios, verificação necessária, questões por esclarecer e respetivos responsáveis. O observador regista se os participantes distinguiram testes locais de utilização conjunta, mantiveram o mínimo aplicável e respeitaram as responsabilidades. Usa “não observado”, “observado com ajuda” ou “observado no ensaio sem ajuda” para cada comportamento. Não somes classificações para atribuir uma certificação. O guião está preparado, mas ainda não foi executado com participantes humanos.
GUIÃO ATLAS | 30 min: 5 + 10 + 10 + 5
Produto e utilizador:
Objetivo comum:
Fatia completa proposta:
Critérios de qualidade aplicáveis:
Evidência local disponível:
Evidência integrada necessária:
Regra ou dependência por esclarecer / responsável:
Estado Done:
Autorização de release / autoridade:
Observação por comportamento: não observado | com ajuda | no ensaio sem ajuda
Próxima ação / responsável / revisão:API e interface passam isoladamente, mas um evento repetido duplica o saldo. A evidência útil é o resultado do fluxo integrado com a correção e os critérios comuns.
Armadilhas comuns
Componentes concluídos como produto utilizável; estimativa imposta pelo prazo; objetivos concorrentes ocultos; Done como autorização automática de release.
Tópicos relacionados: Product Goal e Sprint Goal · Definition of Done · Colaboração com operação
A coordenação deve produzir uma fatia utilizável com qualidade demonstrável e decisões atribuídas a quem tem responsabilidade por elas.
Referência: The Scrum Guide · Scrum Guide November2020; Kanban Guide May2025; EBM May2024; primary guidance reviewed 2026-09-30