Apostilas em PDF – Sprint Planning

A reunião de planejamento da Sprint visa determinar os itens a serem desenvolvidos durante a iteração, estabelecendo o incremento que será entregue. O Product Owner (PO) é responsável por definir quais itens serão incluídos no desenvolvimento.

Esta reunião possui uma duração máxima de oito horas e é dividida em duas partes.

Parte 1: 

Com duração de até quatro horas, nesta etapa são estabelecidas as funcionalidades que comporão a Sprint. O PO apresenta ao time as histórias de usuário de forma priorizada, destacando inicialmente os itens que agregarão maior valor ao negócio e ao cliente.

Em seguida, o Product Owner e a equipe selecionam os itens do Product Backlog que serão incluídos na Sprint atual, podendo refiná-los conforme necessário durante o processo.

Ao término desta fase, a equipe deve ter uma meta de Sprint claramente definida, especificando os itens a serem desenvolvidos. Esta meta representa o incremento a ser entregue ao usuário final ou cliente.

A pergunta central desta etapa é: “O que faremos?”

Determinando o Conteúdo da Sprint

Para identificar quais itens caberão na Sprint, utiliza-se o conceito de histórias de usuário. Estas são descrições concisas das necessidades do usuário em relação ao produto, sob a perspectiva do próprio usuário. Uma história de usuário representa de forma clara e informal um requisito ou necessidade de um potencial usuário, podendo ser considerada uma parte de um objetivo maior.

Histórias de Usuário

As histórias de usuário consistem em frases simples que delineiam o resultado desejado, sem entrar em detalhes excessivos. Os requisitos adicionais são definidos posteriormente, conforme a equipe chega a um consenso. Uma história de usuário é, portanto, uma descrição de um requisito ou necessidade do usuário, sempre apresentada do ponto de vista deste.

Um formato comum para redigir histórias de usuário é: QUEM, O QUÊ e POR QUÊ.

• QUEM: Identifica o usuário que realizará a ação.
• O QUÊ: Descreve a necessidade a ser atendida.
• POR QUÊ: Explica o benefício esperado com o atendimento deste requisito.

Exemplo:

• Como: Agente de precificação
• Quero: Consultar os preços dos concorrentes
• Para: Comparar os valores que pretendo praticar em minha loja sem precisar visitar cada uma delas.

Pontos de História

Pontos de história são unidades de medida que consideram o esforço necessário para desenvolver uma funcionalidade ou item do backlog. Para estimar este esforço, a equipe de desenvolvimento compara a história em questão com outras já trabalhadas no projeto. Assim, um ponto de história combina a quantidade de esforço envolvido, a complexidade do desenvolvimento e os riscos associados.

Uma técnica comum para realizar essa comparação é o Planning Poker. Nesta dinâmica, os membros da equipe atribuem pontos às histórias de usuário de forma colaborativa, promovendo uma compreensão compartilhada sobre o tamanho e a dificuldade de cada item.

Em resumo, um ponto de história é uma unidade de tamanho que faz sentido para o time Scrum, indicando se a história é considerada grande ou pequena em termos de esforço e complexidade.

Planning Poker

O Planning Poker é uma técnica de estimativa colaborativa amplamente utilizada em metodologias ágeis, especialmente no Scrum. Embora não esteja presente no guia oficial do Scrum, continua sendo uma prática comum devido à sua eficácia em promover consenso entre os membros da equipe sobre o esforço necessário para a implementação de histórias de usuário. Esta técnica combina métodos como opinião de especialistas, analogia e desagregação, tornando o processo de estimativa mais interativo e preciso.

Etapas do Planning Poker:

1. Seleção das Histórias: O Product Owner apresenta uma história de usuário específica que necessita de estimativa por parte da equipe.
2. Distribuição das Cartas de Estimativa: Cada integrante recebe um conjunto de cartas numeradas, geralmente seguindo a sequência de Fibonacci modificada (0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100), representando unidades de esforço ou complexidade.
3. Discussão e Esclarecimento: A equipe debate sobre a história apresentada, esclarecendo dúvidas e garantindo entendimento comum sobre o escopo e os requisitos.
4. Estimativas Individuais: Após a discussão, cada membro seleciona, de forma silenciosa, a carta que representa sua estimativa para a história em questão.
5. Revelação das Estimativas: Todos os integrantes revelam simultaneamente suas cartas. Caso haja divergências significativas, especialmente entre as estimativas mais altas e mais baixas, ocorre uma nova rodada de discussões para alinhar entendimentos e ajustar as estimativas conforme necessário.

Além disso, durante a Reunião de Planejamento da Sprint, que possui duração máxima de oito horas e é dividida em duas partes, a equipe define e planeja as funcionalidades a serem desenvolvidas.

Parte 2: Planejamento da Implementação

• Duração: Até quatro horas.
• Objetivo: A equipe discute como desenvolver as funcionalidades definidas na primeira parte da reunião, decompondo os itens selecionados em tarefas menores e mais gerenciáveis.
• Decomposição do Sprint Backlog: As tarefas são detalhadas de modo que possam ser concluídas em menos de um dia. Essa lista de tarefas constitui o Sprint Backlog. A equipe se auto-organiza para assumir e responsabilizar-se pelo trabalho definido, tanto durante a reunião de planejamento quanto durante a execução da Sprint.
• Participação do Product Owner: O Product Owner pode estar presente nesta fase para esclarecer dúvidas relacionadas ao Product Backlog e auxiliar em possíveis ajustes.
• Participação de Outros Stakeholders: Se necessário, outras pessoas, como usuários-chave, podem ser convidadas para fornecer insights adicionais sobre os itens a serem desenvolvidos.
• Pergunta Central: “Como faremos?”

Diferença entre Product Backlog e Sprint Backlog:

• Product Backlog: É uma lista ordenada de todos os itens, funcionalidades e requisitos conhecidos que precisam ser desenvolvidos para o produto. É mantido e priorizado pelo Product Owner, refletindo as necessidades do negócio e do cliente.
• Sprint Backlog: É um subconjunto do Product Backlog, composto pelos itens selecionados para serem desenvolvidos na Sprint atual. Durante a reunião de planejamento, esses itens são decompostos em tarefas específicas e técnicas, sendo gerenciados pela equipe de desenvolvimento ao longo da Sprint.

PULO DO GATO

Resumão Sprint Planning – planejamento da Sprint

O principal objetivo é planejar a Sprint

É realizada no primeiro dia da Sprint

Duração máxima de 8 horas (para Sprint de 4 semanas)

Participam o time, Product Owner e Scrum Master

Resultado: metas da Sprint e do backlog

Segundo o guia do Scrum:

“O Sprint Planning é limitado a um máximo de oito horas para um Sprint de um mês. Para Sprints mais reduzidos, o evento é normalmente mais curto.”

Lembrando que o PO é responsável por garantir que todos os participantes estejam preparados para discutir os itens do Product Backlog.

Não é vetado convidar terceiros para participar da reunião de planejamento

Algumas questões para fixarmos os conteúdos vistos:

CESPE / CEBRASPE – 2022 – BANRISUL – Analista de Transformação Digital

Tendo como referência o Scrum 2020, julgue o item subsequente, acerca de prática ágil para gerenciamento de projetos.

A sprint planning é uma cerimônia na qual o product owner e os developers selecionam, de forma colaborativa, itens do product backlog a serem incluídos na sprint atual.

COMENTÁRIO

Temos que levar como verdade a ‘opinião’ da banca para respondermos esta questão.

Por meio de discussão com o PO, os Developers selecionam itens do Product Backlog para incluir na Sprint a ser desenvolvida. O Scrum Team pode refinar esses itens durante este processo, o que aumenta a compreensão e a confiança entre todos os envolvidos. Logo, há colaboração na escolha dos itens.

Gabarito está CORRETO.

CEBRASPE (CESPE) – 2024 – Analista de Planejamento, Gestão e Infraestrutura em Propriedade Industrial (INPI)

Julgue o próximo item, relativo a padrão de projetos e Scrum.

De acordo com o Scrum, durante uma sprint planning, para cada item do product backlog selecionado, cabe ao product owner planejar o trabalho necessário para criar um incremento de valor que atenda à forma como isso será feito.

COMENTÁRIO

Product Owner: Estabelece e comunica as prioridades e assegura que o Product Backlog esteja claro e entendido.

Equipe de Desenvolvimento: Planeja como o trabalho será executado, dividindo os itens em tarefas realizáveis durante a Sprint.

Scrum Master: Facilita as reuniões e garante que o Scrum seja compreendido e seguido.

Gabarito está ERRADO.

CEBRASPE (CESPE) – 2015 – Auditor Federal de Controle Externo (TCU)

Conforme a metodologia SCRUM, Sprint Planning Meeting é uma reunião de planejamento em que o Scrum Master prioriza os itens do Product Backlog e a equipe seleciona as atividades a serem implementadas no período.

COMENTÁRIO

Consertando a questão:

“… é uma reunião de planejamento em que o PRODUCT OWNER prioriza os itens do Product Backlog e a equipe seleciona as atividades a serem implementadas no período.

Product Owner (“dono” do produto) representa o cliente e é responsável por garantir que a equipe Scrum agregue valor ao negócio”. Ele é o único responsável pelo backlog do produto e suas devidas priorizações.

Gabarito está ERRADO.

CESPE / CEBRASPE – 2024 – CTI – Tecnologista Júnior – I – Especialidade: Inovação e Gestão de Infraestrutura e P&D

Julgue o seguinte item, acerca de Scrum.

Na sprint planning, para cada item do product backlog selecionado, o product owner planeja o trabalho necessário para criar um incremento que atenda à definição de pronto.

COMENTÁRIO

Ajustando a questão: Para cada item do Product Backlog selecionado, os Developers planejam o trabalho necessário para criar um Incremento que atenda à Definição de Pronto

Gabarito está ERRADO.

CEBRASPE (CESPE) – 2024 – Tecnologista Júnior (CTI)/Inovação e Gestão de Infraestrutura de P&D/Des

Julgue o seguinte item, acerca de Scrum.

Ainda que a meta da sprint se torne obsoleta, ela não pode ser cancelada; nesse caso, a sprint planning pode ser renegociada com o product owner para a adaptação do progresso em direção à meta do produto.

COMENTÁRIO

Seguindo o guia do Scrum:

A Sprint poderá ser cancelada se o objetivo da Sprint se tornar obsoleto. Isto pode ocorrer se a organização mudar sua direção ou se as condições do mercado ou das tecnologias mudarem. Geralmente a Sprint deve ser cancelada se ela não faz mais sentido às dadas circunstâncias. No entanto, devido a curta duração da Sprint, raramente cancelamentos fazem sentido. 

Quando a Sprint é cancelada, qualquer item de Backlog do Produto completado e “Pronto” é revisado. Se uma parte do trabalho estiver potencialmente utilizável, tipicamente o Product Owner o aceita. Todos os itens de Backlog do Produto incompletos são reestimados e colocados de volta no Backlog do Produto. O trabalho feito se deprecia rapidamente e deve ser frequentemente reestimado.

Gabarito está ERRADO.

REFERÊNCIAS BIBLIOGRÁFICAS

BOEHM, B.W., ABTS, C., BROWN, A.W., CHULANI, S., CLARK, B.K., HOROWITZ, E., MADACHY, R., REIFER, D., STEECE, B., 2000, Software Cost Estimation with COCOMO II, Prentice Hall;

PRESSMAN, Roger S. ; Bruce R. Maxim. Engenharia de Software, Uma Abordagem Profissional, 8° ed. Porto Alegre: AMGH, 2016.

SOMMERVILLE, Ian. Engenharia de Software, 9. ed. São Paulo: Pearson Prentice Hall, 2011.

FERNANDES, A. A.;  ABREU, V.F.: Implantando a governança de TI, 4ª Ed.- São Paulo, SP: Editora Brasport Livros e  Multimídia Ltda, 2014.

Guia do Scrum. Disponível em: https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-PortugueseBR.pdf

Webinar sobre Introdução ao Scrum e ao Agile e Treinamento para a Certificação Scrum Fundamentals Certified (SFC™). Disponível em: https://www.certinow.org/pdf/SCRUMstudyScrumPresentation-SFCTraining-portuguese.pdf

https://certiprof.com/pt/pages/scrum-guide-2020 Acesso em Março de 2025

https://www.scrum.org/ Acessado em Março de 2025