Em Produto, você vai ouvir muito sobre métricas de produto e a importância dos dados no nosso dia a dia. É comum que, de início, esse tema gere um certo desconforto, mas este artigo tem como objetivo ajudar não apenas com indicadores importantes, mas também desmistificando, mais especificamente, o uso de métricas associadas ao desempenho de um time que roda o Scrum.
Se você ainda não conhece sobre agilidade e o framework Scrum, recomendo que inicie descobrindo esse universo um pouco mais a fundo aqui antes.
Métricas de Produto x Métricas do Scrum
Mas afinal, o que são métricas? De forma resumida, as métricas nada mais são que a interpretação de uma medida ou conjunto de medidas que você utiliza para se orientar à estratégia. Elas vêm de dados, de quantificação, de uma mensuração pensada e alinhada com o quê e para quê se medem.
Quando falamos em métricas de produto, pensamos naquelas que se relacionam profundamente com a saúde financeira e também o sucesso de um produto frente aos seus objetivos (e aqui podem entrar questões como quantificar o quanto um produto é efetivo na resolução da dor de um cliente, ou o quanto um produto atinge seus objetivos de ativar esse cliente gerando receita, por exemplo). Elas podem ser dos mais variados tipos, como de negócios, de engenharia, etc. Até hoje, não existe uma regra decisiva sobre a classificação de cada uma, porém podemos citar algumas mais famosas, como o CAC, o LTV, Churn. Você pode ler sobre métricas de produto clicando aqui.
Já as métricas do Scrum, elas são bem mais específicas. Embora definitivamente também se relacionem ao sucesso de um produto, elas entraram numa escala bem menor e mais pontual no negócio, nos ciclos de desenvolvimento do produto num time que utiliza essa metodologia ágil.
Ou seja, aqui não falaremos exatamente em sucesso do produto, mas sucesso da aplicação do Scrum em um time de Tecnologia, nos ciclos sucessivos de desenvolvimento de software em um produto digital. As métricas do scrum nos ajudam a mensurar o quão bem um time está trabalhando nesse formato, permitindo estimular a melhoria contínua no que for possível.
Velocity (Velocidade) ou Capacidade (Capacity)
Uma das principais características do Scrum é o trabalho contínuo dividido em iterações, ou ciclos de desenvolvimento, as chamadas ‘’sprints’’. Durante a definição do que vai ser desenvolvido em uma sprint, que pode ter uma duração variada entre, normalmente, 1 a 3 semanas (sendo mais comum o uso de sprints de 2 semanas), o time faz um cálculo aproximado de velocidade, que nada mais é do que a quantidade de story points (pontos de história do usuário) que são capazes de entregar naquele ciclo.
Como fazer esse cálculo? Pega-se a quantidade de story points que o time conseguiu entregar nas últimas 3 sprints, por exemplo, basta somar esse número e dividir por 3. Quanto maior o número de sprints anteriores se usar nesse cálculo, melhor a precisão.
Exemplo: O time entregou 26, 28, 24 e 26 pontos nas últimas 4 sprints. Isso indica uma Velocity de 26 pontos (104/4).
Importante ter em mente que essa métrica é algo bem específico e varia para cada time por diversos critérios. Como, por exemplo:
- Quantidade de desenvolvedores;
- Senioridade dos integrantes do time;
- Complexidade do desenvolvimento e das tecnologias utilizadas;
- Tempo que o time está trabalhando junto.
Isso tudo dificulta um pouco pensar na velocidade na primeira iteração de uma equipe. Nesse caso em específico, de uma equipe iniciando sua primeira iteração, a recomendação é ter um bom acompanhamento de pessoas com mais experiência para definição inicial.
Com isso, o time consegue ter uma estimativa da quantidade de story points que consegue entregar por ciclo de desenvolvimento. Isso caracteriza a Velocity do time e deve ser trazido, sobretudo na cerimônia de planejamento, garantido que as histórias puxadas para aquela iteração cabem na velocidade da equipe.
Com o decorrer de algumas iterações e o aumento da maturidade da equipe como um todo, é de se esperar que a velocidade melhore. Ou seja, que aumente a quantidade de pontos por sprint. É por esse motivo que trata-se de um indicador muito importante a ser acompanhado por todos.
Importante frisar que todo esse cálculo também pode ser feito em horas, dependendo da forma como o time estima suas atividades. Nesse caso é mais comum usarmos a nomenclatura Capacidade (Capacity), embora muitas vezes ambas sejam usadas como sinônimos, não tendo, por fim, tanta relevância a escolha de um ou do outro termo.
Lead Time (Tempo por Lead) e Cycle Time (Tempo por Ciclo)
Ambos Lead Time quanto Cycle Time costumam ser contabilizados em dias e/ou horas e vêm do uso conjunto de um quadro Kanban dentro do Scrum. Enquanto o Lead Time se refere ao tempo que um card dura desde sua criação até completude (normalmente quando chega na coluna de “done” no quadro Kanban), o Cycle Time contabiliza apenas o tempo que aquela mesma história passou em efetivo desenvolvimento.
São indicadores preciosíssimos para acompanharmos a média de tempo de entrega de valor pela equipe.
Burndown/Burnup Chart
Dois gráficos que podem ajudar bastante na visão de desempenho do time durante a sprint são os gráficos de Burndown e Burnup.
O gráfico de Burndown monitora a conclusão dos cards (histórias) da sprint, através da comparação entre tempo e quantidade de trabalho a ser concluído (em story points ou ainda em horas). O Burnup igualmente apresenta o ponto do cronograma com o prazo de entrega planejado, porém numa visão crescente em relação ao eixo referência diagonal (que é a referência). Basicamente, enquanto o primeiro mostra melhor o quanto falta para entregar, o segundo ilustra melhor o que já foi entregue pela equipe. São formas diferentes de apresentar os dados, mas que podem ser usadas para adequação e previsibilidade do andamento da sprint. Abaixo alguns exemplos:
Seguimos em busca da melhoria contínua
O acompanhamento de todos esses indicadores podem ser facilitados através de ferramentas/plataformas específicas de gerenciamento ágil de projetos e produto, muito comuns no mercado, como por exemplo o Jira, Trello, Azure, Clickup, etc.
Lembrando que um dos princípios do agile é a autonomia e autogestão dos times, e acompanhar esses dados é apenas uma das formas de fazê-lo em conjunto. Sempre que os indicadores mostraram piora em comparação com as iterações anteriores, vale levantar as hipóteses dos motivos pelos quais isso ocorre e buscar melhoria, levantando o tema nas retrospectivas.
Leia também:
