APRENDER. PRATICAR. EVOLUIR.Escolhas de produto apoiadas em evidência
Scrum é um framework para produzir valor e aprender perante complexidade. Para o PO, empirismo significa decidir com observações em vez de defender uma previsão apesar dos resultados. Transparência permite compreender o estado; inspeção compara o que acontece com o esperado; adaptação altera a próxima escolha. Compromisso, foco, abertura, respeito e coragem sustentam esse trabalho. Num portal de operações, mostra que um piloto não reduziu chamadas, ouve os operadores e investiga a hipótese. Ciclos iterativos e incrementais podem antecipar feedback, reduzir investimento numa solução sem valor e tornar falhas de integração visíveis mais cedo. Se omitires a Review, perdes uma oportunidade conjunta de discutir resultado e contexto; sem Retrospective, a equipa pode repetir obstáculos de colaboração. A colaboração com clientes e a resposta à mudança refletem valores do Manifesto Ágil, sem dispensar qualidade, acordos ou planeamento. Conversar diretamente sobre uma tarefa difícil e observar software funcional ligam também pessoas e interações à evidência de progresso.
Colaboração sem concentrar todas as decisões
O PO mantém responsabilidade pelo valor e gestão do Product Backlog. Os Developers decidem o plano técnico para produzir incrementos utilizáveis e adaptam-no; o Scrum Master ajuda a equipa a compreender e aplicar Scrum e a melhorar eficácia. Antes de selecionar trabalho, o PO explica o efeito pretendido; os Developers esclarecem viabilidade; o Scrum Master pode ajudar a remover uma barreira à colaboração. Uma equipa multifuncional dispõe coletivamente das competências necessárias. Com autogestão, decide internamente quem faz o quê, quando e como. Pode assim reduzir esperas entre especialidades, ligar qualidade ao resultado conjunto e decidir mais perto da informação. O PO não precisa de distribuir tarefas para manter direção de produto. Também não pode prometer autonomia sobre decisões de segurança que pertencem a outra autoridade.
Duração da Sprint e ritmo de aprendizagem
A Sprint tem duração fixa até um mês e contém o trabalho para criar valor em direção ao Product Goal. A próxima começa imediatamente após a anterior. Ao discutir a duração, considera o tempo até feedback útil, o risco de pressupostos errados e a capacidade de produzir uma fatia utilizável. Uma entrevista marcada para daqui a seis semanas não transforma seis semanas numa duração válida de Sprint. Podes trabalhar noutra hipótese verificável enquanto resolves esse acesso. Timeboxes limitam investimento numa conversa, ajudam a focar a decisão e tornam previsíveis oportunidades de inspeção. Reserva preparação suficiente e regista decisões pendentes. O limite temporal não transforma um protótipo incompleto num incremento nem torna verdadeira uma previsão comercial.
Onde participar e o que decidir
Sprint Planning abre a Sprint e envolve toda a Scrum Team: clarificar valor, selecionar trabalho e construir um plano. O PO prepara prioridades e propósito; pessoas externas podem aconselhar. O máximo numa Sprint de um mês é oito horas. O Daily Scrum pertence aos Developers, dura 15 minutos por dia de trabalho e serve para adaptar o plano ao Sprint Goal. O PO participa como Developer quando está ativamente a trabalhar em itens do Sprint Backlog; não precisa de recolher relatórios individuais nesse evento. A Sprint Review ocorre perto do fim, com Scrum Team e stakeholders relevantes, para inspecionar resultado e contexto e discutir adaptações: até quatro horas numa Sprint de um mês. A Retrospective conclui a Sprint com a Scrum Team e procura melhorias de qualidade e eficácia: até três horas numa Sprint de um mês. Em Sprints mais curtas, Planning, Review e Retrospective costumam ser menores, sem uma fórmula proporcional obrigatória. Refinement decorre conforme necessário e não é um sexto evento formal.
Três artefactos, três referências de compromisso
O Product Backlog é ordenado, emergente e transparente: mostra trabalho para melhorar o produto e contém o Product Goal. Este objetivo descreve a evolução que a equipa procura. O Sprint Backlog reúne objetivo, itens escolhidos e plano, é visível e adaptável e pertence aos Developers; o compromisso é o Sprint Goal. O Increment é utilizável, integra-se com os anteriores e foi verificado; o compromisso de qualidade é a Definition of Done. Ao falar com o sponsor, distingue estas três evidências. Uma lista longa de pedidos não comprova execução. Um plano detalhado não comprova conclusão. Uma capacidade Done demonstra uma condição de qualidade e utilização, mas ainda precisas de observar se produz o benefício esperado. Os compromissos tornam as conversas mais precisas sem eliminar incerteza.
Refinement, atributos e mudanças de âmbito
Um item pode ter descrição, ordem e tamanho. A descrição clarifica o que se procura; a ordem mostra prioridade relativa; o tamanho ajuda quem fará o trabalho a avaliar esforço e seleção. Refinement inclui dividir itens, esclarecer necessidades e discutir estes atributos. Ajuda a preparar escolhas compreendidas e a descobrir dependências cedo. O Product Backlog evolui porque utilizadores, condições e conhecimento mudam, não porque qualquer pedido entra diretamente na Sprint. Durante a Sprint, os Developers atualizam o plano e colaboram com o PO para renegociar âmbito sem comprometer o Sprint Goal. Mantém-se esse objetivo para preservar foco e coerência. Quando se torna obsoleto, cabe ao PO ponderar cancelamento. Antes de pedir uma troca de item, explica que aprendizagem mudou e verifica o efeito no objetivo e na qualidade.
Vários incrementos e uma qualidade compreendida
Uma Sprint pode produzir vários incrementos; não é necessário guardar toda a entrega para o último dia ou para aprovação na Review. Uma release continua sujeita aos controlos operacionais aplicáveis. A Definition of Done evolui com aprendizagem e mínimos da organização. Discute cedo um novo critério de recuperação, torna o trabalho necessário visível e evita declarar Done apenas porque uma data comercial chegou. Não se baixa a qualidade durante a Sprint. Em duas equipas no mesmo produto, uma Definition of Done comum evita significados incompatíveis de conclusão e ajuda a garantir que os resultados funcionam em conjunto. Uma equipa pode usar verificações adicionais, mas o produto precisa de referência comum. Para o sponsor, distingue trabalho selecionado, qualidade demonstrada, disponibilidade para utilizadores e benefício observado. Conteúdo adaptado e exemplos originais a partir do Scrum Guide de novembro de 2020, de Ken Schwaber e Jeff Sutherland, sob CC BY-SA 4.0. https://creativecommons.org/licenses/by-sa/4.0/
Dois incrementos Done podem ser entregues em momentos diferentes; o benefício é discutido com stakeholders usando evidência.
Armadilhas comuns
Tratar a Review como aprovação de release; alterar o objetivo para caber mais trabalho; confundir o máximo de um mês com quatro semanas fixas.
Tópicos relacionados: Produto, autoridade e colaboração · Objetivos, fatias e previsões
Mantém visíveis o propósito, o estado utilizável e a decisão de adaptação; escolhe técnicas que respeitem a estrutura.
Referência: The Scrum Guide · No official exam required; CSPO learning objectives January 2022 (formatted February 2024); Scrum Guide November 2020