Com uma certa frequência eu venho escutando especulações sobre story points e sua relação com o tempo de desenvolvimento. Perguntas como: “Por que um card de 3 pontos levou tanto tempo para ser desenvolvido?”, “Quanto tempo um card de 8 pontos leva para ser entregue?”, “Por que o time levou tanto tempo para entregar somente esta quantidade de pontos?” e outras são frequentes. Contudo, quando se pesquisa sobre story points e tempo de desenvolvimento, há uma série de comentários sobre essa relação onde: alguns dizem que story points medem apenas esforço para implementar um card, outros consideram uma relação entre dias (ou até mesmo horas) e os pontos, outros apenas comparam tamanhos entre os cards e por aí vai.

Tentando me embasar melhor neste assunto para conversar com clientes e stakeholders em geral, decidi coletar dados de um projeto real e realizar uma análise sobre a relação da pontuação destes cards e o tempo que os mesmos demoram para serem desenvolvidos, contando desde o momento que eles começam na etapa de desenvolvimento até o momento em que são entregues em produção, o famoso lead time.

Disclaimers

Antes de começar, alguns disclaimers sobre o contexto do projeto:

• Logo nas primeiras semanas do projeto já tivemos o primeiro grande problema com story points: subjetividade na pontuação. Por que este card é 3? Como eu sei se este card é duas vezes maior ou três vezes maior do que o card X? O que eu considero nesta pontuação?
  • Desta forma, foi sugerido ao time que utilizasse alguns critérios para estimar com o intuito de diminuir essa subjetividade.
  • Meu amigo e colega de trabalho Henrique Oliveira sugeriu uma matriz Fibonacci-like, com base nas estimativas T-Shirt Size, para pontuar os cards que auxiliou bem ao time. Confira abaixo:

• Cards com 13 ou mais pontos eram quebrados em cards menores, pois a única vez que tentamos trabalhar com um card do tamanho 13, ele estorou o timebox da sprint, que era de 10 dias úteis.
• Os cards eram quebrados de uma forma que entregassem algo funcional em produção, de forma que backend e frontend ficassem juntos em uma mesma história.

Vamos aos dados

Primeiramente, coletei os dados do projeto como um todo e analisei o gráfico de lead time com todos os cards que já foram finalizados ou que estavam em desenvolvimento.

Após capturar estes dados, eu separei os cards por pontuação e os analisei separadamente, tendo os seguintes gráficos:

Cards com 1 story point

Cards com 2 story points

Cards com 3 story points

Cards com 5 story points

Cards com 8 story points

Cards com 13 story points

Análise dos dados

Após analisar este dados, consegui obter algumas conclusões:

• É possível verificar que cards com 3, 5 e 8 pontos têm um tempo de desenvolvimento (lead time) parecido, não sendo possível estabelecer relação entre tempo e quantidade de story points.
• Se pegarmos uma categoria com bastante amostras, como os cards com 5 story points, é possível perceber que os mesmos variam bastante, não podendo estabelecer afirmações como “um card de 5 pontos leva entre X e Y dias para ser desenvolvido”, sendo X e Y um intervalo pequeno de dias (entre 1 e 3 dias). O mesmo acontece com os cards de 3 e 8 pontos.

Observação: Os dados referentes aos cards de 1, 2 e 13 story points foram retirados da análise individual, pois haviam poucos dados para serem analizados separadamente.

Outras análises além dos story points x lead time

Houve outras conclusões sobre a utilização dos story points que eu gostaria de compartilhar com vocês:

• No começo do projeto, quando começamos a utilizar os story points, a subjetividade era muito alta. Estabelecendo alguns critérios para a pontuação, foi possível estabilizá-la, fazendo com que o tempo de desenvolvimento das histórias variasse menos e, com isso, aumentando a previsibilidade. Se você gostaria de desenvolver isso dentro do seu time, considere a leitura deste artigo do Mike Cohn.
  
• Com a adição de mais critérios à pontuação, como complexidade nos testes, dependência de outras pessoas fora do time (internas ou externas a empresa), risco relacionado a história e outros, diminuímos a variabilidade do lead time e aumentou a previsibilidade de entrega dos cards.
• Muitas vezes story points são relacionados diretamente ao esforço de desenvolvimento, o que faz com que o time foque somente no esforço e no tempo para a execução de uma tarefa. Outro ponto é que os testers/QAs e UXs/designers, geralmente, se envolvem pouco ou nada nas estimativas. Fazer o time pensar não só no desenvolvimento, mas também na duração do processo como um todo (considerando etapas de code review, testes, deploy, etc) e envolver outras pessoas na participação das estimativas para exporem suas preocupações e comentários sobre a demanda, ajuda a melhorar previsibilidade do seu time.
• O auxílio de métricas para melhoria de processos, como lead time breakdown e CFD, ajudaram muito neste processo de estabilização da pontuação, fazendo o time pensar mais no processo como um todo e mostrando em que etapa do processo eles estavam gastando mais tempo.

Conclusões

As principais conclusões que eu tive foram:

• Não foi possível relacionar tempo de desenvolvimento (lead time) com story points diretamente, conforme o propósito do estudo.
  • Vale um adendo aqui que Story Points devem ser utilizados dentro do nível de time. Se quer saber mais sobre este assunto, recomendo a leitura deste texto do Troy Magennis
• Foi possível melhorar a previsibilidade da entrega do time e atingir uma estabilização do processo de desenvolvimento utilizando story points junto com outras ferramentas.
• Existem indícios que, quando se adiciona mais critérios à pontuação, quanto menor a pontuação de um item, menor será seu risco/esforço/complexidade e, consequentemente, maior será sua previsibilidade.
• Um grande ponto aqui é que os Story Points consideram em suas estimativas somente os momentos em que uma demanda estará sendo trabalhada e não considera/não consegue prever o tempo que uma demanda vai ficar em estado de espera. Basicamente, o time considera ao estimar quanto tempo uma demanda pode levar para ser desenvolvida e testada, mas não considera nesta estimativa (por não poder prever alguns pontos no meio do desenvolvimento) quanto tempo uma demanda vai ficar aguardando para ser testada, para realizar o deploy ou para a resolução de um impedimento. Em outras palavras, a eficiência do seu fluxo vai impactar no seu lead time e, consequentemente, na relação dos story points com o tempo de desenvolvimento. Desta forma, é possível que uma user story de 1 ponto leve a mesma quantidade de dias para ser finalizada do que uma user story de 13, devido a sua eficiência de fluxo. Se quiser saber mais, consulte este texto aqui.

E se te perguntassem se você utilizaria story points para estimar um prazo para a entrega de um projeto ou card, o que você responderia?

Eu diria que story points, assim como a matriz de complexidade por incerteza (T-shirt Size), são excelentes ferramentas para instigar o seu time a quebrar melhor as histórias de usuário e ajudar a fazer melhorias de processos, porém, para dar uma estimativa de prazos, eu preferiria utilizar métricas e outras ferramentas, como simulações de Monte Carlo para prever quando um conjunto de cards vai ser entregue.

E você? Já teve alguma experiência com Story Points e estimativas de tempo? Já sofreu com algum cenário parecido? Qual a sua opinião sobre o que compartilhei neste texto? Compartilhe com a gente comentando aqui embaixo ou pelo e-mail contagil@plataformatec.com.br