As estimativas dão errado de maneiras já conhecidas: números que têm significados diferentes para pessoas diferentes, sessões que se prolongam além do previsto, previsões nas quais ninguém confia. A solução raramente é uma fórmula melhor — trata-se de um entendimento comum que toda a equipe compartilha, e de estimativas tratadas como previsões, em vez de compromissos que podem ser usados contra você.

Este guia aborda os elementos que se mostram eficazes na prática — histórias de usuário, planning poker, pontos de história, velocidade e as técnicas que continuam funcionando quando uma história acaba sendo maior do que parecia inicialmente. Quando estiver pronto para realizar uma estimativa com sua equipe, faça a estimativa no TeamRetro: planning poker com votação privada, baralhos reutilizáveis e pontos de história finais que são sincronizados diretamente com seu backlog.

Capítulo 1O que é o Planning Poker?

O Planning Poker é uma técnica ágil de estimativa baseada no consenso: as equipes votam em sigilo, revelam todas as cartas de uma só vez e discutem a variação das estimativas até que elas convergirem.

Capítulo 2Como conduzir uma sessão de Planning Poker

Como conduzir uma sessão de Planning Poker que gere estimativas úteis sem se arrastar: preparação, a rodada de quatro fases, escolha do baralho e limitação rigorosa do tempo.

Dois bonecos de post-it, de costas um para o outro, comparando suas alturas com uma marca na parede, satisfeitos por terem decidido qual deles é mais alto.
Capítulo 3O que são pontos de história? Estimando o esforço, não o tempo

Os story points medem o esforço relativo, a complexidade e a incerteza do trabalho, e não as horas. Como determinar o tamanho em relação a uma história de referência e as dúvidas que costumam confundir as equipes.

Capítulo 4Por que os story points utilizam a sequência de Fibonacci

Os pontos de história aumentam de 1, 2, 3, 5, 8 e 13 porque as diferenças cada vez maiores refletem a incerteza — a escala deixa de fingir que é possível distinguir um 13 de um 14. Eis por que essas diferenças são o ponto principal.

Capítulo 5Pontos de história x horas: por que convertê-los é uma armadilha

Os pontos de história medem o esforço relativo; as horas medem a duração — são eixos diferentes. Se você criar uma tabela de conversão de pontos para horas, sem perceber, estará voltando a estimar o tempo.

Um boneco feito de post-it em um quadro branco traçando uma linha que atravessa seis colunas de sprint, apontando para a parte central estável, em vez do pico mais alto.
Capítulo 6Velocidade da equipe no ágil: como medi-la e utilizá-la (+ calculadora gratuita)

Saiba o que é a velocidade da equipe no ágil, como calculá-la e como planejar sprints com base nela, além de uma calculadora de velocidade gratuita.

Capítulo 7Estimativa relativa versus estimativa absoluta (e por que a relativa é melhor)

As pessoas não são boas em estimar “quanto tempo isso vai levar”, mas são boas em avaliar “isso é maior do que aquilo”. A estimativa relativa usa o segundo critério — e é por isso que os pontos de história funcionam.

Capítulo 8O cone de incerteza na estimativa ágil

As estimativas iniciais apresentam uma grande variação porque o trabalho é desconhecido, e não porque sua equipe não seja boa em fazer estimativas. O que significa o “cone de incerteza” e como reduzi-lo — e não aumentá-lo.

Capítulo 9Épico x história x tarefa: a hierarquia ágil explicada

Épicos, histórias e tarefas são três níveis, cada um com três funções. O que cada um representa, qual deles acumula pontos de história e por que focar no nível errado torna a velocidade sem sentido.

Um personagem em forma de post-it se afastando de uma parede cheia de post-its amontoados, pensando em qual deles ajustar o tamanho.
Capítulo 10Técnicas ágiles de estimativa: qual usar e quando

Um guia prático para a escolha de técnicas de estimativa ágil: planning poker, story points, t-shirt sizing, estimativa por afinidade e velocidade, e quando usar cada uma delas.

Capítulo 11Erros e antipadrões no Planning Poker

As falhas recorrentes nas sessões de Planning Poker — cálculo da média das cartas, estimativas em horas, velocidade usada como arma, inflação de pontos de história — e como corrigir cada uma delas.

Capítulo 12Critérios de aceitação: como redigi-los

Os critérios de aceitação são o teste de aprovação ou reprovação de uma história, redigidos antes do início do trabalho — os formatos que funcionam, exemplos práticos e como eles se diferenciam da definição de “concluído”.

Capítulo 13Definição de “concluído”

A definição de “concluído” consiste em uma lista de verificação para toda a equipe, que cada história deve cumprir antes de ser entregue. Um exemplo de DoD, quem é o responsável por ela e como ela difere dos critérios de aceitação.

Capítulo 14Definição de “pronto”

A definição de “pronto” é a lista de verificação que indica que uma história está pronta para ser incluída no sprint. O que uma lista útil abrange, por que a maioria é ignorada e qual versão realmente bloqueia o processo.

Capítulo 15Divisão de histórias de usuário que não cabem em um sprint

Uma história que você não consegue avaliar geralmente é aquela que ainda não está pronta para ser lançada. Como saber quando dividi-la, quais são as linhas de corte que geram partes prontas para lançamento e quais são apenas uma aparência de que estão prontas.

Capítulo 16Divisão de histórias no SPIDR

O SPIDR consiste em cinco maneiras confiáveis de dividir uma história de usuário — spike, caminho, interface, dados e regras. Cada linha de divisão: quando funciona e quando produz uma divisão incorreta.

Capítulo 17Divisão horizontal x vertical

As divisões verticais geram valor; as divisões horizontais geram promessas. Por que a divisão por camada tecnológica adia a geração de valor e como dividir por resultado para o usuário, de modo que algo seja entregue a cada sprint.

Capítulo 18O que é uma história de usuário?

Uma história de usuário é uma promessa de valor breve e redigida em linguagem simples. O formato “função-objetivo-benefício”, os três Cs, a lista de verificação INVEST e os casos em que as histórias não são a ferramenta adequada.

Capítulo 19Exemplos de histórias de usuário: 16 histórias comentadas, boas e ruins

Dezesseis exemplos de histórias de usuário nas áreas de autenticação, comércio eletrônico, dispositivos móveis, APIs e bugs — cada um deles anotado, com as versões incorretas apresentadas ao lado de suas reescritas, para que a diferença fique visível.

Capítulo 20Modelo de história de usuário e critérios de aceitação

O modelo clássico de história de usuário com um cartão do tipo “copiar e colar”, as variantes que vale a pena conhecer e um exemplo prático que vai do modelo aos critérios de aceitação e à estimativa.

Personagens em post-its vestindo camisetas com etiquetas de tamanho, alinhados sob um cartão de tarefa para, juntos, determinar o tamanho ideal.
Capítulo 21O sistema de tamanhos “T-shirt” ágil: como funciona e quando usá-lo

O que é o sistema de tamanhos de camisetas, como conduzir uma sessão e como converter os tamanhos S/M/L em pontos de história, além de quando o Planning Poker é a melhor opção.