Você conhece o sprint backlog? Ele é um dos principais pontos de qualquer Sprint e ajuda a equipe a entender melhor o objetivo de cada uma delas.
Se você quer implementar esta metodologia e entender mais sobre o assunto, este post vai tirar todas as suas dúvidas sobre este aspecto do Scrum!
O que é o Sprint Backlog?
Basicamente, o Sprint Backlog é uma lista de atividades que precisam ser feitas durante uma Sprint.
No início de cada Sprint, olha-se para o Product Backlog e “puxa-se” o que será feito no Sprint. Essas “histórias” do Product Backlog são agora desmembradas em atividades para serem executadas no Sprint (Sprint Tasks).
Evidentemente, é um aspecto crucial, pois indica todas as entregas a serem feitas. Ou seja, além de ser uma forma de organizar as tarefas, são marcos que permitem controlar o andamento do projeto em cada Sprint.
Como o Sprint Backlog é construído?
Primeiramente, as tarefas são extraídas do Product Backlog, que é elaborado pelo Product Owner (PO).
Ou seja, é uma lista de todas as funcionalidades que são necessárias para um produto. É claro que ele não precisa estar 100% pronto ao começar um projeto, pois ao longo do tempo ele vai evoluindo, assim como tudo no mindset ágil.
Então, a partir de todas as atividades existentes dentro do Product Backlog, a equipe seleciona as que se compromete a fazer naquela Sprint. Porém, é claro que a equipe não decide isso totalmente sozinha. Existe um alinhamento entre as prioridades do PO e a percepção da equipe de quanto tempo existe para fazer todas as tarefas necessárias.
Um outro ponto importante é o entendimento de que o Sprint Backlog nada mais é que a priorização das ações a serem feitas. Trata-se de priorizar, que também é fazer escolhas.
É necessário aceitar que nem sempre conseguimos entregar tudo, fazendo assim um Sprint Backlog condizente com a realidade da equipe.
Está com dúvidas sobre Scrum? Confira tudo aqui!
Como implementar o Sprint Backlog?
É claro que o Sprint Backlog não é escrito em pedra, mas a fidelidade ao que foi definido na reunião de planejamento (Planning) é essencial.
No entanto, se durante o gerenciamento da Sprint o Product Owner decidir que existe um recurso de valor comercial mais alto que precisa entrar no Sprint, o PO deve usar o procedimento de interrupção.
Se ocorrer uma interrupção que altere drasticamente as prioridades ou o escopo da Sprint e não possa ser tratada como uma interrupção, o PO poderá abortar a Sprint.
Nesse caso, a equipe para, uma nova reunião de Planejamento da Sprint é realizada e uma nova Sprint é iniciada. Isso pode ser extremamente prejudicial para a equipe, de modo que o Product Owner deve ficar muito desconfiado em parar no meio do Sprint.
Ao longo da Sprint, o Scrum Master irá facilitar as entregas, incentivando a colaboração, conduzindo as reuniões e ajudando as equipes a melhorarem a produtividade. Isso significa detalhar as tarefas que precisam ser cumpridas, de modo a entender quanto tempo ainda é necessário para cumprir as restantes.
Uma das formas possíveis de fazer esse acompanhamento para uma melhor gestão do tempo é criando um gráfico diário que calcula diariamente o quanto ainda falta para finalizar o backlog: o Gráfico Burndown.
O gráfico Burndown
Com as estimativas de esforço (ou tempo) feitas para as atividades do Sprint Backlog, pode-se fazer um acompanhamento da produtividade da equipe dia-a-dia. Para tal, usa-se o Gráfico Burndown, que consiste basicamente no seguinte:
- Marca-se no eixo Y (vertical) o somatório das estimativas de esforço das atividades do Sprint;
- Marca-se no eixo X (horizontal) o total de dias de trabalho do Sprint;
- Traça-se uma linha reta ligando os dois pontos (linha tracejada da figura ao lado). Ela representa a meta diária de avanço;
- Dia após dia, verifica-se no quadro Scrum as atividades que foram concluídas e marca-se no Gráfico a quantidade de esforço restante até o fim do Sprint;
- A meta é chegar a zero no final do Sprint.
O maior desafio acaba sendo a estimativa do tempo para completar cada tarefa. Segundo a própria teoria do Scrum, o ser humano é ruim em estimar tempo.
Por isso, originalmente no Scrum, a estimativa do “tamanho” do projeto é feita em termos do esforço despendido, por meio de uma medida relativa e não absoluta! No Scrum, utilizamos uma comparativo entre as entregas do projeto para determinar o esforço de cada uma delas.
Essas estimativas são feitas em números adimensionais, que refletem uma medida subjetiva de esforço. Dessa forma, se uma atividade tem esforço 1 e a outra esforço 5, pressupõe-se que a segunda requer cinco vezes mais esforço que a primeira.
Lembre-se, um dos benefícios da metodologia ágil é usar as informações para os próximos Sprints. Portanto, construir o Sprint Backlog a partir do passado é uma ótima ideia.
O que você achou do Sprint Backlog? Se quiser entender melhor como podemos usar o Scrum para organizar a sua empresa e trabalhar de forma mais ágil e eficiente, com a gente para uma conversa.
Veja nossas soluções em nossa página.
Confira também mais sobre mentalidade ágil neste ebook.
