Dando continuidade à série FAQ Scrum, hoje falaremos do Sprint Backlog.
O que é isso de fato, quando e como ele deve ser criado?
Além disso, veremos quais papéis devem estar envolvidos na criação deste artefato que direcionará o trabalho da equipe Scrum durante a próxima Sprint, ou seja, durante o próximo ciclo de desenvolvimento.
O que é?
O Sprint Backlog representa
tudo o que deverá ser feito durante a próxima Sprint do seu projeto. Ele surge a partir do que foi levantado e listado, pelo Product Owner, no Product Backlog. A maioria dos itens que estão no Product Backlog serão implementados
um dia, mas para serem considerados para fazer parte do Sprint Backlog eles devem estar preparados, estimados e priorizados, segundo a definição de preparado estabelecida no início do projeto.
A escolha dos itens que farão parte do Sprint Backlog deve estar de acordo com a Meta da Sprint, que define qual o objetivo do Product Owner com aquela Sprint, ou seja, o que ele espera que o produto seja capaz de fazer quando chegar o fim daquele ciclo de desenvolvimento. E é essa Meta que direciona o Product Owner e a Equipe Scrum para definir quais itens do Product Backlog farão parte do Sprint Backlog.
Quando e como?
O Sprint Backlog é criado durante a Reunião de Planejamento, onde os três papéis do Scrum estão envolvidos. Nesse momento, os itens de Backlog que serão considerados já devem estar preparados, e deixá-los preparados é tarefa do Product Owner. Com os itens preparados, a Equipe Scrum estima o esforço de trabalho para cada um deles e, de acordo com a Meta da Sprint, esses itens são priorizados e uma determinada quantidade deles se torna o Sprint Backlog, sendo detalhados em tarefas.
Essa quantidade é definida a partir da análise do que a Equipe Scrum consegue concluir no próximo ciclo de trabalho e o que realmente deve ser realizado para que a Sprint cumpra a Meta estabelecida.
É aconselhável que nem todos os itens do Sprint Backlog estejam diretamente relacionados à Meta. Isso porque, caso não seja possível concluir um deles, a Meta estará comprometida e, assim, a Sprint não terá sucesso.
Outro ponto importante é que o Sprint Backlog não deve ser mudado porque a Meta da Sprint não pode ser mudada. Além disso, incluir um novo item ao Sprint Backlog pode ocasionar a não conclusão de um outro item. Por isso, itens novos só podem entrar no Sprint Backlog se estiverem relacionados à Meta e se forem contribuir para o seu cumprimento de uma forma que os itens já presentes não cumprirão.
E então? Ficou alguma dúvida sobre Sprint Backlog? Não deixe de comentar aqui seus questionamentos e de assistir aos vídeos do Papo Ágil, na Universidade Scrum.
Se o P.O prioriza um item do product backlog e durante a planning descobre-se que o sprint ficaria muito longo. É possível quebrar em mais de um sprint? Exemplo: A parte de login entregaremos no sprint 1, consulta saldo no sprint 2 e faturas no sprint 3. Se sim como identificar o tamanho de cada sprint sendo que o sprint planning fala sobre cada sprint em específico?
Oi Gabriel,
não sei se entendi direito. Mas pelo que entendi, você diz que a Sprint teria uma história somente e que essa história por ser muito longa seria quebrada em 3? Se for isso, recomendo mesmo que seja quebrada. Pela sua descrição, me parece que se tudo isso está em uma história, esta história está em um nível de abstração alto e deve ser até difícil estimá-la. No entanto, se por outro lado tudo que você descreveu já estava em histórias diferentes, não há problema nenhum em serem feitas em Sprints distintas. A ideia é exatamente essa. A Sprint nada mais é do que um período de trabalho da equipe. O P.O. organiza as histórias nas Sprints da forma que melhor lhe convier, estabelecendo as devidas metas para orientar o trabalho da equipe. Lembre-se porém que as Sprints são planejadas uma a uma. Quero dizer que não dá para planejar a Sprint S+1 antes de terminar a Sprint S, pois nunca sabemos o que ocorrerá durante a Sprint S. Vai que o time não é bem sucedido da Sprint S… teríamos que replanejar tudo da S+1 e perderíamos muito tempo.
Bem, espero ter ajudado. Se não for bem isso que eu entendi ou expliquei, ou se houver alguma outra dúvida, fique a vontade em fazer nova pergunta.
Obrigado por visitar o nosso blog. Visite também o nosso ScrumHalf Agile Manager. Vai te ajudar bastante com seu projeto.