Questão de Engenharia de Software — SCRUM — FCC 2026

Scrum: Refinamento do Product Backlog e Elicitação de Requisitos

Gabarito: letra A. A abordagem mais alinhada às práticas ágeis é promover sessões de Product Backlog Refinement envolvendo o Product Owner, o Development Team e representantes dos usuários (fiscais), utilizando técnicas colaborativas para detalhar as User Stories e definir critérios de aceitação, mantendo o fluxo contínuo da Sprint. Isso porque o Scrum valoriza a colaboração, a inspeção e a adaptação contínuas, e o refinamento é uma atividade contínua que prepara os itens do backlog para a próxima Sprint Planning, sem interromper o trabalho em andamento.

O Product Backlog Refinement (ou Grooming) é uma prática do Scrum que consiste em detalhar e decompor os itens do Product Backlog, adicionando detalhes, estimativas e ordem de prioridade. O objetivo é garantir que os itens estejam "prontos" (Ready) para serem selecionados na próxima Sprint Planning. Essa atividade é contínua e pode ocorrer durante toda a Sprint, conforme necessário. O Guia Scrum (2020) não a define como um evento formal, mas a reconhece como uma prática importante para manter o backlog adequadamente refinado.

A necessidade de refinar as User Stories surge quando elas estão muito genéricas e não refletem as necessidades reais dos usuários. Nesse contexto, a elicitação de requisitos é fundamental. Técnicas como entrevistas, workshops, prototipação e análise de documentos são utilizadas para entender melhor o domínio do problema. No Scrum, essa elicitação deve ser colaborativa, envolvendo o Product Owner (que representa o negócio), o Development Team (que entende a viabilidade técnica) e os stakeholders (que conhecem as necessidades reais).

A alternativa A é a única que combina todos os elementos corretos: envolve as pessoas certas (PO, Time e usuários), utiliza técnicas adequadas (entrevistas colaborativas e análise de documentos), define critérios de aceitação claros e, crucialmente, mantém o fluxo contínuo da Sprint. Isso significa que o refinamento não interrompe o trabalho em andamento, mas ocorre em paralelo, respeitando o princípio de que a Sprint é um ciclo fechado e que mudanças que coloquem em risco a meta da Sprint não devem ser feitas.

As demais alternativas apresentam abordagens que violam os princípios do Scrum: interromper a Sprint para documentação extensa (B), criar relatórios formais e aprovação da alta gestão antes do refinamento (C), realizar brainstorming apenas com o time técnico sem envolver o PO e os usuários (D), e delegar a priorização ao Scrum Master (E). A priorização do Product Backlog é responsabilidade exclusiva do Product Owner, e o Scrum Master não deve priorizar itens.

A pegadinha desta questão está em identificar qual alternativa respeita o fluxo contínuo da Sprint e a colaboração entre os papéis do Scrum. Muitas alternativas parecem razoáveis, mas incluem elementos que violam o framework, como a suspensão da Sprint, a documentação formal extensa ou a inversão de responsabilidades.

Alternativa A — ✅ Correta ⟵ GABARITO

Esta alternativa está correta porque descreve exatamente a prática de Product Backlog Refinement no Scrum. Ela envolve as pessoas certas (Product Owner, Development Team e representantes dos usuários), utiliza técnicas colaborativas de elicitação (entrevistas e análise de documentos), define critérios de aceitação claros e, principalmente, mantém o fluxo contínuo da Sprint. O refinamento é uma atividade contínua que não interrompe o trabalho em andamento, preparando os itens para a próxima Sprint Planning.

Alternativa B — ❌ Incorreta

Esta alternativa está incorreta porque propõe suspender temporariamente as atividades da Sprint atual até a conclusão da documentação completa. Isso viola o princípio do Scrum de que a Sprint é um ciclo fechado e que o trabalho deve fluir continuamente. Além disso, a abordagem de "documentar especificações detalhadas em formato tradicional" é característica de metodologias tradicionais (como o modelo cascata), não de metodologias ágeis. O Scrum valoriza a comunicação face a face e a documentação enxuta, não a documentação extensa e formal.

Alternativa C — ❌ Incorreta

Esta alternativa está incorreta porque propõe documentar os requisitos em relatórios formais e apresentar para aprovação da alta gestão antes de iniciar o refinamento. Isso introduz uma etapa de aprovação formal que não faz parte do Scrum e que pode atrasar o processo. No Scrum, o Product Owner é o responsável por gerenciar o Product Backlog e priorizar os itens, não a alta gestão. Além disso, a documentação formal extensa não é uma prática ágil; o Scrum valoriza a colaboração e a comunicação direta.

Alternativa D — ❌ Incorreta

Esta alternativa está incorreta porque propõe conduzir sessões de brainstorming exclusivamente com o Development Team, sem envolver o Product Owner e os usuários finais. Isso viola o princípio da colaboração no Scrum, que envolve todos os papéis. Além disso, a criação de "documentação de arquitetura detalhada" e a validação por questionários enviados por e-mail são práticas mais tradicionais e menos colaborativas. O Scrum valoriza a comunicação face a face e o feedback rápido, não a validação assíncrona por e-mail.

Alternativa E — ❌ Incorreta

Esta alternativa está incorreta porque propõe solicitar que o Scrum Master priorize os itens antes de incluí-los no Product Backlog. Isso viola uma regra fundamental do Scrum: a priorização do Product Backlog é responsabilidade exclusiva do Product Owner. O Scrum Master é um facilitador e não deve priorizar itens. Além disso, a abordagem de "reuniões individuais sequenciais" e a consolidação em um "documento de requisitos único" são práticas menos colaborativas e mais tradicionais.

Gabarito: letra A