Quando um Sprint está concluído?
É bastante comum que uma equipe ainda tenha trabalhos inacabados no final de um sprint ou iteração ágil. Idealmente, uma equipe sempre concluiria cada item do Sprint Backlog durante o sprint. No entanto, por diversas razões, nem sempre é assim. Isso nos leva a algumas perguntas que vou abordar a seguir:
O que deve acontecer com cada Item do Product Backlog?
Ele deve ser dividido ou transferido para o próximo Sprint? A equipe deve contabilizar os pontos das partes concluídas da Story na Velocity?
O item ainda é relevante?
Quando um Product Backlog Item não foi concluído ao final de um Sprint, ele deveria ser movido de volta para o Product Backlog. Trabalhos nunca são automaticamente transferidos de um Sprint para o próximo.
Talvez eu seja um pouco pedante nesse assunto, mas o que me importa é que cada Sprint comece com o Product Owner tomando uma decisão consciente sobre o que a equipe deve trabalhar. Claro que é muito provável que o Product Owner queira que a equipe finalize no novo Sprint os trabalhos incompletos do Sprint anterior. No entanto, isso deve ser sempre uma decisão consciente do Product Owner.
(Apenas uma observação: não estou dizendo que você deve criar trabalho extra se usar uma ferramenta que torne isso muito complicado. Estou apenas dizendo que o trabalho não é automaticamente transferido para o próximo Sprint. O Product Owner deve sempre decidir se o trabalho ainda é relevante.)
Dividir ou transferir para o próximo Sprint?
Quando um Product Backlog não pôde ser totalmente concluído, os membros da equipe frequentemente se perguntam se devem deixar o Item do Product Backlog como está (mesmo que parte da funcionalidade já esteja pronta) ou se devem reescrevê-lo para descrever apenas a parte que ainda falta.
Exemplo: Vamos usar como exemplo uma equipe que está trabalhando em uma função típica de visualização de impressão para uma aplicação desktop. Se a equipe conseguiu fazer tudo, exceto a função de voltar páginas, os membros da equipe podem levar a User Story original para o próximo Sprint ou escrever uma Story menor: "Como usuário, quero poder voltar páginas quando a visualização de impressão estiver sendo exibida."
Se a Story for concluída no Sprint seguinte, eu sugeriria simplesmente deixá-la como está e não reescrevê-la. Todos conhecem a Story da forma como ela foi escrita. Então, se o Product Owner ainda a considerar importante, ela entra no próximo Sprint sem alterações.
No entanto, se o trabalho restante for adiado para um Sprint posterior, uma nova Story deve ser escrita, descrevendo apenas a parte inacabada da funcionalidade.
Lembre-se: Se o trabalho for concluído no próximo Sprint, a Story não é reescrita.
O time recebe pontos para a Velocity?
Eu prefiro adotar um ponto de vista um pouco conservador em relação à Velocity. Isso significa que um time só deveria receber pontos pelo trabalho que esteja realmente concluído. Ou seja:
Se um item do Product Backlog inacabado for transferido para o próximo Sprint e então concluído, a equipe não deve receber pontos por ele no Sprint original. Em vez disso, a equipe recebe todos os pontos pela Story no Sprint em que o trabalho foi realmente finalizado. Como eu recomendo trabalhar com uma Velocity média, isso se equilibra naturalmente e não há risco de a Velocity ser superestimada.
A situação é diferente quando a equipe divide a Story e devolve o trabalho restante para o Product Backlog para ser trabalhado depois. Nesse caso, os pontos pelo trabalho concluído são creditados à equipe. Os membros da equipe precisam estimar da melhor forma possível quantos pontos o trabalho realizado vale. Mesmo que a Story completa ainda não esteja pronta, pode ser que a equipe receba todos os pontos originais da Story, pois é possível que ela tenha sido maior do que o esperado. Isso não deve acontecer constantemente, mas de vez em quando é aceitável.
Conclusão: Sempre buscar a causa raiz
Quando há trabalho inacabado no final do Sprint, a equipe deve sempre reservar um tempo na Retrospectiva para descobrir se a causa poderia ter sido evitada. Às vezes é simplesmente azar ou má sincronização; por exemplo, quando um membro da equipe fica doente ou surge um problema que não era possível prever no início do Sprint. No entanto, é sempre aconselhável refletir sobre qual foi a causa e como isso pode ser evitado no futuro.
Este texto foi retirado do Blog de Mike Cohn e foi traduzido por nós para o português.
User Stories, Epics, Themes
Explicamos a diferença entre esses itens.
=>User Stories, Epics, Themes
Desenvolver um produto
Da ideia até a conclusão com o Product Vision Board.
=>Product Vision Board
O que são Story Points?
Descobre onde podes melhorar a estimativa da tua equipa.
=>O que são Story Points?
