O Sprint Backlog

Sprint Backlog

Enquanto que o Product Backlog é a lista de funcionalidades desejadas para um determinado produto a médio e longo prazo, o Sprint Backlog é a lista de coisas que estão sendo (ou serão) feitas na sprint atual, no curto prazo.

Existem dois tipos de backlog no framework Scrum: o Product Backlog e o Sprint Backlog. Enquanto que no Product Backlog o Product Owner mantém todas as funcionalidades e melhorias desejadas para o produto, como se fosse uma visão de médio e longo prazo, é no Sprint Backlog que estão os itens a serem trabalhados pelo time nesta sprint, a curto prazo.

No vídeo abaixo, você aprende sobre este tópico também, caso prefira ao invés de ler.

O Sprint Backlog é um artefato gerado na Sprint Planning. Uma vez que o Product Owner tenha um Product Backlog ordenado, com os itens mais no topo detalhados o suficiente para o time entender o que precisa ser feito, são selecionados um a um os itens do Product Backlog durante a Planning: cada item é apresentado, discutido, quebrado em tarefas e adicionado ao Sprint Backlog em uma quantidade que o Time de Desenvolvimento julgue adequada para o tamanho da iteração que estejam utilizando.

É sempre importante ressaltar que eventualmente podem ser adicionados itens no Sprint Backlog que não estavam originalmente previstos pelo Product Owner, como sustentação do sistema, seja ele evolutiva, adaptativa ou mesmo corretiva. No entanto, mesmo que não tenham sido previstos inicialmente pelo PO, sempre é importante alinhar com ele a adição de qualquer item ao Sprint Backlog pois isso pode comprometer a entrega dos itens já planejados. O mesmo vale para quando o PO desejar aumentar o escopo de trabalho da sprint: deve sempre haver um ok por parte do Time de Desenvolvimento.

Ao contrário da crença popular, é bem comum que o escopo do Sprint backlog mude no decorrer da sprint, seja pela descoberta de detalhes desconhecidos no planejamento, dificuldades técnicas que possam surgir, mudanças de prioridade vindas do mercado, incidentes, bugs, etc. Cabe ao Time Scrum determinar como irão lidar com estas mudanças que surgirem: será que podemos inclui-las na próxima sprint? Será que devemos interromper a sprint atual e iniciar outra? Será que devemos trocar itens antigos pelos novos? Será que devemos sempre deixar uma “gordura” para estes casos? Cada caso é um caso e deve ser analisado com cuidado para não prejudicar o Sprint Goal que foi definido (falo disso mais à frente).

O Scrum não prescreve um formato específico de como o Sprint Backlog deve ser organizado, sendo que o formato mais comum entre os times ágeis é o quadro de atividades (board, Kanban, etc), seja ele físico ou virtual. Neste quadro geralmente o time cria colunas com as fases de desenvolvimento de cada item, como TO DO, DOING e DONE, onde os itens que devem ser feitos na sprint iniciam na coluna TO DO, passam para a coluna DOING quando um desenvolvedor pega um deles para trabalhar e finalmente é colocado na coluna DONE quando o item é concluído.

O Scrum também não prescreve como estes itens são descritos, sendo que o formato mais comum é como User Stories do framework XP. Em boards físicos as User Stories possuem sua narrativa descrita na parte da frente dos cards/post-its (Enquanto x eu gostaria de fazer y para poder ter z) e os critérios de aceitação no verso (requisitos que devem ser atendidos para esta história ser homologada pelo PO). Em boards virtuais geralmente há uma organização específica para o preenchimento de User Stories e você deve consultar o manual da sua ferramenta.

Enquanto artefato do Scrum, o uso de um Sprint Backlog é obrigatório dentro deste framework, cabendo ao time apenas a escolha do formato a ser utilizado, seja usando o mais comum (Kanban + user stories) seja qualquer outro formato que fizer sentido para o time. Também é importante que exista um objetivo claro para a sprint (Sprint Goal) que geralmente reflete ou é refletido no conteúdo do sprint backlog. Se nele você tem muitas tarefas de correção de bugs, talvez esta seja uma sprint de estabilização do sistema; se nele tem novas funcionalidades, o goal deve ser melhorias do produto e assim por diante.

Ao término da sprint espera-se que todos os itens do Sprint Backlog tenham sido concluídos. Ao finalizarmos esta iteração, com este artefato temos insumo para uma série de outras atividades como o escopo da Sprint Review, alguns tópicos para a Sprint Retrospective, métricas para o Scrum Master analisar (lead time, cycle time, etc), dados para o Product Owner atualizar no roadmap de produto e muito mais. Por isso é importante gerenciar corretamente este artefato ao longo do desenvolvimento da sprint.

 

Referências bibliográficas

Luiz Duarte. Agile Coaching: Um Guia Prático, LuizTools, 2019

Luiz Duarte. Scrum e Métodos Ágeis: Um Guia Prático, LuizTools, 2016

Schwaber, Ken e Sutherland, Jeff. O Guia do Scrum. O Guia Definitivo para o Scrum: As Regras do Jogo. 2020.

PMI - PROJECT MANAGEMENT INSTITUTE. Guia PMBOK®: Um Guia para o Conjunto de Conhecimentos em Gerenciamento de Projetos, Sexta edição, Pennsylvania: PMI, 2017.

 

 

 

 

 

 

Compartilhar :

Facebook
Twitter
LinkedIn

Deixe um comentário

Abrir bate-papo
Olá 👋
Podemos ajudá-lo?