Quando um Sprint está concluído? I notice this text is already in Portuguese. If you intended for me to translate from Portuguese to another language, please let me know the target language. If this was meant to be a different source text (perhaps in German or English), please provide that text and I'll translate it to Portuguese for you.

É 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:

1. 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.

2. 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?