Story points não fazem sentido; meça as filas

• Story points são totalmente pouco confiáveis e causam confusão, exigindo que seu significado seja constantemente relembrado aos envolvidos
  • Valores baixos de pontos são mais precisos, mas valores altos pressupõem maior variabilidade e representam faixas, tornando impossível somá-los com precisão
  • Story points não representam tempo, mas, quando combinados com métricas de velocidade, acabam significando tempo na prática, o que desde o início inviabiliza o ato de somar números e faixas
• Estimar software é difícil, e a saída do processo geralmente não é útil em comparação com a entrada
• Equipes pequenas com poucas interrupções parecem estimar com precisão, o que na maioria dos casos dá a impressão de que o que estão fazendo está funcionando bem
• Quando a capacity é totalmente utilizada, a variabilidade de todo o trabalho aumenta drasticamente, afetando de forma brusca todas as estimativas e cronogramas
• Filas medidas resolvem problemas de estimativa de curto e longo prazo, lidam naturalmente com mudanças de escopo e oferecem uma prática muito mais valiosa para equipes grandes ao remover a incerteza
• Filas medidas fornecem um indicador antecedente que prevê problemas 20 vezes mais rápido do que métricas relacionadas a velocidade ou cycle time

O que são story points?

• Segundo a Atlassian, story points são uma unidade usada para expressar uma estimativa do esforço total necessário para implementar completamente um item do product backlog ou outro trabalho
• Os pontos representam complexidade, volume de trabalho, risco ou incerteza, e quantidade de trabalho
• A medição de complexidade é um conceito relativo, então cada equipe pode avaliar o mesmo trabalho de forma diferente
• Devido à natureza relativa dos pontos, comparações entre equipes não fazem sentido, e isso costuma ser um problema no nível gerencial

Variabilidade inerente

• Story points se baseiam na sequência de Fibonacci, de modo que valores mais altos representam variabilidade maior
• Somar valores de pontos com alta variabilidade não faz sentido, e o ato de somar pontos em métricas de velocidade está errado
• Segundo a lei de Goodhart, quando uma métrica se torna a meta, ela deixa de ser uma boa métrica

Problemas conhecidos

• Os problemas dos story points são bem conhecidos, mas eles ainda são usados porque técnicas alternativas de estimativa sofrem de problemas semelhantes
• Ron Jeffries, criador dos story points, os repudia e critica seu mau uso
• No Scrum, "Commitment" foi alterado para "Forecast", mas ainda assim continua sendo usado de forma errada
• Surge uma situação paradoxal em que entregar mais trabalho do que o estimado pode resultar em repreensão

Priorização por ROI

• Empresas priorizam o trabalho para otimizar recursos (tempo, dinheiro, ferramentas, pessoas)
• Estimativas de desenvolvimento são necessárias para calcular o custo do investimento, mas estimar em si é difícil e caro
• Software Estimation: Demystifying the Black Art é um excelente livro que trata da dificuldade de estimar

Saída do processo

• O processo de estimar com story points consome muito tempo, mas a saída não tem valor
• Sessões regulares de grooming consomem muito tempo e são aplicadas de formas variadas, sem consistência entre equipes
• Em vez de story points, é mais valioso criar uma lista significativa de tarefas

Proposta de alternativa

• Estimar com tamanhos de camiseta pode ser uma alternativa melhor, mas isso também tem problemas
• Estimar em tempo sofre de problemas semelhantes, e o tempo real de trabalho da equipe difere do tempo esperado pelo lado do negócio
• Em equipes pequenas, estimativas em tempo podem funcionar bem, mas, conforme a equipe cresce, a precisão das estimativas cai
• O livro "The Principles of Product Development Flow", de Donald Reinertsen, apresenta uma alternativa
  • O ponto central é otimizar o fluxo de trabalho com foco no gerenciamento de filas (Queue)
  • É preciso fazer planejamento de capacidade e garantir capacidade de buffer para acomodar a variabilidade

Solução

• Começa com a equipe analisando o trabalho em conjunto, dividindo-o em pequenas tarefas e removendo incertezas
• A lista de tarefas se torna a fila (Queue), e o número total de tarefas representa o tamanho do trabalho (Job Size)
• Em vez de Story Points, usa-se a taxa média de conclusão de tarefas (Average Task Rate) para estimar
• O trabalho é acompanhado com base na velocidade média de execução, e a taxa de conclusão é calculada
• Se as tarefas forem atualizadas conforme novas informações ou feedback surgirem, a estimativa se ajusta naturalmente
• Os desenvolvedores não precisam sofrer pressão psicológica por causa da estimativa

A fila (Queue) é um indicador antecedente

• Taxa média de conclusão de tarefas, Cycle Time, Velocity etc. são indicadores defasados, enquanto Queue é um indicador antecedente
• Se o tamanho da Queue aumenta, é possível perceber e reagir aos problemas com antecedência

Resumo

• Story Points causam confusão, não são confiáveis e foram projetados para falhar
• Em vez disso, vale mais a pena investir tempo em a equipe entender o problema em conjunto, remover incertezas, dividir em tarefas e gerenciar a Queue

Opinião do GN+

• O método de gerenciamento de filas apresentado no artigo parece ser uma alternativa realista para superar as dificuldades de estimativa no desenvolvimento ágil
• Ainda assim, o processo de dividir tarefas em partes menores pode exigir esforço adicional dos desenvolvedores, e pode consumir mais tempo nas fases iniciais do projeto
• Além disso, o processo de análise de tarefas pressupõe participação ativa dos desenvolvedores e manifestação sincera de opiniões
• Por outro lado, também se pode esperar o efeito positivo de a equipe de desenvolvimento compreender profundamente os requisitos de negócio e refletir sobre eles em conjunto

[heal9179]

Isso não é a metodologia Kanban..?

[GN⁺]

Comentários no Hacker News

• Pela minha experiência pessoal, o número de story points não era importante, mas o processo de a equipe avaliar a complexidade do trabalho era muito útil

  • Usar story points para prever o tempo de trabalho era uma métrica pouco confiável
  • Eu tentava evitar story points por vários motivos, como mudanças na equipe e no domínio, além da variabilidade de tarefas fora do desenvolvimento
  • Nas equipes que usavam story points, eles eram usados como ferramenta para compartilhar o entendimento do trabalho

• A mudança de "Commitment" para "Forecast" no guia do Scrum não aconteceu em 2011

  • Ao verificar os guias de 2010 e 2011, a palavra "Commitment" não existia nas versões anteriores a 2011
  • "Forecast" substituiu "Estimate" no guia de 2020

• Decompor pacotes de trabalho em unidades atômicas e medir o tamanho da fila é uma questão de outra ordem

  • Dá para usar story points ao refinar os pacotes de trabalho com a equipe
  • Decompor todo o trabalho em 1 story point foi ineficiente
  • Relacionar o tamanho da fila com o impacto da variabilidade é um conceito interessante

• Há casos em que o modelo waterfall e a estimativa em unidades de tempo funcionam bem

  • Em uma pequena equipe de serviços profissionais, os requisitos do cliente são documentados e, depois de discutidos com a equipe, são estimados em faixas de tempo
  • Quando o cliente aprova, passam por design detalhado, desenvolvimento, QA e release
  • Em 20 anos, o processo não mudou e a equipe é considerada altamente produtiva

• Story points representam complexidade relativa e incerteza, não unidades de tempo

  • Deve ser possível medir histórias com números grandes
  • Em algumas equipes, não se atribuem mais de 7 pontos
  • Em outros lugares, davam 21, 30 ou 50 pontos

• Story points eram, na prática, uma unidade aproximada de tempo

  • Fazer os story points corresponderem claramente a unidades de tempo pode ser enganoso
  • O importante é prever quanto tempo os desenvolvedores vão gastar em uma tarefa
  • Para a análise de filas ser útil, é preciso conhecer o tempo estimado de cada tarefa

• Quando usei Scrum pela primeira vez, usávamos o Rally

  • Rastreávamos story points, tempo estimado e tempo real
  • Depois de migrar para o Jira, o rastreamento de tempo desapareceu
  • Conforme as estimativas ficaram mais precisas, ficou mais fácil equilibrar o trabalho da equipe

• Story points são úteis para discutir a complexidade do trabalho, mas inadequados para medir velocidade

  • Como engenheiro novo, eu concluía muitos story points, mas a gerência tentava ajustar isso
  • Era difícil avaliar adequadamente trabalhos complexos

• É difícil estimar projetos de desenvolvimento de software de forma confiável

  • É importante dividir o trabalho em unidades pequenas com a equipe e estimar faixas de tempo
  • À medida que o projeto avança, é importante reportar a lista de funcionalidades e novas faixas de estimativa

• Estimar em unidades de tempo é um método melhor

  • Story points acabam sendo convertidos em unidades de tempo
  • É mais eficiente evitar os procedimentos complicados do Scrum e simplesmente concluir o trabalho