Gestão de escopo e tempo com Scrum

SBOK § 1.1

5.1 Scrum: organizar o escopo em ciclos curtos

Scrum é um framework adaptativo e iterativo que organiza o desenvolvimento de produtos, serviços ou outros resultados em ciclos curtos de trabalho chamados Sprints. Sua aplicação busca produzir valor desde o início e ao longo do projeto, com comunicação transparente e acompanhamento frequente dos resultados.

Nos capítulos anteriores, discutimos como definir requisitos, decompor entregas e organizar atividades no tempo. Aqui, o foco é como essas decisões evoluem quando parte do escopo precisa ser esclarecida durante a execução. A visão do projeto orienta o trabalho; o Product Backlog priorizado reúne as necessidades; e cada Sprint transforma uma seleção dessas necessidades em um incremento potencialmente entregável.

A figura 5.1 apresenta o ciclo de desenvolvimento de um projeto baseado no Scrum.

Elementos do ciclo

Os elementos a seguir oferecem uma visão inicial do ciclo. Seus conceitos e suas relações serão aprofundados na sequência do capítulo, especialmente nas seções sobre justificativa de negócio, planejamento, priorização e desenvolvimento iterativo.

• Justificativa de negócio do projeto (Project Business Case): explicita a necessidade, os benefícios esperados e as razões para investir no projeto. Sustenta a decisão de iniciá-lo e de continuar sua realização.
• Declaração da visão do projeto: apresenta o resultado que se deseja alcançar e orienta as decisões sobre o produto ou serviço a desenvolver.
• Product Backlog priorizado: é a lista ordenada e continuamente atualizada de requisitos e necessidades do produto. Funciona como um registro do trabalho desejado: os itens prioritários são detalhados para orientar as próximas entregas. O Product Owner mantém sua ordem de acordo com o valor esperado, as incertezas e as dependências.
• Planejamento de releases: organiza a previsão de disponibilizações do produto às partes interessadas a partir do backlog, permitindo comunicar quando conjuntos de funcionalidades poderão ser entregues.
• Sprint Backlog: reúne o trabalho selecionado para uma Sprint e as tarefas planejadas para realizá-lo. Representa o recorte do backlog do produto que será desenvolvido naquele ciclo.
• Sprint e criação de entregas: a Sprint é um ciclo de duração definida no qual a equipe transforma os requisitos selecionados em um incremento potencialmente entregável. O movimento circular da figura representa esse trabalho iterativo.
• Reunião diária: encontro breve e frequente para compartilhar o progresso, alinhar o próximo trabalho e identificar impedimentos durante a Sprint.
• Entregas aceitas: resultados demonstrados e verificados pelo Product Owner em relação aos critérios de aceitação definidos. A aceitação confirma o atendimento desses critérios; a disponibilização ao cliente segue o planejamento de releases e as necessidades do projeto.

O Product Owner expressa as prioridades de negócio e mantém o backlog; a equipe Scrum estima e realiza o trabalho; e o Scrum Master facilita o uso do framework e a remoção de impedimentos. Esses papéis são apresentados apenas para compreender o fluxo. Sua dimensão de liderança, colaboração e organização será aprofundada posteriormente.

Ao final da Sprint, a revisão permite demonstrar as entregas e obter feedback. A retrospectiva identifica melhorias no modo de trabalhar. Esse aprendizado orienta o refinamento do Product Backlog e o planejamento dos próximos ciclos, como veremos adiante.

SBOK § 1.2 · seleção de benefícios

5.2 Por que usar Scrum para gerir escopo e tempo?

SBOK § 1.4.2

5.3 Princípios do Scrum: o que orienta escopo e tempo

O SBOK apresenta seis princípios como fundamentos do Scrum. Neste capítulo, quatro recebem destaque por orientar diretamente as decisões sobre o que entregar, em que ordem e dentro de quais intervalos de tempo. Os outros dois permanecem essenciais, mas serão aprofundados quando tratarmos de pessoas.

• Controle empírico do processo: decisões se apoiam em transparência, inspeção e adaptação. Backlog e trabalho realizado tornam-se visíveis; as entregas são verificadas; planos e prioridades são ajustados ao que se aprende.
• Priorização baseada em valor: busca entregar o maior valor de negócio desde as primeiras etapas e continuamente. A ordem do escopo é uma decisão gerencial, e não apenas uma sequência técnica.
• Time-boxing: considera o tempo uma restrição e estabelece limites para Sprints e reuniões. O trabalho selecionado precisa ser compatível com o intervalo disponível.
• Desenvolvimento iterativo: permite administrar mudanças e aproximar progressivamente o produto das necessidades do cliente.
• Auto-organização: favorece responsabilidade compartilhada e o envolvimento da equipe nas decisões de execução.
• Colaboração: trata a criação de valor como um processo compartilhado de interação e trabalho conjunto.

SBOK §§ 1.4.3.2, 1.4.3.4 e 4.3

5.4 Justificativa de negócio, valor e mudanças

Justificativa de negócio: por que realizar e continuar o projeto?

Antes de iniciar um projeto, a organização precisa avaliar adequadamente a necessidade de negócio, as razões para desenvolver uma mudança, produto ou serviço e a viabilidade de prosseguir. No Scrum, a justificativa de negócio se apoia na entrega orientada a valor. Como os resultados são incertos, não é possível garantir o sucesso ao término, independentemente do porte ou da complexidade do projeto.

Por isso, o Scrum procura começar a entregar resultados o mais cedo possível. A realização antecipada de valor pode criar oportunidades de reinvestimento e demonstrar às partes interessadas a contribuição do projeto. Se a justificativa mudar, sua adaptabilidade permite rever objetivos e processos. O Product Owner tem a responsabilidade principal por manter essa justificativa, com contribuição dos demais participantes.

Paralelo com os capítulos anteriores: o TAP, os objetivos e a ligação entre projeto e estratégia ajudam a justificar sua autorização. Aqui, essa relação continua a orientar a seleção do escopo ao longo do trabalho. Um requisito inicialmente importante pode perder prioridade se deixar de contribuir para o resultado de negócio.

Entrega orientada a valor: o princípio em ação

Um projeto é um empreendimento colaborativo destinado a criar novos produtos ou serviços ou a entregar resultados conforme definidos na Declaração da Visão do Projeto. Os projetos geralmente estão sujeitos a restrições de tempo, custo, escopo, qualidade, pessoas e capacidades organizacionais. Em geral, espera-se que os resultados gerados pelos projetos criem alguma forma de valor de negócio ou de serviço.

Como o valor é uma das principais razões para uma organização levar um projeto adiante, a entrega orientada a valor deve ser o foco principal. A entrega de valor está incorporada ao framework Scrum. O Scrum facilita a entrega de valor desde as primeiras etapas do projeto e continua a fazê-lo ao longo de todo o seu ciclo de vida.

Uma das principais características de qualquer projeto é a incerteza quanto aos resultados. É impossível garantir o sucesso de um projeto ao seu término, independentemente de seu porte ou de sua complexidade. Considerando essa incerteza, é importante começar a entregar resultados o mais cedo possível. Essa entrega antecipada de resultados e, consequentemente, de valor oferece uma oportunidade de reinvestimento e demonstra a relevância do projeto às partes interessadas.

Para proporcionar uma entrega orientada a valor, é importante:

1. Compreender o que agrega valor a clientes e usuários e priorizar os requisitos de alto valor, colocando-os no topo do Product Backlog priorizado.
2. Reduzir a incerteza e tratar continuamente os riscos que, caso se concretizem, possam diminuir o valor. Também é necessário trabalhar em estreita colaboração com as partes interessadas do projeto, apresentando-lhes incrementos do produto ao final de cada Sprint e possibilitando uma gestão eficaz das mudanças.
3. Criar entregas com base nas prioridades definidas, produzindo incrementos de produto potencialmente entregáveis durante cada Sprint, para que os clientes comecem a obter valor desde as primeiras etapas do projeto.

O conceito de entrega orientada a valor torna o framework Scrum muito atraente para as partes interessadas do negócio e para a alta administração. Esse conceito é bastante diferente dos modelos tradicionais de gerenciamento de projetos descritos no guia, nos quais:

1. Os requisitos não são priorizados pelo valor de negócio.
2. Alterar os requisitos após a iniciação do projeto é difícil e só pode ser feito por meio de um processo de gestão de mudanças que demanda tempo.
3. O valor é realizado apenas ao final do projeto, quando o produto ou serviço final é entregue.

O contraste apresentado no texto traduz a caracterização dos modelos tradicionais feita pelo guia, sem pressupor que todo projeto preditivo entregue apenas ao final. Como vimos, marcos e entregas parciais também podem existir em abordagens preditivas e híbridas. Em qualquer caso, concluir atividades ou disponibilizar funcionalidades não comprova, por si só, a realização do benefício: é preciso verificar seu uso e sua contribuição para o negócio.

Mudanças: incorporar aprendizado com controle

Todo projeto está sujeito a mudanças, qualquer que seja o método adotado. Os processos do Scrum foram concebidos para acolhê-las, buscando ampliar seus benefícios e reduzir impactos negativos por meio de uma gestão diligente. Duas condições sustentam essa abordagem: as partes interessadas podem mudar de opinião sobre o que desejam e necessitam; e é difícil definir todos os requisitos na iniciação.

Sprints curtas e iterativas incorporam feedback sobre as entregas e permitem que o cliente reveja necessidades à medida que compreende melhor o resultado. Pedidos com impacto sobre programas ou portfólios podem exigir decisões nesses níveis. No âmbito do produto, as novas necessidades são avaliadas e incorporadas à priorização do backlog.

SBOK § 1.4.4 · processos selecionados

5.5 Processos do Scrum

Antes de examinar os processos, precisamos distinguir os elementos que organizam o trabalho. O ponto de partida é o valor para o cliente: o produto deve permitir que alguém alcance um resultado relevante. O detalhamento do escopo torna esse resultado compreensível e viável para o desenvolvimento.

Product Backlog: organizar o produto em torno do valor

Para fins didáticos, podemos compreender o Product Backlog como a decomposição do produto em entregas de valor para o cliente, organizadas por prioridade. A palavra valor é central: a decomposição deve ajudar a reconhecer para quem uma entrega é útil e qual necessidade atende.

Em termos mais precisos, o Scrum Guide (2020) define o Product Backlog como uma lista ordenada e evolutiva do que é necessário para melhorar o produto. Ele é a fonte do trabalho realizado pela equipe. Seus itens são detalhados e divididos continuamente no refinamento; por isso, não se trata de uma decomposição completa e fixa, estabelecida de uma vez no início.

Essa distinção amplia a formulação didática: o backlog pode incluir trabalho que sustenta o valor do produto, além de funcionalidades diretamente percebidas pelo cliente. Por exemplo, corrigir uma falha que impede a inscrição também contribui para o resultado desejado. O Product Owner responde por manter a ordenação e a clareza do backlog.

História de usuário: necessidade, usuário e benefício

A história de usuário é uma estratégia para expressar necessidades representadas nos itens do Product Backlog sob a perspectiva de quem utilizará o produto. Ela relaciona o que se pretende realizar ao benefício esperado. Conforme a Agile Alliance, a história orienta uma contribuição ao valor do produto e seu detalhamento evolui com a proximidade da execução.

Um formato de apoio é: “Como [usuário ou persona], quero [realizar algo], para [alcançar um benefício]”. Ele ajuda a explicitar quem precisa de quê e por quê, mas não substitui a conversa para esclarecer a necessidade. Fonte: Agile Alliance — User Story Template.

A história também precisa de critérios de aceitação que permitam verificar seu atendimento. O modelo dos três Cs articula o registro breve da história (Card), a conversa que esclarece a necessidade (Conversation) e a confirmação dos resultados esperados (Confirmation). Fonte: Agile Alliance — The Three C’s.

Persona: tornar concreto quem utilizará o produto

Uma persona é uma representação fictícia de um perfil de usuário, construída para evidenciar seus objetivos, comportamentos e contexto de uso. É mais específica que uma função como “participante” ou “administrador”: ajuda a compreender o que essa pessoa procura alcançar e quais dificuldades enfrenta. Fonte: Agile Alliance — Personas.

Neste capítulo, cada história será associada a uma persona, como orientação didática para manter o foco nas necessidades do cliente. Essa escolha não deve ser confundida com uma exigência universal do Scrum: personas e histórias são práticas complementares, e o Scrum Guide não exige que todo item do backlog siga esse formato.

Épico: uma necessidade ampla a ser desdobrada

Um épico é uma história de usuário grande demais para ser concluída em uma única iteração ou suficientemente ampla para ser dividida em histórias menores. Ele mantém visível uma necessidade ainda pouco detalhada, até que seu refinamento seja necessário. Essa é a definição adotada pela Agile Alliance — Epic.

Exemplo didático: “Como participante, quero gerenciar minha participação em eventos para organizar minha agenda” pode ser um épico. Conforme o contexto e o tamanho do trabalho, pode ser dividido em histórias sobre inscrição, confirmação e cancelamento. Cada história deve preservar um resultado compreensível para o usuário.

Da história ao trabalho da Sprint

Tarefas descrevem o trabalho necessário para realizar uma história, como implementar uma validação e executar seus testes. O Sprint Backlog reúne o objetivo da Sprint, os itens selecionados e o plano para desenvolvê-los. Assim, épicos e histórias ajudam a expressar necessidades, enquanto as tarefas detalham sua execução. Nem todo item do Product Backlog precisa ser redigido como história.

Os conceitos acima usam referências complementares para esclarecer o vocabulário. A sequência de processos apresentada a seguir mantém a organização do SBOK de 2016 adotada neste capítulo; ela não é uma lista de processos obrigatórios estabelecida pelo Scrum Guide de 2020.

Visão dos processos abordados

A figura 5.4 apresenta os seis processos selecionados e os principais resultados que conectam o Product Backlog ao planejamento da Sprint. O fluxo é uma síntese didática: o detalhamento pode exigir revisões e ajustes das decisões anteriores.

Explicação dos processos

1. Criar o Product Backlog priorizado

Create Prioritized Product Backlog

Os épicos são refinados, elaborados e priorizados para formar o Product Backlog do projeto. Também são estabelecidos os critérios de conclusão (Done Criteria).

Como aplicar: A visão, as necessidades e os épicos orientam a lista ordenada, mantida pelo Product Owner com contribuições da equipe e das partes interessadas. Os itens mais próximos da execução recebem maior clareza; os mais distantes podem permanecer amplos. O backlog é atualizado ao longo do projeto.

Exemplo: Um portal de eventos pode reunir inscrição, confirmação, lista de espera e relatórios. A ordem deve refletir valor e restrições, não apenas a facilidade de implementação.

Relação com o curso: É a ponte com a definição do escopo: torna visível o trabalho desejado e sua prioridade. Não equivale automaticamente à EAP, cuja função é estruturar hierarquicamente a totalidade do escopo.

2. Criar histórias de usuário

Create User Stories

São criadas histórias de usuário e seus critérios de aceitação. Em geral, o Product Owner as redige para representar claramente os requisitos do cliente; exercícios de escrita podem envolver a equipe. As histórias passam a integrar o backlog priorizado.

Como aplicar: Histórias menores tornam discutíveis a necessidade, o benefício e a forma de verificar a entrega. Os critérios específicos de cada história complementam os critérios de conclusão aplicáveis ao trabalho. Uma história descreve uma necessidade do usuário, e não uma lista de tarefas técnicas.

Exemplo: “Como participante, quero me inscrever em um evento para reservar minha vaga.” Critérios: aceitar dados obrigatórios válidos; impedir inscrição acima da lotação; exibir confirmação da inscrição.

Relação com o curso: Retoma requisitos e critérios de aceitação do capítulo de escopo. A fórmula de escrita usada no exemplo é um apoio didático, não uma condição suficiente para que o requisito esteja claro.

3. Aprovar, estimar e assumir compromisso com histórias

Approve, Estimate, and Commit User Stories

O Product Owner aprova histórias para uma Sprint. Na descrição do SBOK, Scrum Master e equipe Scrum estimam o esforço necessário para desenvolver as funcionalidades, e a equipe assume o compromisso de entregar os requisitos selecionados.

Como aplicar: A seleção considera prioridade, entendimento, dependências e capacidade para a Sprint. Uma história grande ou incerta pode precisar ser esclarecida ou dividida antes da seleção. As estimativas apoiam uma decisão viável; não eliminam a incerteza.

Exemplo: A inscrição recebe estimativa relativa maior que o envio de confirmação. Se as duas não couberem no ciclo, negocia-se uma seleção coerente com o objetivo, preservando uma entrega utilizável.

Relação com o curso: Aprovação da história para planejamento não é aceitação da entrega pronta. Estimativa de esforço também não é, por si só, uma data de término. O termo “compromisso” segue a nomenclatura desta edição do SBOK.

4. Criar tarefas

Create Tasks

As histórias aprovadas, estimadas e assumidas são decompostas em tarefas específicas e reunidas em uma lista de tarefas. Uma reunião de planejamento de tarefas pode apoiar esse trabalho.

Como aplicar: A equipe identifica o que precisa realizar para satisfazer os critérios da história, incluindo desenvolvimento, verificações e documentação necessária à entrega. Dependências e impedimentos devem ficar visíveis.

Exemplo: Para a história de inscrição: definir os campos; criar o formulário; implementar a verificação de lotação; testar inscrições válidas e inválidas.

Relação com o curso: Retoma a decomposição do trabalho em atividades. A história explicita o resultado para o usuário; as tarefas descrevem o trabalho para produzi-lo.

5. Estimar tarefas

Estimate Tasks

Nas reuniões de estimativa de tarefas, o núcleo Scrum estima o esforço necessário para cada tarefa da lista. O resultado é uma lista de tarefas com esforço estimado.

Como aplicar: A avaliação usa o conhecimento de quem executará o trabalho e considera disponibilidade e dependências. Se o detalhamento revelar trabalho incompatível com o intervalo disponível, a seleção deve ser revista.

Exemplo: Exemplo didático: formulário, 6 horas de esforço; validação de lotação, 4 horas; testes, 5 horas. As 15 horas de esforço não significam automaticamente 15 horas corridas de duração.

Relação com o curso: Aplica a distinção entre esforço, recursos e duração vista no capítulo de tempo. Estimativas relativas de histórias e horas de tarefas têm finalidades diferentes; não se deve impor uma conversão fixa entre elas.

6. Criar o Sprint Backlog

Create Sprint Backlog

O núcleo Scrum realiza o planejamento da Sprint e cria o Sprint Backlog com as tarefas a concluir naquele ciclo.

Como aplicar: As histórias selecionadas, suas tarefas e estimativas são organizadas em um plano coerente com o objetivo da Sprint. O Product Backlog expressa as necessidades ordenadas do produto; o Sprint Backlog explicita o trabalho planejado para o ciclo atual.

Exemplo: Objetivo: permitir a inscrição em um evento. O Sprint Backlog reúne as histórias escolhidas, suas tarefas e a organização necessária para realizá-las e verificá-las dentro da Sprint.

Relação com o curso: Conecta escopo e tempo: a prioridade orienta o que selecionar, enquanto capacidade, dependências e time-box limitam quanto trabalho pode ser planejado.

O que conecta essa sequência ao restante do ciclo?

O planejamento de releases, ainda na iniciação, organiza uma previsão de disponibilizações e define a duração das Sprints. Depois do planejamento de cada Sprint, a equipe cria as entregas, acompanha o trabalho diariamente e mantém o Product Backlog refinado. Ao final, demonstra e valida o incremento, registra melhorias na retrospectiva e prepara o ciclo seguinte. Esses processos dão continuidade ao planejamento; não são etapas para congelar todo o escopo antes da execução.

SBOK § 2.6

5.6 Priorização baseada em valor

Priorizar significa definir a ordem do trabalho, separando o que precisa ser feito agora do que pode ser feito depois. A priorização já aparece no planejamento de projetos; no Scrum, torna-se um princípio que orienta continuamente a estrutura e o funcionamento do trabalho, buscando entregar valor elevado no menor intervalo de tempo possível.

O Product Owner trabalha com clientes e patrocinadores para compreender o que gera valor e ordenar as histórias por importância relativa. Mesmo quando o cliente classifica tudo como “alta prioridade”, ainda é necessário estabelecer uma ordem dentro desse conjunto. Os processos de criação e refinamento do Product Backlog materializam essa decisão.

A figura 5.5 ilustra quais são os critérios que devem orientar a priorização do backlog do produto na metodologia Scrum.

Valor

Valor é o nível de importância atribuído pelo cliente a um componente do produto representado no backlog. Pode ser definido em uma escala qualitativa ou quantitativa, mas essa avaliação deve permitir distinguir os componentes entre si, de modo a ordená-los para a priorização.

Risco ou incerteza

Antecipando o que discutiremos oportunamente, neste contexto o risco é considerado pelo grau de incerteza quanto à capacidade de desenvolver o componente do produto. Quanto menor o conhecimento sobre a solução, a viabilidade ou as condições de execução, maior pode ser essa incerteza. Essa é uma leitura inicial para a priorização; a avaliação de riscos será aprofundada posteriormente na disciplina.

Dependência

Dependência é a necessidade, ou não, de que outro componente seja entregue previamente para permitir o desenvolvimento ou a utilização do componente considerado. Essa relação condiciona a ordem de execução, mesmo quando um item possui elevado valor para o cliente.

Os três critérios devem ser considerados conjuntamente. A equipe informa as restrições técnicas, as dependências e as incertezas que possam afetar a entrega; o Product Owner articula essas informações com a importância atribuída pelo cliente para ordenar o backlog.

Aplicação ao portal de eventos: a inscrição pode gerar mais valor imediato que um relatório sofisticado. Entretanto, verificar a disponibilidade de vagas pode ser uma dependência indispensável para que a inscrição funcione. Uma integração incerta também pode exigir investigação antecipada. Assim, priorizar por valor não significa ignorar precedências ou escolher sempre a funcionalidade de maior benefício isolado.

SBOK § 2.7

5.7 Time-boxing: planejar a partir de limites de tempo

Tradução integral das seções 2.7 e 2.7.1 do SBOK™ Guide, edição de 2016. As durações e a nomenclatura abaixo são as dessa edição.

O Scrum considera o tempo uma das restrições mais importantes no gerenciamento de um projeto. Para lidar com essa restrição, introduz o conceito de Time-boxing, que propõe fixar uma determinada quantidade de tempo para cada processo e atividade de um projeto Scrum. Isso ajuda a assegurar que os integrantes da equipe não assumam trabalho em excesso ou em quantidade insuficiente para um período específico e não gastem tempo e energia em trabalho sobre o qual tenham pouca clareza.

Algumas das vantagens do Time-boxing são:

• Processo de desenvolvimento eficiente.
• Menor sobrecarga de coordenação.
• Alta velocidade de realização das equipes.

O Time-boxing pode ser utilizado em muitos processos do Scrum. Por exemplo, no processo Realizar a Reunião Diária (Conduct Daily Standup), a duração da reunião possui um limite de tempo definido. Em algumas situações, o Time-boxing pode ser usado para evitar o aperfeiçoamento excessivo de um item, isto é, a inclusão de melhorias além do necessário, conhecida como gold-plating.

O Time-boxing é uma prática fundamental no Scrum e deve ser aplicado com cuidado. Limites de tempo arbitrários podem desmotivar a equipe e criar um ambiente de apreensão; por isso, devem ser utilizados de maneira apropriada.

Time-boxes do Scrum

Sprint

Uma Sprint é uma iteração com duração delimitada de uma a seis semanas, durante a qual o Scrum Master orienta, facilita e protege a equipe Scrum de impedimentos internos e externos no processo Criar Entregas (Create Deliverables). Isso ajuda a evitar desvios da visão que possam afetar o objetivo da Sprint. Nesse período, a equipe trabalha para converter os requisitos do Product Backlog priorizado em funcionalidades de produto que possam ser entregues.

Para obter o máximo de benefícios de um projeto Scrum, o guia recomenda manter a Sprint limitada a quatro semanas, exceto em projetos com requisitos muito estáveis, nos quais as Sprints podem se estender por até seis semanas.

Reunião diária — Daily Standup Meeting

A reunião diária é um encontro breve, realizado todos os dias, com duração limitada a 15 minutos. Os integrantes da equipe se reúnem para informar o progresso do projeto, respondendo às três perguntas a seguir:

1. O que concluí ontem?
2. O que concluirei hoje?
3. Quais impedimentos ou obstáculos, se houver, estou enfrentando neste momento?

Essa reunião é realizada pela equipe como parte do processo Realizar a Reunião Diária (Conduct Daily Standup).

Reunião de planejamento da Sprint — Sprint Planning Meeting

Essa reunião é realizada antes da Sprint, como parte do processo Criar o Sprint Backlog (Create Sprint Backlog). Sua duração é limitada a oito horas para uma Sprint de um mês. A reunião de planejamento da Sprint é dividida em duas partes:

1. Definição do objetivo: durante a primeira metade da reunião, o Product Owner explica à equipe Scrum as histórias de usuário ou os requisitos de maior prioridade do Product Backlog priorizado. A equipe Scrum, em colaboração com o Product Owner, define então o objetivo da Sprint.
2. Estimativa de tarefas: durante a segunda metade da reunião, a equipe Scrum decide como concluir os itens selecionados do Product Backlog priorizado para alcançar o objetivo da Sprint.

Em algumas situações, as reuniões de planejamento de tarefas, realizadas no processo Criar Tarefas (Create Tasks), e as reuniões de estimativa de tarefas, realizadas no processo Estimar Tarefas (Estimate Tasks), também são chamadas de reuniões de planejamento da Sprint.

Reunião de revisão da Sprint — Sprint Review Meeting

A reunião de revisão da Sprint tem duração limitada a quatro horas para uma Sprint de um mês. Durante essa reunião, realizada no processo Demonstrar e Validar a Sprint (Demonstrate and Validate Sprint), a equipe Scrum apresenta ao Product Owner as entregas da Sprint atual. O Product Owner examina o produto, ou o incremento do produto, em relação aos critérios de aceitação acordados e aceita ou rejeita as histórias de usuário concluídas.

Reunião de retrospectiva da Sprint — Retrospect Sprint Meeting

A reunião de retrospectiva da Sprint tem duração limitada a quatro horas para uma Sprint de um mês e é realizada como parte do processo Realizar a Retrospectiva da Sprint (Retrospect Sprint). Nela, a equipe Scrum se reúne para analisar e refletir sobre a Sprint anterior quanto aos processos seguidos, às ferramentas utilizadas, aos mecanismos de colaboração e comunicação e a outros aspectos relevantes para o projeto.

A equipe discute o que funcionou bem na Sprint anterior e o que não funcionou, com o objetivo de aprender e promover melhorias nas Sprints seguintes. Algumas oportunidades de melhoria ou boas práticas identificadas nessa reunião também podem ser incorporadas aos documentos do Órgão de Orientação do Scrum (Scrum Guidance Body).

A figura 5.6 ilustra os limites de duração das Sprints e das reuniões relacionadas ao Scrum.

SBOK § 2.8

5.8 Desenvolvimento iterativo: detalhar, entregar e aprender

O framework Scrum é orientado pelo objetivo de entregar o máximo de valor de negócio no menor intervalo de tempo possível. Para alcançar esse objetivo na prática, adota o desenvolvimento iterativo das entregas.

Na maioria dos projetos complexos, o cliente pode não conseguir definir requisitos muito concretos ou não ter segurança sobre como será o produto final. O modelo iterativo oferece maior flexibilidade para incorporar ao projeto as mudanças solicitadas pelo cliente. Histórias de usuário podem precisar ser escritas continuamente durante o projeto. Em sua formulação inicial, muitas dessas necessidades representam funcionalidades de alto nível, tratadas como épicos. Como os épicos geralmente são grandes demais para serem concluídos em uma única Sprint, são divididos em histórias menores.

Cada aspecto complexo do projeto é detalhado progressivamente durante o refinamento do Product Backlog priorizado. Os processos Criar Histórias de Usuário e Aprovar, Estimar e Assumir Compromisso com Histórias de Usuário ajudam a incorporar e preparar novos requisitos no backlog. Cabe ao Product Owner buscar maior retorno sobre o investimento, concentrando-se no valor e em sua entrega contínua a cada Sprint.

Ao elaborar e ordenar o Product Backlog, o Product Owner precisa compreender a justificativa de negócio do projeto e o valor que ele deve produzir. Assim, decide quais entregas e, consequentemente, quais contribuições de valor serão desenvolvidas em cada Sprint. Em seguida, os processos Criar Tarefas, Estimar Tarefas e Criar o Sprint Backlog produzem o plano utilizado pela equipe para desenvolver as entregas.

Em cada Sprint, o processo Criar Entregas é utilizado para desenvolver os resultados daquele ciclo. O Scrum Master procura assegurar que os processos Scrum sejam seguidos e facilita o trabalho da equipe para que ela atue da maneira mais produtiva possível. A equipe Scrum se organiza para criar as entregas a partir das histórias selecionadas. Em projetos grandes, diferentes equipes multifuncionais podem trabalhar em paralelo, produzindo soluções potencialmente entregáveis ao final de cada Sprint.

Ao final da Sprint, o Product Owner aceita ou rejeita as entregas com base nos critérios de aceitação, no processo Demonstrar e Validar a Sprint. Desse modo, o projeto avança iterativamente e entrega valor ao longo de seu ciclo de vida.

O benefício do desenvolvimento iterativo é permitir correções de rumo à medida que os participantes compreendem melhor o que precisa ser entregue e incorporam esse aprendizado aos ciclos seguintes. Segundo o guia, isso reduz o tempo e o esforço necessários para alcançar o resultado final e favorece entregas mais adequadas ao ambiente de negócio.

A figura 5.7 apresenta a ilustração do desenvolvimento iterativo do produto.

Das prioridades às Sprints

Entendido o backlog do produto e estabelecida sua priorização, podem-se definir as Sprints: seus objetivos e os componentes a desenvolver em cada ciclo. A seleção considera o valor esperado, as dependências, as incertezas, a capacidade da equipe e o limite de tempo disponível.

Cada Sprint está associada a uma entrega incremental cujo valor pode ser avaliado pelo cliente. No início do projeto, todo o valor previsto para a entrega do produto completo ainda está por realizar: essa é a “dívida” de valor representada na figura. À medida que o desenvolvimento produz entregas utilizáveis e o cliente reconhece seus benefícios, essa dívida diminui.

A curva em degraus representa essa redução progressiva. Cada queda corresponde ao valor realizado com uma entrega, enquanto os trechos horizontais representam o intervalo até a entrega seguinte. A figura é conceitual: as Sprints não precisam entregar parcelas iguais de valor. O total previsto também pode ser revisto quando o aprendizado altera o backlog.

Valor percebido mais cedo e possibilidade de revisão

Aqui reside uma importância fundamental do método: como o backlog é priorizado pelo maior valor, respeitando as dependências e as incertezas, o cliente recebe primeiro as entregas mais relevantes. Isso permite que perceba benefícios e alcance satisfação mais cedo do que no modelo em cascata ilustrado pelo guia, no qual a disponibilização do produto se concentra no final. Essa satisfação depende de as entregas atenderem às necessidades e de seu valor ser reconhecido pelo cliente.

Toda entrega no Scrum pode ser revista para uma Sprint seguinte. As setas de feedback sob os ciclos destacam essa possibilidade: a revisão da entrega pode revelar novas necessidades, ajustes ou melhorias, que retornam ao Product Backlog para avaliação, priorização e planejamento. A retrospectiva também identifica melhorias no modo de trabalhar.

Assim, uma entrega aceita pode ser aperfeiçoada posteriormente. A nova necessidade deve ser incorporada ao planejamento das próximas Sprints, preservando a ligação entre aprendizado, prioridade e capacidade de execução.

Fonte: SCRUMstudy. A Guide to the Scrum Body of Knowledge (SBOK™ Guide), 2016, seção 2.8. Tradução com ajustes de terminologia para manter a coerência com os conceitos e processos apresentados neste capítulo. A explicação da “dívida” de valor é uma interpretação didática da figura.