1. Objetivo
Ao final do exercício, o grupo deverá ser capaz de:
- definir um objetivo de iteração;
- selecionar itens de backlog coerentes com esse objetivo;
- identificar itens que não estão prontos para desenvolvimento;
- aplicar critérios de Definition of Ready (DoR);
- definir uma política simples de fluxo;
- estabelecer limites de WIP;
- definir uma Definition of Done (DoD);
- identificar dependências e riscos;
- justificar as decisões tomadas.
2. Cenário
Vocês fazem parte de um time de desenvolvimento responsável por um aplicativo de delivery de comida.
O produto possui muitos usuários, mas a empresa identificou um problema:
Muitos usuários abandonam o pedido antes de finalizá-lo.
Os dados atuais mostram:
- 100.000 pedidos iniciados por mês;
- 68% chegam à tela de pagamento;
- apenas 42% são efetivamente concluídos;
- usuários reclamam principalmente da quantidade de informações solicitadas e da dificuldade para finalizar o pagamento.
A direção definiu o seguinte objetivo:
Aumentar a conversão do checkout, reduzindo o atrito durante a finalização do pedido.
O time possui 6 pessoas:
- 3 desenvolvedores;
- 1 QA;
- 1 UX/UI;
- 1 Product Owner.
A próxima iteração terá 2 semanas.
3. Backlog disponível
O Product Owner trouxe os seguintes itens:
| ID | Item | Observações |
|---|---|---|
| HIST-101 | Reduzir campos obrigatórios do checkout | UX já possui uma proposta inicial |
| HIST-102 | Comprar com 1 clique | Depende de cartão previamente cadastrado |
| HIST-103 | Criar cadastro de cartão | Integração com gateway ainda não validada |
| HIST-104 | Melhorar mensagem de erro do pagamento | Regras já conhecidas |
| HIST-105 | Criar dashboard de conversão | Métricas ainda precisam ser definidas |
| HIST-106 | Criar novo layout do checkout | Protótipo ainda não aprovado |
| HIST-107 | Corrigir timeout no pagamento | Incidente conhecido em produção |
| HIST-108 | Adicionar cupom de desconto | Regra de negócio ainda não definida |
| HIST-109 | Teste A/B do novo checkout | Depende do novo checkout |
| HIST-110 | Atualizar documentação da API de pagamento | API já está estável |
| HIST-111 | Migrar dados dos cartões antigos | Estratégia de migração ainda não definida |
| HIST-112 | Adicionar logs de conversão | Eventos ainda não foram especificados |
4. Informações adicionais
Durante o planejamento, vocês descobrem:
Capacidade
O histórico do time é de aproximadamente:
12 itens por iteração
Entretanto, nesta iteração:
- uma pessoa ficará 2 dias ausente;
- existe uma integração externa de risco;
- o time quer reduzir multitarefa.
Considerem uma capacidade planejada de aproximadamente:
8 a 10 itens pequenos, dependendo do tamanho e das dependências.
Política de fluxo inicial
O time decidiu trabalhar inicialmente com:
| Coluna | WIP |
|---|---|
| Ready | 6 |
| Dev | 3 |
| Code Review | 2 |
| Test | 2 |
| Done | ∞ |
A regra é:
Não iniciar trabalho novo enquanto houver trabalho bloqueado ou aguardando revisão/teste.
5. Parte 1 — Objetivo da iteração
Definam um Sprint Goal para a iteração.
O objetivo deve:
- ser curto;
- representar um resultado;
- estar relacionado ao problema do checkout;
- permitir verificar posteriormente se a iteração foi bem-sucedida.
Como saberemos que atingimos o objetivo?
Definam 2 métricas ou critérios de sucesso.
6. Parte 2 — Aplicando o DoR
Para cada item abaixo, decidam:
- 🟢 Ready — pode entrar na iteração;
- 🔴 Not Ready — ainda precisa de trabalho antes de entrar.
Avaliem usando os critérios de DoR:
- objetivo/valor claro;
- critérios de aceite testáveis;
- dependências conhecidas;
- riscos identificados;
- tamanho adequado;
- dados necessários disponíveis;
- estratégia de testes possível.
| Item | Ready? | Justificativa |
|---|---|---|
| HIST-101 | ||
| HIST-102 | ||
| HIST-103 | ||
| HIST-104 | ||
| HIST-105 | ||
| HIST-106 | ||
| HIST-107 | ||
| HIST-108 | ||
| HIST-109 | ||
| HIST-110 | ||
| HIST-111 | ||
| HIST-112 |
7. Parte 3 — Selecionando a iteração
Agora vocês devem selecionar os itens que realmente entrarão na iteração.
Regra
Não basta escolher os itens “mais legais”.
Eles devem:
- contribuir para o Sprint Goal;
- estar suficientemente prontos;
- caber na capacidade;
- considerar dependências e riscos.
Itens selecionados
| Ordem | Item | Por que foi selecionado? |
|---|---|---|
| 1 | ||
| 2 | ||
| 3 | ||
| 4 | ||
| 5 | ||
| 6 | ||
| 7 | ||
| 8 |
Itens explicitamente NÃO selecionados
Escolham pelo menos 3 itens que ficarão fora.
| Item | Motivo |
|---|---|
8. Parte 4 — Desenhando o fluxo
Desenhem no papel um quadro Kanban para a equipe.
O quadro deve conter:
Ready → Dev → Code Review → Test → Done
Depois, definam:
1. Limite de WIP
Vocês podem alterar os limites propostos inicialmente.
| Coluna | WIP escolhido | Justificativa |
|---|---|---|
| Ready | ||
| Dev | ||
| Code Review | ||
| Test |
2. Política de fluxo
Criem pelo menos 4 regras explícitas.
Exemplo:
“Um item não pode entrar em Code Review enquanto os testes locais não estiverem passando.”
9. Parte 5 — Criando a DoD
Agora definam uma Definition of Done para uma história.
A DoD deve responder:
“O que precisa ser verdade para podermos afirmar que esta história realmente está concluída?”
Escolham pelo menos 6 critérios.
10. Parte 6 — O problema inesperado
O professor informa uma nova situação:
No terceiro dia da iteração, o gateway de pagamento apresenta instabilidade. A HIST-102 fica bloqueada e não poderá avançar por pelo menos dois dias.
O grupo deve decidir:
1. O que acontece com HIST-102?
2. O time deve iniciar outro item?
3. Qual item poderia ser puxado?
4. O WIP deve ser alterado?
5. Como o bloqueio deve aparecer no quadro?
11. Entrega do grupo
Ao final dos 50 minutos, o grupo deverá apresentar:
- Sprint Goal
- Critérios de sucesso
- Classificação dos itens pelo DoR
- Itens selecionados para a iteração
- Quadro de fluxo
- Limites de WIP
- Políticas de fluxo
- Definition of Done
- Decisão sobre o bloqueio
A apresentação deverá durar aproximadamente 2 minutos por grupo.
12. Perguntas para discussão
Após as apresentações, discutam:
Pergunta 1
Por que um item tecnicamente pequeno pode não estar “Ready”?
Pergunta 2
Qual é o problema de simplesmente aumentar o WIP quando alguém fica sem trabalho?
Pergunta 3
Qual é a diferença entre:
“O código foi escrito”
e
“A história está Done”?
Pergunta 4
O DoR é uma burocracia ou uma ferramenta de redução de risco?
Pergunta 5
Se o time possui capacidade para 10 itens, por que pode ser melhor selecionar apenas 7?
Resultado esperado
O objetivo não é encontrar uma única resposta correta.
O grupo deverá demonstrar que consegue justificar suas decisões usando os conceitos de:
Objetivo → Capacidade → DoR → Seleção → WIP → Fluxo → DoD → Feedback
A principal pergunta que deve orientar o exercício é:
“Como podemos organizar o trabalho para aumentar a probabilidade de entregar valor com qualidade ao final da iteração?”