Gráficos de queimaduras de scrum, eles podem ser negativos? [fechado

Question

Trabalho em uma pequena equipe de desenvolvimento ágil, que faz parte de uma grande corporação que não é aciliadora. Atualmente, praticamos scrum e, ocasionalmente, excedemos nosso compromisso de sprint.

Minha pergunta é: como você lida com gráficos de queimaduras quando excedeu seu compromisso de sprint? Eu posso pensar em duas opções:

• Estenda o eixo y na direção negativa e continue contando
• Adicione mais cartões/histórias/trabalho e faça com que o valor da queima aumente nessa quantidade, queimando quando esse trabalho estiver concluído.

A solução final para minha equipe é clara para o negócio e agrega valor real aos desenvolvedores. Até agora, nenhuma dessas soluções funcionou perfeitamente.

Answer 1

Na minha opinião, os gráficos de Burndown não podem ser negativos. Se você terminou seu trabalho, continua sentado em suas cadeiras, não significa que o Burndown permanecerá em zero.

Se você realmente faz algo, isso deve ser adicionado à sua lista de tarefas, o que significa que o Burndown aumentará e depois descerá novamente quando terminar as tarefas que você adicionou à carga de trabalho do seu sprint.

Um sprint onde a carga de trabalho original foi concluída antes que o sprint termine deve mostrar um pouco de pico quando novas tarefas (tarefas únicas, por exemplo, correções de bug ou qualquer outra coisa ou uma ou mais novas histórias de usuários) foram adicionadas novamente quando ficou claro que há espaço para mais.

No entanto, se isso acontecer com frequência com sua equipe, você parece estar constantemente subestimando sua velocidade e deve começar a se comprometer com mais tarefas desde o início. Não estou dizendo que é uma coisa ruim poder terminar mais cedo e assumir mais tarefas, mas se isso acontecer em muito sprint, é um sinal de que a equipe está se comprometendo desde o início, por acidente ou para fazer Com certeza, não há como eles falharão no sprint.

Se estiver tudo bem com o proprietário do seu produto, que assim seja. Se eu fosse o proprietário do produto e veria uma equipe sempre terminando cedo, tentaria fazê -lo se comprometer com mais tarefas desde o início. Isso pode parecer um pouco mais duro do que se destina a soar.

Answer 2

Burndowns mostra o escopo permanecendo dentro de um compromisso. Se você adicionar algo ao seu compromisso, porque você entrega demais, adicionará-o ao número que está gravando no gráfico. Como resultado, uma equipe que entrega demais terá um queimaduras que se dirige em direção a zero e depois paira até o final da caixa de tempo.

Para mostrar o que você está realmente entregando, considere um diagrama de fluxo queimado ou cumulativo.

EDITAR

• As queimadas mostram o trabalho restante para completar "Something" (um sprint, um lançamento, um mmf/"épico" etc.)
• As queimaduras mostram acúmulo de "algo" (valor comercial ganho, superar a complexidade, etc.)
• Os diagramas de fluxo cumulativos mostram os dois + fornecem informações sobre a qualidade do seu processo

Answer 3

Quando adicionamos mais itens ao sprint, atualizamos o estimativa do trabalho restante Para refletir isso no gráfico de Sprint Burndown:

ALT TEXTO http://www.movingsummit.co.uk/images/burndown_chart.jpg

Mas como apontado em outras respostas, isso mostra que o estimativa do trabalho restante mudou, não o motivo (acabamos de reestimar o trabalho ou adicionamos trabalho?) E não o acúmulo de trabalho realizado. Isso pode não ser um problema.

Para representar o acúmulo de trabalho realizado, um gráfico de queimadura é mais apropriado (usamos um gráfico de queimadura no nível de liberação). Uma queima contra a carga de trabalho permite representar o progresso do trabalho realizado e também um aumento ou diminuição dos requisitos (e como isso afeta a previsão de conclusão):

ALT TEXTO http://www.movingsummit.co.uk/images/burnup_chart.jpg

Answer 4

Estender o eixo y deixa muito claro para todos que você está indo além do gol do sprint. Normalmente, não é um grande problema, porque você não passa muito.

Se isso se tornar uma ocorrência regular ou se você passar por uma quantidade significativa, há algo errado com seu processo de estimativa. Talvez você seja excessivamente cauteloso ao lidar com o lado "não-Agile" do negócio. Tente trazer todo mundo para o passeio.

Answer 5

Estendendo o eixo y do gráfico de Burndown abaixo de zero é uma prática bem estabelecida para rastrear liberar progresso.

Gráfico de Burndown de lançamento de amostra

Na imagem vinculada, você pode ver o gráfico de Burndown de liberação - tudo o que é adicionado para lançar o escopo vai além do zero.

Eu não recomendaria fazer exatamente a mesma coisa para correr o gráfico de queimaduras. Você deve simplesmente adicionar um novo trabalho ao trabalho restante e, obviamente, sua queimadura aumentará por um tempo. Se você estiver usando o quadro branco para apresentar seu gráfico de queimaduras do sprint, é uma boa idéia rotular o local a tempo em que você adicionou novas histórias/requisitos com comentários adequados. Dessa forma, será perfeitamente visível o que aconteceu e por que sua queima subiu.

Answer 6

Se você está persistentemente negativo com a queima, isso indicaria que você está constantemente estimando demais, terminando assim seu trabalho "muito cedo". Para corrigir isso, comece a multiplicar a estimativa por um fator inferior a 1 (ou seja, 0,75, 3/4) (esqueço o termo correto para isso - é "escala"?). Faça isso por um sprint ou três, veja como isso afeta o resultado, pode levar algumas iterações para obter o fator certo para cada desenvolvedor. Isso significa que você poderá se encaixar mais dentro do sprint regular e não deve terminar mais cedo.

Answer 7

Eu imploro para discordar aqui :-) Tente considerar o seguinte cenário: a equipe começa a trabalhar em uma história e perceba que uma certa quantidade de trabalho não foi planejada e agora eles adicionam tarefas para concluir esse trabalho. O Burndown aumenta, mas não exatamente por uma boa razão, nesse caso não é mudança de escopo, mas é "estimativa errada", que da perspectiva da equipe não faz nenhuma diferença, pois a mensagem ainda é: "Esta é a quantidade de trabalho que precisa ser concluído ".

E o proprietário do produto? Quanto você deseja comunicar que entregou demais? Quanto é importante para a equipe distinguir os dois casos e usá -los na retrospectiva para analisar como melhorar as estimativas da próxima vez ou se comprometer com mais desde o início? Uma abordagem semelhante foi usada para definir o gráfico alternativo de Burndown (http://www.mountaingoatsoftware.com/scrum/alt-releaseburndown), assim, reestimando o gráfico e queimando mais, mostre claramente um escopo aumentado, e a queima pode ser a equipe descobriu novas tarefas enquanto começava a trabalhar em uma história em algum lugar do sprint ;-)

tchau
Andreat