roblemas de Burndown da Scrum [fechados]

Estamos usando o Scrum há cerca de 9 meses e foi amplamente bem-sucedido. No entanto, nossos gráficos de burndown raramente se parecem com os gráficos de 'modelo', em vez disso se assemelham a uma montanha-russa aterrorizante com algumas subidas e quedas induzindo vômit

Para tentar combater isso, estamos gastando mais tempo antes da criação e prototipagem do sprint, mas ainda parecemos descobrir muito mais trabalho durante o sprint do que se pensava inicialmente. Nota: com isso, quero dizer que o trabalho necessário para atender à lista de pendências está mais envolvido do que se pensava, em vez de identificarmos novos itens para a lista de pendência

Este é um problema comum com o Scrum e alguém tem alguma dica para ajudar a facilitar o percurs

Devo salientar que a maior parte do nosso trabalho de desenvolvimento não é greenfield, por isso mantemos a funcionalidade em um aplicativo grande e complexo existente. O scrum é menos adequado para esse tipo de desenvolvimento simplesmente porque você não sabe quais problemas o código existente apresentará?

Quanto tempo devemos gastar antes que o sprint comece a trabalhar nos detalhes do desenvolviment

UPDATE: Estamos tendo mais sucesso e um passeio mais suave agora. Isso ocorre principalmente porque adotamos uma visão mais pessimista ao estimar o que está nos dando mais espaço para lidar com as coisas quando elas não planejam. Você poderia dizer que isso nos permite ser mais 'ágeis'. Também estamos tentando mudar a percepção de que o gráfico de queima é algum tipo de cronograma, em vez de uma indicação do escopo v recurso

questionAnswers(22)

yourAnswerToTheQuestion