# Story points: como dimensionar o trabalho sem chutar horas > Story points dizem o tamanho de um trabalho em relação a outros, não quanto tempo ele leva. De onde vêm, como usá-los e quando contar histórias. Source: https://priortasks.com/pt/guides/story-points/ Last updated: 2026-11-05 Story points são um número que a equipe dá a um trabalho para dizer o quanto ele é grande em comparação com outros. Eles não medem horas. Um 5 é maior do que um 3 e menor do que um 8, e o que um 5 significa é definido pela equipe que o usa. ## De onde vêm Os story points vêm da Extreme Programming. Em [Story Points Revisited](https://ronjeffries.com/articles/019-01ff/story-points/Index.html), Ron Jeffries, um dos primeiros praticantes do método, descreve como tudo aconteceu. As equipes de XP estimavam as histórias primeiro em tempo. Depois passaram a usar “dias ideais”, o tempo que uma dupla precisaria sem interrupções, e multiplicavam por um fator de carga de cerca de três para chegar ao tempo real. Os interessados achavam confusa a contagem de dias, então as equipes começaram a chamá-los de “pontos”. Jeffries diz que pode ter inventado o termo e, se inventou, hoje lamenta. O livro *Agile Estimating and Planning* (2005), de Mike Cohn, ajudou a espalhar a prática. O Scrum não exige story points. O [Scrum Guide](https://scrumguides.org/scrum-guide.html) não os menciona. Ele diz que os Desenvolvedores que farão o trabalho são responsáveis por dimensioná-lo, e deixa a forma de fazer isso com eles. ## Por que as pessoas usam Há pouca pesquisa rigorosa por trás dos story points. As razões que as equipes dão são práticas. **Comparar é mais fácil do que prever.** É difícil dizer “isso leva dois dias”. É mais fácil dizer “isto é cerca de duas vezes aquela outra história”. Uma escala relativa permite que a equipe concorde sem discutir horas. **A conversão vem do seu próprio histórico.** As pessoas são otimistas com o próprio tempo. Em um estudo de 1994 de Roger Buehler, Dale Griffin e Michael Ross, estudantes previram que as suas monografias de conclusão levariam, em média, 33,9 dias, e levaram 55,5 (*Journal of Personality and Social Psychology*). Os pontos evitam uma promessa em horas. Você soma os pontos que a equipe realmente concluiu nos sprints recentes, e esse total, chamado velocidade, mostra quanto pegar no próximo. **Eles cobrem o trabalho inteiro da equipe e a dúvida.** Uma escala de pontos inclui testes, revisão e o desconhecido. Quanto maior o número, menos certa é a estimativa. O próprio Jeffries hoje lamenta o uso indevido deles e prefere cortar as histórias até que cada uma seja pequena. É uma alternativa justa, e ela aparece mais adiante. ## Como usar 1. **Escolha uma história de referência.** Pegue uma história concluída, combine que ela vale 2 ou 3, e dimensione as outras em relação a ela. 2. **Dimensione o trabalho inteiro.** Inclua desenho, construção, testes e revisão. Mais trabalho, mais complexidade e mais incerteza empurram o número para cima. 3. **Use uma escala limitada.** Números no estilo Fibonacci (1, 2, 3, 5, 8, 13) forçam uma escolha entre “maior” e “menor” e acabam com as discussões sobre 6 ou 7. 4. **Defina um teto.** Uma história acima de 13 é grande demais para planejar. Divida-a. 5. **Conte só histórias concluídas.** No fim do sprint, some os pontos das histórias prontas. Uma história quase pronta ainda não rende nada. 6. **Planeje com a média.** Tire a média dos seus sprints recentes e use-a como velocidade. Veja como uma equipe pode enxergar isso. “Adicionar a opção lembrar de mim” é um 2. “Redefinir uma senha por e-mail” é um 5, com e-mail, expiração e testes. “Exportar relatórios em PDF com layout” é um 13 e provavelmente precisa ser dividida. Se os últimos três sprints concluíram 18, 22 e 20 pontos, a equipe planeja cerca de 20. Use o [planning poker](https://priortasks.com/pt/guides/planning-poker/) para combinar os números juntos. ## Erros a evitar - **Transformar pontos em horas.** “Um ponto é meio dia” transforma uma escala relativa em um relógio ruim. - **Comparar a velocidade de equipes.** Os pontos de cada equipe significam coisas diferentes. Um número maior não quer dizer que se entregou mais. - **Julgar pessoas pela velocidade.** Quando os pontos viram meta, as pessoas inflacionam as estimativas para bater nela. - **Dar crédito parcial.** Conte uma história quando ela estiver pronta, e não antes. - **Reestimar depois do fato.** Mudar os números depois que o trabalho terminou esconde o que você aprendeu. - **Deixar cada pessoa usar a própria escala.** O número só vale quando a equipe inteira usa a mesma escala. ## Quando não é a ferramenta certa - **Quando os seus itens têm mais ou menos o mesmo tamanho.** Conte os itens. Jeffries prefere cortar as histórias em pedaços pequenos a dimensioná-las. - **Para tarefas pessoais.** Se você precisa de uma duração, use minutos. - **Quando um cliente paga por hora.** Ele quer horas, então estime horas. - **Quando os pontos não acrescentam nada.** Jeffries diz para abandoná-los se não ajudam, e mantê-los se a equipe gosta deles. - **Para uma equipe recém-formada.** Sem sprints por trás, não há velocidade. Conclua alguns sprints e observe o que você entrega. ## No Prior > [!pro] Os story points fazem parte do kit Scrum > Projetos Scrum e Scrumban precisam do Pro no plano do dono do projeto. Sem ele, o projeto funciona como Kanban: o símbolo de prioridade volta e os pontos ficam ocultos. Os seus dados são preservados e voltam quando o dono tiver o Pro. Veja [Planos e preços](https://priortasks.com/pt/docs/account/plans-and-pricing/). Escolha **Ágil · Scrum** ou **Ágil · Scrumban** em **Tipo de projeto** ao criar ou editar um projeto. As tarefas desse projeto passam a ser dimensionadas em pontos, em vez de por prioridade. - **Defina os pontos.** Os detalhes da tarefa têm a linha **Story points**, com uma fileira de cartas: 0, ½, 1, 2, 3, 5, 8, 13 e 21, mais **Limpar**. O compositor de tarefas tem um botão **Pontos** com o mesmo baralho. Um valor fora do baralho, como 4, ganha uma carta própria. Os pontos vão de 0 a 999, em passos de 0,5. A dica diz: “O tamanho do trabalho, não o tempo que leva.” - **Veja o tamanho.** Um selo de pontos substitui o símbolo de P1 a P4 nos cartões e nas linhas: três barras, com uma acesa até 1 ponto, duas até 3 e três até 13. Acima de 13, o selo mostra um “!” em coral, porque a história deve ser dividida. Uma tarefa sem estimativa mostra barras vazias e diz **Sem estimativa**. A prioridade continua editável. - **Estime em conjunto.** A aba **Planning Poker** grava o valor combinado na tarefa. Veja o guia de [planning poker](https://priortasks.com/pt/guides/planning-poker/). - **Divida o que é grande demais.** A mesa de poker oferece **Dividir a tarefa**, e o Prior AI propõe as partes se a sua conta tiver o Pro. Veja [Dividir uma história](https://priortasks.com/pt/docs/agile/split-a-story/). Em um projeto Scrum, os ciclos viram **Sprints**. Cada cartão de sprint mostra o progresso, como “13 de 21 pts concluídos”, e quantas tarefas estão “sem estimativa”, e o editor de sprint mostra os pontos que você comprometeu. O resumo de **Velocidade** acima dos cartões é a média dos pontos concluídos nos últimos três sprints encerrados, arredondada para uma casa decimal. Até um sprint terminar, ele mostra “Conclua um sprint para ver sua velocidade”. Os pontos são mantidos quando você volta um projeto para Kanban ou Padrão. Eles ficam ocultos, não são apagados. Também seguem com a sincronização, a exportação dos dados e as ferramentas MCP, e uma estimativa em umérica do Linear vira story points ao importar. Para a referência completa, veja [Story points](https://priortasks.com/pt/docs/agile/story-points/) e [Ciclos e sprints](https://priortasks.com/pt/docs/agile/cycles-and-sprints/).