Tarefas ou histórias “quase concluídas” justificam o planejamento com sobrecarga no próximo sprint?

O caso em questão:

O sprint está quase no fim e uma das minhas equipes do Scrum não concluiu algumas tarefas. (A razão para isso não é essencial para esta pergunta e será abordada de acordo.) Um deles é um caso clássico de "90% concluído", com um número bastante grande de histórias e fará parte do próximo sprint - como no pergunta aqui .

Fizemos a preparação de pedidos em atraso e algumas estimativas preliminares para o próximo sprint e discutimos como lidar com essa tarefa inacabada. Embora todos concordemos que isso não conta para a velocidade desse sprint, argumentei que não devemos reestimar o caso quase completo com 1 em vez de cinco pontos da história, porque quero que a verdadeira complexidade e o trabalho total sejam realizados. ainda visível. E olhando para trás, a estimativa estava correta. - Estamos apenas migrando para o ágil (em escala) e alguns níveis de gerenciamento precisam "ver" que ainda somos produtivos de mais maneiras do que produtos entregues.

Obviamente, a velocidade nesse sprint diminuirá, mas as partes "já concluídas" transferidas devem subir novamente no próximo sprint.

Até agora todos concordamos.

Mas como nossas equipes são pequenas, quatro pontos são um grande obstáculo. Sugeri que apenas para esta tarefa e com a documentação adequada , pudéssemos planejar conscientemente uma sobrecarga de quatro pontos.

Essa é uma abordagem viável ou vou

• topar com problemas que eu não prevejo ainda
• deu um mau exemplo a uma equipe que foi transferida para o Agile há alguns meses atrás?

Quando uma história não é concluída no final do sprint, os pontos da história não contam para a velocidade desse sprint e a história volta para o backlog.

Se durante o planejamento do próximo sprint a história for selecionada para ser concluída, você poderá fazer uma rápida reavaliação do trabalho restante. Essa estimativa deve ser usada apenas durante a sessão de planejamento para garantir que você não carregue o sprint com histórias com um grande número de pontos em que, na verdade, são necessários muito poucos trabalhos para concluí-los.
No quadro (e na velocidade do novo sprint), deve ser usada a estimativa original da história transportada.

Essas histórias transportadas são uma das razões pelas quais a velocidade pode variar de um sprint para outro e você deve usar uma média para calcular a capacidade da equipe ao planejar um sprint.

Se a história não concluída não for apanhada no próximo sprint, será melhor planejá-la para o valor total de pontos quando ela for apanhada novamente, porque também levará tempo para ser atualizada novamente com o que o estado era quando a equipe parou de trabalhar nele.

Não tente fazer sua velocidade parecer melhor do que é. O caminho a seguir é reconhecer que a tarefa não foi concluída e você superestimou o que poderia fazer no sprint e falhou. Mas isso é vida e uma oportunidade de aprender.

Portanto, 0 pontos para a tarefa incompleta.

Quanto ao novo sprint, estime o trabalho necessário para concluir a tarefa nos pontos da história e conte-a como uma tarefa normal.

Você está preocupado que sua velocidade pareça muito baixa, você deve estar preocupado que sua velocidade seja artificialmente muito alta.

Ter uma velocidade mais alta do que você pode realmente atingir, irá prepará-lo para a falha repetidas vezes.

Em nossa equipe, usamos algumas maneiras diferentes de lidar com histórias de transição, dependendo das circunstâncias.

• Quando o sprint está quase no fim e tudo planejado já está concluído (o que acontece em qualquer outro sprint), começamos as próximas histórias no backlog (mas não as comprometemos com o lançamento do sprint). Eles são incluídos automaticamente no próximo sprint e, para fins de relatório, todos os pontos da história vão para o próximo sprint.

• Quando partes da história são completamente concluídas e têm valor comercial por conta própria, em geral, reajustamos o escopo e a estimativa da história original, e as partes restantes retornam ao backlog.

• Se a estimativa original da história estava errada (o que às vezes acontece em histórias grandes e complexas), tentamos aprender com ela :). Nenhum ponto da história no sprint atual, reestime a história inteira no próximo planejamento do sprint.

Quando algumas das histórias são herdadas do sprint anterior, no planejamento do sprint, você não começa com um backlog vazio do sprint. A equipe decide quanto trabalho extra eles podem levar além disso. Por exemplo: capacidade normal da equipe 100 SP / sprint, 20 pontos já em andamento, a equipe decide receber 90 novos SPs, então você tem 110 SPs no sprint no início do sprint.

A principal desvantagem dessa abordagem é que os relatórios de velocidade não são tão bons quanto alguns gerentes gostariam que fossem. Mas, a longo prazo, tudo se iguala e, dessa forma, tudo o que é potencialmente liberável é entregue o mais cedo possível, e a equipe recebe créditos por seu trabalho.

Um pouco de pano de fundo: originalmente essa equipe tinha uma abordagem muito rigorosa dos prazos de sprint, para que se recusassem a receber histórias mais amplas do que poderiam terminar na primeira semana (do sprint de 2 semanas) e usariam pequenas e seguras trabalhe para a parte restante do sprint. Embora isso tenha resultado em um bom backlog de sprint vazio no final do sprint, isso teve muita influência na pergunta 'em que trabalharemos a seguir?'.

Esta não é uma pergunta para uma resposta fácil. Haverá muitas opiniões sobre o que fazer, mas sugiro que você comece identificando as várias necessidades que precisa atender e crie uma solução com base nelas. Exemplo:

1. Uma equipe "precisa" entender como eles estão trabalhando e identificar oportunidades de melhorias. Às vezes, alterar os pontos da história mascara questões que devem ser abordadas.
2. O Dono do produto "precisa" saber quantos pontos da história foram estimados para um Recurso (geralmente eles são agregados no nível do recurso) ou Versão (AKA "PI" no SAFe-speak) e pode solicitar uma queima em o nível do recurso (ou PI) para demonstrar o progresso na entrega de um MVP ou MMF. Mudar os pontos da história pode distorcer os números e causar alguma confusão.

Existem alguns "trilhos de guarda" para ajudar a orientar a decisão.

• O trabalho é FEITO ou não. O trabalho incompleto não conta para o sprint em que foi concluído.
• As histórias incompletas devem ser priorizadas novamente (não é "dado" que elas sejam transferidas para o próximo sprint, elas podem retornar à lista de pendências ou serem abandonadas).

Dito isto, tenho visto muitas equipes lidarem com isso de várias maneiras.

1. Se a história incompleta ainda for válida e aprovada pelo OP, toda a história será levada para o próximo sprint. O que essas equipes costumam fazer é marcar essas histórias como anotações e estimar quantos pontos de "trabalho restante" eles representam. Portanto, se for uma história de 13 pontos, mas apenas tiver 1 ponto restante, eles fazem as contas para ajustar isso subtraindo 12. Isso deixa a estimativa original para fins históricos, como você sugeriu, enquanto ajuda a equipe a descobrir sua capacidade. Nesse caso, SIM, você pode ter "mais pontos" do que o seu "limite" da capacidade baseada na velocidade. Mas a velocidade pode mudar um pouco, não está escrita em pedra.
2. Vi equipes dividirem a história (o Rally, por exemplo, tem uma funcionalidade muito boa para isso), e aplicaram alguns pontos na parte da história que "permanece" no sprint antigo e depois aplicaram pontos na parte que leva adiante. Essa abordagem é conveniente, mas viola o princípio de "Concluído significa CONCLUÍDO" e oculta o fato de que as estimativas podem ser fracas e o trabalho está sendo transferido, de modo que a oportunidade de aprender e melhorar pode ser perdida. (Esta não é minha recomendação por esses motivos)
   3. A pior solução que vi foi que eles acabaram de marcar a história antiga CONCLUÍDA, talvez tenham reduzido os pontos, talvez não, e então abriram uma nova história para o trabalho restante (geralmente testando!). Esta é uma solução feia por qualquer padrão, IMHO.

O que eu focalizaria é o seguinte: "Um deles é um caso clássico" 90% concluído "com um número bastante grande de histórias" - a chave aqui é a GRANDE história! Lembre-se de INVEST: as histórias devem ser PEQUENAS. A equipe deve olhar para a divisão de histórias (preferida) ou para enxameando-as. Mas maior sempre significa mais risco, mesmo quando pululando.