Iterações, fluxo e evidência de progresso

Conceito e mecanismo

Planear uma iteração começa pelo resultado que se pretende obter ou pela incerteza que importa reduzir. Uma lista extensa de tarefas não explica, por si só, por que vale a pena realizar o trabalho. Define uma fatia que permita observar comportamento útil, as condições para a considerar concluída e quem pode fornecer feedback relevante.

Reutiliza informação de âmbito e dependências, mesmo quando vem de uma WBS preparada para entrega preditiva. A estrutura por camadas técnicas pode precisar de ser reorganizada: interface, regras e dados isolados não formam necessariamente uma entrega utilizável.

Um percurso simples de ponta a ponta pode permitir testar uma hipótese com menos compromisso. Separar âmbito não significa reduzir condições obrigatórias de qualidade. Uma simulação pode apoiar aprendizagem sobre interação, mas não demonstra integração real ou autorização para produção.

Mantém essa fronteira explícita ao apresentar a demonstração e ao selecionar trabalho posterior.

Aplicação guiada

Num serviço fictício, o objetivo é permitir que um cliente peça um reembolso simples, veja a validação e receba confirmação. Um relatório de gestão é desejável, mas não é necessário para esse resultado. A equipa identifica uma dependência externa de certificado com prazo de uma semana.

Prepará-la apenas no último dia comprometeria a previsão. Durante o trabalho, descobre uma alteração pequena necessária à confirmação. Se retirar o relatório opcional mantém o Sprint Goal viável, Product Owner e Developers podem clarificar esse ajuste de âmbito e os Developers atualizam o plano.

Não chamam concluída à fatia sem confirmação nem retiram validação para manter todos os itens inicialmente selecionados. A revisão considera o que está efetivamente Done e a razão da divergência face à previsão. A informação serve para melhorar seleção e preparação seguintes, sem apagar o histórico.

Artefactos e decisões durante a iteração

Em Scrum, o Product Goal é o compromisso do Product Backlog, o Sprint Goal é o compromisso do Sprint Backlog e a Definition of Done é o compromisso do Increment. Os Developers selecionam trabalho considerando desempenho anterior, disponibilidade e condições de conclusão.

O Sprint Backlog evolui com a aprendizagem, sem transformar cada pedido novo numa obrigação automática. Colabora com o Product Owner quando o âmbito precisa de ser clarificado ou renegociado e preserva o objetivo. Um item que não cumpre Done não passa a estar concluído porque terminou o Sprint.

Fica visível para futura consideração no Product Backlog. O objetivo e os critérios permitem discutir por que seis itens concluídos de uma previsão de oito podem ainda representar um resultado útil, ou por que oito itens superficialmente terminados podem falhar o resultado procurado. Não converte pontos em horas nem compara equipas sem base adequada.

Interpretar gráficos e populações

Um burndown de trabalho restante pode subir quando se descobre trabalho necessário; isso não prova que a equipa deixou de trabalhar. Um burnup com linhas de âmbito total e trabalho concluído ajuda a separar entrega de crescimento do âmbito.

Vinte unidades concluídas num âmbito de 80 representam 25%; se o âmbito passa a 100 sem nova conclusão, representam 20%. A redução da percentagem não apaga o trabalho feito. Anota a alteração em vez de reescrever o histórico.

Num diagrama de fluxo cumulativo, uma faixa de validação que alarga sugere acumulação: investiga capacidade, bloqueios e políticas, sem presumir uma única causa. Mede throughput como conclusões por período. A distribuição de cycle time dos concluídos deve ser acompanhada da idade do trabalho aberto; concluir itens rápidos enquanto os antigos continuam bloqueados pode melhorar a mediana sem recuperar o serviço para todos.

Prioridade e sucesso com condições explícitas

Ordena trabalho considerando impacto, risco, urgência, esforço, dependências e condições de execução. Maior valor esperado não obriga a iniciar um item bloqueado antes de obter a autorização necessária; pode justificar preparar a dependência e selecionar outro resultado útil entretanto.

Num piloto, define antecipadamente população, janela de observação e critérios conjuntos. Se a meta é reduzir contactos de suporte para, no máximo, 20 por 100 utilizadores e manter erros abaixo de 3%, observar 18 contactos e 6% de erros não satisfaz o critério completo.

Regista a melhoria e a condição falhada, investiga o retrabalho e decide se uma correção merece nova experiência. Não transforma erros em entregas adicionais para aumentar volume. O critério de resultado dá direção à decisão de continuar, adaptar ou parar, e o registo conserva as condições que tornam a comparação válida.

Armadilhas comuns

Confundir esforço com conclusão; substituir o objetivo por contagem de tarefas; ocultar trabalho descoberto para preservar um gráfico; comparar escalas de pontos diferentes; apresentar mediana como prazo máximo; excluir itens abertos antigos; alterar critérios de sucesso depois de conhecer o resultado.