Histórias de usuário e planejamento de iteração

Uma história de usuário é uma descrição curta de algo de que um usuário precisa, escrita do ponto de vista dele. O planejamento de iteração é como uma equipe decide em quais histórias vai trabalhar na próxima caixa de tempo. Muitas equipes chamam essa caixa de tempo de sprint e a reunião de sprint planning; o East Agile Tracker as chama de iterações e planejamento de iteração.

O que é uma história de usuário

O modelo mais comum é:

Como [tipo de usuário], eu quero [alguma capacidade], para que [algum benefício].

Por exemplo: Como gerente de projeto, eu quero ver quais histórias estão bloqueadas, para que eu possa desbloqueá-las antes de a iteração terminar.

O modelo diz quem se beneficia, do que precisa e por quê. O “por quê” permite que a equipe encontre uma forma mais simples de entregar o mesmo benefício. Uma história é um lembrete de uma conversa, não uma especificação completa: os detalhes são definidos entre quem pede e quem constrói.

INVEST: a história está pronta?

INVEST é um checklist para uma história bem formada:

• Independent (Independente) — pode ser construída e entregue sozinha.
• Negotiable (Negociável) — os detalhes estão abertos a discussão.
• Valuable (Valiosa) — entrega algo que importa para um usuário ou cliente.
• Estimable (Estimável) — a equipe a entende bem o suficiente para dimensioná-la.
• Small (Pequena) — cabe confortavelmente em uma iteração.
• Testable (Testável) — há uma forma clara de saber que ela está pronta.

Critérios de aceitação

Os critérios de aceitação dizem o que precisa ser verdade para que a história conte como pronta. Escrevê-los no formato Given / When / Then transforma cada um em um teste de aceitação:

Given uma história com um bloqueio não resolvido, when eu abro a coluna Blocked, then a história aparece nela.

Os critérios são combinados antes de o trabalho começar, para que a equipe e a pessoa que aceita a história compartilhem a mesma definição de pronto.

Planejamento de iteração

O planejamento de iteração responde a uma pergunta: em que vamos trabalhar nesta iteração? Ele precisa de três entradas:

1. Um backlog ordenado — histórias classificadas por prioridade, com as do topo prontas (atendendo ao INVEST, com critérios de aceitação).
2. Estimativas — cada história candidata dimensionada em story points.
3. Velocidade — quantos pontos a equipe conclui por iteração. Veja O que é velocidade?.

A equipe pega histórias do topo do backlog até o total atingir sua velocidade. Assumir mais que isso depende de a equipe de repente trabalhar mais rápido; assumir menos deixa capacidade sem uso.

Como o East Agile Tracker faz

• As histórias têm quatro tipos: features, bugs, chores e releases. Por padrão, só as features recebem pontos. Veja Histórias.
• Os critérios de aceitação vão na descrição. Não há um campo separado; os critérios pertencem à descrição antes de a história ser iniciada. Quando uma história é entregue, o product owner a aceita ou a rejeita com base nesses critérios. Veja a máquina de estados e o ciclo de aceitação.
• O backlog é uma única lista em ordem estrita, e ele projeta as próximas iterações a partir da velocidade, três ou quatro adiante, marcando qualquer grupo que exceda a velocidade. Veja Iterações.
• O planejamento de iteração é em grande parte automático. Com auto-plan iterations ligado (o padrão), a iteração atual é preenchida até a sua velocidade; puxar uma nova história move a de menor prioridade de volta para o topo do Backlog. Equipes que se comprometem com um escopo fixo, no estilo Scrum, podem desligar o auto-plan e planejar quanto quiserem, com um contador que fica vermelho acima da velocidade. Veja Planejar uma iteração.
• Criar uma história abre um compositor para título, descrição, tipo, estimativa e donos. Veja Criar uma história.

Leitura adicional

• O que são story points? — dimensionar histórias.
• O que é velocidade? — o lado da capacidade no planejamento.
• eXtreme Programming — de onde vêm as histórias de usuário e o Jogo do Planejamento.