Nessa série 4, vamos ver os detalhes do Release Burndown, utilizado por times Scrum que trabalham com sprints. Essencial para identificar o quão rápido o seu time está trabalhando em relação ao backlog da release e poder projetar a quantidade de sprints futuras necessárias para completar o trabalho de entrega de uma release, baseada nessa velocidade.

Se você esta acompanhado essa nossa maravilhosa série, não deixe de ler também:

O que é o Release Burndown?

O Release Burndown vai ajudar você acompanhar como esta o progresso de trabalho do seu time para uma determinada release, ajudando você a monitorar se sua release irá ser cumprida no prazo ou se você deve tomar alguma ação para colocá-la nos trilhos.

Veja algumas maneiras para qual você pode utilizar a análise do Release Burndown Report:

  • Identificar o quão rápido o seu time está trabalhando em relação ao backlog de uma release
  • Identificar se foram adicionados ou removidos trabalhos durante a sprint e como esses afetaram o progresso do seu time
  • Prever quantas sprints futuras você necessitará para completar o trabalho de uma versão, baseado na velocidade da equipe nas sprint passadas.



Compreendendo o Release Burndown

Vamos compreender o que significam as principais informações a serem analisadas no gráfico

  • Seção Verde Claro - representa o total e trabalho completado na sprint. 
    (info) Se uma barra estiver totalmente verde clara você não poderá afirma quanto trabalho foi completado em relação ao Original Estimate. Você vai precisar clicar na barra pra ver os detalhes.
  • Seção Azul Claro - representa o trabalho remanescente para versão, em relação ao total estimado para versão no início da Sprint
  • Seção Azul Escuro - Representa o trabalho adicionado durante a sprint, que não foi originalmente incluso. (representa uma mudança de escopo)
  • Seção Verde Claro + Seção Azul Claro - Representa o total de trabalho estimado no início da sprint.
  • Seção Azul Claro + Seção Azul Escuro - Representa o total de trabalho na versão, que remanesceu no final da Sprint.

Como é feito cálculo de previsão das sprints futuras com o Release Burndown Report ?

A previsão das Sprint é calculada baseada na velocidade do time (são sempre consideradas as 3(três) últimas sprints), e o total de trabalho remanescente no seu backlog. 

(info) O escopo adicionado não é considerado para o cálculo da velocidade do time, mas esse é considerado no total de trabalho remanescente.

Vamos calcular o exemplo abaixo:

  1. Análise o trabalho realizado:
    Remanesceram 26 Story Points para versão antes do início da sprint corrente (sprint 5)

    Perceba que no topo do release Burndown report, nesse cenário ele está indicando 22 Story points restantes.

    Aqui ele já esta considerando que na sprint corrente serão subtraídos 4 story points (velocidade prevista do time)

  2.  Calcule a velocidade do time:
    Para calcular a velocidade do time, você deve somar o trabalho realizado pelo time nas 3(três) ultimas sprints.
    Nesse cenário foram 11 Story points (sprint 2, Sprint 3 e Sprint 4). agora que você tem o total completado nas 3(três) ultimas sprints, divide por 3(três) e vai chegar na velocidade média do time. 11/3 = 3,6666 → 4 Story Points por sprint.
  3. Calcule a previsão de sprints necessárias para completar o trabalho restante da release:
    sabendo que a velocidade do time é de 4 story points por sprint, e restam 26 story points para serem completados, é possível fazer o cálculo para saber quantas sprints serão necessárias. Vamos ao cálculo.
 A minha sprint corrente conta quando é calculada a velocidade do time ?

Usualmente a sprint corrente não conta quando é calculada a velocidade do time.
Nesse exemplo acima a sprint corrente mostra as barras em cinza (como barras de sprints previstas) para representar isso. 

A exceção é quando você já completou mais trabalho na sprint corrente do que o trabalho calculado previsto para as sprints seguintes. Nesse caso a sprint corrente(e o atual trabalho completado) é usada como uma das 3(três) sprints para calcular a velocidade do time. Então a barra da sprint ira ser exibida na cores verde claro e Azul, como barras de uma sprint completada.

Por exemplo, nesse gráfico acima, se o time tivesse completado mais de do que 4 story points na sprint 5, então o trabalho completado nas sprints 3, 4, e 5, seria utilizado para calcular a velocidade, ao invés das sprints 2, 3 e 4.

Outras funcionalidades e dúvidas em relação ao comportamento do Release Burndown report

Vamos ver abaixo as principais duvidas a cerca do Release Burndown. Expanda os tópicos abaixo para visualizar os detalhes:

 Porque que as datas da primeira e última sprint no meu relatório não são as mesmas de início e fim das datas das releases configuradas na minha versão?

Start date e Release date configurado para versão são exibidos abaixo do relatórios como Planned start date Planned end date. No entanto essas são datas planejadas, e não determinam o início e fim da sprint que exibida no relatório.

  • Inicio da Sprint mostra a primeira tarefa na versão que foi transicionada do status "To do". Por exemplo, teve seu trabalho iniciado na versão.
  • Fim da Sprint mostra quando o trabalho é concluído para versão, ou se houver trabalho remanescente, então o(s) sprint(s) previsto(s) quando o trabalho será concluído.

Info (i) O mapeamento dos status no seu board determina quando uma issue é considerada 'To Do" ou "Done".

 Como que a percentagem de tarefas não estimadas afeta o relatório ?

O Release Burndown report pode apenas realizar as previsões baseado em tarefas estimadas da sua versão. Se você tem uma alto percentual de tarefas não estimadas, as previsões no relatórios não serão realistas. O label % unestimated issues vai ficar na cor vermelha quando o percentual for a cima de 30%, para alertá-lo disso.

Por exemplo, se você tem apenas 10% das tarefas estimadas na versão, então as previsões no relatório para completar o trabalho na versão serão baseados nos 10% do total das tarefas. Na realidade provavelmente o seu time tenha muito mais trabalho para completar.

 Quais mudanças afetam o Original estimate e quais mudanças afetam o escopo (Work added)?

As seguintes mudanças afetam o original estimate da sprint:

  • Se uma tarefa em uma versão (depois que a sprint é iniciada) é estimada (estimativa é adicionada)
  • Se uma tarefa em uma versão (depois que a sprint é iniciada) é re-estimada (Estimativa modificada)

As seguintes mudanças afetam o escopo da sprint:

  • Se uma tarefa é adicionada para uma versão (depois que essa foi iniciada) com uma estimativa existente.
  • Se uma tarefa que foi adicionada para uma versão (depois que essa foi iniciada) é estimada (estimativa adicionada)
  • Se uma tarefa que foi adicionada para uma versão (depois que essa foi iniciada) é re-estimada (estimativa modificada). Observe que, se o problema for re-estimado em um sprint posterior, o escopo será retroativamente ajustado no sprint ao qual o problema foi originalmente adicionado.
 Se o trabalho for concluído fora da sprint, como este é representado?

Qualquer alteração (Burndown ou Escopo) que ocorrer fora da Sprint ira ser exibida como parte da sprint com a ultima data de inicio depois da mudança da data.

 Se um tarefa concluída é reaberta ou adicionada/removida de uma versão, como isto é representado?

Se uma tarefa concluída em um sprint for reaberta:

  • A tarefa não será mostrada na sprint anterior.

Se uma tarefa é concluída em uma versão, mas removida da versão depois:

  • O escopo permanecerá inalterado e o trabalho concluído ainda será exibido.

Se uma tarefa é concluída em uma outra versão ou sem uma versão, mas depois é inclusa em uma versão.

  • O escopo irá permanecer inalterado.

Se uma tarefa é conlcuida em uma sprint, mas é adicionada a uma versão depois:

  • A tarefa sera exibida no relatório, como se fosse sempre parte da versão.
 O que acontece se minha tarefa estiver em um status não mapeado?

Se sua tarefa esta em um status não mapeado (não foi mapeado para uma coluna do board), este não será considerado no Release Burndown Chart, nem será incluso no sprint bar, % unestimated issue, remaining story point, etc.


Espero que possam ter aproveitado as dicas e cenários abrangidos para o Release Burndown. Nos vemos no próximo blog da série. Ótimo planejamento e controle a todos. (big grin)

Fonte: Jira Software Server - Release Burndown


Gostou do post? Compartilhe e siga nossas Redes Sociais 

Posts