Scrum — artefatos e compromissos: Backlogs, Metas, Incremento/Definição de Pronto

A ideia que organiza o assunto

O Scrum tem exatamente três artefatos, e eles existem por um motivo só: tornar o trabalho visível. Sem transparência não há o que inspecionar, e sem inspeção não há adaptação — o ciclo empírico inteiro desaba. Por isso os artefatos não são documentos de projeto: são as três formas de olhar para o mesmo trabalho em três horizontes diferentes.

Desde o Guia de 2020, cada um deles carrega um compromisso, e apenas um — a medida que diz quando aquele artefato está bom o bastante:

• o backlog do produto carrega a meta do produto;
• o backlog da sprint carrega a meta da sprint;
• o incremento carrega a definição de pronto.

Guarde os três pares nessa ordem e você resolve a maior parte dos itens do assunto sem precisar de mais nada. A banca raramente inventa um artefato: ela embaralha os pares, troca o dono, ou prende ao artefato errado uma característica verdadeira do vizinho. Antes de julgar qualquer item, responda a três perguntas — de que artefato estamos falando, de quem ele é, e qual compromisso está pendurado nele.

Quem faz o quê em cada evento, e quanto tempo cada evento dura, está na nota de eventos e timeboxes do Scrum; aqui ficam os artefatos e os compromissos.

Por que se usa (e o que custa)

Ganha-se uma fonte única de trabalho. Tudo o que pode ser feito no produto está em uma lista só, ordenada, com um responsável só pela ordem. Isso elimina a fila paralela, o pedido que entra por fora e a discussão sobre o que é mais urgente: a posição na lista já é a resposta. E ganha-se um critério objetivo de qualidade — a definição de pronto transforma “está quase pronto” em uma pergunta de sim ou não.

Paga-se em franqueza. O artefato só funciona se refletir a realidade: backlog maquiado, incremento declarado pronto sem atender à definição e meta de sprint frouxa produzem transparência falsa, que é pior do que nenhuma, porque as decisões seguintes serão tomadas sobre ela. E paga-se em disciplina de escopo: uma definição de pronto rigorosa entrega menos por sprint — de propósito.

Como funciona

Backlog do produto. Lista ordenada e emergente de tudo o que pode ser necessário para melhorar o produto, e a única fonte de trabalho do time Scrum. Ela nunca está completa: muda continuamente conforme o produto e o ambiente evoluem. Quem responde pela ordem é o Product Owner. Os itens costumam ter os atributos descrição, ordem, estimativa e valor, e frequentemente descrições de teste que comprovam a completude quando estiverem prontos. O refinamento é atividade contínua, não um evento: quebra os itens em unidades menores e mais precisas, e por isso o que está no topo é o mais valioso e também o mais detalhado, enquanto o fundo da lista pode permanecer grosseiro.

O compromisso é a meta do produto: o objetivo de longo prazo do time. É uma por vez — o time precisa cumprir ou abandonar um objetivo antes de assumir o próximo.

Backlog da sprint. Tem três componentes, e é útil decorá-los como três perguntas: a meta da sprint (por quê), os itens do backlog do produto selecionados (o quê) e o plano de ação para entregar o incremento (como). É um plano feito pelos Developers e para os Developers, suficientemente detalhado para que o progresso seja inspecionado na daily, e atualizado ao longo de toda a sprint conforme se aprende mais.

O compromisso é a meta da sprint, criada na sprint planning e incorporada ao backlog da sprint. Durante a sprint, nenhuma mudança que coloque a meta em risco é feita, a qualidade não diminui, o backlog do produto é refinado conforme necessário e o escopo pode ser renegociado com o Product Owner. O que está travado é a meta, não a lista.

Incremento. Degrau concreto em direção à meta do produto. É aditivo: cada incremento se soma aos anteriores e todos precisam funcionar juntos, o que exige verificação conjunta. Um trabalho só é incremento quando atende à definição de pronto; se não atender, não pode ser liberado nem apresentado na sprint review e volta ao backlog do produto. Duas regras do Guia de 2020 que parecem heterodoxas e caem justamente por isso: vários incrementos podem ser criados dentro de uma mesma sprint, e um incremento pode ser entregue aos stakeholders antes do fim da sprint.

O que não é artefato. Burndown, burn-up e diagrama de fluxo cumulativo são práticas complementares de projeção: cruzam trabalho restante com tempo e permitem estimar quando o trabalho chega a zero. São úteis e cobrados, mas não substituem a inspeção empírica nem figuram entre os três artefatos. Também não são artefatos as responsabilidades — Product Owner, Scrum Master e Developers são papéis do time Scrum.

A hierarquia do backlog (épico agrupa features, feature agrupa histórias de usuário, história se decompõe em tarefas) é prática de mercado, não texto do Guia, e é cobrada nessa ordem de grandeza.

O que decide os itens

Os três pares — a distinção que decide mais itens que todas as outras juntas:

artefato	compromisso	de quem é	horizonte
backlog do produto	meta do produto	Product Owner (ordem)	vida do produto
backlog da sprint	meta da sprint	Developers	uma sprint
incremento	definição de pronto	time Scrum	o que ficou pronto

Backlog do produto × backlog da sprint — origem, dono e destino:

	backlog do produto	backlog da sprint
quando nasce	antes da primeira sprint	na sprint planning
quem mantém	Product Owner	Developers
do que é feito	itens ordenados por valor	meta + itens selecionados + plano
quando acaba	nunca	com a sprint

Plano × resultado — backlogs planejam o trabalho a fazer; o incremento é o resultado. Artefato descrito como relatório do que foi alcançado, documento entregue ao cliente ou registro formal de aceite está trocado.

Ordenado × priorizado em faixas — o backlog do produto é uma lista ordenada, com uma posição por item. Classificar itens em prioridade alta, média e baixa cria empates e não responde o que entra primeiro na sprint.

Três e três — artefatos são backlog do produto, backlog da sprint e incremento; responsabilidades são Product Owner, Scrum Master e Developers. Lista de pessoas rotulada como artefato (ou o contrário) é item errado.

O quê × como, na planning — o Product Owner responde pelo valor, pela ordem e pelo esclarecimento dos itens; planejar como o trabalho será feito é exclusivo dos Developers, e o Guia diz expressamente que ninguém mais lhes diz como fazer. Este é o par que a banca mais troca.

Enumeração parcial × enumeração fechada — listar dois dos três componentes do backlog da sprint costuma dar item Certo; a mesma lista fechada por unicamente, apenas ou somente dá Errado. O que decide é a palavra de exclusividade, não a contagem.

De quem é o absoluto — “nunca está completo”, “é atualizado constantemente” e “fica a critério exclusivo dos developers” são palavras do próprio Guia e sustentam itens Certos. Absoluto do elaborador é outra coisa: “somente ao fim da sprint”, “unicamente”, “todo item deve”.

Como a CEBRASPE derruba você aqui

Os 26 itens do tópico estão explicados. Sobre os 13 de gabarito Errado: troca de termo 46% (6 itens), atribuição errada 31% (4), generalização 15% (2) e inversão 8% (1). Os outros 13 são Certo — o tópico é exatamente meio a meio.

Duas observações sobre o recorte, antes das famílias. A primeira: atribuição errada em 31% é uma taxa muito acima do normal, e ela diz o que Scrum é como matéria de prova. Aqui quase tudo tem dono — o artefato tem dono, o compromisso tem artefato, a decisão tem papel — e a banca troca o dono em vez de mentir sobre o conceito. A segunda: três dos 26 itens não são Scrum. Um cobra a velocidade do projeto em XP; outro compara o backlog do produto ao termo de abertura do PMBOK; e um terceiro cobra a hierarquia épico → feature → história → tarefa, que é vocabulário corrente de ferramenta e de escala, não do Guia do Scrum. Não se surpreenda com eles.

O rótulo trocado pelo do vizinho — 46%, a família dominante — com a frase em volta intacta. Quatro dos seis itens trocam o rótulo de uma categoria: “Uma equipe scrum é formada pelos seguintes artefatos: um dono do produto, o scrum master e a equipe de desenvolvimento” — são as três responsabilidades; os artefatos são outros três e nenhum é gente. “O backlog do produto é aquele criado durante o planejamento da sprint” — quem nasce na planning é o backlog da sprint; o do produto é anterior à primeira sprint e acompanha toda a vida do produto. “O backlog da sprint […] contém os resultados alcançados durante a sprint” — backlog é plano, olha para o trabalho a fazer; resultado é o incremento. “Os itens do product backlog devem ser classificados como de prioridade alta, média ou baixa” — o backlog é ordenado, uma posição por item, porque faixa de prioridade cria empate e não diz o que entra primeiro na sprint. O quinto troca o evento: “o time Scrum transforma uma seleção do trabalho em um incremento de valor durante uma daily” — a daily são 15 minutos de replanejamento; o contêiner onde o incremento nasce é a sprint. E o sexto inventa vocabulário com aparência técnica: “práticas de estimativa como burndown e burncomplete, em conjunto com gráficos de barra, […] para estabelecer o burndown baseline” — burncomplete não existe, baseline não é marco do Scrum e burndown não se desenha em barras. Defesa: para cada substantivo do item, pergunte de que categoria ele é (artefato, responsabilidade, evento, compromisso, prática) — e, se o nome não está na trinca burndown, burn-up e fluxo cumulativo, desconfie antes de avaliar o resto da frase.

O dono trocado — 31%. Quatro itens, e em todos a metade descritiva está impecável; só o sujeito do verbo mudou. Na planning, “o product owner é o responsável […] por planejar e definir a forma como será executado o trabalho” — o como é atribuição exclusiva dos Developers; o PO responde pelo porquê e pelo quê. Ainda na planning, “o Scrum master determina a prioridade e a ordem dos itens que comporão a próxima sprint” — ordenar o Product Backlog é do Product Owner, e o Scrum Master não decide prioridade nem escopo. Um terceiro cruza os pares artefato-compromisso: “a definição de pronto é considerada o compromisso a ser alcançado pelo sprint backlog” — a definição de pronto é o compromisso do incremento; o do sprint backlog é a meta da sprint. E o quarto empresta ao backlog uma função que não é dele: o Product Backlog apresentado como equivalente ao termo de abertura do PMBOK, “visto que o backlog promove o registro formal e o compromisso com o projeto” — autorizar o projeto e conferir autoridade sobre recursos não é função de backlog nenhum. Defesa: leia só o sujeito do verbo — quem planeja, quem ordena, quem seleciona —, e monte o par artefato-compromisso que o item propõe antes de aceitá-lo. O Scrum Master é o papel que a banca mais usa para roubar atribuição alheia.

A regra fechada com palavra de exclusividade — 15%. Dois itens, e os dois fecham uma porta que o framework mantém aberta. “O sprint backlog é formado unicamente dos itens do product backlog selecionados para a sprint e da meta da sprint”: a enumeração some justamente com o terceiro componente, o plano para entregar o incremento, que é a parte construída pelos Developers — e repare que, sem o “unicamente”, listar dois dos três componentes costuma ser item Certo. “O processo de Scrum declara o produto como pronto somente ao fim de cada ciclo típico de sprint e após a aprovação formal das justificativas do scrum master pelos stakeholders”: quem declara pronto é a definição de pronto, aplicada a cada incremento, e um incremento pode ser entregue antes de a sprint acabar. O Scrum não tem homologação, aceite assinado nem autorização de Scrum Master. Defesa: diante de “unicamente”, “somente” ou “apenas”, conte os componentes oficiais; diante de um portão de aprovação, lembre que ele não existe no Guia.

A hierarquia com dois níveis girados — 8%. Um item só: “os épicos são usados para agrupar cada uma das histórias de usuários, as quais contêm features e tarefas”. O topo está certo e os dois níveis de baixo estão invertidos — a ordem é épico agrupa feature, feature agrupa história, história se decompõe em tarefa. Defesa: em item de granularidade de backlog, escreva os quatro níveis em ordem antes de ler a frase; a banca troca a posição relativa de dois níveis vizinhos.

Erros clássicos

Achar que o backlog do produto nasce no planejamento da sprint. Ele é anterior à primeira sprint e sobrevive a todas elas. O que nasce na planning é o backlog da sprint.

Tratar o backlog da sprint como entrega. Ele é plano de trabalho dos Developers, visível a todos, não relatório de resultados nem documento submetido ao cliente.

Supor um incremento por sprint, sempre ao fim dela. Podem existir vários dentro da mesma sprint, e um deles pode ir para os stakeholders antes de a sprint terminar.

Confundir ordenar com priorizar em faixas. A lista tem uma posição por item; faixas empatam e não decidem o que entra primeiro.

Chamar de artefato quem é papel. Product Owner, Scrum Master e Developers são responsabilidades do time Scrum.

Achar que o backlog do produto fica congelado durante a sprint. O que não pode ser posto em risco é a meta da sprint; refinar o backlog do produto e renegociar escopo com o Product Owner continuam permitidos.