Scrum - como transportar um User Story parcialmente completo para o próximo Sprint sem inclinar o backlog

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

Como não parecemos estar perdendo nada óbvio, achamos que essa é uma das decisões que cada equipe precisa tomar por si mesmas com base em como querem trabalhar e quais métricas são mais importantes para elas.

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

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

Concluímos, portanto, que a opção A é certa para nós. Vamos re-estimar os pontos da história para quaisquer histórias que concluirmos parcialmente em um sprint, a fim de que possamos planejá-las adequadamente em sprints subseqüentes. Com o passar do tempo, o backlog do produto será um pouco abaixo do número de pontos de história que implementamos, mas isso será menos problemático do que qualquer outra opção e poderá ser resolvido alterando nossa manutenção de registros e relatórios.

A opção A é um curso de ação comumente recomendado. Você não atribui pontos para a conclusão da história para o sprint anterior e para mover a história de volta para o backlog do produto, onde é repriorizado. Você calcula sua velocidade (e outras métricas) com base nas histórias de usuário e no valor agregado concluídos. Quando você começa a planejar o próximo sprint, você pega as histórias de maior prioridade com base em seu valor (o que pode ou não incluir a história inacabada, se as prioridades do negócio tiverem mudado). Quando você estimar a história, inclua o trabalho que já foi feito ao considerar a nova quantidade de pontos para a matéria.

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

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

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, então não contamos pontos para isso, é tudo ou nada.

Então, mudamos toda a história inacabada para o próximo sprint e todos os pontos da história serão adicionados à velocidade do próximo sprint. Velocidades se igualam ao longo do tempo e tomamos uma média dos poucos sprints anteriores como referência para determinar estimativas de velocidades futuras.

Pensar muito sobre isso faz com que pareça mais complicado do que é ... Na verdade, é bem simples:

Opção C

Histórias incompletas voltam para o 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 decidir que pode encaixá-la no sprint, ela entra, com seu número original de pontos. Se não, fica no backlog. Feito. Os pontos são atribuídos ao sprint em que a história foi concluída.

Se isso ajudar, você poderá acompanhar uma métrica "restante do trabalho" por história do usuário, para que, se no final do sprint, a história não estiver completa, o trabalho estimado restante possa ser anotado na história e fatorada ao planejar sua inclusão em um sprint subsequente. Mas, mesmo assim, não altere o valor pontual da história original.

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

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

editar: Isso pressupõe (como eu acredito que o OP estava assumindo) que o trabalho quase completo não foi derrubado em prioridade e que chegar ao resultado do esforço anterior o mantém alto o suficiente na lista para continuar trabalhando. Eu sei que algumas lojas não fazem isso, mas a maioria dos lugares em que trabalhei consideram terminar uma tarefa de sobra quase completa para ser valiosa o bastante para continuar, a menos que algo tenha mudado drasticamente. A penalidade de mudar de contexto muitas vezes não vale a pena mudar a ordem.

Rastreamos o tempo gasto na iteração de sprint para fins de capitalização (horas gastas em tarefas relacionadas a uma história do usuário) e movemos a história do usuário pontual, se a meta da PO for manter o caminhão nela durante a próxima sprint, deixando os pontos iguais.

Se o objetivo do PO é mover algo mais em seu lugar, basta colocar a história inacabada no backlog e fazer o que quiser. Deixar a estimativa original dos pontos é minha recomendação, porque se você tivesse o hábito de morder mais do que poderia mastigar, a cada sprint, você estaria "completando" os pontos da história em um sprint que não estava completo e limpo. itens testados.

Se você quisesse deixar algo no sprint, apontasse, ou tivesse que enviar, eu pensaria que você determinaria um ponto de corte dentro da história original, ao qual você alcançou o ponto final, e cometeu essa parte menor para sua iteração. Então, o restante poderia ser apontado novamente e colocado no backlog. Essa seria uma oportunidade de reestimar, porque você concordou com sua equipe em dividir a história em fatias.

Given that the User Story we are carrying over is partially complete, how do we estimate for it correctly in the next Sprint Planning session?

Eu não acho que as opções A até C são boas, principalmente porque o que (eu acho) deveria ser mais importante em relação à velocidade de uma equipe é a velocidade média e não se a velocidade de qualquer sprint subiu ou desceu.

Quando uma história de usuário é definida, ela deve ter critérios de aceitação. Se alguma coisa nos critérios de aceitação não for feita , a equipe simplesmente não ganhará nenhum dos pontos. Se a história for terminada (ou seja, codificada, testada e aceita pelo P.O.), então a equipe recebe todos os pontos.

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

Como M. Cohn em seu livro, eu costumo ter uma preferência por um cenário de tudo ou nada. Afinal, tentar estimar se você completou 5 pontos de 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 de que você já recebeu a inicial estimar a distância. Provavelmente, é melhor usar 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):

I’m generally in favor of an all-or-nothing stance toward counting velocity: if a story is done (coded, tested, and accepted by the product owner), the team earns all the points, but if anything on the story isn’t done, they earn nothing. At the end of an iteration, this is the easiest case to assess: If everything is done, they get all the points; if anything is missing, they get no points. If the team is likely to take on the remaining portion of the story in the next iteration, this works well. Their velocity in the first iteration is a bit lower than expected because they got no credit for partially completing a story. In the second iteration, however, their velocity will be higher than expected because they’ll get all of the points, even though some work had been completed prior to the start of the iteration. This works well as long as everyone remembers that we’re mostly interested in the team’s average velocity over time, not in whether velocity jumped up or down in a given iteration.

Estimativa Ágil e Planejamento , 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ão fazemos mais isso ... vai ver) Este é especialmente o caso porque as histórias devem ser estimadas como uma equipe , mas se apenas uma pessoa estiver trabalhando nisso, ser mais difícil para a equipe saber o quanto um indivíduo realmente foi concluído. O Agile está mais interessado na velocidade média de um time do que em quão "agradável" um determinado sprint parece.

Dito isto, o autor faz mencionar que a atribuição de pontos parciais pode ser considerada se for improvável que a equipe lide com o trabalho restante na próxima iteração. Nesse caso, a equipe estimaria o trabalho que ainda resta e o dividiria em novas histórias de usuários com qualquer tamanho que eles achem que deveriam ter. Como o autor menciona²:

The combined estimates would not need to equal the original estimate...

² Ditto, p.66

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

However, the two best solutions to allocating points for incomplete stories are not to have any incomplete stories and to use sufficiently small stories that partial credit isn’t an issue.

³ Ditto, p.67

Espero que isso ajude.

A primeira pergunta a fazer é: o que significa um ponto de história? Se você definir um ponto da história como "Quanto engenharia de trabalho é feita", qualquer resposta será suficiente. No entanto, se você definir um ponto da história como "Quanto valor é entregue ao negócio", torna-se 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 depois de um sprint com base no que foi concluído só esconderá 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 não tinha critérios de aceitação mensuráveis, d ) não é um entendimento profundo o suficiente das tarefas ou dependências para completar a história, e) subestimou o esforço para testar a história, f) derrubou muitos pontos da história, ou g) ... insira sua razão 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.