Os erros comuns no Scrum raramente aparecem como erro. Eles aparecem como adaptação: "aqui a Sprint é de três semanas, mas pode esticar", "o Product Owner é o comitê de diretores", "a retrospectiva a gente faz quando sobra tempo". Cada exceção parece razoável sozinha. Juntas, elas produzem um time que cumpre todos os ritos e não entrega mais valor do que antes.
O próprio Guia do Scrum avisa que o framework é imutável como conjunto: dá para implementar só partes dele, mas o resultado não é Scrum. Isso não quer dizer que o time não possa adaptar as práticas (técnicas de estimativa, formato da Daily, ferramentas). Quer dizer que papéis, eventos, artefatos e regras existem para garantir transparência, inspeção e adaptação, e tirar qualquer um deles enfraquece os três pilares.
Os erros abaixo estão organizados por onde aparecem (papéis, eventos, artefatos e organização), cada um com o sintoma que denuncia o problema, a causa que costuma estar por trás e a correção.
Formação relacionada
Papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
Por que os erros comuns no Scrum se repetem
Os mesmos desvios aparecem em empresas de setores muito diferentes porque nascem de poucas causas de fundo:
- Adoção pelo vocabulário. A empresa troca os nomes (reunião de acompanhamento vira Daily, gerente vira Scrum Master, cronograma vira backlog) e mantém o modelo de decisão. O comportamento antigo continua, agora com nome novo.
- Framework aprendido de segunda mão. Muita gente aprende Scrum com colegas, cursos rápidos ou ferramentas, e não com o Guia. Práticas opcionais viram regra (três perguntas, story points obrigatórios) e regras de verdade somem (Meta da Sprint, Definição de Pronto).
- Organização intocada. O time muda, mas orçamento, metas, contratos e aprovações continuam desenhados para projetos com escopo fechado. O time passa a carregar o atrito entre os dois mundos.
- Ausência de inspeção do próprio processo. Quando a retrospectiva enfraquece, o mecanismo que deveria corrigir os outros erros para de funcionar, e eles se acumulam.
Ter essas causas em mente ajuda a não tratar só o sintoma. Encurtar a Daily resolve pouco se ela continua sendo uma prestação de contas para a chefia.
Erros nos papéis
1. Product Owner sem autoridade (ou por comitê)
- Sintoma: o time espera dias por uma decisão; prioridades mudam depois de cada reunião de diretoria.
- Causa: a organização nomeou alguém para o papel, mas não transferiu o poder de decidir.
- Correção: o patrocinador precisa declarar, por escrito se necessário, que o Product Owner decide a ordem do backlog. Quem quiser mudar prioridade convence o Product Owner, como o Guia determina.
2. Product Owner ausente
- Sintoma: ele aparece na Sprint Planning e na Review; no meio da Sprint, ninguém consegue tirar dúvidas.
- Causa: o papel foi acumulado com outra função de tempo integral.
- Correção: negociar disponibilidade mínima (por exemplo, horários fixos diários para dúvidas) ou trocar a pessoa. Product Owner sem tempo gera itens mal refinados e retrabalho.
3. Scrum Master como gerente ou secretário
- Sintoma: ele distribui tarefas, cobra prazos ou só marca reuniões e atualiza o quadro.
- Causa: a empresa trocou o nome do cargo do gerente ou do analista sem mudar a atuação.
- Correção: voltar às três frentes do Guia (time, Product Owner, organização). Um teste prático: se o Scrum Master falta uma semana e o time para, ele está fazendo o trabalho do time.
Erros nos eventos
4. Sprint de duração variável
- Sintoma: "vamos estender a Sprint até quinta para terminar".
- Causa: a Sprint está sendo tratada como prazo de um pacote de escopo, e não como cadência.
- Correção: manter a duração fixa. O que não ficou pronto volta para o Product Backlog e o time descobre na retrospectiva por que superestimou a capacidade.
5. Sprint sem Meta da Sprint
- Sintoma: a Sprint Planning termina com uma lista de itens, e ninguém consegue dizer em uma frase por que a Sprint existe.
- Causa: o time aprendeu a selecionar itens, mas não a definir um objetivo.
- Correção: definir a meta antes de escolher os itens. Sem ela, não há critério para renegociar escopo quando surge um imprevisto.
6. Daily Scrum como relatório de status
- Sintoma: cada pessoa fala olhando para o gestor; a reunião passa de 15 minutos.
- Causa: a daily foi herdada de uma reunião de acompanhamento e mudou só de nome.
- Correção: centrar a conversa na Meta da Sprint e no quadro, não nas pessoas. O roteiro completo está em como conduzir a Daily Scrum.
7. Sprint Review como apresentação de slides
- Sintoma: o time mostra telas estáticas, os stakeholders aplaudem e o Product Backlog não muda.
- Causa: a Review é vista como prestação de contas, não como sessão de trabalho.
- Correção: mostrar o Incremento funcionando, deixar os usuários manusearem e terminar a reunião com o backlog revisado.
8. Retrospectiva sem mudança
- Sintoma: os mesmos problemas aparecem em todas as retrospectivas; o time desanima e começa a pular o evento.
- Causa: o time levanta dez melhorias e não implementa nenhuma.
- Correção: escolher uma ou duas ações, com responsável, e colocá-las no Sprint Backlog seguinte. Variar o formato ajuda a sair da rotina: veja dinâmicas de retrospectiva.
Erros nos artefatos
9. Definição de Pronto ausente ou com exceções
- Sintoma: "está pronto, só falta testar"; itens voltam com defeito Sprints depois.
- Causa: ninguém escreveu o que significa pronto, ou o time abre exceções para não "perder" pontos.
- Correção: escrever a Definição de Pronto e aplicá-la sem exceção. Item que não atende não entra no Incremento e volta para o Product Backlog.
10. Backlog como depósito de pedidos
- Sintoma: centenas de itens, sem ordem clara, muitos com mais de um ano.
- Causa: tudo o que alguém pediu entra no backlog e nada sai.
- Correção: arquivar o que não será feito nos próximos meses, ordenar o restante e refinar só o topo.
11. Velocidade como meta de desempenho
- Sintoma: a diretoria cobra aumento de pontos; os pontos inflam a cada Sprint.
- Causa: uma ferramenta de previsão virou indicador de produtividade.
- Correção: usar a velocidade só para planejar e prever, e medir o valor entregue com indicadores de resultado (adesão do usuário, redução de chamados, receita). O artigo sobre burndown e velocidade mostra o uso correto.
Erro na organização
12. Scrum no time, cascata em volta
- Sintoma: o time trabalha em Sprints, mas o orçamento é aprovado por escopo fechado, a homologação é feita por outra área três meses depois e o cronograma original continua sendo cobrado.
- Causa: a adoção ficou restrita ao time de desenvolvimento.
- Correção: levar os impedimentos organizacionais ao patrocinador e mudar as regras uma de cada vez. O artigo sobre como implementar Scrum traz uma tabela com os ajustes de governança mais comuns.
Como priorizar o que corrigir primeiro
Não tente corrigir tudo na mesma Sprint. Uma ordem que costuma funcionar:
- Product Owner com autoridade e tempo. Sem isso, nada mais se sustenta.
- Definição de Pronto aplicada. Garante que o que o time chama de entregue é de fato utilizável.
- Meta da Sprint em toda Sprint. Dá foco e critério de decisão.
- Retrospectiva com uma ação por Sprint. Cria o mecanismo que corrige o restante.
- Ajustes na organização. Os mais lentos, mas os que sustentam o resultado no longo prazo.
| Se você observa | Comece por |
|---|---|
| Time parado esperando decisões | Erros 1 e 2 |
| Muito retrabalho e defeitos | Erro 9 |
| Sprints sem foco, escopo trocado o tempo todo | Erros 4 e 5 |
| Reuniões longas e desmotivação | Erros 6 e 8 |
| Diretoria insatisfeita apesar do "ágil" | Erros 7, 11 e 12 |
Próximo passo
Leve esta lista para a próxima retrospectiva e peça para cada pessoa marcar, em silêncio, os três erros que mais reconhece no time. Os mais votados viram as primeiras ações. Para olhar além do framework e enxergar a saúde do projeto como um todo, o health check do projeto da Projeto Diário avalia escopo, prazo, custo, riscos, equipe e patrocínio em 20 perguntas e mostra onde agir primeiro. Para revisar os fundamentos que cada correção acima pressupõe, o guia completo de métodos ágeis e Scrum é o ponto de partida.
