O que é Story Points?

A estimativa relativa com story points foi popularizada em práticas ágeis e descrita por autores como Mike Cohn. O Scrum Guide de 2020 não prescreve essa escala. Sua utilidade depende de referências compartilhadas no próprio time e da decisão que a estimativa apoia; não existe tabela oficial que converta pontos em dias.

Story points são uma escala relativa usada por algumas equipes para comparar o tamanho de itens de trabalho. Em vez de afirmar que um item levará exatamente certo número de horas, o grupo pergunta como ele se compara a referências já conhecidas. Complexidade, quantidade de trabalho e incerteza podem influenciar a avaliação. Não existe conversão universal de um ponto para tempo. O Scrum Guide não exige pontos, Planning Poker nem qualquer técnica específica de estimativa.

Crie referências compartilhadas. Escolha itens concluídos que a equipe compreende e use-os para calibrar a escala. Se um item novo parece aproximadamente duas vezes maior que uma referência, a conversa importa mais que a precisão aparente do número. Referências devem ser revisadas quando produto, tecnologia ou composição do time mudarem. Comparar pontos de equipes diferentes é frágil, porque cada grupo forma seu próprio entendimento.

Converse sobre divergências. Em Planning Poker, pessoas fazem estimativas individualmente e revelam ao mesmo tempo, para que perspectivas diferentes apareçam. Alguém pode enxergar dependência desconhecida enquanto outra pessoa assume um caso simples. A divergência é oportunidade para descobrir risco e fatiar trabalho, não votação sobre quem está certo. Uma discussão útil pode terminar com item reescrito ou adiado para investigação, mesmo sem número final.

Use escala grosseira. Sequências como 1, 2, 3, 5, 8 e 13 deixam claro que a incerteza cresce com o tamanho. O formato exato não é obrigatório. Se um item ultrapassa uma referência combinada, fatiá-lo em resultados menores costuma ser mais útil que debater se vale 21 ou 34. Não transforme a escala em sistema de contabilidade com casas decimais e ajustes por pessoa.

Separe tamanho de duração. Dois times podem atribuir cinco pontos a trabalhos de dificuldade semelhante e levar tempos diferentes para terminá-los. Mesmo no mesmo time, bloqueios e interrupções alteram prazo. Pontos são entrada possível para previsão, mas não promessa individual. Para responder a uma pergunta de data, observe histórico do próprio time, variação dos itens, capacidade futura e escopo ainda desconhecido. A previsão deve expressar incerteza.

Trate velocity com cautela. Somar pontos concluídos por Sprint pode ajudar uma equipe estável a pensar em capacidade futura. Não é métrica de valor, produtividade pessoal ou comparação entre grupos. Aumentar pontuações sem mudar entregas eleva velocity no papel. Mudanças na Definition of Done, composição, tipo de demanda ou política de estimativa podem quebrar a série histórica. Use o número para aprender, não para pressionar.

Compare com alternativas. Contagem de itens concluídos, throughput, tempo de ciclo e classes de tamanho podem apoiar previsões sem estimar cada história em pontos. Um time com itens pequenos e razoavelmente homogêneos pode preferir contar entregas. Um time com grande variabilidade talvez precise fatiar antes de qualquer método. A escolha depende da pergunta e do custo da estimativa. Não atribua pontos apenas por tradição.

Evite esforço individual. O item é realizado pelo time dentro de seu sistema de trabalho. Transformar cinco pontos em “cinco dias da pessoa sênior” cria disputa de capacidade e desincentiva colaboração. Diferentes habilidades podem influenciar a conversa, mas o número não deve virar avaliação de desempenho. Ajuda técnica, revisão e testes fazem parte do trabalho necessário para chegar a Done.

Não some o desconhecido como certeza. Um backlog distante pode conter itens grandes e imprecisos. Somar seus pontos e dividir pela última velocity dá uma data aparentemente exata para um escopo que ainda mudará. Use faixas, cenários e revisão frequente. Também considere se hipóteses de valor podem ser testadas antes de construir tudo. Um plano de release serve para orientar decisões, não para esconder incerteza.

Inspecione custo e benefício. Se sessões longas produzem debates de meia hora sobre um ponto sem mudar decisões, simplifique. Se a comparação revela requisitos e dependências antes ignorados, pode valer o investimento. Revise previsões depois das Sprints e pergunte se a técnica ajudou a escolher, dividir e entregar. Pontos são ferramenta de conversa; o resultado é melhor compreensão e fluxo, não uma pontuação perfeita.

Exemplo hipotético: uma equipe usa como referência uma alteração já concluída de três pontos. Ao discutir uma história de cadastro, metade do grupo propõe três e metade oito. A diferença revela que uma pessoa incluiu migração de dados antigos e outra imaginou apenas o novo formulário. O Product Owner esclarece a necessidade, e o grupo separa uma migração técnica e uma entrega menor de cadastro.

Depois de algumas Sprints, o time observa que concluiu 18, 22 e 16 pontos. Não anuncia que fará exatamente 19 no próximo ciclo; considera férias, suporte e tipo de itens. Também observa quantos itens terminam e quanto tempo levam, para não depender de uma única medida. Os números são apenas ilustrativos, não referências de desempenho.

Ao comparar seu resultado com outro time, percebe que o segundo usa escala diferente. Evita concluir que uma equipe é mais produtiva. O valor dos pontos está na calibragem interna e na conversa que revelou a migração oculta.

Horas tentam representar duração ou esforço em unidade temporal; pontos comparam tamanho relativo dentro de um time. Contar itens concluídos e medir tempo de ciclo são alternativas para acompanhar fluxo e prever entrega. Nenhuma medida elimina variabilidade. Escolha a que responde à pergunta com custo de coleta razoável e dados comparáveis, sem transformar a métrica em meta de produtividade individual.

Cursos K21 recomendados