Como usar story points para calcular cycle time de sua equipe?5 min read
Categoria: Engenharia de Softwares
Esse é um dos grandes desafios que tenho observado nas equipes que liderei recentemente: conseguir saber qual é a velocidade do time. Uma das ferramentas que lhe ajudam a prever em quanto tempo um determinado desenvolvimento será entregue é através do uso de story points. Antes de começar a explorar a resposta, vamos entender o que é o story point e o que é o lead time.
Story point
Story Points é uma unidade relativa de medida utilizada na agilidade (Scrum, Kaban e afins) para estimar a complexidade, esforço e tamanho das histórias de usuário durante o planejamento de um projeto de desenvolvimento de software. Normalmente, se usa o escala de fibonacci (1, 2, 3, 5, 8, 13) ou pontuação por tamanho de camisa (P, M, G).
Muitas empresas utilizam o famoso planning poker para auxiliar no processo de pontuação.
Cycle time
Cycle time é o tempo total desde o início do processo de desenvolvimento de software, feature ou tarefa. Para ficar ainda mais claro: é o tempo total em dias entre a data de início da execução e data de término de um desenvolvimento.
Não confundir com o lead time que é o tempo total decorrido desde o início da atividade entrar no backlog até sua finalização. Ou seja, o lead time é tempo que leva para uma tarefa ou uma história de usuário ser concluída, desde o momento em que é adicionada ao backlog até a entrega final ao cliente.
Como encontrar o Cycle Time usando story point
Agora que você sabe o que cada termo significa, vamos ver como usar o story point para começar a estimar o tempo de entrega em times de desenvolvimento. Você pode usar o story point em basicamente qualquer modelo ágil.
Uma palavra merece destaque quando falamos de story point: se atente a palavra “relativa“, pois para que o story point te ajude a mensurar o cycle time, você precisa usar alguma referência. A melhor forma de encontrar a referência quando você não conhece a equipe, ou a equipe não conhece o projeto é estimar pela primeira vez baseado em alguma premissa que seja possível comparar. Vejamos um exemplo usando fibonacci:
Sprint 1
- Você começou hoje em um projeto e não tem ideia da complexidade da entrega de uma feature que está estimando
- Então, arbitrariamente baseado em uma primeira estimativa você diz que essa feature está estimada em 8 pontos
- Você continua a pontuar as tarefas e a partir dessa primeira pontuação a próxima task que você pontua, você já tem uma referência: ou essa nova task a ser pontuada vai ser de tamanho igual a 8 pontos, menor ou maior
Perceba que, no exemplo acima, eu não falei em nenhum momento que 8 pontos vale X dias pois, na prática, o cycle time vai se forma com o tempo.
Sprint 2
Com base na sprint 1, você vai ter novas referências para estimar. Vejamos:
- Digamos que você teve 3 tasks na sprint 1: uma estimada em 5 ponto, outra em 3 pontos e outra em 8 pontos
- Nessa sprint 2 você passa a usar como referência a pontuação da sprint anterior
Veja que agora você tem referências para usar para pontuar novas tasks.
Sprint 3
O processo acima se repete indefinidamente, ou seja: a cada nova sprint você toma como referência uma task para cada pontuação que você já executou em sprints passadas.
A partir deste momento, com cada pontuação calibrada você vai começar a perceber que para cada ponto, você leva X dias para executar uma tarefa com aquele time.
Yes: assim surge o cycle time para cada tamanho de entrega!
Agrupando o cycle time por story point
A partir deste momento você já pode começar a agrupar por cada estimativa de ponto quanto tempo, aproximadamente, o time leva para concluir uma tarefa. No exemplo deste artigo, vamos imaginar que:
- 1 ponto: de 1 a 2 dias
- 2 pontos: de 2 a 3 dias
- 3 pontos: de 3 a 5 dias
- 5 pontos: de 5 dias a 7 dias
- 8 pontos: de 7 dias a 10 dias
- 13 pontos: de 10 dias a 15 dias
Veja que a partir disso e monitorando de tempo em tempo, você consegue “prever” em quanto dias sua equipe vai entrega determinado desenvolvimento solicitado, baseado na estimativa “relativa” que foi dada.
Considerações importantes
Esse é um modelo que já apliquei inúmeras vezes e continuo a aplicar sempre que tenho oportunidade. Funciona muito bem, porém você precisa de pelo menos duas sprints para conseguir ter as primeiras pontuações que serão a referência inicial.
Um ponto de atenção: se você é líder, é importante estar atento que estimativas são estimativas (fui redundante de propósito), pois por vezes a gente estima com o alvo em acerta sempre, mas nem sempre é possível acerta uma estimativa já que elas podem errar para mais ou para menos.
Neste caso o monitoramento do cycle time de cada pontuação sempre terá uma margem de variação, por isso no exemplo que passei existe um intervalo de x dias para cada pontuação.
Ferramentas úteis para auxiliar nas pontuações
Uma ferramenta que tenho usado que ajuda bastante nisso é o planitpoker.com. Você pode usar ele para separar as entregas por assuntos.
Outra ferramenta para auxiliar na pontuação é a planningpokeronline.com.
Ambas são gratuitas. Após pontuar você pode usar alguma ferramenta para te auxiliar na gestão de tempo decorrido de cada pontuação. Uma planilha será a forma mais simples para fazer isso, porém ferramentas como o Jira já irão lhe oferecer plugins e painéis que automatizam isso, desde que você configure.