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

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

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

O que é Scrum e de onde vem

O nome foi buscar-se ao râguebi: a formação em que a equipa inteira empurra em conjunto para ganhar a bola. A comparação aparece num artigo de 1986, de Hirotaka Takeuchi e Ikujiro Nonaka, publicado na Harvard Business Review, que descrevia equipas de desenvolvimento de produtos a trabalhar de forma integrada, em vez de passarem o trabalho de setor em setor como numa corrida de estafetas.

Ken Schwaber e Jeff Sutherland formalizaram o Scrum para software na década de 1990 e apresentaram-no publicamente em 1995. Desde então, o método é descrito no Guia do Scrum, um documento curto, gratuito e atualizado de tempos a tempos. A versão de 2020, que serve de base a 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. Define as regras do jogo, mas deixa a cada equipa a decisão de como trabalhar dentro delas. Isto explica por que razão duas equipas de Scrum podem parecer muito diferentes vistas de fora.

Os três pilares e os cinco valores

O Scrum assenta na ideia de que o trabalho complexo não se planeia inteiro de antemão: aprende-se a fazer. Por isso há três pilares.

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

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

Os papéis da equipa Scrum

O Scrum tem três papéis, todos dentro de uma única equipa. Não existe hierarquia entre eles: a equipa é pequena, 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 porquê. Fala com clientes, administração e áreas internas, e leva as necessidades deles para a equipa sob a forma de itens priorizados. É uma pessoa, não um comité: alguém tem de ter a palavra final sobre a ordem do backlog, senão tudo passa a ser prioridade.

Scrum Master

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

Programadores

São quem faz o trabalho de entregar o incremento. O nome vem do contexto de software, mas refere-se a qualquer pessoa que produza o item: um designer, uma redatora, um analista, uma engenheira. A equipa é autogerida, ou seja, decide internamente quem faz o quê e como.

E o gestor de projeto?

Esse cargo não aparece no Scrum. As suas funções são distribuídas: o Product Owner cuida da prioridade e do valor, a equipa organiza a execução, e o Scrum Master cuida do processo. Nas empresas que adotam o Scrum sem mudar a estrutura, o gestor costuma assumir um destes papéis ou passa a cuidar da carteira de projetos e da relação com a administração.

Os cinco eventos do Scrum

Os 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 é produzido um incremento utilizável. Durante a sprint, o objetivo não é alterado, a qualidade não é reduzida, e o âmbito pode ser renegociado entre o Product Owner e a equipa à medida que se aprende mais. A 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 planeamento

Responde a três perguntas: por que razão 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; a equipa diz quanto acredita que cabe, com base na velocidade dos ciclos anteriores.

A reunião diária

São 15 minutos, à mesma hora e no mesmo local, para a equipa ajustar o plano das 24 horas seguintes. 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 é um relatório para o chefe: é a equipa a conversar entre si diante do quadro.

A revisão

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

A retrospetiva

O foco está no processo, não no produto. A equipa responde ao que funcionou, ao que atrapalhou e ao que vai mudar na próxima sprint. O critério de qualidade é simples: sai-se com uma ou duas ações concretas, com responsável, e a retrospetiva seguinte começa por verificar se foram feitas. Uma retrospetiva que só gera desabafos torna-se uma reunião vazia.

Os artefactos e os seus compromissos

Os artefactos 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á "pronta": evolui à medida que se aprende. Os itens do topo são pequenos e bem compreendidos, porque serão feitos em breve; 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 face à qual o backlog é medido.

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

Sprint backlog

É o que a equipa puxou do product backlog para a sprint, mais o plano de como fazer. Pertence aos programadores, que o atualizam durante a sprint. O compromisso é o objetivo da sprint: uma frase que explica por que razão o ciclo existe, como "permitir que o cliente pague com PIX no checkout". Se o âmbito mudar durante o ciclo, o objetivo orienta o que fica e o que sai.

Incremento

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

Definição de pronto

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

Épico, user story e tarefa

Estas três palavras aparecem em todos os backlogs e causam confusão. A forma mais simples de as entender é pensar em tamanhos. A secção seguinte resume a ideia; o artigo Épico, user story e tarefa aprofunda-a com mais exemplos.

Exemplo 1: loja online

A Casa do Café, loja online 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 único meio de pagamento".
• Tarefas da primeira história: desenhar o ecrã de escolha, criar o registo dos tipos de grão, programar o cálculo do frete, escrever os textos, testar no telemóvel.

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 uma 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 a 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 [porquê]". Serve para forçar a pergunta sobre o valor: se 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 está cumprida. "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 numa sprint, é um épico e tem de ser dividida. Dividir por fatias verticais (uma versão simples que funciona de ponta a ponta) costuma ser melhor do que dividir por camadas (só a base de dados, depois só o ecrã).

Pontos e velocidade

O que são pontos de história

Os pontos são uma medida relativa de esforço, complexidade e incerteza. Em vez de estimar em horas ("isto demora 6 horas"), a equipa compara itens entre si: "esta dá duas vezes mais trabalho do 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 não prometem uma precisão que não existe e não variam consoante quem executa. A desvantagem é que são um conceito abstrato para quem está de fora; fora da TI, muitas equipas preferem estimar em horas ou simplesmente contar o número de itens, desde que tenham aproximadamente o mesmo tamanho.

Planning poker, numa linha

É uma técnica para estimar em grupo: cada pessoa escolhe, em segredo, uma carta com um valor, e todas as 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

A velocidade é a soma dos pontos dos itens concluídos numa sprint. Se a equipa fechou 21, 24 e 27 pontos nas últimas três sprints, a média é 24. Para o planeamento seguinte, a equipa puxa qualquer coisa como 24 pontos, e não os 40 que o otimismo sugere.

Três cuidados evitam o mau uso da velocidade:

• Só conta item concluído. Um item 90% pronto vale zero. Isto incentiva a terminar em vez de começar.
• Não compare equipas. Um ponto na equipa A não é um ponto na B. A velocidade serve para a própria equipa prever.
• Não a use como meta. Se a velocidade passa a ser cobrança, a equipa 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 facto aconteceu.

• Linha real acima da ideal: a equipa está atrasada em relação ao plano.
• Linha real abaixo da ideal: está adiantada, e talvez seja possível puxar mais algum item.
• Linha reta durante vários dias seguida de queda brusca: o trabalho está a ser concluído em bloco no fim, sinal de itens grandes demais ou de um quadro pouco atualizado.
• Linha que sobe: entrou âmbito novo a 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 âmbito ou de pedir ajuda. O artigo Burndown: como ler traz exemplos de cada formato.

Scrum fora da TI

O mecanismo do Scrum, que é ciclo curto, backlog ordenado, revisão e retrospetiva, funciona em qualquer área. O que costuma correr mal é importar tudo de uma vez, com os nomes e a cerimónia. O artigo Sprints fora da TI trata disso com calma; aqui fica um resumo por área.

Numa administradora de condomínios de Porto Alegre, por exemplo, a equipa de manutenção separou o trabalho em duas frentes: a fila de pedidos do dia a dia segue em fluxo contínuo, e a quinzena é reservada para o que é planeado, 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 administrador do condomínio aprovou. Não há "Product Owner": a gestora de contratos prioriza. Funciona, e ninguém precisou de decorar o vocabulário.

Erros comuns ao adotar o Scrum

1. Mudar o âmbito da sprint a toda a hora. Se tudo muda pelo caminho, é fluxo contínuo, e talvez o Kanban sirva melhor.
2. Sprint sem objetivo. Sem uma frase que explique por que razão o ciclo existe, passa a ser só uma lista de tarefas.
3. Product Owner sem poder de decisão. Se cada prioridade precisa da aprovação de três administradores, o backlog bloqueia.
4. Scrum Master como gestor. Quando distribui tarefas e cobra, a equipa deixa de se autogerir.
5. Backlog como depósito. Duzentos itens que ninguém lê. Descarte o que não vai ser feito.
6. Pronto sem definição. Sem critérios claros, o item volta como retrabalho na sprint seguinte.
7. Usar a velocidade para cobrar. Ela existe para prever, não para pressionar.
8. Daily transformada em reunião de estado. Todos falam com o gestor, ninguém fala com a equipa.
9. Saltar a retrospetiva. É onde a equipa melhora. Sem ela, os mesmos problemas repetem-se a cada ciclo.
10. Sprint longa demais. Quanto maior o ciclo, mais tarde se descobre que saiu do rumo.
11. Estimar em pontos sem perceber o conceito. Se a equipa não gosta de pontos, estime em horas ou conte itens.
12. Ignorar o que ficou de fora. O item que não terminou volta ao backlog e é reavaliado, em vez de ser empurrado automaticamente para a sprint seguinte.

Como começar a sua primeira sprint

1. Escolha a duração. Duas semanas é um bom padrão. Fixe-a e mantenha-a.
2. Reúna o backlog. Tudo num único lugar, por 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 chegam para começar.
5. Planeie com folga. Na primeira sprint, puxe cerca de 60% do que acha que cabe. Estimar sem histórico é um palpite; o primeiro ciclo serve para o criar.
6. Faça a diária e atualize o quadro. Quinze minutos, à mesma hora.
7. Feche com revisão e retrospetiva. Sem elas, é só um calendário com um nome bonito.

Passadas duas ou três sprints, a velocidade começa a ter significado, e o planeamento passa a apoiar-se em dados. O modelo de backlog e sprint traz uma folha de cálculo preenchida para adaptar.

Scrum e Kanban em conjunto

Muitas equipas usam os dois: o Scrum dá o ritmo (ciclos, planeamento, revisão), e o quadro Kanban mostra o andamento dentro da sprint, com limite de trabalho em curso nas colunas do meio. O guia de Kanban explica o outro lado. Uma regra prática: se o seu trabalho é planeá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 fecho. Fazem parte do plano Pro.

• Backlog. As tarefas que ainda não entraram em nenhum ciclo ficam no backlog, por ordem de prioridade.
• Planeamento do ciclo. Puxa do backlog o que cabe na sprint, com estimativa e responsável, e fecha o âmbito com todos a ver.
• Um sprint, vários projetos. O mesmo ciclo pode reunir tarefas de projetos diferentes, que é como muitas equipas 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 a meio do ciclo, não na véspera, se vai dar tempo.
• Velocidade. A média dos ciclos anteriores serve de base ao planeamento seguinte.
• Relatório de fecho. Mostra o que foi planeado, 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 encontrar a etapa onde o trabalho encrava.

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