O Sprint Backlog é o plano que os Developers montam para a Sprint: o objetivo, os itens escolhidos e o trabalho necessário para entregá-los. Parece simples, mas é o artefato que mais se deforma na prática. Em alguns times vira uma lista de tarefas distribuídas pelo gerente na segunda-feira; em outros, uma cópia do topo do Product Backlog, sem plano nenhum.
Os dois extremos trazem o mesmo problema: ninguém consegue olhar o plano e dizer, numa terça-feira qualquer, se o time está perto ou longe da Meta da Sprint. E é exatamente para isso que ele existe.
A seguir estão a definição pelo Guia do Scrum, quem manda no plano da Sprint, como montá-lo, um exemplo preenchido e um modelo para copiar.
Formação relacionada
Papéis, eventos, práticas e ciclo de vida do Scrum, com preparação para o exame ASF.
O que é Sprint Backlog, segundo o Guia do Scrum
O Guia do Scrum 2020 diz que o Sprint Backlog é composto de três partes:
- A Meta da Sprint (o porquê). O objetivo único da Sprint e o compromisso deste artefato.
- Os itens do Product Backlog selecionados para a Sprint (o quê).
- Um plano de ação para entregar o Incremento (o como).
O Guia acrescenta características que orientam o uso no dia a dia:
- É um plano feito pelos Developers e para os Developers.
- É uma imagem visível e em tempo real do trabalho que os Developers pretendem realizar na Sprint.
- É atualizado ao longo da Sprint, conforme o time aprende.
- Deve ter detalhe suficiente para que os Developers inspecionem o progresso na Daily Scrum.
O Sprint Backlog é um dos três artefatos do Scrum, ao lado do Product Backlog e do Incremento. Como os três se relacionam está em artefatos do Scrum, e o panorama do framework, no guia completo de métodos ágeis e Scrum.
Quem é dono do Sprint Backlog e quem pode mudá-lo
Os Developers são donos desse plano. Isso tem consequências práticas:
- As tarefas são deles. Ninguém de fora do grupo, nem o Product Owner nem um gestor, distribui tarefas ou define como o trabalho será feito.
- Eles podem mudar o plano a qualquer momento. Tarefas novas aparecem, outras são descartadas, a ordem muda. Isso é sinal de aprendizado, não de falha.
- O escopo é renegociado com o Product Owner. Se o trabalho se mostrar maior do que o previsto, os Developers conversam com o PO sobre o que sai, sem comprometer a meta.
- A Meta da Sprint não muda. Se ela perder o sentido, só o Product Owner pode cancelar a Sprint.
Como escrever uma meta que realmente oriente essas decisões está em meta da sprint.
Como montar o Sprint Backlog: passo a passo
O plano nasce na Sprint Planning. O roteiro completo do evento está em Sprint Planning: como conduzir; aqui o foco é o artefato que sai dele.
- Escreva a Meta da Sprint no topo. Ela é a primeira linha do plano e o filtro para tudo o que vem abaixo.
- Liste os itens selecionados. Os itens do Product Backlog que os Developers acreditam conseguir concluir, de acordo com a Definição de Pronto, dentro da capacidade da Sprint.
- Marque quais itens servem à meta. Se houver itens que não servem, deixe isso visível: são os primeiros candidatos a sair se o tempo apertar.
- Decomponha os primeiros itens em tarefas. O Guia diz que isso costuma ser feito quebrando os itens em unidades de trabalho de um dia ou menos. Não é preciso detalhar tudo no primeiro dia; os itens do fim da lista podem ser decompostos depois.
- Inclua o trabalho que a Definição de Pronto exige. Testes, revisão de código, documentação, implantação em homologação. Se não estiver no plano, vai ficar para "depois".
- Inclua a melhoria escolhida na Retrospectiva, quando houver. O Guia diz que as melhorias de maior impacto podem entrar no Sprint Backlog da Sprint seguinte.
- Deixe tudo visível num quadro. Físico ou digital, com colunas simples, e com a meta à vista de todos.
A diferença entre item do backlog e tarefa é simples: o item diz o que o usuário ganha e é ordenado pelo Product Owner; a tarefa diz o que os Developers vão executar e só eles a organizam.
Exemplo de Sprint Backlog preenchido
O exemplo é ilustrativo. Uma rede de academias está construindo o aplicativo de agendamento de aulas, em Sprints de duas semanas.
Meta da Sprint: o aluno consegue reservar uma vaga em aula coletiva pelo aplicativo e receber a confirmação.
| Item do Product Backlog | Serve à meta? | Tarefas (plano dos Developers) | Situação |
|---|---|---|---|
| Ver a grade de aulas da unidade | Sim | Consultar a grade no sistema da academia; montar a tela de grade; tratar unidade sem aulas cadastradas; testes automatizados | Em andamento |
| Reservar vaga em aula | Sim | Criar a regra de limite de vagas; tela de confirmação; bloquear reserva duplicada; testes da regra de limite | A fazer |
| Receber confirmação da reserva | Sim | Enviar notificação no aparelho; texto da mensagem validado com o marketing; teste em Android e iOS | A fazer |
| Ajustar contraste dos botões para acessibilidade | Não | Revisar paleta; ajustar componentes; validar com leitor de tela | A fazer |
| Melhoria da Retrospectiva: automatizar a publicação em homologação | Não (processo) | Configurar a esteira; documentar o passo a passo | Concluída |
Repare em três coisas. A meta está acima de tudo. O item de acessibilidade entrou porque havia capacidade, mas fica claro que ele sai primeiro se algo der errado. E a melhoria da Retrospectiva aparece no plano, com tarefas, em vez de ficar numa ata.
Modelo de Sprint Backlog para copiar
SPRINT BACKLOG: [produto] Sprint [n]: [dd/mm] a [dd/mm]
META DA SPRINT:
[quem] consegue [fazer o quê], para [qual benefício]
ITENS SELECIONADOS
1. [item do Product Backlog] Serve à meta: sim/não Tamanho: [ ]
Tarefas:
[ ] [tarefa de um dia ou menos]
[ ] [tarefa]
[ ] Trabalho da Definição de Pronto (testes, revisão, homologação)
2. [item]
...
MELHORIA DA RETROSPECTIVA
[ ] [ação] Como vamos medir: [ ]
IMPEDIMENTOS E RISCOS
[descrição] Dono: [ ] Desde: [dd/mm]
NOTAS DE RENEGOCIAÇÃO COM O PRODUCT OWNER
[dd/mm] [o que saiu ou entrou e por quê]
A última seção não é exigência do Guia, mas ajuda muito na Sprint Review: mostra às partes interessadas, com datas, o que mudou no escopo e por quê.
Como acompanhar o Sprint Backlog durante a Sprint
- Na Daily Scrum, os Developers olham o quadro da Sprint para responder se estão mais perto da meta e ajustam o plano do dia. Se o quadro não permite essa leitura em poucos segundos, ele está detalhado demais ou de menos.
- Ao longo do dia, cada pessoa atualiza o que pegou e o que terminou. Atualização só na véspera da Review esconde problemas.
- Com um gráfico simples, como o burndown do trabalho restante, o time vê a tendência. O Guia não exige gráfico; use se ajudar.
- No quadro, colunas como "a fazer", "em andamento", "em revisão" e "pronto" bastam para começar. O artigo quadro Scrum traz um modelo para montar o seu.
Erros comuns ao montar e usar o plano da Sprint
- Tarefas atribuídas por alguém de fora. Tira dos Developers a responsabilidade pelo plano e pela meta.
- Sem Meta da Sprint. Vira uma lista de itens, e qualquer corte de escopo parece fracasso.
- Plano que não muda. Se o plano do último dia é igual ao do primeiro, ninguém atualizou.
- Itens maiores que a Sprint. Sinal de que o refinamento não aconteceu antes da planning.
- Trabalho invisível. Suporte, reuniões técnicas e correções urgentes ficam fora do quadro, e a capacidade some sem explicação.
O que fazer agora
Na próxima Sprint Planning, use o modelo acima: comece pela meta, marque o que serve a ela e decomponha só os primeiros itens. Na Retrospectiva, pergunte se o plano ajudou a decidir algo durante a Sprint. Se o time usa o Jira, vale configurar o quadro para mostrar a meta, os itens e as tarefas da forma que o time realmente trabalha; o curso Jira Avançado da Projeto Diário trata da configuração de fluxos, quadros, automações e relatórios para times de entrega.
