Cerim\u00f4nias do Scrum: um guia completo para todos os 5 eventos

$Equipe ilustrada de desenvolvedores reunidos em torno de um quadro scrum com sticky notes, progredindo por diferentes formatos de reuni\u00e3o em um espa\u00e7o de trabalho \u00e1gil e colorido$ Equipe ilustrada de desenvolvedores reunidos em torno de um quadro scrum com sticky notes, progredindo por diferentes formatos de reuni\u00e3o em um espa\u00e7o de trabalho \u00e1gil e colorido O Scrum define exatamente cinco eventos. N\u00e3o quatro, n\u00e3o seis. Cada um existe por uma raz\u00e3o espec\u00edfica, e pular qualquer um deles deixa uma lacuna no ciclo de feedback que faz o Scrum funcionar. Aqui est\u00e1 para que serve cada evento, quem participa, quanto tempo dura e os erros que silenciosamente prejudicam as equipes.

O Sprint

O Sprint \u00e9 o cont\u00eainer para todo o resto. Todos os outros eventos scrum acontecem dentro de um Sprint. \u00c9 um timebox fixo, geralmente de uma a quatro semanas, onde a equipe constr\u00f3i um incremento potencialmente entreg\u00e1vel do produto. Detalhes principais:

Dura\u00e7\u00e3o: 1-4 semanas (2 semanas \u00e9 o mais comum)
Quem participa: Todo o time Scrum
Resultado: Um incremento pronto

Sprints n\u00e3o s\u00e3o estendidos. Se a equipe n\u00e3o conseguir terminar tudo, os itens voltam para o backlog. Essa restri\u00e7\u00e3o \u00e9 o ponto. Ela for\u00e7a conversas dif\u00edceis sobre escopo e prioridade mais cedo, em vez de deixar prazos escorregarem silenciosamente. Sprints mais curtos (uma ou duas semanas) reduzem o risco porque voc\u00ea recebe feedback mais r\u00e1pido. Sprints mais longos d\u00e3o mais espa\u00e7o para trabalho complexo. A maioria das equipes opta por duas semanas e nunca muda.

Quando encurtar o seu Sprint

Se sua equipe consistentemente leva trabalho inacabado para o pr\u00f3ximo Sprint, tente sprints mais curtos. \u00c9 mais f\u00e1cil planejar com precis\u00e3o para uma semana do que para quatro, e voc\u00ea detectar\u00e1 problemas de escopo mais cedo.

Sprint Planning

O Sprint Planning d\u00e1 in\u00edcio a cada Sprint. A equipe decide o que construir e como construir. Detalhes principais:

Timebox: At\u00e9 8 horas para um Sprint de 4 semanas (reduza proporcionalmente, ent\u00e3o ~2 horas para um Sprint de 2 semanas)
Quem participa: Product Owner, Scrum Master, Time de Desenvolvimento
Resultado: O objetivo do Sprint e o Sprint Backlog

A reuni\u00e3o tem duas partes. Primeiro, o Product Owner apresenta os itens de maior prioridade do backlog e a equipe discute o que \u00e9 alcan\u00e7\u00e1vel. Segundo, os desenvolvedores dividem esses itens em tarefas e definem a abordagem. O objetivo do Sprint importa mais do que os itens individuais. Ele d\u00e1 \u00e0 equipe dire\u00e7\u00e3o e flexibilidade para negociar escopo se surpresas surgirem no meio do Sprint.

Como o Planning Poker se encaixa

Muitas equipes usam o Planning Poker durante ou antes do Sprint Planning para estimar itens do backlog. Cada membro da equipe estima story points de forma independente, e ent\u00e3o o grupo discute quaisquer diferen\u00e7as grandes. Isso exp\u00f5e suposic\u00f5es e mal-entendidos antes do trabalho come\u00e7ar. Saiba mais sobre como o Planning Poker funciona e as escalas de story points que as equipes usam.

Erro comum

N\u00e3o deixe o Sprint Planning se tornar uma sess\u00e3o de refinamento do backlog. Os itens j\u00e1 devem estar refinados e estimados antes de entrarem no planejamento. Se metade da reuni\u00e3o \u00e9 gasta esclarecendo requisitos, seu processo de refinamento precisa de melhorias.

Daily Scrum

A Daily Scrum (ou daily standup) \u00e9 uma sincroniza\u00e7\u00e3o de 15 minutos para o time de desenvolvimento. N\u00e3o \u00e9 um relat\u00f3rio de status para a gest\u00e3o. Detalhes principais:

Timebox: 15 minutos, mesmo hor\u00e1rio e local todos os dias
Quem participa: Time de Desenvolvimento (Scrum Master facilita se necess\u00e1rio, Product Owner opcional)
Resultado: Entendimento compartilhado do progresso e impedimentos

O formato cl\u00e1ssico s\u00e3o tr\u00eas perguntas: O que eu fiz ontem? O que vou fazer hoje? O que est\u00e1 me bloqueando? Mas esse formato pode ficar repetitivo. Algumas equipes percorrem o quadro, focando nos tickets em vez das pessoas. Outras usam formatos ass\u00edncronos para equipes distribu\u00eddas. A Daily Scrum existe para ajudar os desenvolvedores a se coordenarem. Se algu\u00e9m est\u00e1 travado, a equipe resolve junto. Se duas pessoas est\u00e3o prestes a trabalhar em altera\u00e7\u00f5es conflitantes, elas descobrem aqui em vez de em um conflito de merge.

A alternativa do standup ass\u00edncrono

Para equipes remotas e distribu\u00eddas, standups ass\u00edncronos est\u00e3o substituindo a reuni\u00e3o matinal tradicional. Os membros da equipe publicam suas atualiza\u00e7\u00f5es no pr\u00f3prio ritmo, e toda a equipe se mant\u00e9m informada sem lutar contra diferen\u00e7as de fuso hor\u00e1rio. Se voc\u00ea optar pelo ass\u00edncrono, escrever atualiza\u00e7\u00f5es que as pessoas realmente leiam \u00e9 uma habilidade que vale a pena desenvolver. Confira como escrever atualiza\u00e7\u00f5es de standup que s\u00e3o lidas. $Ilustra\u00e7\u00e3o em tela dividida mostrando um c\u00edrculo de standup tradicional de um lado e membros da equipe postando atualiza\u00e7\u00f5es ass\u00edncronas de diferentes locais do outro, conectados por linhas fluidas$ Ilustra\u00e7\u00e3o em tela dividida mostrando um c\u00edrculo de standup tradicional de um lado e membros da equipe postando atualiza\u00e7\u00f5es ass\u00edncronas de diferentes locais do outro, conectados por linhas fluidas

Sprint Review

A Sprint Review acontece no final do Sprint. A equipe demonstra o que construiu para os stakeholders e coleta feedback. Detalhes principais:

Timebox: At\u00e9 4 horas para um Sprint de 4 semanas (~1-2 horas para um Sprint de 2 semanas)
Quem participa: Time Scrum + stakeholders (usu\u00e1rios, gest\u00e3o, outros times)
Resultado: Feedback sobre o incremento, Product Backlog atualizado

Isso n\u00e3o \u00e9 uma apresenta\u00e7\u00e3o formal. \u00c9 uma sess\u00e3o de trabalho onde os stakeholders usam o produto real, fazem perguntas e dizem o que acham que deveria mudar. O Product Owner usa esse feedback para ajustar o backlog. Equipes que pulam ou fazem Sprint Reviews de qualquer jeito tendem a se afastar do que os usu\u00e1rios realmente precisam. Voc\u00ea pode planejar no v\u00e1cuo por apenas algum tempo antes de construir a coisa errada.

Sprint Review vs. Sprint Demo

As pessoas usam esses termos de forma intercambi\u00e1vel, mas o Scrum Guide descreve uma sess\u00e3o de trabalho colaborativa, n\u00e3o uma demonstra\u00e7\u00e3o unilateral. A diferen\u00e7a importa. Uma demo \u00e9 passiva. Uma review \u00e9 interativa. Os stakeholders devem sair com opini\u00f5es, e a equipe deve sair com informa\u00e7\u00f5es sobre as quais possam agir.

Quem deveria estar presente?

Convide qualquer pessoa que se importa com o produto. L\u00edderes de engenharia, designers, sucesso do cliente, at\u00e9 mesmo clientes reais, se poss\u00edvel. Quanto mais diverso o feedback, melhor ser\u00e1 o pr\u00f3ximo Sprint.

Sprint Retrospective

A retrospectiva \u00e9 onde a equipe inspeciona a si mesma. O que foi bem? O que n\u00e3o foi? O que deveria mudar? \u00c9 o \u00fanico evento focado inteiramente em como a equipe trabalha, e n\u00e3o no que est\u00e1 construindo. Detalhes principais:

Timebox: At\u00e9 3 horas para um Sprint de 4 semanas (~90 minutos para um Sprint de 2 semanas)
Quem participa: Scrum Master, Time de Desenvolvimento (Product Owner opcional, mas recomendado)
Resultado: Itens de a\u00e7\u00e3o para o pr\u00f3ximo Sprint

Uma boa retro produz um ou dois itens de a\u00e7\u00e3o concretos. N\u00e3o uma lista de desejos. N\u00e3o compromissos vagos como "comunicar melhor". Mudan\u00e7as espec\u00edficas, atribu\u00edveis, que a equipe realmente executa. Para um aprofundamento, veja nosso guia para conduzir uma retrospectiva eficaz. Se suas retros parecem repetitivas, tente variar o formato com ideias novas para retrospectivas ou comece com perguntas quebra-gelo para aquecer as pessoas antes da discuss\u00e3o real. $Equipe ilustrada sentada em c\u00edrculo com bal\u00f5es de pensamento contendo marcas de verifica\u00e7\u00e3o verdes e bandeiras vermelhas, votando em sticky notes em um quadro$ Equipe ilustrada sentada em c\u00edrculo com bal\u00f5es de pensamento contendo marcas de verifica\u00e7\u00e3o verdes e bandeiras vermelhas, votando em sticky notes em um quadro

Tornando as retros seguras

As retrospectivas s\u00f3 funcionam quando as pessoas se sentem seguras para serem honestas. Feedback an\u00f4nimo e vota\u00e7\u00e3o ajudam. Assim como estabelecer regras no in\u00edcio: sem culpa, sem interrup\u00e7\u00f5es, todas as perspectivas s\u00e3o bem-vindas. Se os membros da equipe se seguram, a retro se torna uma formalidade em vez de uma ferramenta. Os quadros de retrospectiva do Kollabe suportam submiss\u00f5es e vota\u00e7\u00f5es an\u00f4nimas por padr\u00e3o, o que ajuda membros mais quietos a contribuir sem press\u00e3o.

Acompanhe seus itens de a\u00e7\u00e3o

O maior assassino de retros \u00e9 nunca dar seguimento aos itens de a\u00e7\u00e3o. Escolha uma ou duas mudan\u00e7as por Sprint e atribua uma pessoa espec\u00edfica para cada. Revise as a\u00e7\u00f5es do Sprint anterior no in\u00edcio de cada retro.

Como os cinco eventos se conectam

Esses eventos n\u00e3o s\u00e3o reuni\u00f5es isoladas. Eles formam um ciclo:

Evento	Entrada	Sa\u00edda
Sprint Planning	Backlog refinado, feedback anterior	Objetivo do Sprint + Sprint Backlog
Daily Scrum	Progresso de ontem, plano de hoje	Coordena\u00e7\u00e3o, resolu\u00e7\u00e3o de impedimentos
Sprint Review	Incremento pronto	Feedback dos stakeholders, atualiza\u00e7\u00f5es do backlog
Sprint Retrospective	Observa\u00e7\u00f5es da equipe	Melhorias de processo
Sprint	Tudo acima	Incremento entreg\u00e1vel

O feedback da Sprint Review flui para a prioriza\u00e7\u00e3o do backlog. Os itens de a\u00e7\u00e3o da retrospectiva mudam como o pr\u00f3ximo Sprint funciona. As Daily Scrums revelam problemas que s\u00e3o resolvidos no mesmo dia. Remova qualquer evento e o ciclo se quebra.

Erros comuns em todas as cerim\u00f4nias

\ud83d\ude34Fazer por fazer

Realizar eventos porque o Scrum manda, sem engajamento genu\u00edno. Se ningu\u00e9m est\u00e1 prestando aten\u00e7\u00e3o, a reuni\u00e3o \u00e9 desperd\u00edcio.

\u23f0Ignorar os timeboxes

Uma standup de 15 minutos que dura 45 minutos n\u00e3o \u00e9 uma standup. Timeboxes existem para for\u00e7ar o foco. Use um cron\u00f4metro.

\ud83d\udeabPular eventos quando est\u00e1 ocupado

O Sprint em que voc\u00ea "n\u00e3o tem tempo para uma retro" \u00e9 o Sprint que mais precisava de uma.

\ud83d\udc65P\u00fablico errado

Stakeholders na Daily Scrum, desenvolvedores ausentes na Sprint Review. Cada evento tem um p\u00fablico definido por uma raz\u00e3o. Veja nosso guia sobre quem deve participar de uma retrospectiva.

Refer\u00eancia r\u00e1pida

Evento	Timebox (Sprint de 2 semanas)	Participantes	Frequ\u00eancia
Sprint	2 semanas	Todo o time Scrum	Cont\u00ednuo
Sprint Planning	~2 horas	PO, SM, Time de Dev	In\u00edcio do Sprint
Daily Scrum	15 minutos	Time de Dev	Todos os dias
Sprint Review	~1-2 horas	Time Scrum + stakeholders	Final do Sprint
Sprint Retrospective	~90 minutos	SM, Time de Dev, PO (opcional)	Final do Sprint, ap\u00f3s a review

Conclus\u00e3o

As cerim\u00f4nias do Scrum funcionam como um sistema. Cada evento alimenta o pr\u00f3ximo, e juntos criam um ciclo de planejar, construir, receber feedback e ajustar. Entenda cada um individualmente, mas preste aten\u00e7\u00e3o em como eles se conectam. Se voc\u00ea quer ferramentas melhores para suas cerim\u00f4nias, o Kollabe cuida de estima\u00e7\u00e3o, retrospectivas e standups em um s\u00f3 lugar.

Sim. O Scrum Guide usa "eventos" como o termo oficial, mas "cerim\u00f4nias" \u00e9 amplamente utilizado na pr\u00e1tica. Eles se referem \u00e0s mesmas cinco atividades: o Sprint, Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospective.

Cada evento tem um papel espec\u00edfico no ciclo de inspecionar e adaptar. Pule as Sprint Reviews e voc\u00ea constr\u00f3i a coisa errada. Pule as retros e problemas de processo nunca s\u00e3o corrigidos. Pule o planejamento e ningu\u00e9m concorda com o objetivo. Eles funcionam como um conjunto.

A Daily Scrum \u00e9 a mais f\u00e1cil de tornar ass\u00edncrona, especialmente para equipes distribu\u00eddas. Sprint Planning e retrospectivas se beneficiam de discuss\u00e3o em tempo real, mas podem usar abordagens h\u00edbridas onde o input \u00e9 coletado de forma ass\u00edncrona e as decis\u00f5es s\u00e3o tomadas de forma s\u00edncrona. Sprint Reviews s\u00e3o as mais dif\u00edceis de fazer de forma ass\u00edncrona, j\u00e1 que o feedback ao vivo \u00e9 o objetivo principal.

Organiza\u00e7\u00f5es maiores que usam frameworks como SAFe ou LeSS adicionam eventos de coordena\u00e7\u00e3o al\u00e9m dos cinco principais. Mas no n\u00edvel do time individual, as cerim\u00f4nias permanecem as mesmas. Cada time Scrum (idealmente 3-9 pessoas) conduz seu pr\u00f3prio conjunto de eventos independentemente do tamanho da empresa.

Última atualização em 09/02/2026