03712194005 - Diovan Hegon Kochenborger

Scrum
❏ Década de 90 – Jeff Sutherland & Ken Schwaber – “SCRUM Software
Development Process”
❏ Em 2001, estavam entre os 17 proponentes do Manifesto Ágil
❏ A Scrum Alliance é criada, junto com o programa de certificação Scrum
Master
❏ Hoje, Scrum é método de trabalho adotado por dois em cada três
profissionais em projetos de desenvolvimento de software

03712194005 - Diovan Hegon Kochenborger

 O que é?
❏ Framework ágil, simples e leve, para a gestão do
desenvolvimento de produtos complexos
❏ Iterativo e incremental
• Entrega valor com frequência e reduz os riscos do projeto
❏ Baseado no empirismo
• Experiências práticas

03712194005 - Diovan Hegon Kochenborger

 O que NÃO é?
❏ Não é uma metodologia ou conjunto de processos
• É um Framework – uma estrutura básica que serve de guia
❏ Não é prescritivo
• Não há regras sobre como executar as tarefas
• São prescritos apenas 3 papeis, 3 artefatos e 5 cerimônias
❏ Não é fácil de aplicar, ainda que simples

03712194005 - Diovan Hegon Kochenborger

 Benefícios
❏ Entregas frequentes que dão retorno ao investimento de clientes
❏ Redução de riscos do projeto
❏ Maior qualidade no produto gerado
❏ Mudanças utilizadas como vantagem competitiva
❏ Visibilidade do progresso do projeto
❏ Redução do desperdício e aumento de produtividade

03712194005 - Diovan Hegon Kochenborger

 Aplicabilidade
❏ Scrum é a solução para tudo?
❏ Quando utilizar Scrum?
❏ E quando NÃO utilizar?

❏ Scrum foi criado para o desenvolvimento de projetos

“complexos”

03712194005 - Diovan Hegon Kochenborger

Teoria da Complexidade
Menos ordem Mais ordem

Complexo Complicado
O relacionamento entre causa e efeito só pode O relacionamento entre causa e efeito requer
ser percebido retrospectivamente análise ou alguma outra forma de investigação ou,
ainda, a aplicação de conhecimento especializado,
mas não há muitas mudanças

Investigar – Perceber – Responder Perceber – Analisar – Responder

Desordem

Caótico Simples
Não há relacionamento entre causa e efeito O relacionamento entre causa e efeito é
perceptível óbvio para todos

Agir – Perceber – Responder Perceber – Categorizar – Responder

03712194005 - Diovan Hegon Kochenborger

 Abordagem Tradicional x Scrum
❏ Métodos tradicionais de gestão de projetos os tratam como se fossem simples
ou, no máximo, complicados
❏ Supõe-se que é possível estabelecer uma relação clara entre causa e efeito e
traçar um plano com ações bem definidas
❏ Mas a grande maioria dos projetos de software é de domínio COMPLEXO
❏ Scrum entende que o desenvolvimento de software deve ser realizado de
forma empírica, com base em experiência prática

03712194005 - Diovan Hegon Kochenborger

 Exercícios
(CESPE / CEBRASPE - 2022 - Petrobras - Analista de Sistemas – Processos de negócio)

Transparência, inspeção e adaptação são pilares do Scrum que provêm do controle empírico de
processos

Scrum é uma metodologia ou um conjunto práticas de engenharia de software para criar produtos

03712194005 - Diovan Hegon Kochenborger

 Exercícios
(INSTITUTO AOCP - 2021 - FUNPRESP-JUD - Analista de Tecnologia da Informação -
Desenvolvimento de Sistemas)

A abordagem Scrum é um método ágil geral, mas seu foco está no gerenciamento do desenvolvimento
iterativo, ao invés das abordagens técnicas específicas da engenharia de software ágil. Scrum não
prescreve o uso de práticas de programação, como programação em pares e desenvolvimento test-
first.

03712194005 - Diovan Hegon Kochenborger

03712194005 - Diovan Hegon Kochenborger
O Time Scrum (Papeis)

03712194005 - Diovan Hegon Kochenborger

 Product Owner
❏ Define as funcionalidades do produto
❏ Decide as datas de lançamento e conteúdo
❏ Prioriza as funcionalidades de acordo com o valor para a
empresa
❏ Aceita ou rejeita os resultados dos trabalhos

03712194005 - Diovan Hegon Kochenborger

 Product Owner - Características
Único
❏ O papel de PO deve ser exercido por uma única pessoa
❏ O PO não é um comitê ou departamento da organização
❏ Ele pode trabalhar com vários times, mas cada time pode ter apenas um PO
❏ Substituições eventuais podem acontecer, mas devem ser exceções

03712194005 - Diovan Hegon Kochenborger

 Product Owner - Características
Disponível
❏ O PO deve estar disponível sempre que necessário
❏ Participar de todas as cerimônias cuja sua presença seja necessária
❏ Tirar dúvidas sobre o desenvolvimento do produto a qualquer momento
❏ Interagir com os demais stakeholders para entender as necessidades de
negócio

03712194005 - Diovan Hegon Kochenborger

 Product Owner - Características
Conhecimento de Negócio
❏ O PO deve passar aos Developers todo o conhecimento de
negócio necessário à construção do produto
❏ Cuidado: o PO não é o “Superman”, ele não precisa saber de
tudo, mas é esperado que ele busque as respostas necessárias

03712194005 - Diovan Hegon Kochenborger

 Product Owner - Tarefas
Gerenciar o Produto
❏ É de responsabilidade do PO definir os objetivos do projeto
❏ Ele define as necessidades e as prioriza em uma lista chamada
“Product Backlog”
❏ O PO define a Visão do Produto e o Roadmap do Produto

03712194005 - Diovan Hegon Kochenborger

 Product Owner - Tarefas
Gerenciar as Partes Interessadas
❏ O PO deve identificar corretamente que são os clientes e pessoas
relevantes do projeto
❏ Ele deve entender as diversas necessidades, muitas vezes
conflitantes, e gerenciar as expectativas dos stakeholders

03712194005 - Diovan Hegon Kochenborger

 Product Owner - Tarefas
Gerenciar Releases
❏ Uma Release acontece quando o PO decide disponibilizar o produto aos
usuários finais em seu ambiente-alvo
❏ A decisão de fazer uma Release é influenciada por vários fatores
❏ É de responsabilidade do PO decidir quando e como será feita uma Release

03712194005 - Diovan Hegon Kochenborger

 Product Owner - Tarefas
Planejar Sprints
❏ Junto com o Time de Desenvolvimento, o PO decide que itens farão parte de
uma determinada Sprint
❏ Ele é responsável pode definir uma Meta da Sprint

03712194005 - Diovan Hegon Kochenborger

 Product Owner - Tarefas
Colaborar com o Time de Desenvolvimento
❏ Durante toda a Sprint, o PO soluciona dúvidas do Time de Desenvolvimento
❏ Além disso, ele faz o Refinamento de Backlog

03712194005 - Diovan Hegon Kochenborger

 Product Owner - Tarefas
Aceitar ou rejeitar resultados
❏ Na entrega da Sprint, o PO aceita ou rejeita os resultados gerados pelo Time
de Desenvolvimento
❏ Apenas os itens “prontos” serão aceitos
❏ O PO comunica claramente se a Meta da Sprint foi alcançada ou não

03712194005 - Diovan Hegon Kochenborger

 Exercícios
(INPI – CESPE 2013)
No Scrum, o Product Owner (PO) é responsável por definir a visão do produto e remover os
impedimentos, enquanto o Scrum Master (SM) é responsável por elaborar e manter o
Product Backlog, bem como por ajudar o PO a executar suas atividades diárias.

(Banco da Amazônia – CESPE 2012)

O escopo, a importância e a estimativa de um Sprint do Scrum são definidos pelo product
owner.

(ANAC – CESPE 2012)

O único papel definido pelo Scrum com autoridade para cancelar uma Sprint é o do
product owner.
03712194005 - Diovan Hegon Kochenborger
03712194005 - Diovan Hegon Kochenborger
 Desenvolvedores
❏ Contém tipicamente entre 3 e 9 pessoas
❏ Multifuncional e auto-gerenciados
• Programadores, testadores, desenvolvedores de interfaces, etc.
❏ Orientado à excelência técnica
❏ Focado nas metas estabelecidas pelo PO

03712194005 - Diovan Hegon Kochenborger

 Desenvolvedores - Características
Multidisciplinar
❏ O time possui em seus membros todas as habilidades necessárias
para desenvolver o produto
❏ Não significa que todos têm que saber de tudo – é possível
haver especialistas

03712194005 - Diovan Hegon Kochenborger

 Desenvolvedores - Características
Auto-Organizado (Auto-Gerenciado)
❏ O time planeja e gerencia o seu próprio trabalho
❏ Não há gerentes de projeto dizendo como o time deve trabalhar
❏ Não é anarquia – ainda há regras!
❏ Para que a auto-organização funcione, o time deve se comunicar muito bem
(mais uma razão para mantê-lo pequeno)

03712194005 - Diovan Hegon Kochenborger

 Desenvolvedores - Tarefas
Planejar o Trabalho Técnico
❏ Os Developers são responsáveis por estimar o esforço necessário
para implementar cada item do backlog

03712194005 - Diovan Hegon Kochenborger

 Desenvolvedores - Tarefas
Desenvolver o Produto
❏ O “desenvolvimento” do produto inclui todas as tarefas
necessárias para entregar o incremento do produto
• Programação, testes, documentação, etc.
❏ O objetivo é alcançar a Meta proposta pelo PO
• O que não significa, necessariamente, desenvolver todo os itens da Sprint

03712194005 - Diovan Hegon Kochenborger

 Desenvolvedores - Tarefas
Identificar e Informar Impedimentos
❏ Impedimentos são barreiras ou obstáculos que dificultam
significativamente o trabalho do time
❏ A sua resolução está fora do alcance do time ou lhe tomaria
muito tempo
❏ Atenção: problemas que podem ser resolvidos pelo time em um
tempo razoável NÃO são impedimentos

03712194005 - Diovan Hegon Kochenborger

 Exercícios
(ANVISA - CETRO 2013)
Quanto à metodologia Scrum e no que diz respeito às características das Equipes de
Desenvolvimento, é incorreto afirmar que:

a) não há exceções para a regra de que o único título dos integrantes é o de

Desenvolvedor, independentemente do trabalho que está sendo realizado pela pessoa.
b) são auto-organizadas e nem mesmo o Scrum Master diz à Equipe de Desenvolvimento
como transformar o Backlog do Produto em incrementos de funcionalidades potencialmente
utilizáveis.
c) são multifuncionais, possuindo todas as habilidades necessárias, enquanto equipe, para
criar o incremento do Produto.

03712194005 - Diovan Hegon Kochenborger

 Exercícios
d) Individualmente os integrantes podem ter habilidades especializadas e área de
especialização, mas a responsabilidade pertence à Equipe de Desenvolvimento como um
todo.
e) elas contêm subequipes dedicadas a domínios específicos de conhecimento, tais como
teste ou análise de negócios.

03712194005 - Diovan Hegon Kochenborger

03712194005 - Diovan Hegon Kochenborger
 Scrum Master
❏ Responsável pela aplicação dos valores e práticas Scrum
❏ Remove obstáculos, facilita resultados
❏ Garante a plena funcionalidade e produtividade da equipe
❏ Escudo para interferência externas

03712194005 - Diovan Hegon Kochenborger

Scrum Master - Características
❏ Competente em Soft Skills (habilidades interpessoais)
• Resolve conflitos e promove mudanças necessárias
• Habilidade de negociação e comunicação são essenciais
❏ Neutro
• Deve ser um facilitador o mais neutro possível
• Trabalha para o time como um todo, e não apenas os desenvolvedores
• É possível que seja um dos desenvolvedores, mas não é recomendado
• Nunca deve ser, ao mesmo tempo, o Product Owner
03712194005 - Diovan Hegon Kochenborger
 Scrum Master - Tarefas
❏ Facilitar o trabalho
• Aconselhar, dar autonomia, estimular o time
❏ Remover impedimentos
• Tomar ações rápidas e efetivas para resolvê-los
❏ Promover mudanças organizacionais
• Treinar pessoas, mudar cultura, promover eventos
❏ Garantir o uso do scrum
• Valores e práticas estão sendo seguidos por todos

03712194005 - Diovan Hegon Kochenborger

 Exercícios
(CESPE / CEBRASPE - 2022 - Petrobras - Analista de Sistemas – Processos de negócio)
O scrum master tem a responsabilidade de avaliar, após cada sprint, a necessidade de
mudar algo no rumo do projeto ou reorganizar as prioridades para as próximas sprints.

(TCE/RO – CESPE 2013)

Na metodologia Scrum, a equipe trabalha nos processos e não há cargos na equipe. Como
um dos papéis necessários, o Scrum master deve garantir que o processo seja entendido e
atuar como facilitador para ajudar a equipe

03712194005 - Diovan Hegon Kochenborger

03712194005 - Diovan Hegon Kochenborger
Artefatos e Produtos de
Trabalho

03712194005 - Diovan Hegon Kochenborger

 Artefatos “oficiais” do Scrum
❏ Product Backlog
❏ Sprint Backlog
❏ Definition of Done
❏ Incremento do Produto
❏ Meta da Sprint

03712194005 - Diovan Hegon Kochenborger

 Product Backlog
❏ É uma lista de tudo aquilo que precisa ser feito durante o projeto
❏ Comprometimento: Meta do Produto
❏ Pode conter:
• Necessidades ou objetivos de negócio
• Questões arquiteturais e/ou técnicas
• Melhorias e correções a serem realizadas no produto

03712194005 - Diovan Hegon Kochenborger

 Product Backlog (cont.)
❏ É um artefato “vivo” e sofre constantes modificações
❏ O Product Owner é o único responsável por gerenciá-lo,
podendo:
• Adicionar, remover, atualizar e reordenar itens
• Para isso, ele deve interagir com as demais partes interessadas no projeto
❏ Não há nenhum formato prescrito para o Product Backlog

03712194005 - Diovan Hegon Kochenborger

Product Backlog (formato
típico)

03712194005 - Diovan Hegon Kochenborger

 Product Backlog - Características
❏ Ordenado
• Há algum grau de importância entre os itens
• Necessidade, Risco, Tecnologia, Retorno Financeiro, etc.
❏ Dinâmico
• Constantemente atualizado e gradualmente detalhado
❏ Planejável
• Cada item tem uma estimativa de esforço
03712194005 - Diovan Hegon Kochenborger
 Exercícios
(ANCINE – CESPE 2013)
O backlog do produto é uma lista priorizada cujos itens de maior importância ficam no topo e,
portanto, devem ser mais detalhados.

(BACEN – CESPE 2013)

No SCRUM, o product owner é responsável por alterar o backlog da sprint durante a sprint.

(ABIN – CESPE 2013)

No SCRUM, um backlog consiste em uma lista de itens priorizados a serem desenvolvidos para um
software. Essa lista é mantida no product owner, o qual pode alterá-la a qualquer momento, desde
que os itens alterados não estejam na sprint backlog. Isso significa que product backlog e sprint
backlog são estruturas similares.

03712194005 - Diovan Hegon Kochenborger

03712194005 - Diovan Hegon Kochenborger
 ... Sobre Estimativas
❏ Abordagens tradicionais costumam utilizar estimativas de “alta
precisão”
❏ Na prática, essas estimativas são artificiais e raramente se
concretizam
• Situação conhecida como Lei de Parkinson (a famosa “Síndrome do
Estudante”)
❏ No Scrum, quanto menos detalhes se conhece sobre um item,
menor será a precisão de estimativa sobre ele
03712194005 - Diovan Hegon Kochenborger
 Unidades de Estimativas
❏ Tempo Real
• Dias ou horas reais sobre um item. É a unidade mais tradicional
❏ Tempo Ideal
• Dias ou horas de trabalho sobre um item considerando que nenhuma
interrupção existirá
❏ Story Points
• Unidade relativa de tempo. É a mais utilizada por equipes ágeis

03712194005 - Diovan Hegon Kochenborger

 Story Points
❏ Utiliza uma escala relativa
❏ Entende-se que é mais fácil realizar estimativas fazendo
comparações do que em termos absolutos
❏ Em vez de dizermos que determinada atividade terá “X tempo”,
dizemos que ela tem o “dobro de duração” de outra atividade
ou “metade do tempo”, etc.

03712194005 - Diovan Hegon Kochenborger

 Story Points (cont.)
❏ Em vez de utilizar horas ou dias, o Time utiliza uma escala adotada como
referência
❏ Fibonacci (adaptada por Mike Cohn)
• 1 2 3 5 8 13 20 40 100
❏ T-Shirt Sizing
• PP P M G GG XG
❏ Uma vez selecionada a escala e o ponto de referência, as demais estimativas
podem ser feitas
03712194005 - Diovan Hegon Kochenborger
 Story Points (cont.)
❏ As estimativas sobre os itens de backlog são feitas
exclusivamente pelo Time de Desenvolvimento
❏ Regra de Ouro: “quem estima é quem faz”
❏ O tempo gasto para estimar deve ser aceitável (não pode ser
muito demorado por si só)
• Do contrário teríamos que estimar “o tempo para estimar o tempo”!

03712194005 - Diovan Hegon Kochenborger

 Planning Poker
❏ Técnica mais utilizada por equipes ágeis para estimativa de backlog
❏ Consiste em chegar a um consenso após algumas rodadas de estimativas
❏ O processo é o seguinte:
• Dado um item de backlog, cada membro do time escolha uma carta (estimativa) sem mostrá-
la Todos mostram suas cartas ao mesmo tempo
• Os membros que deram as estimativas mais altas ou baixas discutem suas razões
• Uma ou mais rodadas de estimativas são realizadas até se alcançar um consenso

03712194005 - Diovan Hegon Kochenborger

Planning Poker

03712194005 - Diovan Hegon Kochenborger

 Velocidade do Time
❏ Conhecer a velocidade dos Developers é importante para
planejar os itens de backlog
❏ A velocidade é a taxa média de produção de “pontos ágeis”
por Sprint
❏ Espera-se que a velocidade se mantenha estável, considerando a
mesma equipe e tamanho de Sprint
❏ O valor é considerado uma referência

03712194005 - Diovan Hegon Kochenborger

 Como representar itens de backlog?
❏ Scrum não prescreve uma forma para descrever os itens de
backlog, sendo possível usar diversas formas
❏ A técnica mais comum utilizada por equipes ágeis é a “User
Story” (História de Usuário)
❏ Ela busca descrever uma necessidade de forma simples e leve

03712194005 - Diovan Hegon Kochenborger

 User Story
❏ User Story é uma descrição concisa de uma necessidade do
usuário (ou seja, de um “requisito”)
❏ Utiliza o ponto de vista do usuário
❏ Sua estrutura padrão é QUEM, O QUE POR QUÊ
❏ QUEM – define quem é o usuário
❏ O QUÊ – define qual é a necessidade
❏ POR QUÊ – define o benefício esperado
03712194005 - Diovan Hegon Kochenborger
 User Story (exemplo)
“Como um professor <quem>, eu posso fazer backup do meu HD <o
que> para garantir a integridade dos meus arquivos <por quê>”

“Como um estudante <quem>, eu posso comprar um Passe Estudantil

<o que> para ir à escola <por quê>”

03712194005 - Diovan Hegon Kochenborger

 Exercícios
(MPE/CE – FCC 2013)
O Scrum é um modelo ágil para a gestão de projeto de software. No Scrum,
a) o scrum team é a equipe de desenvolvimento com 6 a 10 pessoas, necessariamente
dividida em papéis como analista, designer e programador.
b) o scrum master é um gerente e um líder como nos modelos prescritivos, já que as
equipes não são autoorganizadas.
c) o product backlog precisa ser completo desde o início do projeto, contemplando todas
as funcionalidades.
d) as funcionalidades a serem implementadas em cada projeto (requisitos ou histórias de
usuário) são mantidas em uma lista chamada de product backlog.
e) o product owner define quais são os requisitos mais importantes a serem tratados em
cada sprint, porém, não é o responsável pelo ROI (Return Of Investment), nem por avaliar
as necessidades dos clientes. 03712194005 - Diovan Hegon Kochenborger
03712194005 - Diovan Hegon Kochenborger
 Sprint Backlog
❏ O Sprint Backlog é uma lista de itens (tarefas) para o
desenvolvimento do Incremento do Produto
❏ Comprometimento: Meta da Sprint
❏ Também envolve um plano sobre como o trabalho será realizado
• Normalmente expresso por uma lista de tarefas
❏ Pertence ao Time de Desenvolvimento, que é responsável pelo
seu uso
03712194005 - Diovan Hegon Kochenborger
 Sprint
Item de Backlog
Backlog

Tarefas
Fonte: [Link]
03712194005 - Diovan Hegon Kochenborger
 Exercícios
(EBC – CESPE 2011)
SCRUM é um framework para gerenciar o desenvolvimento de produtos
complexos. Com relação a essa metodologia, assinale a alternativa correta.
a) O SCRUM Master é o responsável primário pelo gerenciamento do Backlog do
produto.
b) O SCRUM Master é responsável por ordenar (priorizar) os itens do Backlog do
Produto para alcançar
melhor as metas e missões.
c) O Sprint Backlog é uma lista de todas as tare fas que o Time de
Desenvolvimento se com promete a fazer ao longo do desenvolvimento do
produto.
03712194005 - Diovan Hegon Kochenborger
 Exercícios
d) O Sprint Backlog é uma lista contendo todas as funcionalidades
desejadas para o produto, sendo seu conteúdo defnido pelo
SCRUM Master e pelo contratante do projeto.
e) Uma equipe SCRUM é composta por um Product Owner (Dono
do Produto), por um SCRUM Master e pelo Time de
Desenvolvimento.

03712194005 - Diovan Hegon Kochenborger

03712194005 - Diovan Hegon Kochenborger
 Definition of Done (“Pronto”)
❏ A definição de “pronto” é um acordo formal entre PO e Time de Des.
❏ Define quando um trabalho realizado na Sprint realmente está pronto
❏ São critérios acordados de antemão para garantir a transparência
❏ A definição é criada antes do desenvolvimento, mas pode evoluir durante o
projeto

03712194005 - Diovan Hegon Kochenborger

 Incremento do Produto
❏ O Incremento do Produto é o resultado de trabalho de uma
Sprint
❏ Todos os itens entregues devem estar “prontos”
❏ Espera-se que o incremento seja implantável, mas o PO pode
decidir esperar antes de realizar um lançamento (release)

03712194005 - Diovan Hegon Kochenborger

 Meta da Sprint
❏ Uma Meta de Negócio no Scrum não é um valor financeiro ou uma
determinada quantidade de trabalho
❏ Na verdade, é uma necessidade a ser satisfeito por meio de um trabalho
❏ Funcionam como guias ou motivadores, e são definidas pelo Product Owner
juntamente com o Time de Desenvolvimento

03712194005 - Diovan Hegon Kochenborger

 Meta da Sprint (cont.)
❏ Definida no Sprint Planning
❏ Não é numérica ou um conjunto de itens, mas um objetivo de negócio
❏ Não deve mudar durante a Sprint, uma vez que já foi estabelecida
❏ Os Developers não precisam, necessariamente, implementar todos os itens de
uma Sprint – eles precisam alcançar a Meta

03712194005 - Diovan Hegon Kochenborger

 Gráficos de Acompanhamento
(opcional)
❏ Os Gráficos de Acompanhamento são ferramentas para
visualizar o progresso do trabalho
❏ O gráfico mais utilizado por equipes ágeis é o de “Sprint
Burndown Chart” (cuidado: não é parte integrante do Scrum)

03712194005 - Diovan Hegon Kochenborger

Gráficos de Acompanhamento
(opcional)

Fonte: Rafael Sabbagh

03712194005 - Diovan Hegon Kochenborger
 Exercícios
(QUADRIX 2014)
No modelo ágil Scrum, durante o sprint, cabe ao product owner manter o sprint backlog
atualizado, indicando as tarefas já concluídas e aquelas ainda por concluir,
preferencialmente mostradas em um gráfico atualizado diariamente e aí vista de todos. A
cada dia pode-se avaliar o andamento das atividades, contando a quantidade de
atividades por fazer e a quantidade de atividades terminadas, o que vai produzir o
diagrama:

a) sprint schedule
b) sprint burndown
c) daily work.
d) daily burndown.
e) dailyscrum. 03712194005 - Diovan Hegon Kochenborger
03712194005 - Diovan Hegon Kochenborger
Cerimônias (eventos)

03712194005 - Diovan Hegon Kochenborger

 Cerimônias do Scrum
❏ Sprint
❏ Sprint Planning
❏ Daily Scrum
❏ Sprint Review
❏ Sprint Retrospective

03712194005 - Diovan Hegon Kochenborger

 Sprint
❏ É o ciclo de desenvolvimento do Scrum
❏ Ocorrem uma atrás da outra, sem intervalos
• Tudo é trazido para dentro de uma Sprint, no Scrum
❏ Pode ser cancelada apenas pelo PO
❏ São como “miniprojetos”, onde ocorre tudo o que é necessário ser
feito
❏ A duração fixa cria um ritmo regular
03712194005 - Diovan Hegon Kochenborger
 Sprint (resumo)
❏ Objetivo: atingir a meta da Sprint
❏ Quando: durante todo o projeto, de maneira contínua
❏ Duração: fixa, de uma a quatro semanas
❏ Participantes: PO, SM, Developers
❏ Saída: incremento do Produto “pronto”

03712194005 - Diovan Hegon Kochenborger

 Exercícios
(CESPE / CEBRASPE - 2022 - Petrobras - Analista de Sistemas –
Processos de negócio)
O evento timeboxed (sprint), em Scrum, é executado em sala fechada e tem
duração indeterminada.

03712194005 - Diovan Hegon Kochenborger

03712194005 - Diovan Hegon Kochenborger
 Sprint Planning
Ocorrem três perguntas:
❏ “O que pode ser feito nesta Sprint?”
• O PO apresenta os itens mais importantes e responde dúvidas sobre cada
um deles
• O PO propõe a Meta da Sprint e os Developers se comprometem a
alcançá-la

03712194005 - Diovan Hegon Kochenborger

 Sprint Planning (cont.)
❏ “Como o trabalho será feito?”
• Os Developers traçam um “plano” para implementar os itens de backlog
• Itens + Plano = Sprint Backlog (expresso em tarefas)
• Os itens são quebrados em tarefas necessárias para sua implementação
• A participação do PO na segunda etapa não é obrigatória, apesar de
recomendada

03712194005 - Diovan Hegon Kochenborger

 Sprint Planning (cont.)
❏ “Porque o trabalho será feito?”
• Representa a razão de negócio ou benefício a ser atingindo com o
desenvolvimento da sprint que está sendo planejada
• Mantém o foco da equipe no que realmente interessa

03712194005 - Diovan Hegon Kochenborger

 Sprint Planning (resumo)
❏ Objetivo: planejar o ciclo de desenvolvimento que se inicia
❏ Quando: no primeiro dia da Sprint
❏ Duração: máxima, proporcional a 8 horas para uma Sprint de
quatro semanas
❏ Participantes: PO, SM, Developers
❏ Saída: Meta da Sprint e Sprint Backlog

03712194005 - Diovan Hegon Kochenborger

 Exercícios
(CESPE / CEBRASPE - 2022 - Petrobras - Analista de Sistemas –
Processos de negócio)
No Scrum, para cada sprint o time de desenvolvimento realiza uma reunião de
curta duração, na qual se faz necessária a presença do product owner e do
scrum master.

Em ambientes voláteis, o escopo do projeto pode mudar com frequência, o que

leva a adoção de sprints menores; em ambientes estáveis, adota-se sprints
maiores.

03712194005 - Diovan Hegon Kochenborger

03712194005 - Diovan Hegon Kochenborger
 Daily Scrum
❏ É uma reunião curta feita diariamente pelo Time de
Desenvolvimento
❏ Podem ser feitas quaisquer perguntas
❏ O objetivo da Daily Scrum é inspecionar o progresso em direção
à Meta da Sprint e adaptar o Sprint Backlog conforme
necessário, ajustando o próximo trabalho planejado.
❏ A presença do Scrum Master NÃO é obrigatória

03712194005 - Diovan Hegon Kochenborger

 Daily Scrum NÃO é:
❏ O único momento onde são informados impedimentos ao Scrum
Master
• Isso deve acontecer assim que são identificados!
❏ Uma reunião de trabalho
• A Daily Scrum não é o momento para tirar dúvidas técnicas ou de negócio
❏ Uma prestação de contas
• O foco não reside em cobrar tarefas
03712194005 - Diovan Hegon Kochenborger
 Daily Scrum (resumo)
❏ Objetivo: planejar o próximo dia de desenvolvimento
❏ Quando: diariamente, durante a Sprint
❏ Duração: máxima de 15 minutos
❏ Participantes: Developers
❏ Saída: feedback para o próximo dia de trabalho

03712194005 - Diovan Hegon Kochenborger

 Exercícios
(TRE/CE – FCC 2012)
Um dos pontos da metodologia Scrum é o Daily Scrum, que consiste em uma reunião
diária com aproximadamente 15 minutos de duração onde são tratados assuntos
relacionados ao projeto. Nessa reunião são feitas 3 perguntas a cada membro do time de
desenvolvimento, constando o que foi feito desde a última reunião, o que será feito até a
próxima reunião e qual

a) modelo de testes está sendo utilizado pela tarefa atual.

b) o tempo restante para finalização da tarefa.
c) a relação da tarefa atual com o outro membro da equipe.
d) a tarefa que está sendo executada no momento.
e) obstáculo impede o desenvolvedor de prosseguir com a tarefa.
03712194005 - Diovan Hegon Kochenborger
03712194005 - Diovan Hegon Kochenborger
 Sprint Review
❏ A Sprint Review nada mais é do que uma “demo” funcional do produto
❏ A demonstração é informal e funcional (nada de PowerPoint)
❏ É importante alinhar as expectativas com todas as partes interessadas
❏ O PO confirma se cada item do backlog está sendo entregue “Pronto” (Done)

03712194005 - Diovan Hegon Kochenborger

 Sprint Review (resumo)
❏ Objetivo: inspecionar o incremento do produto
❏ Quando: no último dia de cada Sprint
❏ Duração: máxima, de 4 horas proporcional a uma Sprint de quatro semanas
❏ Participantes: PO, SM e Developers
❏ Saída: visibilidade sobre o incremento de produto

03712194005 - Diovan Hegon Kochenborger

03712194005 - Diovan Hegon Kochenborger
 Sprint Retrospective
❏ Buscam melhorar o processo utilizado pela equipe
❏ Ao contrário da reunião post-mortem tradicional, a Retrospectiva permite
melhoria durante o projeto
❏ São inspecionados: comportamentos, práticas, dinâmicas, ferramentas, etc.
❏ NÃO se deve:
• Identificar melhorias no produto (Sprint Review)
• Buscar culpados (realizar acusações)

03712194005 - Diovan Hegon Kochenborger

 Sprint Retrospective (resumo)
❏ Objetivo: melhoria contínua dos processos de trabalho
❏ Quando: no último dia de cada Sprint, após a Sprint Review
❏ Duração: máxima, de 3 horas proporcional a Sprints de quatro semanas
❏ Participantes: PO, SM e Developers
❏ Saída: propostas de melhorias nos processos de trabalho

03712194005 - Diovan Hegon Kochenborger

 Exercícios
(ALEPE – FCC 2014)
O Scrum define reuniões e eventos que devem ser realizados de forma a oferecer
oportunidades formais para inspeção e adaptação, cujos tempos de duração são
referenciais máximos recomendados. Considere:

I. É uma Sprint de um mês, para inspecionar o incremento e adaptar o Backlog do

Produto, se necessário.
II. É uma reunião timeboxed de 3 horas para uma Sprint de um mês, sendo uma
oportunidade para o Time Scrum inspecionar a si próprio e criar um plano para melhorias
a serem aplicadas na próxima Sprint.
III. É um evento timeboxed de 15 minutos, para que a Equipe de Desenvolvimento possa
sincronizar as atividades e criar um plano para as próximas 24 horas.
IV. É um timebox de 8 horas para uma Sprint de um mês de duração.
03712194005 - Diovan Hegon Kochenborger
 Exercícios
(ALEPE – FCC 2014)
Estão de acordo com as definições I, II, III e IV, respectivamente, as denominações:

a) planejamento da Sprint revisão da Sprint daily Scrum retrospectiva da Sprint

b) revisão da Sprint retrospectiva da Sprint daily Scrum planejamento da Sprint
c) revisão da Sprint planejamento da Sprint 15 min break retrospectiva da Sprint
d) retrospectiva da Sprint planejamento da Sprint short meeting revisão da Sprint
e) planejamento da Sprint retrospectiva da Sprint daily Scrum revisão da Sprint

03712194005 - Diovan Hegon Kochenborger

Visão Geral
O que você fez ontem?

O que você fará hoje?

Reuniões Há algum obstáculo no seu caminho?

Diárias
(Daily
Scrums)
Product
24 horas
Backlog Incremento do
Sprint produto
Backlog
2-4 Semanas

03712194005 - Diovan Hegon Kochenborger

OBRIGADO
Prof. Fernando Pedrosa

03712194005 - Diovan Hegon Kochenborger

03712194005 - Diovan Hegon Kochenborger