Scrum - como transportar uma História do usuário parcialmente completa para o próximo Sprint sem distorcer o backlog

Estamos usando o Scrum e ocasionalmente descobrimos que não conseguimos terminar uma História do Usuário no sprint em que ela foi planejada. No verdadeiro estilo Scrum, enviamos o software de qualquer maneira e consideramos incluir a história do usuário no próximo sprint durante a próxima sessão de planejamento do Sprint. Como a história do usuário que estamos transportando está parcialmente concluída, como a estimamos corretamente na próxima sessão de planejamento do Sprint? Nós consideramos:

a) Ajustar o número de pontos da história para baixo para refletir apenas o trabalho que resta para concluir a história do usuário. Infelizmente, isso atrapalha o relatório do Backlog do Produto.

b) Feche a história do usuário parcialmente concluída e crie uma nova para implementar o restante desse recurso, que terá menos pontos da história. Isso afetará nossa capacidade de ver retrospectivamente o que não concluímos naquele sprint e parece um pouco demorado.

c) Não se incomode com a ou b e continue a adivinhar durante o Sprint Planning dizendo coisas como "Bem, essa história de usuário pode ser X pontos da história, mas eu sei que ela está 95% concluída, então tenho certeza de que podemos encaixá-la".

Na minha equipe atual, fazemos c).

A velocidade deve explicar as coisas que a equipe realmente terminou no sprint. Algo que não foi entregue não tem valor para o cliente, por isso não contamos pontos, é tudo ou nada.

Então, mudamos toda a história inacabada para o próximo sprint e todos os seus pontos da história serão adicionados à velocidade do próximo sprint. As velocidades diminuem com o tempo e tomamos uma média dos poucos sprints anteriores como referência para determinar as velocidades futuras estimadas.

A opção A é um curso de ação comumente recomendado. Você não concede pontos pela conclusão da história para o sprint anterior e move a história de volta para a lista não processada do produto, onde é repriorizada. Você calcula sua velocidade (e outras métricas) com base nas histórias de usuário concluídas e no valor agregado. Quando você começa a planejar o próximo sprint, pega as histórias de maior prioridade com base em seu valor (que pode ou não incluir a história inacabada, se as prioridades de negócios foram alteradas). Quando você estimar a história, inclua o trabalho que já foi realizado ao considerar a nova quantidade de pontos para a história.

Obviamente, uma opção alternativa (e minha preferência) seria usar o número estimado original de pontos da história, o que já fiz no passado. Isso pressupõe que sua estimativa foi boa e bem fundamentada, mas você reduziu muito o trabalho para o sprint (por exemplo - a história realmente valeu 3 pontos, mas o problema está no fato de que você reduziu 15 pontos quando você deveria ter puxado apenas 13). É uma suposição potencialmente perigosa se você não estiver confiante em sua capacidade de executar as estimativas, mas pode funcionar com base em sua equipe e processo.

No entanto, você mencionou que isso "atrapalhará os relatórios do Backlog do Produto". O Backlog do Produto deve ser dinâmico de qualquer maneira, com a ordem e as estimativas de cada história mudando conforme mais se entende sobre a tecnologia, o sistema, os requisitos e o cliente. Normalmente, o que é relatado no Backlog do produto é o número de histórias de usuários e o número total de pontos de histórias. Isso deve mudar à medida que as prioridades mudam, novos requisitos são adicionados, requisitos inválidos são removidos e mais informações são aprendidas.

Pensar demais nisso faz com que pareça mais complicado do que é ... Na verdade, é bem simples:

Opção C

Histórias incompletas voltam ao backlog do produto, sem que os pontos sejam alterados. Ao planejar o próximo sprint e o que pode ser feito, a discussão deve incluir o fato de que grande parte do trabalho já foi realizado. Se a equipe decide que pode encaixá-lo no sprint, ele entra, com seu número original de pontos. Caso contrário, ele permanece na lista de pendências. Feito. Os pontos são atribuídos ao sprint em que a história foi concluída.

Se ajudar, você pode rastrear uma métrica separada de "trabalho restante" por história de usuário, para que, no final do sprint, a história não esteja completa, o trabalho restante estimado poderá ser anotado na história e levado em consideração quando planejando sua inclusão em um sprint subsequente. Mas, mesmo assim, não altere o valor em pontos da história original.

Se sua ferramenta de relatórios não puder lidar com a opção A com precisão, eu usaria a opção B, a menos que você não tenha esperança de usar suas métricas.

Em alguns casos, você pode executar a opção B E não distorcer o que significa fechado, estreitando o escopo da tarefa antiga que está prestes a fechar e criando apenas uma nova tarefa para o escopo restante. Isso faz com que a história faça mais sentido semântica e geralmente indica lugares onde você deveria ter considerado a tarefa mais detalhada. Às vezes, isso não é possível ou lógico e você simplesmente tem uma tarefa que é tão grande ou se depara com esse nível de problemas.

edit: Isso pressupõe (como eu acredito que o OP estava assumindo) que o trabalho quase completo não foi derrubado com prioridade e que a recompensa pelo esforço anterior o mantém alto o suficiente na lista para continuar trabalhando. Sei que algumas lojas não fazem isso, mas a maioria dos lugares em que trabalhei consideram que concluir uma tarefa restante quase completa é valioso o suficiente para continuar, a menos que algo tenha mudado drasticamente. A penalidade de mudar o contexto geralmente não vale a pena mudar a ordem.

Como a história do usuário que estamos transportando está parcialmente concluída, como a estimamos corretamente na próxima sessão de planejamento do Sprint?

Eu não acho que as opções de A a C sejam boas, principalmente porque o que (acho) deveria ser mais importante em relação à velocidade de uma equipe é a velocidade média e não se a velocidade de um determinado sprint aumentou ou diminuiu.

Quando uma história de usuário é definida, ela deve ter critérios de aceitação. Se algo nos critérios de aceitação não for feito, a equipe simplesmente não ganha nenhum dos pontos. Se a história estiver pronta (ou seja, codificada, testada e aceita pelo OP), a equipe receberá todos os pontos.

Isso funciona bem quando a equipe está focada na velocidade média, e não na velocidade de um determinado sprint.

Como M. Cohn em seu livro, tenho tendência a preferir um cenário de tudo ou nada. Afinal, tentar estimar se você completou 5 pontos em uma história de 8 pontos, ou talvez apenas 6 ou 7 acabará sendo outro jogo de adivinhação ... e não se esqueça que você já obteve o primeiro estimar muito longe. Provavelmente é melhor seguir o método mais simples e obter todos os pontos depois de realmente ter sido concluído.

Citando M. Cohn de seu livro¹ (minha ênfase):

Geralmente sou a favor de uma postura de tudo ou nada em relação à velocidade de contagem: se uma história for concluída (codificada, testada e aceita pelo proprietário do produto), a equipe ganhará todos os pontos, mas se alguma coisa na história não for feito, eles não ganham nada. No final de uma iteração, este é o caso mais fácil de avaliar: se tudo estiver pronto, eles obtêm todos os pontos; se falta alguma coisa, eles não ganham pontos. Se é provável que a equipe assuma a parte restante da história na próxima iteração, isso funcionará bem. A velocidade deles na primeira iteração é um pouco menor do que o esperado, porque eles não receberam nenhum crédito por concluir parcialmente uma história. Na segunda iteração, no entanto, sua velocidade será maior do que o esperado, porque eles obterão todos os pontos, mesmo que algum trabalho tenha sido concluído antes do início da iteração.Isso funciona bem desde que todos se lembrem de que estamos interessados ​​principalmente na velocidade média da equipe ao longo do tempo, e não se a velocidade saltou para cima ou para baixo em uma determinada iteração.

¹ Estimativa e planejamento ágeis , re-estimando histórias parcialmente concluídas, p.66

Minha equipe já havia tentado atribuir pontos parciais, apesar de algumas objeções, e não acho que funcionou bem. (Nós não fazemos mais isso ... vai entender) Este é especialmente o caso porque as histórias são supostamente para se estima como uma equipe , no entanto, se apenas uma pessoa está trabalhando nisso, vai ser mais difícil para o time de saber quanto um indivíduo realmente completou. O Agile está mais interessado na velocidade média de uma equipe do que na aparência "agradável" de um sprint específico.

Dito isto, o autor faz menção de que a atribuição de pontos parciais podem ser consideradas se a equipe é pouco provável para enfrentar o trabalho restante na próxima iteração. Nesse caso, a equipe estimaria o trabalho restante e o dividiria em novas histórias de usuários com o tamanho que eles acham que deveriam ter. Como o autor menciona²:

As estimativas combinadas não precisariam ser iguais à estimativa original ...

² Idem, p.66

A melhor recomendação para a equipe é dividir as histórias em um tamanho suficientemente pequeno para evitar esse tipo de problema³:

No entanto, as duas melhores soluções para alocar pontos para histórias incompletas não são ter histórias incompletas e usar histórias suficientemente pequenas para que o crédito parcial não seja um problema.

³ Idem, p.67

Espero que isto ajude.

Estou surpreso que não pareça haver uma resposta direta para isso. Eu estava esperando um coro de "opção D, manequim"!

Como não parecíamos estar perdendo nada óbvio, concluímos que essa é uma daquelas decisões que cada equipe precisa tomar para si, com base em como deseja trabalhar e em quais métricas são mais importantes para eles.

Decidimos que é essencial manter registros precisos das histórias de usuários que implementamos, pois elas formam a base de nossos testes, documentação de suporte e notas de versão - isso exclui a opção B.

Em seguida, descobrimos que ser capaz de executar o planejamento de sprint com precisão era essencial - isso exclui a opção C.

Concluímos, portanto, que a opção A é adequada para nós. Vamos reestimar os pontos da história para todas as histórias que concluímos parcialmente em um sprint para que possamos planejá-las adequadamente nos sprints subsequentes. Com o tempo, a lista de pendências do produto subestimará um pouco a quantidade de histórias que implementamos, mas isso será menos problemático do que qualquer outra opção e poderá ser resolvido alterando a manutenção e os relatórios de registros.

Nós rastreamos o tempo gasto na iteração do sprint para fins de capitalização (horas queimadas em tarefas relacionadas a uma história de usuário) e avançamos a história do usuário apontada se o objetivo do OP é continuar transportando caminhões durante o próximo sprint, deixando aponta o mesmo.

Se o objetivo do OP é mover algo mais em seu lugar, simplesmente colocaríamos a história inacabada no backlog e faríamos o que quisessem. Deixar a estimativa original de pontos é minha recomendação, porque se você tivesse o hábito de morder mais do que podia mastigar, a cada corrida, estaria "completando" pontos da história em uma corrida que não foi totalmente concluída e limpa. itens testados.

Se você quisesse deixar algo no sprint, apontou ou tivesse que enviar, acho que você determinaria um ponto de fatia dentro da história original, para a qual alcançou o ponto final e cometeria aquele pedaço menor para sua iteração. Em seguida, o restante poderia ser apontado novamente e colocado na lista de pendências. Essa seria uma oportunidade de reestimar, porque você concordou com sua equipe em dividir a história em fatias.

A primeira pergunta a ser feita é: o que significa um ponto de história? Se você definir um ponto da história como "Quanto trabalho de engenharia é feito", qualquer resposta será suficiente. No entanto, se você definir um ponto da história como "Quanto valor é entregue ao negócio", será importante não dar crédito até que uma história seja 100% concluída, aceita e entregue 100%. Modificar os pontos da história após um sprint com base no que foi concluído apenas ocultará o problema real: a) não havia uma compreensão clara da história, b) a história era muito grosseiramente definida, c) a história carecia de critérios de aceitação mensuráveis, d ) não possui um entendimento profundo o suficiente das tarefas ou dependências para concluir a história, e) subestimou o esforço para testá-la, f) reduziu muitos pontos da história, ou g) ... insira seu motivo aqui ...

O objetivo do ágil é ser flexível e previsível. A melhor maneira de ser consistente, na minha opinião, é descobrir o que deu errado sem modificar as estimativas originais da história.