Conceito e mecanismo
Uma lista de vinte tarefas técnicas não explica, por si só, o resultado esperado de um Sprint. Um objetivo como permitir ao operador identificar ficheiros em falta cria um critério para escolher alternativas. O Product Goal dá direção ao produto; o Sprint Goal dá coerência ao trabalho do Sprint. O plano detalhado pode mudar quando a equipa aprende. O Increment precisa de ser utilizável e cumprir a Definition of Done, não apenas reunir tarefas que foram marcadas como terminadas.
Aplicação guiada
No exercício, uma consulta simples permite identificar ficheiros em falta antes de estar pronta uma interface sofisticada. Discute se essa opção preserva o objetivo e os critérios de qualidade. Developers e Product Owner podem renegociar âmbito ao aprender, sem prejudicar o Sprint Goal. Se o objetivo do produto muda, itens antigos não permanecem prioritários apenas porque já foram detalhados. Refinar deve reduzir incerteza útil para decisões próximas; não precisa de transformar todo o futuro num plano minucioso e fixo.
A equipa troca um gráfico opcional por uma tabela utilizável e mantém a identificação de exceções como resultado do Sprint.
Armadilhas comuns
Tratar o Sprint Goal como lista rígida de tarefas; confundir trabalho iniciado com valor utilizável.
Tópicos relacionados: Previsão, capacidade e adaptação diária · Qualidade integrada e decisões de release
Os objetivos dão direção e os artefactos tornam a decisão inspecionável.
Referência: The Scrum Guide, November 2020 · PSM I; Scrum Guide November 2020; no public numbered exam revision