Módulo de Métricas: Times

Introdução

A página inicial do Modulo Métricas é a página de times ela mostra uma visão do desenvolvimento dos times através do tempo. É possivel através desta página verificar a maturidade do time através da matriz de maturidade e acessar diversas métricas de desenvolvimento acessando a página do VSM (Value Stream Mapping). Esta visão permite ao usuário ter um maior controle sobre os diversos contextos que abrangem os seus times e desta forma tomar medidas para sua evolução.

Página Inicial

A página inicial do módulo Métricas é a página de Times. Ela é composta por: um select de escolha de matriz; um gráfico onde é possível visualizar a matriz selecionada e uma lista de todos os times da organização.

Matriz

A matriz é composta de categorias e indicadores que podem ser personalizados conforme a necessidade da organização. Para cada indicador é possível agregar um valor e com isso gerar uma pontuação geral para cada time. A página inicial de Times mostra um gráfico com esta pontuação através do tempo, onde cada linha representa um time da organização. É possível ainda, neste gráfico, visualizá-lo sem os valores, desativando o botão de alternância (toggle) de “Rótulo de dados” logo acima do gráfico. Isto permite uma melhor visualização da curva de evolução ou decaimento dos times. É possível ainda, que uma organização possua mais de uma matriz, sendo este o caso, pode-se alternar entre elas através do select “Escolha uma matriz”. Ao clicar sobre “Ir para Matriz”, abre-se a página de “Maturidade do Time”.

Lista de Times

Além da matriz, na página inicial de Times, é possível visualizar uma “Lista dos Times” da organização. Ao lado do nome de cada time tem 4 itens: o primeiro leva o usuário a página do Value Stream Mapping (VSM), que será discutida posteriormente; o segundo item funciona como um semáforo e mostra uma cor agregada a pontuação do time dentro do VSM, vermelho para uma pontuação baixa, amarelo para atenção e verde para uma pontuação boa. A pontuação que guia estas cores é configurada pela organização. O terceiro mostra a aderência, que é calculada através das respostas da matriz selecionada; e o quarto representado por um lápis é onde respondemos aos indicadores da matriz.

Ao clicar sobre o quarto item o usuário é direcionado para uma página onde é possível visualizar a matriz em gráficos mais pontuais, mostrando o resultado das respostas para os diversos indicadores e categorias da matriz. É possível também agregar valor a cada indicador que define a matriz selecionada. Para responder aos indicadores basta clicar neles na lista mostrada a esquerda da tela. Estes valores são utilizados na construção da matriz em relação ao tempo.

VSM

A página do Value Stream Mapping (VSM), tem por intuito mostrar diversos indicadores, cálculos e gráficos. Indicando o andamento e evolução dos times em relação as suas estimativas e entregas dentro do Sprints ou Períodos. Estes dados são buscados diretamente na plataforma gerencial do cliente, permitindo que os indicadores e gráficos estejam sempre atualizados e condizentes com a realidade.

Para começar a utilizar a página do VSM é necessário primeiro entender alguns fatores, como a adição, edição e exclusão do sprint/período, a personalização da página e suas configurações.

Adicionar uma Sprint ou Período

O primeiro passo é verificar para quais sprints ou períodos quer-se gerar os cálculos, é necessário então, adicionar um sprint ou período. Para isso, clica-se sobre adicionar e irá abrir um modal.

Para adicionar um sprint basta selecionar o checkbox superior e então buscá-lo através do seu ID ou nome. Estes dados devem ser iguais aos fornecidos na plataforma gerencial usada pelo cliente, pois é de lá que são buscados os dados para a realização dos cálculos. Já o período é adicionado selecionando-se o checkbox inferior e é necessário dar um nome a ele e definir uma data de início e de fim do período. Ao clicar em “Adicionar” o sprint ou período será adicionado à lista.

Editar uma Sprint ou Período

Ao clicar sobre o ícone de lápis, é possível editar a sprint/período. É aberto então um modal. Este modal permite: editar o nome do sprint/período; visualizar a data de início e fim do sprint e em caso de períodos é possível editar também estes valores. Definir um número de desenvolvedores e de QAs; e ainda colocar algumas observações.

Excluir uma Sprint ou Período

Ao clicar no ícone de lixeira, é possível excluir um sprint/período. Será então exibida uma mensagem, para validar a intenção do usuário e minimizando a possibilidade de exclusão acidental. Ao excluir um sprint/período ele não será modificado dentro da plataforma gerencial utilizada pelo cliente, assim se for necessário adicioná-lo novamente é só seguir o processo de adicionar sprint/período descrito anteriormente.

Se o sprint/período estiver carregado em uma aba não será possível excluí-lo, aparecerá uma mensagem de alerta para que primeiro se exclua a aba e depois tente novamente a exclusão.

Carregar Dados

Após adicionar sprints ou períodos, pode-se selecionar quais deseja visualizar e clicar em “Carregar dados”. Após esta ação, todos os sprints/períodos selecionados serão dispostos em abas. Ao carregar um sprint/período pela primeira vez, será feito uma busca de todos os dados necessários para a realização dos cálculos e montagem dos gráficos. Isto pode demorar um pouco, dependendo da quantidade de informações que o time possui em seu backlog.

Reordenar

Após o carregamento os dados, cada sprint/período será disposto em uma aba correspondente. Ao carregar mais de um sprint/período será também criado uma aba de comparativo que mostra diversos indicadores de comparação entre os sprints/períodos abertos nas abas. Este comparativo leva em consideração a ordem em que as abas de sprint/período estão, então, pode ser necessário reordená-las. Tanto para a utilização delas em comparativo, quanto para se ter uma melhor visualização a reordenação pode ser útil. Após clicar em “Reordenar” que fica abaixo da lista de sprints/períodos será aberto um modal, onde é possível arrastar os sprints/períodos para que fiquem na ordem desejada. Após selecionar a ordem o usuário pode clicar sobre “Cancelar” e a modificação não será aplicada ou sobre “OK” e então as abas aparecerão na nova ordem.

Configurações

Ao ser adicionada ao AI Cockpit, uma organização é configurada, porém é possível realizar algumas modificações por time se necessário, clicando em Configurações, abaixo da lista de sprints/períodos. As configurações são separadas em seis fatores: Básico, Tipos, Compromisso, Fluxo de Trabalho, Organização e Outros. Tem como objetivo guiar os cálculos executados para a realidade do time.

Após realizar qualquer modificação nas configurações é necessário recalcular todos os sprints/períodos para que eles possam ser atualizados com as novas configurações.

Personalizar

É possível ainda personalizar a página, para que sejam mostrados só os indicadores e gráficos desejados e definir em que ordem devem ficar dispostos. Para isto, é necessário clicar em "PERSONALIZAÇÃO"abaixo da lista de sprints/períodos. Será então aberto um modal para realizar estas configurações.

Esta página consiste em duas abas, onde é possível personalizar as abas de “Sprint/Período” e/ou a de “Comparativo”. Há também, duas colunas de “Ativos” e “Desativados”. Ao clicar sobre um item, ele é levado para a outra coluna. Todos os itens que estiverem na coluna de “Ativos” serão mostrados na página no VSM, enquanto os que estão na coluna de “Desativados” serão ocultados. Para ordenar os itens basta arrastá-los para o local desejado. Os itens mais acima serão mostrados primeiro na página do VSM, portanto terão um acesso mais rápido.

Depois de realizar uma modificação de personalização, é possível salvá-la com um nome, permitindo ao usuário armazenar várias personalizações. Isso facilita o acesso aos indicadores mais relevantes para sua realidade em diferentes contextos.

Aba de Sprint/Período

Após carregar um sprint/período será aberta uma aba contendo informações dos indicadores e gráficos. É possível realizar três ações relacionadas a esta aba. Através dos ícones mostrados no canto superior direito.

• 1 - Detalhe do Sprint - Clicar neste ícone abrirá um modal com as seguintes informações sobre o sprint/período aberto: Nome, Tipo de Compromisso, Data de Início, Data de Fim, Status, Desenvolvedores, QAs e Observações.
• 2 - Recalcular - Após carregar um sprint/período pela primeira vez, pode ser necessário recarregá-lo (por exemplo, alterações nas configurações ou atualizações do sistema). Para fazer isso, basta clicar neste ícone, e o processo de recarregamento começará.
• 3 - Descartar resultados - Clicar neste ícone removerá a aba, mas o sprint/período permanecerá na lista de Sprints/Períodos para ser carregado novamente, se necessário. Após fazer uma modificação de personalização, é possível salvá-la com um nome, permitindo ao usuário armazenar várias personalizações. Isso facilita o acesso aos indicadores mais relevantes para sua realidade em diferentes contextos.

Indicadores de Sprint/Período

Nesta seção, exploraremos todos os indicadores e gráficos exibidos na página de VSM, nas abas Sprint/Período, para facilitar uma melhor compreensão de seus contextos.

Pontuação do Sprint

Este indicador tem como objetivo avaliar o desempenho e o andamento do sprint/período em questão. São considerados cinco indicadores principais e seu cálculo consiste na média aritmética desses indicadores.

Pontuação do Sprint = (Somatória dos indicadores)÷5

Pontuação do Sprint = (9.90 + 7.59 + 10 + 6.99 + 5.00)÷5 = 7.9

Cada um dos cinco indicadores possui suas próprias regras e fórmulas descritas a seguir:

Ocorrência de Impedimentos

Este indicador varia de 0 a 10, sendo 10 um cenário onde não foram encontrados bloqueios durante o sprint ou período. Ele sofrerá uma queda de valor sempre que um item for bloqueado. Por isso, ele é inversamente proporcional à porcentagem de itens bloqueados (% Bloqueados).

Os dois indicadores, “I” e “T”, podem ser encontrados no card de Principais Indicadores, sob os nomes Total de horas dos itens bloqueados e Total de horas dos itens em Work e Wait, respectivamente.

Ocorrência de impedimentos = (100 - (309.26÷8092.86 x 100))÷10

Ocorrência de impedimentos = 9.62

Índice de Eficiência

Este indicador varia de 0 a 10 e mensura a relação entre:

• Quanto tempo os itens ficaram em etapas do fluxo onde há agregação de valor (WORK).
• Quanto tempo os itens ficaram em etapas do fluxo onde NÃO há agregação de valor (WAIT).
• Quanto tempo os itens ficaram em etapas do fluxo onde há agregação de valor (WORK), porém bloqueados.

(100 - ((A+C)÷(B+C) x 100))÷10

A = Tempo de todos os status em "WAIT" B = Tempo de todos os status em "WORK"e "WAIT" C = Tempo em que os itens ficaram bloqueados em status de "WORK"

O tempo bloqueado C é adicionado tanto no numerador quanto no denominador, já que o bloqueio é tratado como uma parte significativa que afeta tanto o "WAIT"quanto o fluxo geral.

Índice de Eficiência = (100 - ((1333.3 + 0)÷(5535.96 + 0) x 100))÷10

Índice de Eficiência = 7.59

Os valores podem ser alterados devido a uma configuração nos cálculos do time. Se o cálculo de Eficiência estiver ativado, apenas os tipos de issues utilizados neste indicador irão fazer parte do cálculo do índice de eficiência. Caso esteja desativado, os valores serão baseados em todos os tipos de issues que fazem parte do compromisso.

Neste indicador podemos visualizar uma listagem das issues que foram bloqueadas durante a Sprint/Período. Ao clicar no ícone azul ao lado do valor, é exibido um modal com detalhes como Tempo de Bloqueio, Status de Bloqueio e o Status atual.

Para uma melhor compreensão do cálculo e de quais issues estão sendo utilizadas é possível ver o detalhamento das issues, clicando sobre o ícone azul apresentado no card. Isto abrirá um modal.

Ao clicar sobre o Issue-Key associado a issue desejada, o usuário será direcionado para sua plataforma gerencial e poderá ver a issue em questão. É possível ainda realizar um filtro para mostrar apenas as issues que estão em bloqueio ou não.

Defeitos durante o Sprint/Período

Este indicador varia de 0 a 10 e mensura a quantidade de defeitos encontrados no sprint ou período. O valor de 10 representa um cenário onde não foram encontrados story bugs ou sub-bugs, este valor decairá sempre que um for encontrado.

Na área de compromisso das configurações do time, há um botão de alternância (toggle) que ativado ou desativado, altera os tipos de issues inclusas para este indicador. No caso do toggle estar habilitado, as issues referentes a task e bugs serão incluídas no cálculo de defeitos durante o Sprint/Período.

(100 - (D x 100)) / 10

Quando desativado "Personalizar Cálculo de Defeitos" D = (Total StoryBug / (Total Story + Total Debt Tech + Total Melhoria))

Quando ativado "Personalizar Cálculo de Defeitos" D = (Total StoryBug / (Total Story + Total Debt Tech + Total Melhoria + Total Task + Total Bug))

Defeitos durante o Sprint = (100 - (0 x 100)) / 10

Defeitos durante o Sprint = 10

Compromisso Atingido

Compromisso são todos os itens que foram propostos a serem entregues durante um tempo determinado, que pode variar de acordo com o processo ágil utilizado. A ferramenta disponibiliza três tipos de cáculo: Scrum, Kanban por Percentil de Process Time e Kanban compromisso entregue por estimado.

Este indicador varia de 0 a 10 e mensura a completude dos itens que fazem parte do compromisso da sprint ou período. Ao clicar sobre o ícone azul mostrado no card é possível ver detalhes das issues incluídas no cálculo além de conseguir filtrá-las por concluídas ou não.

Scrum

O cálculo é baseado na porcentagem de conclusão do compromisso (% Conclusão), encontrado junto dos indicadores de compromisso.

C÷D x 100)÷10

C = Compromisso ENTREGUE

D = Compromisso ESTIMADO

Os dois indicadores utilizados para compor a pontuação do Compromisso Atingido, podem ser encontrados no card Indicadores de Compromisso. Sendo o C o número de Story Points Planejados e o D o número de Story Points realizados.

Compromisso Atingido = (58÷83 x 100)÷10

Compromisso Atingido = 6.99

Kanban

O cálculo Kanban pode ser feito de duas formas, para alternar entre elas é necessário modificar o botão de alternância (toggle), que é encontrado na página Admin > Organizações > Parâmetros VSM na aba Organização com o nome Compromisso Kanban. É necessário ter permissões de administrador para realizar esta alteração.

Kanban por Percentil de Process Time

Se o toggle estiver habilitado, irá contabilizar somente as issues que tem o tempo de Process Time menor ou igual à média do Percentil do Process Time dos últimos 3 Períodos. Esse valor pode ser visto nos Demais Indicadores.

Segue a fórmula de como é feito o cálculo Kanban por percentil de Process Time:

(C÷D x 100)÷10

C = Quantidade de itens entregues dentro do percentil do Process Time (Compromisso Realizado)

D = Quantidade de itens entregues no período atual (Issues Concluídas)

Kanban compromisso entregue por estimado

Se o Toggle estiver desabilitado o cálculo será semelhante ao do Scrum, porém é necessário realizar a configuração do “modo de controle do compromisso”, para considerar a lista de início do Kanban + Lista de tipos.

É necessário, também, definir nas configurações o campo “Status de issues que dão início ao compromisso do Kanban”.

(C÷D x 100)÷10

C = Quantidade de itens entregues dentro do percentil do Process Time (Compromisso Realizado)

D = Quantidade de itens entregues no período atual (Issues Concluídas)

Com estas configurações feitas, é possível realizar o cálculo. Pegando o exemplo mostrado na figura todas as issues que passarem pelos status To do ou To Do dentro do período selecionado serão consideradas como Compromisso Estimado. Enquanto, todas as issues finalizadas dentro do período serão consideradas as issues do Compromisso Entregue. Podemos então utilizar o cálculo mostrado abaixo para chegar ao indicador de compromisso atingido.

(C÷D x 100)÷10

C = Compromisso ENTREGUE

D = Compromisso ESTIMADO

Análise do Backlog de Defeitos

Este indicador varia de 0 a 10 e tem como objetivo mensurar o quão saudável está o backlog do produto em relação a defeitos (Bug). Esta pontuação pode ser feita de duas formas e para optar entre elas deve-se ter permissões de administrador. Então, é necessário ir na página Admin > Organizações > Parâmetros VSM na aba Organização e modificar o botão de alternância (toggle) de Backlog de Defeitos.

Quando o botão de alternância (toggle) estiver setado como não: O cálculo será composto pela análise 3 valores:

• Defeitos no backlog do time não vinculados ao Sprint/Período. São os BUG’s no backlog no primeiro dia do sprint/período.
• Defeitos criados durante o curso do sprint/período não vinculados ao Sprint/Período. São os BUG’s criados após o primeiro dia do sprint/período.
• Defeitos em correção no Sprint/Período. São os BUG’s em correção no sprint/período.

nota

É feita uma previsão considerando o ritmo atual projetando quantos sprints/períodos serão necessários para zerar o backlog de defeitos (Bug’s).

Quando o botão de alternância (toggle) estiver setado como sim: O Cálculo será feito da seguinte forma:

(100 - (((D+N)÷(E+N)) x 100))÷10

Onde:

D = Quantidade de defeitos não resolvidos no backlog

N = Quantidade de novos bugs cadastrados no período

E = Quantidade total de itens entregues no compromisso

Para validar os cálculos é possível pegar estes valores em “Demais indicadores”. Para isso, os mesmos, deverão estar habilitados nas configurações na lateral.

Principais Indicadores

Os Principais Indicadores, como o próprio nome sugere, representam os indicadores de maior relevância e importância para os cálculos e análises realizados durante as sprints ou períodos de trabalho. Neste painel, são apresentadas informações detalhadas sobre diversos parâmetros, como o total de horas dos itens em Work e Wait, os Story Points planejados, o Lead Time médio, o Queue Time médio, entre outros indicadores relevantes que o usuário configurar para que sejam exibidos na lista.

Atualmente, esta seção oferece quase 40 indicadores diferentes para análise, proporcionando uma visão abrangente e detalhada do desempenho da equipe.

Indicadores de Compromisso

O indicador de Compromisso refere-se à capacidade da equipe de cumprir suas promessas e compromissos dentro de um ciclo de trabalho, como um sprint ou período. Ele mede o quanto a equipe se comprometeu com as tarefas planejadas e a eficácia da entrega esses itens. Compromisso são todos os itens que foram propostos a serem entregues durante a sprint ou período.

• Itens que fazem parte do compromisso da Sprint;
• Itens que passam pelo Status configurado como status de comprometimento.

No módulo Métricas, é possível configurar o VSM para definir o compromisso, considerando três opções diferentes:

• 1. Apenas lista de tipos: o compromisso é determinado apenas pelo tipo dos itens configurados no campo “Tipos que fazem parte do compromisso”;
• 2. Considerar Flag e lista de tipos: compromisso é determinado pela lista de tipos combinado com um código de um campo específico na plataforma gerencial, esse código precisa ser configurado no campo “Nome do campo com a Flag do compromisso”;
• 3. Considerar lista de início do Kanban e lista de tipos:
  • O compromisso é determinado pela lista de status iniciada pelo status configurado no campo “Status de issues que dão início ao compromisso no Kanban”.
  • Combinado com o tipo dos itens configurados no campo “Tipos que fazem parte do compromisso”.

Conclusão do Compromisso

Este campo mensura em porcentagem a completude dos itens que fazem parte do compromisso da sprint ou período. Para isso são recuperados da plataforma gerencial dois dados:

• Somatória da estimativa contabilizada no compromisso quando a sprint ou período finalizou (Total);
• Somatória da estimativa concluída do compromisso na sprint ou período (Concluídos).

Com ambos os dados recuperados, realizamos o cálculo abaixo:

(Concluídos÷Total) x 100

Conclusão do Compromisso = (92÷115) x 100

Conclusão do Compromisso = 80

Compromisso Atual

Este campo indica o compromisso atual estimado no caso de Story Point, Relativa ou no caso de contagem de tickets informa os itens que entraram no compromisso. Quando a estimativa for Story Points ou Relativa este indicador exibe a variação de estimativa dos itens do compromisso da sprint/período através de dois dados:

• Planejados iniciais: Somatória dos story points ou relativa originais de todos os itens do compromisso atual da sprint ou período;
• Planejados finais: Somatória dos story points ou relativa atuais de todos os itens do compromisso atual da sprint ou período.

Nenhum cálculo adicional é realizado. Estimativas (Story Point/Relativa): Ainda referente a este indicador no caso das Estimativas Story Point ou Relativa é importante o seguinte esclarecimento: Para ambos os dados são considerados os itens que atualmente estão dentro da sprint independente se estes estão na sprint desde o início ou foram adicionados depois. Por este motivo, o primeiro dado não deve ser confundido com a quantidade de story points ou relativa que existia da sprint quando ela iniciou. Para um maior entendimento, veja o exemplo hipotético abaixo:

Uma sprint começa com 21 pontos com as histórias a seguir: A (8), B (8) e C (5). Após seu início, os seguintes eventos ocorrem na ordem a seguir:

• História D é adicionada com 3 pontos.
• História A é alterada para 13 pontos.
• História D é alterada para 5 pontos.

Com isso, o indicador story points/esforço planejados exibirá:

24→31

sendo:

24 = A (8) + B (8) + C (5) + D (3)

31 = A (13) + B (8) + C (5) + D (5)

Compromisso Realizado

Este indicador exibe o valor do compromisso concluído, isto é, a somatória todos as estimativas/itens concluídos do compromisso durante a sprint ou período. Esse dado é recuperado da plataforma gerencial. Nenhum cálculo adicional é realizado. Estimativas/itens:

• Estimativas quando usado “Story Point” ou “Relativa”;
• Itens quando usado “Contagem de tickets”.

Novos Compromissos

Este indicador mensura a quantidade de estimativas/itens* adicionados dentro do compromisso após o início da sprint ou período. São exibidos dois dados correlacionados:

• Somatória das estimativas/itens* adicionados ao compromisso após início da sprint ou período (Novos);
• Porcentagem das estimativas/itens adicionados ao compromisso após início da sprint ou período em relação ao número total das estimativas/itens do compromisso na sprint ou período.

Enquanto o primeiro é recuperado da plataforma gerencial, o segundo é obtido através de um cálculo simples de porcentagem.

Para calcular a porcentagem precisamos dos seguintes dados – já abordados:

• Somatória das estimativas/itens adicionados ao compromisso após início da sprint ou período (Novos);
• Somatória das estimativas/itens* atuais de todos os itens do compromisso atual da sprint ou período (Planejados Finais).

Uma sprint começa com 21 pontos com as histórias a seguir: A (8), B (8) e C (5). Após seu início, os seguintes eventos ocorrem na ordem a seguir:

• História D é adicionada com 3 pontos.
• História A é alterada para 13 pontos.
• História D é alterada para 5 pontos.

Com isso, o indicador story points/esforço planejados exibirá:

24→31

E o indicador novos story points/esforço exibirá:

10 (32.25%)

Sendo:

10 = (31 – 21)

32.25% = (10÷31) x 100

Variação de Estimativa – Estimativas (Story Point/Relativa)

Este indicador mensura a variação de estimativa dos story points/esforço planejados que – relembrando – são:

• Planejados iniciais: somatória dos story points/esforço originais de todos os itens do compromisso atual da sprint ou período;
• Planejados finais: Somatória dos story points/esforço atuais de todos os itens do compromisso atual da sprint ou período.

Com ambos os dados disponíveis, calcula-se a diferença (Variação) entre eles, e em seguida, procede-se com o cálculo:

(Variação÷Planejados Finais) x 100

Variação = 115 – 73

Variação = 42

Variação de Estimativa = (42÷115) x 100

Variação de Estimativa = 36.52

Compromisso Bloqueado

Este indicador mensura a quantidade das estimativas/itens atualmente bloqueados dentro do compromisso.

São exibidos dois dados correlacionados:

• Somatória das estimativas/itens atualmente bloqueados do compromisso na sprint ou período (Bloqueados);
• Porcentagem das estimativas/itens* bloqueados em relação ao número total das estimativas/itens do compromisso na sprint ou período.

Enquanto o primeiro é recuperado da plataforma gerencial, o segundo é obtido através de um cálculo simples de porcentagem.

Para calcular a porcentagem precisamos dos seguintes dados:

• Somatória das estimativas/itens* atualmente bloqueados dentro do compromisso (Bloqueados);
• Somatória das estimativas/itens* todos os itens quando a sprint ou período finalizou (Planejados Finais).

(Bloqueados÷Planejados Finais) x 100

Compromisso bloqueado = (3÷115) x 100

Compromisso bloqueado = 2.61

Compromisso Cancelado

Este indicador mensura a quantidade das estimativas/itens cancelados dentro do compromisso, isto é, a somatória das estimativas/itens dos itens cancelados do compromisso durante a sprint ou período.

Esse dado é recuperado da plataforma gerencial, mas sua visibilidade depende da configuração do VSM “Excluir issues canceladas do compromisso”. A configuração proporciona duas possibilidades:

• 1 - Quando configurado para não considerar itens cancelados no compromisso, o indicador exibirá “-”.
• 2 - Quando configurado para considerar itens cancelados no compromisso, o indicador exibirá a somatória das estimativas/itens cancelados.

Ainda referente à configuração do VSM para considerar ou não itens cancelados como parte do compromisso, é importante ressaltar que ele também altera o número das estimativas/itens planejados – e por consequência todos os indicadores que dependem dele.

Veja os exemplos abaixo:

• 1 - Não são considerados itens cancelados e temos um total de 356 story points planejados.

• 2 - Quando configurado para considerar itens cancelados no compromisso, o indicador exibirá a somatória das estimativas/itens cancelados.

Defeitos da Sprint/Período

Este indicador exibe a quantidade de defeitos abertos durante a sprint/período, também conhecidos como story-bugs ou sub-bugs. Esse dado é recuperado da plataforma gerencial, e então apresentado de acordo com a configuração do VSM de quais tipos devem ser tratados como story-bug. Nenhum cálculo adicional é realizado.

Sub-tasks Concluídas

Este indicador exibe a quantidade de sub-tasks concluídas durante a sprint ou período. Esse dado é recuperado da plataforma gerencial e então apresentado de acordo com a configuração do VSM de quais tipos devem ser tratados como sub-tasks. É importante ressaltar que este indicador não leva em consideração se as sub-tasks fazem parte ou não do compromisso.

Demais Indicadores

Os Demais Indicadores, representam indicadores complementares dos Principais Indicadores. Alguns indicadores estão presentes em ambos os quadros. Este painel exibe várias informações relacionadas a determinados parâmetros, servindo como complemento caso não estejam incluídas nos Principais Indicadores.

Issues – Bloqueio e eficiência

Este painel apresenta de forma detalhada os índices de bloqueio e eficiência que compõem a pontuação global da sprint ou período analisado, fornecendo uma visão clara sobre o desempenho e as métricas relacionadas.

Porcentagem de itens bloqueados

Este indicador mensura em porcentagem quantos itens estão atualmente bloqueados na sprint ou período. Para isso são recuperados da plataforma gerencial dois dados:

• Número de itens atualmente bloqueados na sprint ou período (Bloqueados);
• Número total de itens na sprint ou período (Total);

nota

Atualmente, no caso de sprints ou períodos já encerrados, considera-se que a tarefa permaneceu bloqueada até o momento de seu fechamento.

Com a recuperação de ambos os dados, procede-se ao cálculo conforme apresentado abaixo:

(Bloqueados÷Total) x 100

Bloqueados = (1÷26) x 100

Bloqueados = 3.85

Porcentagem que sofreram bloqueios

Este indicador mede, em termos percentuais, a quantidade de itens que foram bloqueados em algum momento durante a sprint ou período em análise.

Para isso são recuperados da plataforma gerencial dois dados:

• Número itens que sofreram bloqueios na sprint ou período (Bloqueios);
• Número total de itens na sprint ou período (Total).

Com a recuperação de ambos os dados, procede-se ao cálculo conforme apresentado abaixo:

(Bloqueios÷Total) x 100

% de Bloqueios = (3÷26) x 100

% de Bloqueios = 11.54

Porcentagem de eficiência

Este indicador mensura a eficiência com base no tempo dedicado a etapas que agregam valor, em comparação ao tempo gasto em etapas que não agregam valor.

Para isso, são recuperados da plataforma gerencial os seguintes três dados:

• Tempo de todos os status em ’WAIT’;

• Tempo de todos os status em ’WORK’ e ’WAIT’;

• Tempo em que os itens ficaram bloqueados em status de ’WORK’.

Com a recuperação dos dados, procede-se ao cálculo conforme apresentado abaixo:

(100 - ((A+C)÷(B+C) x 100))÷10

A = Tempo de todos os status em ’WAIT’

B = Tempo de todos os status em ’WORK’ e ’WAIT’

C = Tempo em que os itens ficaram bloqueados em status de ’WORK’

(100 - ((1756.38+309.27)÷(8092.87+309.27) x 100))÷10 = 7.39

A = 1756.38 horas (Wait)

B = 8092.87 horas (Work/Wait)

C = 309.27 horas (Bloqueio em Work)

Tempo de bloqueios

Neste quadro, são apresentados dois indicadores relacionados ao bloqueio e à eficiência do processo:Tempo Total de BloqueioeTempo Médio de Bloqueio.

• Tempo Total de Bloqueio: Refere-se à soma absoluta do tempo em que os itens estiveram bloqueados, sem qualquer tipo de cálculo adicional.
• Tempo Médio de Bloqueio: Calculado a partir da divisão do tempo total de bloqueio pelo número de itens bloqueados. No exemplo ilustrado abaixo, consideram-se três itens bloqueados, e, portanto, o tempo total de bloqueio é dividido por três, resultando no valor médio de bloqueio por item.

A imagem a seguir complementa essa explicação, ilustrando a aplicação dos indicadores mencionados.

Distribuição de Tickets

Este gráfico permite ter uma visão de quais tickets entraram na sprint/período selecionado. Ele permite ter uma visão de tickets por classe e por tipo, além de permitir filtrar apenas os tickets concluídos ou visualizar todos.

Fluxo Cumulativo de Status

O indicador de Fluxo Cumulativo de Status ou Cumulative Flow Diagram (CFD) é uma ferramenta visual utilizada para monitorar o progresso de um projeto ao longo do tempo. Ele ajuda a visualizar o estado do trabalho em diferentes fases do processo, facilitando a identificação de problemas e a otimização do fluxo de trabalho. Ao observar o tamanho das áreas no gráfico, é possível identificar onde o trabalho está acumulado. Um aumento significativo em uma área indica um gargalo, onde as tarefas estão sendo retidas e não avançam para a próxima fase. A área de "Concluído"deve aumentar gradualmente, indicando que a equipe está entregando o trabalho conforme planejado.

Distribuição do Trabalho em Andamento

O gráfico de Distribuição do Trabalho em Andamento proporciona uma visão clara sobre a quantidade de trabalho que está sendo assumida pelo time em um determinado momento. Idealmente, o volume de trabalho deve estar alinhado com a capacidade de entrega da equipe, permitindo que os integrantes se concentrem nas tarefas sem a necessidade de mudanças frequentes de contexto.

A recomendação é que o número de tickets em andamento seja aproximadamente equivalente ao número de membros da equipe. Quando o volume de tickets excede a quantidade de integrantes, há o risco de o time se envolver simultaneamente em múltiplas tarefas, o que pode resultar em perda de eficiência devido à troca constante de foco.

Por outro lado, quando o número de tickets em andamento é inferior ao número de membros da equipe, isso pode indicar que alguns membros não estão conseguindo atuar de forma independente nas tarefas, possivelmente devido à falta de demandas e/ou uma distribuição desequilibrada do trabalho

A imagem a seguir ilustra esse comportamento e contextualiza os diferentes cenários de distribuição de trabalho.

Indicadores de fluxo de trabalho

Os Indicadores de Fluxo de Trabalho são utilizados para avaliar se o volume de trabalho em andamento está adequado à capacidade da equipe. O objetivo é garantir que o time tenha uma carga de trabalho compatível com sua capacidade de entrega, de forma a maximizar a eficiência e minimizar desperdícios.

• Excesso de Trabalho em Andamento: Um número elevado de tarefas simultaneamente em andamento pode indicar que o time está passando muito tempo trocando de contexto entre as atividades, o que tende a resultar em perda de eficiência devido ao tempo gasto no chaveamento entre as tarefas.
• Insuficiência de Trabalho em Andamento: Quando o volume de trabalho é baixo, pode ser um indicativo de que a equipe não possui demanda refinada ou pronta para ser executada em quantidade suficiente, o que pode afetar a produtividade e o ritmo de entrega.

Esses indicadores ajudam a identificar desequilíbrios no fluxo de trabalho, permitindo ajustes que promovam uma entrega mais eficiente e contínua.

Alertas de Uso | Qualidade dos dados

Este quadro exibe Alertas de Uso relacionados à Qualidade dos Dados durante as transições de issues entre os diferentes status na ferramenta de gestão. Ele tem como objetivo monitorar a consistência e a precisão dos dados, garantindo que as informações registradas estejam corretas ao longo do processo.

Os alertas identificam possíveis inconsistências ou imprecisões nas informações, ajudando a garantir que o fluxo de trabalho seja refletido de maneira fiel na ferramenta e permitindo ações corretivas rápidas para manter a integridade dos dados.

Horas por status (em %)

Este indicador calcula a proporção de horas associadas a cada status em relação ao total de horas do tipo ao qual o status pertence. Os status do tipo work são proporcionais ao total de horas work, enquanto os status do tipo wait são proporcionais ao total de horas wait.

Essa métrica permite acompanhar a distribuição do tempo entre os diferentes estados do fluxo de trabalho, facilitando a análise da eficiência e alocação de recursos.

Status com wait

Os status de espera (ou wait) referem-se às situações em que os tickets permanecem aguardando a atuação do time. Quanto maior o tempo de permanência nesses status, menor será o indicador de eficiência da equipe. No gráfico a seguir, são apresentados os tempos correspondentes a cada status. A maior representação de um status no gráfico indica sua contribuição significativa para o aumento do tempo de entrega das issues e, consequentemente, para a redução da eficiência da equipe.

Caso um status de atuação (status work) seja exibido no gráfico, ele deve ser incluído na configuração "Status de Issues que Geram Valor (Work)", para que seja considerado como parte do trabalho efetivo, impactando positivamente no índice de eficiência. Por outro lado, se um status não representar uma fase de trabalho, mas sim uma situação em que a demanda ainda não está pronta para ser atendida (ex.: não foi priorizada, não está na fila), esse status deve ser incluído na configuração "Status de Issues que Devem Ser Excluídos do Cálculo da Eficiência", de modo que não seja contabilizado no cálculo da eficiência, pois não reflete atividades diretamente relacionadas ao processo de entrega.

Criticidade dos Defeitos

O painel "Criticidade dos Defeitos"apresenta uma visão sobre os defeitos encontrados durante o desenvolvimento da Sprint/Período e após a entrega.

Defeitos da Sprint são erros detectados durante a implementação das histórias ou sub-tarefas dentro da Sprint, classificados como, por exemplo, Story Bug ou Story Bug - Sub-task. Esses defeitos estão diretamente relacionados ao processo de desenvolvimento.

Defeitos de Produção, por sua vez, são falhas que surgem no ambiente de produção após a conclusão da Sprint, sendo classificados como Bug como um exemplo. Esses defeitos geralmente indicam problemas que não foram identificados antes da entrega e podem afetar a experiência do usuário final.

A distinção entre esses tipos de defeitos permite um acompanhamento eficaz da qualidade durante o ciclo de desenvolvimento e a operação do sistema.

Causa dos Defeitos

É um complemento da Criticidade dos Defeitos, detalhando as causas dos defeitos da sprint ou período, como também após as entregas.

Distribuição de Lead Time

O Lead Time é o tempo total entre a criação de uma issue e sua conclusão. Ele mede a eficiência do processo de entrega, indicando quanto tempo a equipe leva para transformar uma demanda em uma entrega finalizada.

A contagem do Lead Time começa no momento da criação da issue ou em outro evento configurado, como a entrada em um status de trabalho, e termina quando a issue é concluída. A plataforma utilizada para gerenciar o fluxo de trabalho pode ser configurada para ajustar esses pontos de início e término, afetando diretamente a medição do Lead Time.

Essa métrica é essencial para avaliar o desempenho da equipe e identificar possíveis gargalos ou áreas de melhoria no processo de desenvolvimento.

O gráfico de distribuição mostra como os valores de Lead Time estão distribuídos em um determinado intervalo de tempo. Ele agrupa os dados em classes ou tipos e exibe a frequência com que esses intervalos ocorrem. Isso permite visualizar o comportamento geral do Lead Time, identificando tendências, como a maioria das issues sendo concluídas em um tempo mais curto ou mais longo. É uma representação útil para compreender a forma geral da distribuição dos tempos de entrega e avaliar a consistência do processo.

Dispersão de Lead Time por tamanho

Como mencionado anteriormente, o Lead Time é a métrica que mede o tempo entre a criação e a conclusão de uma issue. A principal diferença entre os dois gráficos está na forma como os dados são representados. O primeiro gráfico exibe a distribuição do Lead Time, enquanto o segundo gráfico apresenta a dispersão dos dados.

O gráfico de dispersão, como o nome sugere, visualiza a variação individual dos valores de Lead Time ao longo do tempo. Em vez de mostrar uma distribuição agregada, ele apresenta cada ponto de dado de forma isolada, permitindo identificar mais claramente os casos que estão fora da média ou que apresentam variações significativas. Esse tipo de gráfico é útil para analisar padrões e identificar issues que levaram mais tempo do que o esperado para serem concluídas.

Distribuição de Queue Time

O Queue Time é o tempo decorrido entre o momento em que uma issue entra em um status que indica que ela foi priorizada ou selecionada para ser trabalhada, e o momento em que é concluída. Essa métrica reflete o tempo que a demanda permanece "em espera"ou "na fila"antes de ser efetivamente processada, medindo a eficiência da priorização e alocação de recursos.

A contagem do Queue Time começa quando a issue entra em um status específico configurado, como "To Do"ou "Ready for Work", ou qualquer outro status configurado como ponto de início. Ela é interrompida assim que a issue é finalizada ou movida para o status de concluída.

Assim como o Lead Time, o Queue Time pode ser ajustado de acordo com as configurações da plataforma utilizada, influenciando a forma como o tempo de espera é calculado. A métrica é importante para entender o quanto as issues ficam aguardando antes de serem trabalhadas, fornecendo uma visão crítica da eficiência do processo de priorização.

O gráfico de distribuição de Queue Time apresenta a variação do tempo de espera das issues dentro de um intervalo de tempo determinado. Ele agrupa os dados em faixas de tempo e mostra a frequência com que diferentes intervalos de Queue Time ocorrem. Com isso, é possível visualizar a distribuição do tempo de espera, identificando padrões e possíveis gargalos na fase de priorização ou escolha das demandas. Essa análise ajuda a identificar se há problemas na agilidade de início das tarefas e se o processo de alocação de recursos está funcionando de forma eficiente.

Dispersão de Queue Time por tamanho

O gráfico de dispersão de Queue Time mostra a variação individual dos tempos de espera das issues antes de serem iniciadas. Em vez de agrupar os dados, ele exibe cada ponto isoladamente, facilitando a identificação de casos com tempos de espera muito elevados.

Esse gráfico é útil para detectar padrões ou situações atípicas, como issues que ficaram muito tempo aguardando para serem iniciadas. Ele oferece uma visão clara da consistência e agilidade do fluxo de trabalho, ajudando a identificar áreas que podem precisar de ajustes.

Distribuição de Process Time (Touch Time)

O Process Time é a métrica que mede o tempo entre o início efetivo da atuação na issue e sua conclusão. Esse tempo reflete o quanto a equipe leva para trabalhar diretamente na demanda, desde o momento em que começa a ser processada até sua entrega final.

O gráfico de distribuição de Process Time exibe como os tempos de trabalho estão distribuídos dentro de um intervalo de tempo específico. Ele agrupa os dados em classes de tempo, permitindo visualizar a frequência com que diferentes intervalos de Process Time ocorrem.

Esse gráfico é útil para entender o comportamento geral do tempo de processamento das issues, indicando se a maioria das tarefas está sendo concluída rapidamente ou se há uma tendência de demora em determinados casos. Além disso, permite identificar padrões no desempenho da equipe, como consistência no tempo de execução ou possíveis variações em função de fatores específicos.

Dispersão de Process Time por tamanho (Touch Time)

O gráfico de dispersão de Process Time mostra a variação individual dos tempos de processamento das issues ao longo do tempo. Em vez de agrupar os dados, ele exibe cada valor de Process Time de forma isolada, o que ajuda a identificar casos com tempos de processamento anormalmente longos ou curtos.

Esse gráfico é útil para identificar situações atípicas, como issues que levaram mais tempo do que o esperado para serem concluídas. Ele ajuda a visualizar casos em que o trabalho na issue pode ter enfrentado interrupções ou atrasos, além de destacar a variabilidade no desempenho da equipe. A análise desses pontos isolados oferece uma visão detalhada sobre a eficiência do processo de execução e pode indicar áreas que precisam de ajustes para melhorar a agilidade e consistência.

Dispersão de Cycle Time por tamanho (Desenvolvimento)

O Cycle Time mede o tempo que uma issue permanece na etapa de desenvolvimento, desde o início da atuação efetiva até sua evolução para a próxima etapa, como a transição para testes, por exemplo. Esse tempo reflete o esforço necessário para avançar a demanda no processo de construção, sem considerar o tempo de espera ou a fase de conclusão.

O gráfico de distribuição de Cycle Time por Tamanho exibe como os tempos de desenvolvimento variam de acordo com o tamanho ou complexidade das issues. Ele agrupa os dados em intervalos de tempo, permitindo visualizar a frequência com que diferentes tamanhos de issues são concluídas em um determinado tempo de ciclo.

Esse gráfico é útil para analisar como o Cycle Time se comporta em relação ao tamanho das tarefas. Ele pode mostrar se issues mais complexas ou de maior porte levam mais tempo para serem desenvolvidas ou se há uma variação no tempo de ciclo de acordo com a complexidade. Isso ajuda a equipe a entender a relação entre o tamanho da demanda e a eficiência do processo de desenvolvimento, permitindo identificar áreas para melhorar a alocação de recursos ou a estimativa de tempo para diferentes tipos de tarefas.

Lista de Tickets

O objetivo principal da Lista de Tickets é fornecer um detalhamento completo das issues que foram tratadas durante o ciclo de trabalho (sprint ou período específico), facilitando a análise do desempenho do time, o acompanhamento de tarefas e a visualização do estado atual de cada item. A partir dessa lista, é possível obter uma visão detalhada do progresso de cada ticket, identificar possíveis bloqueios, verificar o histórico de mudanças de status e outros detalhes associados à sua execução.

Funcionamento do Painel

A Lista de Tickets inclui diversas informações relevantes sobre as issues do período ou sprint, tais como:

• ID do Ticket: Exibe o identificador único da issue. Ao clicar no ID, o usuário é redirecionado para a ferramenta de origem (plataforma gerencial das issues) para ver mais detalhes ou realizar ações adicionais.
• Status da Issue: Indica o status atual de cada issue, mostrando onde se encontra no fluxo de trabalho (por exemplo, "Em desenvolvimento", "Em teste", "Homologação", "Concluído", etc.).
• Tempo Gasto em Cada Status: Exibe o tempo total que cada issue permaneceu em cada status durante o período da sprint, ajudando a identificar possíveis gargalos no fluxo de trabalho.
• Responsável: Na plataforma de gerenciamento de issues, é indicado qual membro da equipe é responsável por cada tarefa. Essa informação facilita o acompanhamento da carga de trabalho individual e a análise da distribuição das atividades.
• Data de Criação e Conclusão: Exibe as datas de criação e conclusão de cada ticket, permitindo uma análise mais profunda sobre o tempo de execução de cada tarefa e a eficiência no ciclo de vida do ticket.
• Tipo de Issue: Pode ser um bug, melhoria, tarefa técnica, entre outros, facilitando a categorização e a análise de tipos específicos de demandas dentro da sprint.

Filtro de busca

A Lista de Tickets oferece a possibilidade de utilizar filtros para refinar a busca e localizar rapidamente informações específicas. Esses filtros podem ser aplicados com base em vários critérios, como:

• Filtro por Status: Filtra por status específico para ver apenas tickets em determinados estágios do processo.
• Filtro por Indicador: Filtra por indicadores das issues, como “em aberto”, “cancelado”, “concluídas” entre outros.
• Filtro de texto: Filtra as issues com base no texto digitado no filtro.

Como usar

• Ao visualizar a Lista de Tickets, utilize os filtros disponíveis para refinar sua busca conforme a necessidade.
• Clique no ID do Ticket para ser redirecionado para a ferramenta de origem, onde você pode visualizar mais informações.
• Use a lista para monitorar o progresso de cada ticket e identificar áreas que possam exigir atenção, como tickets que estão levando mais tempo do que o esperado para serem finalizados ou que estão bloqueados em um status específico.

Benefícios

• Visibilidade e Controle: Oferece uma visão clara e detalhada de todas as issues trabalhadas durante o período ou sprint, permitindo que os gestores acompanhem o andamento das atividades em tempo real.
• Análise de Desempenho: Através das informações sobre tempo gasto em cada status e os responsáveis, é possível identificar potenciais áreas de melhoria, como gargalos no fluxo de trabalho ou desequilíbrios na distribuição de tarefas.
• Facilidade de Acompanhamento: Com a capacidade de filtrar e buscar issues específicas, a lista torna-se uma ferramenta prática para acompanhamento e gestão do progresso da equipe, sem sobrecarga de informações.

Totalização das transições por status

Apresenta uma visão detalhada das transições de status das issues ao longo do fluxo de trabalho, proporcionando informações sobre o tempo gasto em cada estágio e o desempenho do time. Ele inclui várias métricas que ajudam a monitorar e analisar a eficiência do processo, identificar gargalos e avaliar o impacto do retrabalho nas entregas. A seguir estão os principais componentes do painel:

• Em trabalho/Agregando Valor (horas): Essa métrica contabiliza a quantidade de horas que as issues ficam em status de trabalho, ou seja, quando a equipe está efetivamente realizando atividades de desenvolvimento, como codificação ou testes. Este tempo é considerado como "agregando valor", pois representa o período em que o time está ativamente contribuindo para o progresso da entrega.
• Em espera/Desperdício (horas): Aqui são contabilizadas as horas que as issues permanecem em status de espera, como "esperando deploy"ou "em espera". Esses status são considerados como desperdício, pois representam períodos em que a issue não está sendo ativamente trabalhada. O objetivo é reduzir esse tempo, já que, sem essas esperas, o tempo total de entrega seria menor.
• Esforço (worklog): Refere-se às horas que o time registra na plataforma de gerenciamento de issues, especificamente no campo de worklog, como o tempo efetivamente dedicado ao trabalho nas issues. Essas horas representam o esforço da equipe no desenvolvimento das atividades, sendo uma métrica importante para medir a carga de trabalho e o comprometimento do time.
• Total de ocorrências: Este indicador mostra o número total de issues que passaram por determinado status ao longo do período analisado. Ele permite verificar a frequência com que as issues transitaram por esse status, ajudando a identificar quais fases do processo têm maior volume de transições.
• Repetição - Ticket voltou a passar pelo status: Refere-se às issues que retornaram a um status previamente alcançado. Por exemplo, uma issue que foi para "In Testing"e depois voltou para "Desenvolvimento"para ajustes, e em seguida retornou para "In Testing". A métrica de repetição ajuda a identificar possíveis retrabalhos ou ciclos de validação que podem indicar ineficiências ou falta de clareza nos requisitos.
• Percentual de tickets completos (sem retrabalho): Esse indicador apresenta o total de issues que passaram por determinado status e o percentual delas que não sofreram retrabalho. Ou seja, ele mostra a proporção de issues que transitaram pelo status de forma linear, sem a necessidade de retornar para fases anteriores. Esse percentual é importante para avaliar a qualidade do trabalho realizado e a eficiência do fluxo de entrega, já que um percentual baixo de tickets completos pode indicar problemas com a qualidade ou com os processos de revisão e validação.

Distribuição de tickets no backlog do time

O indicador de Distribuição de Tickets no Backlog do Time é uma métrica essencial para monitorar a organização e priorização das tarefas e solicitações dentro do backlog. Ele oferece uma visão clara sobre a alocação e o equilíbrio das demandas, permitindo identificar padrões e possíveis gargalos no processo de gestão do trabalho. A análise desse indicador fornece informações valiosas para a tomada de decisões estratégicas, permitindo uma melhor compreensão da carga de trabalho da equipe e a eficiência no fluxo de tarefas. Além disso, contribui para a otimização do processo de priorização, assegurando que os itens mais relevantes sejam atendidos dentro dos prazos estipulados.

Distribuição do tempo das issues em backlog

O indicador Distribuição do Tempo das Issues em Backlog mede o tempo decorrido entre a criação de uma issue e o início da Sprint/Período em que ela é efetivamente trabalhada. O cálculo é realizado desde a data de criação da issue até a data de início da Sprint/Período, sendo esta última utilizada como referência para identificar o momento em que os itens foram selecionados do backlog do produto e movidos para o backlog da Sprint/Período. Este indicador é fundamental para analisar o tempo que as issues permanecem no backlog antes de serem priorizadas e incluídas em uma Sprint/Período, oferecendo insights valiosos sobre o processo de seleção e planejamento. Além disso, a análise desse dado pode revelar possíveis gargalos na preparação do trabalho, ajudando a equipe a melhorar a previsibilidade e a eficiência no ciclo de desenvolvimento.

Análise do backlog

Este indicador (fig. 67) varia de 0 a 10 e tem como objetivo mensurar a saúde do backlog do produto e da sprint/período em relação aos defeitos de produção (bugs).

Se um time hipotético possui muitos defeitos no backlog do produto, gera uma quantidade significativa de defeitos durante uma sprint ou período, e não consegue corrigir os defeitos de maneira sustentável, o score desse time será baixo.

Por outro lado, se o time possui poucos defeitos no backlog do produto, gera poucos defeitos durante uma sprint ou período, e consegue corrigir mais defeitos do que gera, o score será alto.

Sobre esse score, é importante notar que existem duas variações de cálculo: a padrão e a ponderada. A variação a ser utilizada depende de como o indicador foi parametrizado no cadastro da organização no Agile Cockpit.

Para consultar qual variação está em uso atualmente, acesse o modal de detalhes (fig. 68) e verifique se a mensagem exibida é:

Cálculo padrão:

Este cálculo determina quantas Sprints/Períodos são necessários para limpar o backlog de defeitos, utilizando a fórmula:

Sprints/Períodos = (Antigos + Novos)÷(Novos - Em correção)

Exemplo:

Com Antigos = 0, Novos = 2 e Em Correção = 3:

Sprints/Períodos = (0 + 2)÷(2 – 3) = -2

Cálculo do Score:

Se Sprints/Períodos < 0 ou > 12, o score é 0, Se Sprints/Períodos < 2, o score é 10.

Para outros casos, o score é calculado como:

Score = 10 - (Sprints/Períodos - 2)

Exemplo de Score:

Se Sprints/Períodos = 2: Score = 10 - (2 – 2) = 10

Cálculo ponderado:

O sistema atribui pesos diferentes aos defeitos, com base em sua situação atual e criticidade:

• Situação: A lista de situações é fixa (três) e cada situação é um indicador separado.
• Criticidade: A lista de criticidades é dinâmica e parametrizável no cadastro da organização.

Recuperação de Dados:

• Da ferramenta de gestão: Quantidade total de defeitos e defeitos por criticidade.
• Do cadastro da organização: Pesos de criticidades e indicadores.

Exemplo: Quantidade Ponderada:

Qtde. Ponderada = Í (Qtde.×Peso C)

Total Ponderado:

Total Ponderado = Qtde. Ponderada x Peso I

Com os indicadores ponderados calculados, o score final é determinado a partir do campo total de cada indicador. Para o cálculo padrão, usa-se o total de cada indicador, enquanto no cálculo ponderado, utiliza-se o total ponderado.

Pesos:

• Os pesos das situações e criticidades são parametrizáveis, com valores padrão sugeridos pelo sistema.
• Se uma criticidade não estiver parametrizada, seu peso será 1.
• Para o cálculo padrão, todos os pesos são iguais a 1.

Indicadores:

• Em backlog fora da sprint/período: Defeitos criados antes da sprint, fora do backlog da sprint.
• Criados durante a sprint /período e fora da sprint /período: Defeitos criados durante a sprint /período, mas fora do backlog da sprint.
• Em correção na sprint /período: Defeitos que estão no backlog da sprint/período.

Exemplo de Cálculo Ponderado: Se temos:

Antigos = 192

Novos = 0

Em Correção = 272

O total seria:

Total = 192 + 0 + 272 = 464

E o cálculo do score ponderado seria:

Fórmula = (Em correção Total÷Total) x 2 x 10

Score = (272÷464) x 2 x 10 = 10

Burndown de issues

O gráfico de burndown é uma representação visual do trabalho restante versus o tempo disponível, sendo utilizado para monitorar o progresso da equipe ao longo de uma Sprint/período.

A linha de trabalho em aberto "ideal"indica a quantidade de trabalho que deveria permanecer pendente em cada momento, a fim de garantir que todo o trabalho planejado seja concluído até o final da Sprint/período.

Por outro lado, a linha de trabalho em aberto "atingido"representa a quantidade real de trabalho que permanece em aberto até o momento.

Quando a linha de atingido se encontra acima da linha ideal, isso indica que o time está "atrasado"em relação à meta estabelecida. Nesse caso, ações corretivas devem ser tomadas para recuperar o tempo perdido, visando aproximar a linha de atingido da linha ideal.

Se a linha de atingido estiver abaixo da linha ideal, significa que o time está "adiantado"em relação ao planejamento. Nesse cenário, devem ser tomadas medidas para evitar que o time fique ocioso até o final da Sprint/período, garantindo a continuidade do trabalho e a otimização do tempo.

Burnup de issues

O gráfico Burnup oferece uma representação visual do trabalho concluído em uma Sprint/período, comparando-o com o escopo total planejado. Ele permite acompanhar o progresso da equipe em direção à conclusão da Sprint/período e identificar possíveis problemas relacionados ao aumento do escopo durante o ciclo.

O eixo vertical do gráfico representa o total de trabalho para a Sprint/período, geralmente medido em número de tarefas ou pontos. O eixo horizontal, por sua vez, reflete a passagem do tempo ao longo da Sprint/período, normalmente em dias. A linha diagonal cinza, que atravessa o gráfico, representa o progresso ideal de conclusão do trabalho ao longo do tempo. A linha azul indica a conclusão real do trabalho, enquanto a linha verde reflete a quantidade de issues ainda em aberto.

À medida que o trabalho é concluído, a linha azul deve seguir de perto a linha diagonal (progresso ideal), garantindo que o objetivo da Sprint/período seja alcançado ao final. Além disso, a linha verde deve diminuir progressivamente, indicando que o número de issues pendentes está sendo reduzido ao longo do tempo.

Proporção por tamanho

Este gráfico exibe a distribuição das issues na Sprint conforme o seu tamanho relativo, permitindo visualizar a proporção de trabalho associado a diferentes categorias de tamanho das tarefas.

Se a opção "Concluídas"for selecionada, o gráfico considerará apenas as issues que estão no status de concluídos na configuração, ou seja, aquelas que já foram concluídas e entregues para parâmetros do time/organização. Essa funcionalidade permite acompanhar especificamente o progresso das issues finalizadas dentro da Sprint, facilitando a análise do trabalho completado em relação ao seu tamanho.

Distribuição de Lead Time até homologação

O Lead Time até Homologação é o tempo total entre a criação de uma issue e sua conclusão, ou seja, até a homologação, quando a issue atinge o status de "concluído"ou "homologado". Essa métrica mede a eficiência do processo de entrega, indicando quanto tempo a equipe leva para transformar uma demanda em uma entrega pronta para ser validada.

A contagem do Lead Time até Homologação começa no momento da criação da issue ou de outro evento configurado, como a entrada em um status de trabalho, e termina quando a issue chega ao status de Homologação, considerado o ponto final do processo de entrega. A plataforma utilizada para gerenciar o fluxo de trabalho pode ser configurada para ajustar esses pontos de início e término, o que impacta diretamente a medição do Lead Time.

Essa métrica é fundamental para avaliar o desempenho da equipe e identificar possíveis gargalos ou áreas de melhoria no processo de desenvolvimento até o momento da homologação, antes que a issue seja efetivamente entregue ao cliente ou parte interessada.

O gráfico de distribuição do Lead Time até Homologação mostra como os valores dessa métrica estão distribuídos em um determinado intervalo de tempo. Ele agrupa os dados em classes ou tipos de tempo e exibe a frequência com que esses intervalos ocorrem. Esse gráfico permite visualizar o comportamento geral do Lead Time, identificando tendências, como a maioria das issues sendo concluídas em um tempo mais curto ou mais longo até alcançar o status de homologação. A distribuição facilita a análise da consistência do processo de desenvolvimento, ajudando a entender se o tempo até homologação está dentro do esperado ou se há variações significativas que merecem atenção. as dentro da Sprint, facilitando a análise do trabalho completado em relação ao seu tamanho.

Motivos de impedimentos e bloqueios

A Métrica de Bloqueios é utilizada para rastrear e categorizar os principais motivos que causam a paralisação ou atraso no andamento das atividades. O objetivo dessa métrica é identificar e compreender os fatores que impedem o progresso do trabalho planejado, oferecendo insights valiosos para a melhoria contínua do processo e para a eliminação ou mitigação de obstáculos no fluxo de trabalho.

O impacto dos bloqueios é direto no tempo de entrega do projeto: quanto mais frequentes e prolongados forem os bloqueios, maior será o tempo necessário para concluir as atividades. Portanto, monitorar essa métrica é essencial para aumentar a eficiência da equipe, promovendo um ambiente de trabalho mais produtivo e menos sujeito a interrupções. Com isso, a equipe se torna mais autônoma e capaz de lidar com possíveis obstáculos, aprimorando o fluxo de trabalho e reduzindo os impactos negativos no cronograma.

Aba Comparativo - Indicadores de Comparativo

Insight Metrics

Este modal foi desenvolvido para auxiliar o usuário a identificar déficits nas entregas. Ele proporciona uma comparação entre os dados de mais de uma Sprint ou Período, eliminando a necessidade de alternar entre abas para acessar as informações. Utilizando inteligência artificial, a ferramenta oferece uma visão clara do que está melhorando ou piorando na equipe. Esses indicadores ajudam a identificar pontos críticos que precisam ser abordados, permitindo que o time melhore seu desempenho em situações futuras. Além de mostrar uma comparação entre as Sprints/Períodos selecionadas, provendo a transparência e um maior controle da evolução do time.

Após carregar mais de uma sprint/período, é possível iniciar a análise.

Na imagem é possível observar que as Sprints/Períodos estão sendo processados pela inteligência artificial. Esse processamento permite realizar um comparativo e identificar as melhorias e os déficits de desempenho da equipe. Dentro do Insights com IA, são abordados os seguintes pontos:

Work e Wait:

Este insight, apresenta uma métrica que permite avaliar o tempo de progresso em comparação ao tempo de ociosidade. Analisamos o tempo de atuação em Sprints/Períodos carregados previamente, como ilustrado na imagem abaixo, que revela o percentual de melhoria ou piora durante esse intervalo. Essa análise nos ajuda a entender melhor a eficiência e a produtividade ao longo do tempo.

Throughput:

Neste insight, é analisada a eficiência das entregas utilizando o Throughput, que mede a quantidade de itens concluídos em cada período. Ao comparar a quantidade de tarefas finalizadas em diferentes intervalos de tempo, conseguimos calcular uma média de entregas por iteração. Esses dados são avaliados com o auxílio de inteligência artificial, permitindo um comparativo entre os períodos apresentados na imagem abaixo. Essa abordagem proporciona uma visão detalhada sobre o ritmo de produção, destacando a evolução e a consistência das entregas ao longo do tempo.

Process Time:

Neste insight, realizamos uma comparação da eficiência nas entregas, utilizando a diferença entre o tempo inicial e o tempo final. Com isso, calculamos a média do tempo de todas as tarefas concluídas. Esses dados serão analisados por meio de inteligência artificial, permitindo um comparativo entre os períodos apresentados na imagem abaixo. Essa abordagem nos proporciona uma visão mais clara sobre a performance e a evolução nas entregas.

Lead Time:

Neste insight, é realizada uma análise comparativa do tempo decorrido entre a entrada de um item nas etapas de upstream e seu término em ambiente produtivo nas etapas de downstream.

nota

• Upstream: Refere-se ao conjunto de etapas que ocorrem antes do início das atividades produtivas.
• Downstream: Abrange as etapas de desenvolvimento, execução e/ou produção dos itens.

Essa análise nos permite identificar oportunidades de melhoria e otimização no fluxo de trabalho.

Comparativo das Sprints/Períodos

Esta tabela traz 5 indicadores: Diferença estimada vs Realizada, % não entregue, Entrega estimada, Entrega realizada e % total entregue. O intuito, como o nome já diz, é trazer um comparativo destes resultados entre as sprints/períodos abertos sem precisar ficar trocando de aba.

Compromisso Entregue

O compromisso entregue representa o total de story points ou quantidade de issues entregue em cada Sprint/Período. As configurações podem variar entre story points, contagem de tickets ou relativa. Ao mudar estas configurações do cálculo podem deixar essa visão distorcida até que algumas Sprints se passem e ocorra a estabilização. É importante que estes dados levem em consideração o percentual do compromisso entregue para ter uma melhor leitura da evolução.

Evolução Score

Este gráfico tem o intuito de proporcionar uma melhor visão da evolução da pontuação, impedimentos, backlog de defeitos, eficiência através do tempo e compromisso.

Evolução do Backlog de Defeitos

Este traz uma evolução dos bugs. É possível observar, por meio desse indicador, se a entrada e a saída de defeitos estão ocorrendo na mesma proporção. Ele apresenta três métricas principais: Defeitos no Backlog, Defeitos Incluídos na Sprint e Defeitos Criados durante a Sprint, oferecendo uma visão abrangente da evolução dos defeitos ao longo do tempo.

Evolutivo

Neste gráfico é possível verificar diversos fatores como Quantidade total de issues do backlog, Defeitos da Sprint Abertos e Issues concluídas. Além disto, se pode acompanhar a evolução entre o percentual de compromisso entregue e o percentual de retrabalho (percentual de story bugs por história de usuário).

Times das Sprints/Períodos e Compromissos Realizados

Este gráfico permite ver a relação entre os times e o story points entregues dentro das Sprints ou Períodos

Distribuição de Tickets

Este gráfico utiliza cores para ilustrar a quantidade e os tipos de issues inseridos em cada Sprint ou período, permitindo uma análise clara do trabalho realizado e de seu volume.

Comparativo de Tipos de Defeito

É importante ter-se um controle dos bugs e este gráfico traz uma boa visão dos bugs criados durante cada sprint/período.

Criticidade dos Defeitos

Este gráfico permite uma melhor visão da criticidade dos bugs incluídos em cada sprint/-período. Ele mostra barras, agregando uma cor a cada sprint/período selecionado e separa por criticidade no eixo x. Estes valores de criticidade dependem do utilizado pelo cliente na sua plataforma gerencial.

Work (+)/ Wait (-)

Este gráfico mostra uma visão de quanto tempo as issues passaram por cada status e pode ser visto em contagem de horas ou em percentual. Os valores dos status de Wait são contabilizados como negativos e são mostrados abaixo do eixo X, enquanto os valores de Work são positivos e mostrados acima do eixo X.

Eficiência de Detecção de Defeitos

Este gráfico mostra quantos defeitos (Story Bugs) foram encontrados em cada sprint/período.

Compromisso: Estimado vs Realizado

Este gráfico de barras exibe a quantidade de story points estimados e realizados em cada sprint ou período. Os resultados são diferenciados por cores, facilitando a interpretação e análise dos dados.

% Entregue vs % Não Entregue

Similar ao gráfico de Compromisso entregue vs Realizado, este gráfico mostra os dados de percentual de story points entregues versos o percentual de story points não entregues em cada sprint/período. Os dados são mostrados em cores diferentes para uma melhor visualização.

Compromisso, Tasks e Defeitos

Este gráfico permite acompanhar a evolução e ter um comparativo entre as sprints/períodos selecionadas levando em considerações 4 indicadores: Tickets estimados, Tickets concluídos, tasks concluídas e defeitos.

nota

Este gráfico levará em consideração a configuração realizada no compromisso atual estimado no caso de Story Point, Relativa ou no caso de contagem de tickets informa os itens que entraram no compromisso.

Motivo de Impedimentos e Bloqueios

Este gráfico mostra os motivos das criações dos defeitos (story bugs) dentro das sprints/períodos e quantos foram criados pelo mesmo motivo.

Throughput

Este gráfico foi adicionado para que os usuários possam comparar a quantidade de tarefas entregues em cada intervalo de tempo (Sprint ou Período). As informações podem ser visualizadas por classe ou por tipo, facilitando a análise das entregas.

Este gráfico apresenta um detalhamento, que mostra a média de entregas para cada tipo de issue, além de um resumo absoluto para cada período comparado, agrupados pelos meses em que houve interação. Também calcula a média dos valores representados na imagem acima, com o objetivo de demonstrar de forma mais clara quais tipos de tarefas estamos abordando para melhorar as entregas.

Além disso, é possível detalhar os tipos de issues, permitindo visualizar a quantidade total de itens comprometidos em comparação com a quantidade de itens entregues, todos agrupados por mês. Essa análise proporciona uma compreensão mais clara do desempenho da equipe, ajudando a identificar áreas de melhoria e a eficiência nas entregas. Com essas informações, os usuários podem ajustar suas estratégias e focar nas issues que necessitam de atenção especial, otimizando assim o fluxo de trabalho e a produtividade.