Sete verificações antes de começar
Usa esta lista no refinement. Uma resposta negativa abre uma conversa; não rejeita automaticamente o ticket.
1. Objetivo
Que problema resolvemos, para quem e como reconheceremos o resultado? Explica o valor antes de escolher a implementação.
2. Âmbito
Que ecrã, serviço ou fluxo está incluído? O que fica de fora? Separa alterações independentes quando exigem decisões diferentes.
3. Comportamento esperado
O que faz a pessoa, o que mostra o sistema e o que conta como sucesso? Num erro, regista o comportamento observado e o esperado.
4. Papéis e permissões
Quem pode executar a ação? Verifica as permissões existentes. Não inventes um papel novo por faltar uma indicação no ticket.
5. Casos limite e erros
Escolhe casos que podem alterar a solução: numa exportação, por exemplo, resultados vazios e pedidos falhados. Decide o que a pessoa vê, se pode repetir e se existe sucesso parcial.
6. Dependências
Estão disponíveis API, design, conteúdo, dados e acessos? Liga a fonte de referência e atribui uma pessoa responsável a cada dependência em aberto.
7. Critérios de aceitação
É possível verificar se o trabalho terminou? Escreve condições observáveis a partir de requisitos confirmados. O guia de critérios de aceitação ajuda a evitar pressupostos.
Bloqueio ou pergunta normal?
Um bloqueio é uma decisão cuja resposta pode mudar substancialmente a solução. Antes de desenhar um pagamento, importa saber se é único ou recorrente. O texto final de um botão pode, em certos casos, ser decidido enquanto a lógica avança; mesmo assim, regista quem decide e quando.
O limite depende da tarefa. A comparação entre Definition of Ready e critérios de aceitação explica a decisão de começar. Depois de fechares as lacunas importantes, estima a tarefa. A ferramenta de preparação de tarefas ajuda a identificar decisões em aberto antes do refinement.