Um guia aprofundado sobre o evento de 15 minutos dos Developers: inspecionar o progresso em direção ao Sprint Goal, adaptar o Sprint Backlog, escolher um formato eficaz, evitar o comportamento de reunião de status e usar o planejamento diário para fortalecer o autogerenciamento.
Tempo estimado de leitura: 25 minutos
Por João Ricardo Dutra••Artigo completo
Objetivo do capítulo
Ao final deste capítulo, você deverá compreender o propósito da , quem participa, por que o evento possui um de 15 minutos, como ele conecta o à adaptação diária, por que o formato é intencionalmente flexível, como evoluiu o antigo exemplo das três perguntas, o que o faz e não faz e como distinguir Daily Scrums eficazes de reuniões de status.
Introdução: quinze minutos para melhorar as próximas vinte e quatro horas
A não é valiosa simplesmente porque as pessoas conversam todos os dias. Ela é valiosa quando os saem com um plano melhor para alcançar o .
Entre todos os eventos do , a talvez seja o mais fácil de imitar e o mais fácil de compreender de forma equivocada. Um grupo se reúne todas as manhãs. Um a um, seus integrantes dizem o que fizeram ontem, o que farão hoje e se estão impedidos. Um ou gerente escuta. Quinze minutos depois, a reunião termina. A organização chama isso de .
Essa rotina pode parecer correta e, ainda assim, deixar de cumprir quase por completo o propósito do evento. O Scrum Guide atual define a como um evento de 15 minutos para os do , cujo propósito é inspecionar o progresso em direção ao e adaptar o conforme necessário, ajustando o trabalho planejado para o período seguinte. O evento trata de planejamento e autogerenciamento, e não de prestação de contas sobre atividades individuais.
Essa diferença é importante porque o trabalho complexo de produto muda todos os dias. Uma suposição técnica mostra-se incorreta. Um teste revela um risco. Uma dependência torna-se disponível. Um item selecionado deixa de ser necessário. Uma área do trabalho transforma-se em gargalo enquanto outra termina antes do esperado. Um plano criado na não consegue permanecer útil se os não o compararem repetidamente com a realidade.
A cria uma cadência diária mínima para essa comparação. Os observam o , inspecionam a situação atual da e decidem como organizar o próximo período de trabalho. Eles podem se concentrar coletivamente em um item difícil, alterar a sequência, deixar de iniciar novos trabalhos, pedir ajuda, renegociar escopo com o ou identificar uma discussão que precise continuar imediatamente após o evento.
Historicamente, a redação da evoluiu, embora seu propósito de tenha sido preservado. Versões anteriores do Scrum Guide incluíam um exemplo baseado em três perguntas. O Guide de 2017 dizia explicitamente que as equipes poderiam usar perguntas ou outro formato de discussão. O Guide de 2020 removeu o exemplo por completo e tornou ainda mais clara a liberdade de estrutura: os podem selecionar a estrutura e as técnicas que desejarem, desde que o evento se concentre no progresso em direção ao e produza um plano acionável para o dia seguinte.
Compreender essa evolução é especialmente útil na preparação para a . Muitas alternativas incorretas do exame descrevem hábitos conhecidos do ambiente de trabalho, e não o atual: o conduzindo a reunião, reportando status ao , rodadas obrigatórias das três perguntas, extensão do encontro para resolução detalhada de problemas ou tratamento da coleta de impedimentos como seu único propósito. Este capítulo desenvolve o raciocínio necessário para enxergar além desses padrões.
O propósito oficial da
A existe para inspecionar o progresso em direção ao e adaptar o conforme necessário, ajustando o trabalho planejado para o período seguinte. Cada palavra desse propósito é importante.
Inspecionar o progresso significa que os comparam a realidade atual com o objetivo da . Eles não precisam reportar cada tarefa nem descrever cada hora trabalhada. A pergunta relevante é se o estado atual do trabalho aumenta ou reduz a confiança em alcançar o .
Adaptar o significa que se espera que o plano mude. O não é um artefato congelado criado na . À medida que os aprendem mais, novos trabalhos podem surgir, trabalhos desnecessários podem desaparecer, a sequência pode mudar e as pessoas podem colaborar de maneira diferente.
Ajustar o trabalho planejado para o período seguinte torna a orientada para o futuro. O dia anterior só importa na medida em que fornece informações para a próxima decisão. Um histórico detalhado das atividades individuais que não modifica o plano da equipe costuma representar um uso de baixo valor do .
O evento, portanto, cria um ciclo diário de controle: -> evidências atuais -> plano revisado. É o do operando na menor cadência formal dentro da .
em uma frase
Inspecionar o progresso em direção ao -> adaptar o -> sair com um plano acionável para o dia seguinte.
Quem participa? A é para os
A é um evento de 15 minutos para os do . O evento existe para ajudar as pessoas que criam o a gerenciar seu trabalho; portanto, os são os participantes obrigatórios.
O e o não participam automaticamente na condição de e . Se qualquer um deles estiver trabalhando ativamente em itens do , participa como Developer para os fins do evento.
Essa distinção é sutil, mas importante. Um pode estar presente em muitas conversas colaborativas durante a , mas a não é uma revisão de status destinada ao . Um pode observar, orientar ou ajudar a remover uma interferência, mas o evento não é realizado para o .
Outras pessoas podem, ocasionalmente, estar por perto ou ser convidadas por um motivo específico, mas não devem transformar o evento em uma reunião de status mais ampla. O pode colaborar com stakeholders durante toda a ; a simplesmente possui propósito e público principal específicos.
O Guide atual também reforça o autogerenciamento ao deixar a estrutura do evento a cargo dos . A responsabilidade por realizar uma eficaz pertence aos , e não a um facilitador que seja permanentemente dono da pauta.
Âncora para a
A é para os . ou participam como somente quando estão trabalhando ativamente em itens do .
O de 15 minutos
A possui um de 15 minutos. Diferentemente da maioria dos outros eventos do , esse limite não se torna maior em uma de um mês nem menor, por regra, em uma mais curta. Ele permanece com duração máxima de 15 minutos porque o evento foi concebido para um planejamento diário focado.
Um é uma duração máxima, e não uma obrigação de consumir todos os minutos. Se os cumprirem o propósito em oito minutos, não precisam inventar sete minutos de conversa para preencher o tempo. Se o evento precisar constantemente de trinta minutos, a equipe deve inspecionar o motivo.
O impede que o evento se transforme em um workshop detalhado de resolução de problemas. Uma questão técnica pode exigir quarenta e cinco minutos de análise, mas nem todo Developer precisa participar dessa análise. A pode identificar o problema, decidir quem precisa continuar e transferir a conversa detalhada para imediatamente após o evento.
O mesmo princípio se aplica a debates de design, esclarecimentos com stakeholders, análise de incidentes e detalhes de backlog. A deve produzir um plano acionável. Conversas mais longas podem ocorrer a qualquer momento do dia entre as pessoas que delas necessitam.
Essa é outra forma pela qual o reduz a sobrecarga de reuniões. Daily Scrums podem eliminar a necessidade de outras reuniões de coordenação quando os as utilizam para tomar decisões rápidas e, em seguida, colaboram diretamente conforme necessário.
Mesmo horário e local: reduzindo a complexidade da coordenação
O Scrum Guide determina que a seja realizada no mesmo horário e local em todos os dias úteis da , a fim de reduzir a complexidade. O propósito é prático: os não deveriam precisar de outro processo de coordenação apenas para coordenar o próprio evento de coordenação.
Para equipes distribuídas, 'local' pode significar uma sala virtual ou espaço de colaboração consistente. O ponto importante é o acesso previsível, e não a exigência de um escritório físico.
O Guide não prescreve que o evento ocorra pela manhã, em pé ou presencialmente. A equipe pode realizá-lo em um horário compatível com suas necessidades de colaboração. '' é uma expressão comum no setor, mas permanecer em pé não é uma regra do , e o nome oficial do evento é .
O evento ocorre em todos os dias úteis da . Sua cadência existe porque aprendizagem e coordenação acontecem continuamente. As equipes devem ter cautela ao substituí-lo por reuniões de status menos frequentes simplesmente porque o não é discutido todos os dias.
O é o centro da conversa
A não é organizada em torno da utilização individual. Ela é organizada em torno do progresso em direção ao .
Essa mudança altera as perguntas feitas pelos . Em vez de 'Todos concluíram a tarefa atribuída ontem?', a equipe pergunta se o trabalho como um todo está avançando em direção ao objetivo. Um Developer que concluiu cinco tarefas pode ter contribuído menos para o objetivo do que uma dupla que passou um dia descobrindo que uma abordagem dispendiosa deveria ser abandonada.
Um significativo oferece aos um filtro para decisões. Se um item está bloqueado, a equipe deve se concentrar coletivamente nele ou iniciar outra coisa? Se uma tarefa de baixo valor está consumindo esforço enquanto um trabalho crítico permanece inacabado, ela deveria ser interrompida? Se uma descoberta muda o caminho técnico, qual plano preserva melhor o objetivo?
Sem um claro, a frequentemente se degrada em uma prestação de contas item por item, pois a equipe não possui um objetivo de nível mais alto contra o qual inspecionar o progresso. O evento torna-se um reflexo do trabalho fragmentado, e não um mecanismo de planejamento coletivo.
Por esse motivo, a qualidade das Daily Scrums frequentemente revela a qualidade da . Se os não conseguem explicar o que estão tentando alcançar juntos, nenhuma técnica de facilitação consegue compensar isso integralmente.
Adaptando o todos os dias
O é uma representação altamente visível e em tempo real do trabalho que os planejam realizar para alcançar o . A é um dos principais momentos para inspecionar se essa representação ainda é precisa.
A adaptação pode assumir muitas formas. Os podem adicionar uma tarefa técnica recém-descoberta, remover um trabalho que já não é necessário, dividir um item, alterar a sequência de implementação, reduzir o trabalho simultâneo, reorganizar o pareamento ou planejar uma conversa com o sobre escopo.
Os não precisam esperar pela para adaptar. O Scrum Guide observa explicitamente que eles costumam se reunir ao longo do dia para conversas mais detalhadas sobre adaptação ou replanejamento do restante do trabalho da . A cria um ponto de verificação diário mínimo, e não uma janela exclusiva de planejamento.
Uma equipe que atualiza mecanicamente um quadro, mas não muda seu comportamento, não está necessariamente se adaptando. O resultado importante é um plano melhor, independentemente de a mudança ser grande ou pequena.
Da mesma forma, adaptação não deve se transformar em troca aleatória de prioridades. O fornece o propósito estável. O muda a serviço desse objetivo.
Liberdade de formato: o prescreve o propósito, não o roteiro
Os podem selecionar qualquer estrutura e técnicas para a , desde que o evento se concentre no progresso em direção ao e produza um plano acionável para o dia seguinte.
Essa liberdade permite que o evento se adapte ao trabalho da equipe. Uma equipe pode percorrer um quadro de fluxo da direita para a esquerda, começando pelo trabalho mais próximo de Done. Outra pode inspecionar riscos ao . Outra pode discutir apenas os poucos itens que estão afetando o objetivo naquele momento. Uma equipe distribuída pode usar um quadro visual compartilhado e uma breve chamada de voz.
O formato deve servir ao propósito. Uma técnica que funcionou no passado pode tornar-se obsoleta. Se a equipe responde mecanicamente às mesmas perguntas todos os dias, os devem sentir-se livres para redesenhar a conversa.
O melhor formato não é o mais moderno. É aquele que ajuda os a compreender o progresso atual, tomar decisões e coordenar o dia seguinte com o mínimo de desperdício.
Formato possível
Como pode servir ao propósito
primeiro
Começar avaliando a confiança no , identificar as maiores ameaças ou oportunidades e, então, ajustar o plano.
Percorrer o quadro
Inspecionar primeiro o trabalho mais próximo de Done, discutir bloqueios e próximas ações e, depois, avançar para trás pelo trabalho ativo.
Baseado em riscos
Concentrar-se em incertezas, dependências, riscos de qualidade e decisões que possam afetar o .
Focado em fluxo
Inspecionar trabalho em andamento, itens envelhecidos, filas, gargalos e oportunidades de terminar antes de iniciar mais trabalho.
Perguntas clássicas
Usar as perguntas históricas somente se elas realmente melhorarem a coordenação e permanecerem centradas no .
As antigas três perguntas: história útil, não um requisito atual
O formato das três perguntas é uma das tradições mais persistentes do . Muitas equipes ainda acreditam que o exige que todo Developer responda a três perguntas em sequência.
O Scrum Guide de 2017 não exigia esse formato. Ele dizia explicitamente que o definia a estrutura da reunião e poderia conduzi-la de maneiras diferentes, desde que mantivesse o foco no progresso em direção ao . Em seguida, o Guide apresentava as perguntas apenas como exemplo.
O que fiz ontem que ajudou o a alcançar o ?
O que farei hoje para ajudar o a alcançar o ?
Vejo algum impedimento que impeça a mim ou ao de alcançar o ?
Essas perguntas já eram mais orientadas à equipe do que o antigo hábito de simplesmente reportar atividades pessoais. Ainda assim, muitas equipes as utilizavam como ritual: cada pessoa falava para o enquanto todos os demais aguardavam sua vez.
O Scrum Guide de 2020 removeu o exemplo por completo. A redação atual enfatiza a liberdade de estrutura e um resultado obrigatório: foco no e um plano acionável para o dia seguinte.
As três perguntas ainda podem ser úteis. Elas não são proibidas. Uma equipe nova pode considerá-las úteis enquanto aprende a se coordenar. O problema começa quando as perguntas se tornam a definição do evento, em vez de uma entre várias técnicas possíveis.
Distinção histórica para o exame
As três perguntas eram um exemplo no Guide de 2017. Elas não são prescritas no Scrum Guide de 2020.
Por que a não é uma reunião de status
Uma reunião de status existe principalmente para transferir informações a alguém que precisa exercer supervisão: um gerente, líder de projeto, cliente ou coordenador. A existe principalmente para que os possam o próprio plano.
Essa diferença muda a direção da comunicação. Em uma reunião de status, os indivíduos frequentemente falam para cima: 'Terminei isto. Estou trabalhando naquilo. Estou bloqueado por isto.' Em uma eficaz, os conversam entre si: 'Este item ameaça o . Podemos trabalhar juntos nele? Esta dependência agora está disponível. Vamos concluir a integração antes de iniciar o próximo item.'
Uma reunião de status pode terminar quando o gerente obtém informações suficientes. Uma deve terminar quando os possuem um plano útil para o dia seguinte.
O comportamento de status também enfraquece o autogerenciamento. Se o ou o gerente é dono das perguntas, acompanha compromissos individuais e posteriormente cobra tarefas não concluídas, os aprendem que a responsabilidade pelo planejamento está fora da equipe.
Isso não significa que informações de status sejam proibidas. Transparência é valiosa. Gerentes e stakeholders podem precisar de informações sobre o produto. Contudo, a não deve ser reaproveitada como mecanismo para coletá-las. O oferece transparência do , transparência do , Reviews, colaboração direta e outras formas de comunicação sem sacrificar o propósito da .
Dimensão
Reunião de status
Público principal
Gerente / coordenador / stakeholder
Propósito principal
Inspecionar o progresso em direção ao e adaptar o plano
Comunicar o status atual
Direção da conversa
Colaboração Developer para Developer
Relato individual ao gerente
Resultado típico
Plano acionável para o dia seguinte
Atualização da percepção da gestão
Responsabilidade
Normalmente, a pessoa que solicita o status
Efeito sobre o autogerenciamento
Fortalece-o quando é eficaz
Pode enfraquecê-lo quando usado para controle de tarefas
O papel do na
O é accountable por estabelecer o e ajudar o a melhorar sua efetividade. Isso não faz do o presidente da .
Os são responsáveis pela realização do evento. O pode ensinar o propósito, orientar os em direção ao autogerenciamento, ajudá-los a manter o evento dentro do de 15 minutos ou facilitar temporariamente quando a equipe precisar de apoio.
Um maduro trabalha para se tornar menos necessário na mecânica da . Se a equipe só consegue conduzir o evento quando o faz as perguntas, abre o quadro, chama os participantes, registra bloqueios e encerra a reunião, o autogerenciamento ainda não se desenvolveu plenamente.
O também pode ajudar com impedimentos, mas não deve transformar o evento em um workshop de resolução de impedimentos. Os identificam que algo ameaça o progresso; as pessoas necessárias para tratar o assunto podem colaborar imediatamente depois.
Quando participantes externos prejudicam o propósito, o pode orientar a organização e proteger o foco do evento. O objetivo de longo prazo é ampliar a compreensão, e não exercer policiamento permanente.
Antipadrão do
Se o é permanentemente dono da pauta da , coleta status individuais, atribui trabalhos de acompanhamento ou se torna a única pessoa capaz de conduzir o evento, está enfraquecendo o autogerenciamento.
Como é uma eficaz
Uma eficaz costuma ser concisa, orientada a objetivos e rica em decisões. As palavras exatas podem variar, mas alguns padrões são comuns.
Os conseguem declarar o e utilizá-lo como base para decisões.
A equipe discute o trabalho como um sistema compartilhado, e não como atribuições pessoais isoladas.
O muda quando novas informações exigem um plano diferente.
Os identificam gargalos e decidem quem ajudará a concluir o trabalho crítico.
Impedimentos tornam-se visíveis e a responsabilidade pelo acompanhamento fica clara.
A resolução detalhada de problemas é adiada para as pessoas relevantes após o evento de 15 minutos.
As pessoas conversam entre si em vez de reportar para cima.
O evento pode terminar antes quando seu propósito já foi alcançado.
O não é necessário para fazer a conversa acontecer.
A equipe sai sabendo o que mais importa para o próximo dia útil.
Como é uma ruim
Todos apresentam um status individual ao .
O nunca é mencionado nem utilizado nas decisões.
Os leem mecanicamente IDs de tickets, sem colaboração.
Um gerente pergunta por que estimativas não foram cumpridas e atribui tarefas corretivas.
O reprioriza trabalhos individuais durante a reunião.
A equipe passa 40 minutos depurando um único problema enquanto a maioria dos participantes espera.
Os mesmos bloqueios são reportados todos os dias sem um plano para tratá-los.
Os não têm permissão para alterar o sem aprovação.
A reunião é cancelada sempre que o está ausente.
O evento termina com informações trocadas, mas sem um plano melhorado.
Exemplo prático - uma para uma de confiabilidade de API
Imagine um responsável por melhorar uma plataforma de APIs utilizada por produtos de pagamento. O é reduzir falhas de autenticação durante picos de tráfego sem enfraquecer os controles de segurança.
Na , os fazem a de vários itens do e criam um contendo melhorias de testes de carga, trabalho de cache, alterações de observabilidade, validações de segurança e tarefas de rollout.
No quarto dia útil, os iniciam a revisando o e o fluxo atual. Um item de cache está tecnicamente concluído, mas aguarda um teste de segurança. Um item de dashboard de prioridade menor está em andamento. Um teste de carga revelou que o maior risco agora está em um timeout de dependência, e não no cache em si.
Em vez de fornecer relatos individuais, os discutem o significado das novas evidências. Eles decidem que duas pessoas que trabalham no dashboard irão interromper esse trabalho e ajudar a criar o ambiente de testes da dependência. O Developer com foco em segurança fará pareamento com o Developer responsável pelo cache imediatamente após a . O dashboard permanece no , mas deixa de ser a prioridade do dia.
Um Developer levanta uma questão detalhada sobre um algoritmo de retry. A equipe não passa quinze minutos resolvendo-a. Três pessoas relevantes concordam em continuar a discussão depois da .
O observa, mas não dirige a conversa. A própria equipe atualiza o . O não está presente porque não está trabalhando ativamente em itens do . Mais tarde, os entram em contato com o porque as novas evidências técnicas podem exigir a renegociação de um item selecionado do .
A termina após onze minutos. O resultado não é apenas conhecimento compartilhado: a equipe mudou quem irá colaborar, alterou a prioridade do trabalho, identificou uma discussão de acompanhamento e melhorou o plano para alcançar o .
Agora imagine o mesmo evento como uma reunião de status. Cada Developer lê as tarefas de ontem. O registra bloqueios. O gerente pergunta por que o dashboard está atrasado. Ninguém muda o plano. O timeout da dependência permanece sem tratamento até mais tarde. A reunião segue um ritual reconhecível, mas contribui pouco para o autogerenciamento ou para o sucesso da .
Antipadrões comuns da
Antipadrão
Por que enfraquece o evento
Relato em rodízio
As pessoas falam apenas quando são chamadas e se dirigem ao facilitador em vez de colaborar.
Recitação de tickets
O quadro é lido em voz alta sem decisões nem adaptação.
Inspeção pelo gerente
Um gerente avalia desempenho ou compromissos individuais.
Dependência do
O evento não consegue funcionar sem o .
Poço de resolução de problemas
Uma discussão técnica detalhada consome todo o .
Ausência de
A equipe coordena tarefas sem um objetivo compartilhado.
Nenhuma mudança no plano
O permanece inalterado mesmo quando as evidências mudam.
Somente coleta de impedimentos
A equipe reporta bloqueios, mas trata o como o único responsável por removê-los.
Três perguntas obrigatórias
O formato é seguido mesmo quando já não ajuda o planejamento.
Status para stakeholders
Participantes externos usam o evento para coletar relatos de progresso.
Atribuição diária de tarefas
Um líder ou decide quem trabalha em quê.
Pular porque 'nada mudou'
A equipe perde uma oportunidade regular de inspeção e pode normalizar um foco fraco no .
Armadilhas comuns da sobre a
Armadilha
Interpretação correta segundo o
A é para todo o .
Falso. É um evento de 15 minutos para os ; PO/SM participam como apenas se estiverem trabalhando ativamente em itens do .
O conduz a .
Falso. Os são responsáveis por conduzi-la.
O participa para receber status.
Falso. Relatar status não é o propósito do evento.
As três perguntas são obrigatórias.
Falso. Os escolhem a estrutura e as técnicas que alcançam o propósito.
A deve durar exatamente 15 minutos.
Falso. Quinze minutos é o limite máximo do ; ela pode terminar antes.
A serve apenas para identificar impedimentos.
Falso. Seu propósito é inspecionar o e adaptar o .
Os só podem alterar o durante a .
Falso. Eles podem adaptar o plano durante todo o dia.
A resolução detalhada de problemas deve acontecer durante a .
Em geral, falso. Discussões detalhadas podem ocorrer imediatamente depois com as pessoas relevantes.
Uma é bem-sucedida se todos apresentarem status.
Falso. O principal resultado é um plano acionável para o dia seguinte.
É obrigatório ficar em pé.
Falso. O não exige que os participantes permaneçam em pé.
O evento deve ocorrer logo no início da manhã.
Falso. Ele deve ocorrer no mesmo horário e local em todos os dias úteis para reduzir a complexidade.
Stakeholders podem participar e atribuir trabalho urgente.
Falso. A presença deles não deve alterar o propósito do evento nem o autogerenciamento dos .
Um framework de raciocínio para questões da sobre a
Propósito: a resposta inspeciona o progresso em direção ao e adapta o ?
Participantes: ela preserva o evento como uma atividade de 15 minutos dos ?
Autogerenciamento: os conduzem o evento e gerenciam o próprio plano?
: a conversa está focada no objetivo da , e não na atividade pessoal?
Resultado: a equipe sai com um plano acionável para o dia seguinte?
Formato: a resposta permite que os escolham a estrutura e as técnicas?
Três perguntas: elas são tratadas como técnica histórica opcional, e não como regra atual?
: ele está orientando e habilitando, em vez de presidir e coletar status?
Resolução de problemas: discussões detalhadas são movidas para fora do quando apenas um subconjunto de pessoas é necessário?
Adaptação contínua: a resposta permite que os replanejem a qualquer momento durante o dia?
Heurística rápida para o exame
Se a se parece com pessoas reportando para cima, provavelmente está errada. Se os estão planejando juntos em torno do , provavelmente está mais próxima do .
Conclusão: a é um ato diário de autogerenciamento
A é um evento pequeno com um propósito amplo. Em quinze minutos ou menos, os criam uma oportunidade regular de comparar o plano atual com a realidade e decidir como melhorar o próximo dia de trabalho.
Seu centro é o . Sem o objetivo, o evento facilmente se reduz a relatos individuais de tarefas. Com um objetivo significativo, os podem decidir se devem concentrar esforços coletivamente, alterar a sequência, remover trabalho desnecessário, buscar ajuda ou renegociar escopo.
O é o objeto prático da adaptação. Espera-se que evolua ao longo da , e a é uma cadência mínima e recorrente para tornar essa evolução deliberada e transparente.
A liberdade de formato é intencional. O não prescreve que os participantes fiquem em pé, usem um quadro específico, sigam uma ordem de fala ou façam as antigas três perguntas. O framework prescreve propósito e e, então, confia nos para selecionar técnicas que apoiem o autogerenciamento.
As três perguntas permanecem como parte útil da história e ainda podem ser uma prática útil, mas não são a definição do evento. O Scrum Guide atual as removeu justamente para reforçar que a deve ser orientada a resultados, e não a rituais.
O ajuda a equipe a compreender esse propósito e a desenvolver sua capacidade de conduzir o evento de forma eficaz, mas não é o dono da reunião. Uma que exige que o peça status todos os dias é sinal de que o autogerenciamento ainda precisa evoluir.
Na minha visão, as melhores Daily Scrums frequentemente se parecem menos com reuniões e mais com um breve reajuste tático. Os observam a realidade, tomam algumas decisões importantes e retornam ao trabalho com maior alinhamento. Esse é um padrão muito mais elevado do que simplesmente concluir quinze minutos de conversa - e é o padrão que um candidato à deve compreender.
Principais conclusões
O propósito da é inspecionar o progresso em direção ao e adaptar o conforme necessário.
A é um evento de 15 minutos para os .
e participam como somente se estiverem trabalhando ativamente em itens do .
O evento ocorre no mesmo horário e local em todos os dias úteis da para reduzir a complexidade.
O deve ser a referência central para inspeção e planejamento.
A deve produzir um plano acionável para o dia seguinte de trabalho.
Os escolhem a estrutura e as técnicas do evento.
As três perguntas históricas são opcionais e não são prescritas pelo Scrum Guide de 2020.
A não é uma reunião de status para o , o ou a gestão.
Os podem adaptar o a qualquer momento, e não apenas durante a .
A resolução detalhada de problemas pode continuar imediatamente após o evento com as pessoas relevantes.
O ensina e orienta sobre o propósito e o , mas não deve se tornar o presidente permanente do evento.
Boas Daily Scrums melhoram a comunicação, a tomada rápida de decisões, o foco e o autogerenciamento.
Questões da frequentemente testam antipadrões de reunião de status, o mito das três perguntas obrigatórias e a responsabilidade dos pelo evento.
