O que é Scrum: sprint, papéis e burndown na prática.

Scrum é uma estrutura de trabalho para equipes que precisam entregar resultado em ciclos curtos, aprendendo a cada entrega. O time trabalha em períodos de duração fixa, chamados sprints. No começo de cada um, escolhe o que vai fazer; no fim, mostra o que ficou pronto e discute como melhorar. Tudo isso com poucos papéis, poucas reuniões e três listas bem definidas.

Este guia explica as peças do Scrum na ordem em que elas aparecem na rotina: valores, papéis, eventos, artefatos, a diferença entre épico, user story e tarefa, estimativa por pontos, velocidade e burndown. No fim, mostra como adaptar o método para equipes fora da tecnologia e como aplicar tudo na Tasskee.

O que é Scrum e de onde ele vem

O nome foi tirado do rúgbi: a formação em que o time inteiro empurra junto para ganhar a bola. A comparação aparece em um artigo de 1986, de Hirotaka Takeuchi e Ikujiro Nonaka, publicado na Harvard Business Review, que descrevia equipes de desenvolvimento de produtos trabalhando de forma integrada, em vez de passar o trabalho de setor em setor como numa corrida de revezamento.

Ken Schwaber e Jeff Sutherland formalizaram o Scrum para software na década de 1990, e o apresentaram publicamente em 1995. Desde então, o método é descrito no Guia do Scrum, um documento curto, gratuito e atualizado de tempos em tempos. A versão de 2020, que serve de base para este texto, tornou o guia ainda mais enxuto.

Um ponto que o próprio guia faz questão de dizer: Scrum é uma estrutura, não um processo completo. Ele define as regras do jogo, mas deixa para o time decidir como trabalhar dentro delas. Isso explica por que dois times de Scrum podem parecer muito diferentes de fora.

Os três pilares e os cinco valores

O Scrum se apoia na ideia de que o trabalho complexo não se planeja inteiro de antemão: aprende-se fazendo. Por isso há três pilares.

• Transparência. O trabalho e o andamento precisam estar visíveis para quem é afetado por eles. Se o status real vive na cabeça de uma pessoa, não há o que inspecionar.
• Inspeção. Em intervalos regulares, o time olha o que foi feito e o quanto se avançou em direção ao objetivo.
• Adaptação. Se a inspeção mostra que algo saiu do rumo, o time ajusta o que precisa ser ajustado, logo.

Os cinco valores descrevem o comportamento que faz isso funcionar: compromisso, foco, abertura, respeito e coragem. Na prática, eles se traduzem em coisas concretas: o time se compromete com o objetivo da sprint, concentra-se nele, fala abertamente dos problemas, respeita a opinião dos colegas e tem coragem de dizer "isso não cabe".

Os papéis do time Scrum

O Scrum tem três papéis, todos dentro de um único time. Não existe hierarquia entre eles: o time é pequeno, em geral de poucas pessoas, e responde coletivamente pelo resultado.

Product Owner

É quem responde pelo valor do produto e pelo product backlog, a lista de tudo o que se pretende fazer. Decide o que vem primeiro e por quê. Fala com clientes, diretoria e áreas internas, e leva as necessidades deles para o time em forma de itens priorizados. É uma pessoa, não um comitê: alguém precisa ter a palavra final sobre a ordem do backlog, senão tudo vira prioridade.

Scrum Master

É quem cuida para que o Scrum seja entendido e praticado. Não é gerente do time nem "o chefe da reunião". Ajuda o time a remover impedimentos, facilita os eventos quando necessário, protege o time de interrupções e ensina a organização a trabalhar com o método. Quando o time amadurece, o trabalho do Scrum Master diminui, e isso é bom sinal.

Desenvolvedores

É quem faz o trabalho de entregar o incremento. O nome é tirado do contexto de software, mas se refere a qualquer pessoa que produz o item: um designer, uma redatora, um analista, uma engenheira. O time é autogerenciado, ou seja, decide internamente quem faz o quê e como.

E o gerente de projeto?

Esse cargo não aparece no Scrum. Suas funções são distribuídas: o Product Owner cuida da prioridade e do valor, o time organiza a execução, e o Scrum Master cuida do processo. Em empresas que adotam Scrum sem mudar a estrutura, o gerente costuma assumir um desses papéis ou passa a cuidar da carteira de projetos e do relacionamento com a diretoria.

Os cinco eventos do Scrum

Eventos existem para criar ritmo e dar oportunidade de inspecionar e adaptar. Os tempos abaixo são limites máximos do Guia do Scrum para uma sprint de um mês; para sprints mais curtas, os eventos costumam ser proporcionalmente menores.

A sprint

É o coração do método: um período de duração fixa, no máximo um mês, em que um incremento utilizável é produzido. Durante a sprint, o objetivo não é alterado, a qualidade não é reduzida, e o escopo pode ser renegociado entre o Product Owner e o time conforme se aprende mais. Duração constante é uma regra prática importante: sprints de tamanhos diferentes tornam impossível comparar a velocidade de um ciclo com a de outro.

O planejamento

Responde a três perguntas: por que esta sprint é valiosa (o objetivo da sprint), o que pode ser feito (os itens escolhidos do backlog) e como o trabalho será realizado (a divisão em tarefas). O Product Owner traz os itens mais importantes; o time diz quanto acredita que cabe, com base na velocidade dos ciclos anteriores.

A reunião diária

São 15 minutos, no mesmo horário e lugar, para o time ajustar o plano das próximas 24 horas. O formato das três perguntas (o que fiz ontem, o que farei hoje, o que me impede) é uma convenção antiga; o guia atual deixa o formato livre, desde que o foco seja o objetivo da sprint. Uma boa diária não é relatório para o chefe: é o time conversando entre si diante do quadro.

A revisão

Não é uma apresentação formal. É uma conversa em que o time mostra o que ficou pronto, e as pessoas interessadas (cliente, diretoria, outras áreas) opinam. O resultado alimenta o backlog: itens novos, itens descartados, prioridades revistas.

A retrospectiva

Foco no processo, não no produto. O time responde ao que funcionou, ao que atrapalhou e ao que vai mudar na próxima sprint. O critério de qualidade é simples: sai com uma ou duas ações concretas, com responsável, e a retrospectiva seguinte começa verificando se elas foram feitas. Retrospectiva que só gera desabafo vira reunião vazia.

Os artefatos e seus compromissos

Artefatos são as listas e os resultados que tornam o trabalho transparente. Cada um tem um compromisso associado, que serve para dar foco.

Product backlog

É a lista ordenada de tudo o que se sabe que o produto precisa. Nunca está "pronto": evolui conforme se aprende. Os itens do topo são pequenos e bem entendidos, porque serão feitos logo; os do fim são grandes e vagos, porque podem mudar até lá. O compromisso associado é o objetivo do produto, a meta de longo prazo contra a qual o backlog é medido.

O trabalho de manter o backlog em ordem se chama refinamento. Não é um evento obrigatório do Scrum, mas a maioria dos times reserva um horário semanal para quebrar itens grandes, esclarecer dúvidas e estimar.

Sprint backlog

É o que o time puxou do product backlog para a sprint, mais o plano de como fazer. Pertence aos desenvolvedores, que o atualizam durante a sprint. O compromisso é o objetivo da sprint: uma frase que explica por que o ciclo existe, como "permitir que o cliente pague com PIX no checkout". Se o escopo mudar durante o ciclo, o objetivo orienta o que ficar e o que sair.

Incremento

É o resultado concreto e utilizável da sprint, somado aos anteriores. Não é "uma parte do trabalho pela metade": é algo que poderia ser entregue. O compromisso é a definição de pronto.

Definição de pronto

É a lista de critérios que um item precisa cumprir para ser considerado concluído. Sem ela, "pronto" significa uma coisa para o desenvolvedor, outra para o Product Owner e uma terceira para o cliente. Exemplo de definição de pronto de uma agência de marketing: texto revisado por outra pessoa, arte aprovada pelo cliente, link conferido e peça agendada na ferramenta de publicação. Exemplo de uma equipe de software: código revisado, testes passando, documentação atualizada e implantado em ambiente de homologação.

Épico, user story e tarefa

Essas três palavras aparecem em todo backlog e causam confusão. A forma mais simples de entender é pensar em tamanhos. A seção a seguir resume a ideia; o post Épico, user story e tarefa aprofunda com mais exemplos.

Exemplo 1: loja virtual

A Casa do Café, loja virtual de Pouso Alegre, quer vender assinatura mensal.

• Épico: assinatura mensal de café.
• User stories: "Como cliente, quero escolher o tipo de grão e a frequência de entrega, para receber o café do jeito que gosto" e "Como cliente, quero pagar a assinatura por PIX ou cartão, para não depender de um só meio de pagamento".
• Tarefas da primeira história: desenhar a tela de escolha, criar o cadastro dos tipos de grão, programar o cálculo do frete, escrever os textos, testar no celular.

Exemplo 2: RH

O departamento de pessoas da Metalúrgica Serra Azul, em Sorocaba, quer melhorar a integração de novos funcionários.

• Épico: integração de novos colaboradores.
• User stories: "Como novo funcionário, quero receber o cronograma da primeira semana antes de começar, para saber o que esperar" e "Como gestor, quero um checklist de acessos e equipamentos, para o novo colega encontrar tudo pronto no primeiro dia".
• Tarefas da segunda história: levantar os acessos de cada área, montar o checklist, combinar o fluxo com a TI, publicar o modelo no sistema.

Como escrever uma boa história

O formato clássico é "Como [quem], quero [o quê], para [por quê]". Ele serve para forçar a pergunta sobre o valor: se você não consegue completar o "para", talvez o item seja uma tarefa disfarçada. Além do enunciado, uma história precisa de critérios de aceitação, que dizem quando ela está atendida. "O cliente consegue pagar com PIX e recebe o e-mail de confirmação em menos de um minuto" é um critério testável; "o pagamento funciona bem" não é.

Um teste útil de tamanho: se a história não cabe em uma sprint, ela é um épico e precisa ser dividida. Dividir por fatias verticais (uma versão simples que funciona de ponta a ponta) costuma ser melhor que dividir por camadas (só o banco de dados, depois só a tela).

Pontos e velocidade

O que são pontos de história

Pontos são uma medida relativa de esforço, complexidade e incerteza. Em vez de estimar em horas ("isso leva 6 horas"), o time compara itens entre si: "essa é duas vezes mais trabalhosa que aquela". As escalas mais usadas seguem a sequência de Fibonacci (1, 2, 3, 5, 8, 13), porque quanto maior o item, mais incerta a estimativa, e os saltos crescentes refletem isso.

A vantagem dos pontos é que eles não prometem precisão que não existe e não variam com quem executa. A desvantagem é que são um conceito abstrato para quem está de fora; fora da TI, muitos times preferem estimar em horas ou simplesmente contar o número de itens, desde que tenham o mesmo tamanho aproximado.

Planning poker, em uma linha

É uma técnica para estimar em grupo: cada pessoa escolhe, em segredo, uma carta com um valor, e todas viram ao mesmo tempo. Se os valores divergem muito, quem deu o maior e o menor explica o raciocínio, e o grupo vota de novo. O ganho está na conversa, não no número.

Velocidade

Velocidade é a soma dos pontos dos itens concluídos em uma sprint. Se o time fechou 21, 24 e 27 pontos nas últimas três sprints, a média é 24. Para o planejamento seguinte, o time puxa algo em torno de 24 pontos, e não os 40 que o otimismo sugere.

Três cuidados evitam o mau uso da velocidade:

• Só vale item concluído. Item 90% pronto conta zero. Isso incentiva terminar em vez de começar.
• Não compare times. Um ponto na equipe A não é um ponto na B. A velocidade serve para o próprio time prever.
• Não use como meta. Se a velocidade vira cobrança, o time infla as estimativas e o número perde o sentido.

Burndown: como ler o gráfico da sprint

O burndown mostra, dia a dia, quanto trabalho ainda falta na sprint. O eixo horizontal são os dias; o vertical é o trabalho restante (em pontos, horas ou número de itens). A linha ideal desce do total até zero no último dia; a linha real mostra o que de fato aconteceu.

• Linha real acima da ideal: o time está atrasado em relação ao plano.
• Linha real abaixo da ideal: está adiantado, e talvez dê para puxar mais algum item.
• Linha reta por vários dias seguida de queda brusca: o trabalho está sendo concluído em bloco no fim, sinal de itens grandes demais ou de quadro pouco atualizado.
• Linha que sobe: entrou escopo novo no meio da sprint.

O valor do gráfico está em avisar cedo. Na quarta-feira da primeira semana, ver a linha acima da ideal ainda dá tempo de tirar um item do escopo ou de pedir ajuda. O post Burndown: como ler traz exemplos de cada formato.

Scrum fora da TI

O mecanismo do Scrum, que é ciclo curto, backlog ordenado, revisão e retrospectiva, funciona em qualquer área. O que costuma dar errado é importar tudo de uma vez, com os nomes e a cerimônia. O post Sprints fora da TI trata disso com calma; aqui vai um resumo por área.

Em uma administradora de condomínios de Porto Alegre, por exemplo, a equipe de manutenção separou o trabalho em duas frentes: a fila de chamados do dia a dia segue em fluxo contínuo, e a quinzena é reservada para o que é planejado, como pintura da garagem, troca de lâmpadas por LED e revisão dos extintores. A reunião de início da quinzena escolhe os serviços; a de fim confere o que o síndico aprovou. Não há "Product Owner": a gerente de contratos prioriza. Funciona, e ninguém precisou decorar o vocabulário.

Erros comuns ao adotar Scrum

1. Mudar o escopo da sprint toda hora. Se tudo muda no meio do caminho, é fluxo contínuo, e talvez o Kanban sirva melhor.
2. Sprint sem objetivo. Sem uma frase que explique por que o ciclo existe, vira só uma lista de tarefas.
3. Product Owner sem poder de decisão. Se toda prioridade precisa de aprovação de três diretores, o backlog trava.
4. Scrum Master como gerente. Quando ele distribui tarefa e cobra, o time deixa de se autogerenciar.
5. Backlog como depósito. Duzentos itens que ninguém lê. Descarte o que não será feito.
6. Pronto sem definição. Sem critérios claros, o item volta como retrabalho na sprint seguinte.
7. Usar velocidade para cobrar. Ela existe para prever, não para pressionar.
8. Daily virar reunião de status. Todo mundo fala com o gerente, ninguém fala com o time.
9. Pular a retrospectiva. É onde o time melhora. Sem ela, os mesmos problemas se repetem a cada ciclo.
10. Sprint longa demais. Quanto maior o ciclo, mais tarde se descobre que saiu do rumo.
11. Estimar em pontos sem entender o conceito. Se o time não gosta de pontos, estime em horas ou conte itens.
12. Ignorar o que ficou de fora. Item que não terminou volta ao backlog e é reavaliado, em vez de ser empurrado automaticamente para a próxima sprint.

Como começar sua primeira sprint

1. Escolha a duração. Duas semanas é um bom padrão. Fixe e mantenha.
2. Reúna o backlog. Tudo em um único lugar, em ordem de prioridade, com os itens do topo bem descritos.
3. Defina quem prioriza e quem conduz. Quem é o Product Owner? Quem facilita o processo? Podem ser pessoas com outro cargo.
4. Escreva a definição de pronto. Três a cinco critérios bastam para começar.
5. Planeje com folga. Na primeira sprint, puxe cerca de 60% do que você acha que cabe. Estimar sem histórico é chute; o primeiro ciclo serve para criá-lo.
6. Faça a diária e atualize o quadro. Quinze minutos, mesmo horário.
7. Feche com revisão e retrospectiva. Sem elas, é só um calendário com nome bonito.

Depois de duas ou três sprints, a velocidade começa a ter significado, e o planejamento passa a se apoiar em dados. O modelo de backlog e sprint traz uma planilha preenchida para você adaptar.

Scrum e Kanban juntos

Muitos times usam os dois: o Scrum dá o ritmo (ciclos, planejamento, revisão), e o quadro Kanban mostra o andamento dentro da sprint, com limite de trabalho em andamento nas colunas do meio. O guia de Kanban explica o outro lado. Uma regra prática: se o seu trabalho é planejável em quinzenas, use sprints; se chega de forma imprevisível e precisa de resposta rápida, use fluxo contínuo; se é uma mistura, separe as duas frentes, como no exemplo da administradora de condomínios.

Como fazer na Tasskee

Os sprints da Tasskee cobrem o ciclo inteiro, do backlog ao relatório de fechamento. Eles fazem parte do plano Pro.

• Backlog. As tarefas que ainda não entraram em nenhum ciclo ficam no backlog, em ordem de prioridade.
• Planejamento do ciclo. Você puxa do backlog o que cabe na sprint, com estimativa e responsável, e fecha o escopo com todos vendo.
• Um sprint, vários projetos. O mesmo ciclo pode reunir tarefas de projetos diferentes, que é como muitos times trabalham de verdade.
• Quadro da sprint. As tarefas do ciclo aparecem no quadro Kanban, que pode ser agrupado por responsável, prioridade ou sprint.
• Burndown diário. Acompanhe o gráfico desde o primeiro dia e descubra no meio do ciclo, não na véspera, se vai dar tempo.
• Velocidade. A média dos ciclos anteriores serve de base para o planejamento seguinte.
• Relatório de fechamento. Mostra o que foi planejado, o que foi concluído e o que voltou para o backlog, sem apagar o histórico.
• Números de fluxo. Lead time, cycle time e fluxo cumulativo nos relatórios, para achar a etapa onde o trabalho trava.

Para o time começar com algo preenchido, use o modelo de backlog e sprint. E se os ciclos precisam empurrar objetivos maiores, ligue-os às metas do trimestre.