Analisar as estatísticas de performance da sua equipe, hoje é um passo fundamental para ajudá-los a desenvolverem melhores projetos e produtos. Nessa série nós vamos entrar nos detalhes para ajudá-lo a interpretar os relatórios ágeis do JIRA Software. Vamos iniciar a série entendendo como interpretar o Version Report.

  

Entrando de cabeça no JIRA Version Report

Após muitas horas de estudo sobre o Version Report, muitas dúvidas sobre como interpretar os seus dados e previsões plainaram sobre minha mente. Saber como que esses dados são realmente afetados, e como projetar as previsões de formas realistas baseado no desempenho da minha equipe. Muitas investigações depois, trago esse blog post para compartilhar tudo o que aprendi sobre o JIRA Version Report.

Como que a velocidade do time é calculada

Uma das partes fundamentais para poder entender as projeções de entrega da versão nesse relatório, é o entendimento de como calcular a velocidade desempenha pelo time até a data corrente da versão. Esse cálculo considera o número de dias úteis trabalhados e o total de story points (ou outra estatística de estimativa) para poder determinar a velocidade média do time por dia. Importante se atentar que esse leva em consideração o número de dias baseado na data de início da versão (Start date da versão), e não de uma sprint.


Explicando a estratégia de projeções

O processo seria o seguinte:

  • Conte o número de dias desde que a versão foi iniciada até a data atual (obs: Data de início da versão, não da sprint)
  • Identifique a quantidade de pontos completados até a data corrente
  • Agora é só dividir o total de pontos completados / pelo número de dias úteis trabalhados na versão até a data corrente, e você terá a velocidade estimada por dia (estimativa(pontos/horas, etc).
  • Para projetar, basta continuar adicionando esse número da velocidade média por dia, até chegar no total de estimativa restante para completar toda a versão.

(info) Se todas as semanas tiverem o mesmo número de dias úteis, essa projeção será linear.

Qual a importância de ter configurada a data de início da versão ?

Se o Fix Version no JIRA não tiver sido configurada a data de início da versão, então o gráfico começará a partir da data em que a Fix Version foi associado a uma tarefa. Se isso levar algum tempo antes do início do trabalho na versão, a data de início da versão deverá ser definida como a data de início da primeira sprint, na qual os problemas associados a essa versão de correção foram executados.

Abaixo segue um exemplo, em que o Product Owner definiu logo no começo a data de inicio da versão, enquanto ele planejava um novo conjunto de funcionalidades para equipe trabalhar. Perceba que demorou algum tempo até que a equipe realmente começasse a desenvolver qualquer uma das atividades em um sprint. Com isso o calculo de previsão de entrega dessa versão ficou previsto para o dia 27 de Outubro.


O gráfico acima estava usando para a data de início da versão o padrão em que o Fix Version foi associado com a primeira story. No gráfico abaixo, quando essa data de início da versão foi modificada para a data em que a equipe iniciou o desenvolvimento das story na primeira sprint, o gráfico se modificou, dando uma nova projeção de conclusão da versão para o dia 24 de Agosto.


Isso ocorre porque o primeiro gráfico incluía a velocidade de fevereiro a abril, embora a equipe não estivesse progredindo em nenhuma das stories. Como resultado, a previsão foi muito mais distante porque o Jira estava incluindo várias semanas de velocidade zero da equipe para a versão. Quando a data de início foi definida corretamente no início do primeiro sprint que incluiu essa versão, a previsão foi ajustada corretamente.

O que faz o gráfico curvar ?

Geralmente, a linha de previsão do gráfico tende a ser reta. No entanto, em algumas circunstâncias, a linha será curvada a partir da data corrente. Isso pode acontecer em qualquer direção, para cima ou para baixo, dependendo do evento que a causou. A seguir, vou explicar um pouco dos eventos simulados que podem causar essa curva no gráfico.

  1. Non-Working days

    Se houver mais dias não úteis definidos em um lado considerando a data corrente do que no outro, o gráfico será curvado de acordo, pois levaria um número diferente de dias no segundo plano para alcançar o mesmo número de pontos concluídos no plano anterior.

    Por exemplo, o gráfico irá curvar ligeiramente quando houver mais 'dias não úteis' no primeiro semestre, antes da data corrente, do que no segundo semestre.

  2. Fechando e reabrindo uma tarefa

    Este é um ponto em que existe um bug aberto na Atlassian (SWSERVER-11735) onde, em vez de subtrair os pontos das stories de um problema reaberto, ele continua adicionando-os. O que resulta na projeção incorreta, onde a velocidade assume que a equipe irá acelerar nas próximas semanas e atingir a meta mais rapidamente. Isso significa que as tarefas fechadas que são reabertas fazem com que a linha se curve para cima.
  3. Removendo o fix version de uma tarefa fechada

    Remover a versão de correção de um problema que já está fechado faz com que a linha seja curvada para cima. (Isso não acontece com problemas que estão abertos, apenas com aqueles que já estão fechados quando a alteração é feita.)

    Vale a pena ser muito cauteloso sobre esses eventos, já que a curva no gráfico geralmente não é reversível. Para exemplificar, abaixo segue um gráfico proveniente do resultado da remoção da versão de correção de várias stories fechadas.


Como as mudanças de escopo são tratadas?

As mudanças no escopo, além daquelas descritas acima, parecem ser tratadas de maneira consistente e esperada. Isso inclui o seguinte:

  • Aumentar / reduzir os pontos de uma story
  • Adicionando uma tarefa à versão de correção ou removendo a versão de correção de um tarefa aberta

Quando tal alteração é feita, isso altera o escopo de destino no lado direito do gráfico, de forma que a linha de previsão se intercepta em um ponto anterior ou posterior, fornecendo assim uma data de previsão atualizada. Veja o exemplo a seguir, em que o escopo foi reduzido, fornecendo uma previsão anterior para conclusão:

Conclusão

O version report, é um relatório muito útil para poder obter previsões a cerca de como sua equipe esta progredindo, e realizar projeções a cerca da entrega de uma versão. Por isso é muito importante entender de forma consistente como que esse relatório é construído. Espero que esse blog possa ajuda-lo nas suas previsões de lançamento das suas versões.


Fonte: https://community.alfresco.com/community/ecm/blog/2015/07/29/inside-the-jira-version-report


Gostou do post? Compartilhe e siga nossas Redes Sociais 


Posts