Superestimação e replanejamento do Scrum

Estamos no meio do nosso primeiro Sprint e algo nos amanhece: superestimamos!

Planejamos 114 horas ideais para essa iteração de duas semanas e, no final da primeira semana, finalizamos todo o Sprint. O que fazemos agora? O "livro" diz que deveríamos obter os próximos itens de alta prioridade do backlog. No entanto, como os adicionamos ao gráfico de gravação? Nós a reescrevemos para dar conta dessas histórias como se elas estivessem lá desde o início? Ou simplesmente adicione suas estimativas ao eixo y no dia em que começamos a trabalhar nelas (mostrando um salto de ângulo de 90o)?

Qualquer feedback é bem-vindo!

Um dos objetivos de ter um gráfico de burndown é mostrar como, com o tempo e com transparência, o valor está sendo oferecido.

As histórias dos novos usuários não estavam no sprint no início, então parece um pouco complicado fingir que estavam. Ao adicioná-los ao gráfico de burndown no momento, você mostra com precisão que o nível atual de estimativa ainda está um pouco em suas fases evolutivas preliminares.

Isso é bom para você e para o proprietário do produto. Ele mostra e mostra como o uso desse sistema de gerenciamento de projetos tem e permitirá que você se torne um avaliador melhor.

Você será capaz de ver desde o início que estava superestimando, depois subestimando, depois superestimando um pouco mais, mas um pouco menos ... e, eventualmente, verá as melhorias na estimativa à medida que avança.

Acho que estimar as histórias de usuários é uma das partes mais difíceis de um sprint e somente quando sua equipe aprender a evoluir juntas elas se tornarão cada vez mais eficientes no processo. É bom que isso seja demonstrado através das ferramentas que você está usando, como o gráfico de burndown.

Não vai doer se você cancelar o sprint e planejar o próximo sprint levando em consideração sua velocidade atual.

No Guia oficial do Scrum :

Os sprints podem ser cancelados antes que a caixa de tempo do Sprint termine. Somente o Dono do Produto tem autoridade para cancelar o Sprint, embora possa fazê-lo sob influência das partes interessadas, da Equipe ou do ScrumMaster.

Como o planejamento do sprint deve ser realizado em uma discussão com o proprietário do produto, o mestre do scrum e a equipe, seria contraproducente simplesmente escolher as próximas histórias de usuários.

No caso de você ter adiantado um pouco, poderia ter escolhido a próxima história com maior prioridade, mas aqui a sua situação é muito diferente.

Você pode adicionar um gráfico de gravação . Eles mostram, sem ambiguidade, quando e quanto novo trabalho você adicionou:

Este gráfico mostra que a equipe adicionou mais 20 pontos de trabalho na iteração 5. Esta imagem mostra iterações, mas funciona da mesma maneira com dias.

Existem várias técnicas diferentes para visualizar isso.

Uma delas é introduzir um deslocamento no eixo y (o eixo horizontal) no dia em que as novas histórias foram adicionadas, com o gráfico de burndown real indo abaixo do nível "0" original.

Outra é fingir que eles estavam lá desde o início (o que é muito mais fácil de você usar gráficos de burndown baseados em CGI).

E você pode criar o seu próprio.

O mais importante é discutir isso entre equipe, mestre do scrum e proprietário do produto para chegar a um acordo sobre o que você deseja fazer nessa situação. Não há uma maneira absolutamente fixa de fazer algo no scrum além das regras básicas. O Scrum deve evoluir ao longo do tempo para melhor atender às necessidades do seu ambiente.

Eu gostaria de dividir o problema do OP em três perguntas distintas:

1. Continuar ou cancelar o sprint?
2. O que fazer na semana restante se o sprint continuar?
3. Como planejar o próximo sprint?

Os gráficos de burndown e burn-up mencionados em outras perguntas, embora úteis, são secundários aos "O que fazemos agora?"

Continuar ou cancelar : estou com Pierre aqui, é apropriado cancelar este sprint e começar a planejar o próximo imediatamente. O cancelamento do sprint não é uma opção se houver outras equipes e os sprints precisarem ser sincronizados (a maioria dos gurus do Scrum recomenda que eles sejam sincronizados).

Se o sprint continuar: Limite o trabalho em andamento . Trabalhe em apenas uma história de cada vez, com foco em finalizações, para as quais você tem menos de uma semana. Verifique se não há histórias em um estado parcialmente finalizado no final do sprint.

Como planejar o próximo : as opções aqui são tentar a estimativa do tamanho relativo ou usar a equivalência da história-ponto-pessoa-dia e o fator de foco como uma aproximação, conforme descrito no livro "Scrum e XP das trincheiras" de Henrik Kniberg. Já discutimos isso em um tópico diferente.

Concluir na metade do tempo é uma enorme variação das estimativas. Para mim, isso indicaria um risco significativo de que o que sua equipe realmente fez se desvie do que os usuários esperavam no início do Sprint. Além disso, um Sprint também deve fornecer funcionalidade suficiente para que agora seja hora de receber novos comentários do OP.

Portanto, o risco de apenas pegar coisas do topo do PB e continuar é que esses itens no topo do PB estão desatualizados (tanto em conteúdo quanto em prioridade), e que sua Equipe tenha entendido algo errado no último Sprint e você continuará desenvolvendo esses erros sem receber feedback do OP.

Eu diria que o curso de ação mais razoável é encerrar a Sprint, realizar seu final habitual de revisão da Sprint, planejar reuniões e retrospectivas e iniciar a próxima Sprint.

Quanto ao material do gráfico de burndown, a pergunta original parece não entender o objetivo. É realmente apenas uma ferramenta para determinar se você está tendo problemas com o progresso durante o seu Sprint. Com o que foi descrito, o gráfico de burndown deveria ter entrado em jogo nessa situação nos dias 2 ou 3 do Sprint, quando mostraria que a equipe estava muito adiantada no cronograma das tarefas do Sprint. Em seguida, você faz a pergunta "Por quê?" E determina se suas estimativas estão muito longe ou se os programadores estão interpretando mal as tarefas ou se algo está saindo dos trilhos de alguma forma.

Mas quando você ignora o gráfico de burndown e navega como se não houvesse nada de estranho, parece que você está apenas tratando-o como um artefato inútil que está produzindo porque o "livro" diz para você. Na minha opinião, se você decidir retirar mais algumas coisas do topo do OP e continuar pela segunda semana, inicie uma nova burndown pela segunda semana (e poderá ignorar como fez para a primeira semana).

Eu consultava o proprietário do produto sobre o trabalho a ser feito e o adicionava ao sprint atual na data em que o trabalho foi realizado. Pode-se acompanhar o trabalho adicional no gráfico de queima. Não tenho problemas com um gráfico de gravação que parece um pouco com uma montanha-russa. Isso acontecerá de qualquer maneira, pois os membros do scrum estimam o tempo restante nas tarefas.