Scrum: conceitos básicos e origem do nome

Aula 04
MP-MG (Analista do Ministério Público -

Área Análise e Programação) Engenharia
de Software - 2022 (Pré-Edital)
Autor:
Diego Carvalho, Equipe
Informática e TI, Fernando
Pedrosa Lopes
10 de Setembro de 2022
81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

Diego Carvalho, Equipe Informática e TI, Fernando Pedrosa Lopes
Aula 04
Índice
1) Metodologias Ágeis - Scrum
..............................................................................................................................................................................................3
2) Metodologias Ágeis - Scrum - Pilares Fundamentais

..............................................................................................................................................................................................
10
3) Metodologias Ágeis - Scrum - Principais Valores

..............................................................................................................................................................................................
13
4) Metodologias Ágeis - Scrum - Papeis

..............................................................................................................................................................................................
15
5) Metodologias Ágeis - Scrum - Artefatos

..............................................................................................................................................................................................
25
6) Metodologias Ágeis - Scrum - Eventos

..............................................................................................................................................................................................
36
7) Metodologias Ágeis - Scrum - Novidades do Scrum

..............................................................................................................................................................................................
53
8) Resumo - Metodologias Ágeis - Scrum

..............................................................................................................................................................................................
57
9) Questões Comentadas - Metodologias Ágeis - Scrum - Multibancas

..............................................................................................................................................................................................
61
10) Lista de Questões - Metodologias Ágeis - Scrum - Multibancas

..............................................................................................................................................................................................
131
2
MP-MG (Analista do Ministério Público - Área Análise e Programação) Engenharia de Software - 2022 (Pré-Edital)
www.estrategiaconcursos.com.br 171

Aula 04
APRESENTAÇÃO
O assunto da aula de hoje é: Scrum! Trata-se do principal framework ágil de gerenciamento de
projetos de quaisquer áreas para construção de produtos complexos. Cai demaaaaaaais em prova,
mas ele tem uma vantagem bem interessante: é baseado em um guia bem pequeno. A imensa
maioria das questões são retiradas desse pequeno guia, então aqui nós vamos apenas orientá-los
sobre os detalhes que o guia não mostra.
PROFESSOR DIEGO CARVALHO - www.instagram.com/professordiegocarvalho
Galera, todos os tópicos da aula possuem Faixas de Incidência, que indicam se o assunto cai
muito ou pouco em prova. Diego, se cai pouco para que colocar em aula? Cair pouco não significa
que não cairá justamente na sua prova! A ideia aqui é: se você está com pouco tempo e precisa ver
somente aquilo que cai mais, você pode filtrar pelas incidências média, alta e altíssima; se você tem
tempo sobrando e quer ver tudo, vejam também as incidências baixas e baixíssimas. Fechado?
INCIDÊNCIA EM PROVA: baixíssima

INCIDÊNCIA EM PROVA: baixa
INCIDÊNCIA EM PROVA: média
INCIDÊNCIA EM PROVA: ALTA
INCIDÊNCIA EM PROVA: Altíssima
Além disso, essas faixas não são por banca – é baseado tanto na quantidade de vezes que caiu em
prova independentemente da banca e também em minhas avaliações sobre cada assunto...
3

Aula 04
4

Aula 04
SCRUM
Conceitos Básicos
INCIDÊNCIA EM PROVA: ALTA
Galera, alguém de vocês sabe de onde vem esse nome? Então, eu vou contar para vocês! Esse nome
vem do Rugby e é utilizado como uma metáfora para refletir o alto grau de cooperação
necessária para obter sucesso no alcance de algum objetivo. Imagino que poucos de vocês
entendam as regras desse esporte, portanto vou explicar de forma bastante rápida e objetiva o
porquê dessa metáfora ser utilizada.
No Rugby, um time pontua sempre que a bola cruza a linha de gol e toca o chão – sendo carregada
ou por meio de passes. Caso o jogador seja derrubado, ele deve soltar a bola, e a jogada se reiniciará!
Além disso, deve haver intensa troca de passes entre os jogadores, de modo a deixá-los menos
vulneráveis a serem derrubados por outros jogadores. Calma que tudo isso que estou dizendo fará
sentido...
Bem... cada jogada se inicia quando um scrum é realizado, isto é, forma-se uma parede de força
entre os jogadores, como pode ser visto nas imagens acima. Observem que os jogadores se reúnem
de forma bastante próxima e coesa, unindo suas forças e habilidades para trabalhar em conjunto
5

Aula 04
e harmonicamente a fim de conseguir recuperar a bola. Percebam, portanto, que o time inteiro
deve trabalhar para que a equipe possa pontuar.
Diferentemente do Futebol Americano, não há um quarterback ou uma estrela no time – todos têm
suas funções e responsabilidades, e são igualmente importantes! Acredito que agora ficou mais
fácil entender de onde vem esse nome. Antes de iniciarmos a teoria, eu gostaria de enfatizar a
importância de ler o guia oficial: ele tem apenas 13 páginas em sua última versão, mas eu inseri na
aula tanto o Guia Scrum Versão 2017 quanto à Versão 2020.
Logo, eu recomendo que vocês o leiam por inteiro, porque ele é a fonte de praticamente tudo que
veremos aqui! Tem versão em português, é gratuito, é enxuto, então não tem desculpas :)
Scrum é um framework leve, simples de entender e extremamente difícil de dominar, para

desenvolver e manter produtos complexos e adaptativos, enquanto entrega produtiva e
criativamente produtos com o mais alto valor possível. Na minha época de concurso, eu decorava
essa definição – sim, eu recomendo decorar algumas definições! Fiquem calmos porque nós vamos
esmiuçar cada parte desse conceito.
[Guia Scrum - Versão 2017]
Scrum é um framework para desenvolver, entregar e manter produtos complexos. Este guia contém a definição do Scrum.
Esta definição consiste em papéis, eventos, artefatos e as regras do Scrum que unem os demais e os mantém integrados.
Ken Schwaber e Jeff Sutherland desenvolveram o Scrum; o Guia do Scrum é escrito e fornecido por eles. Juntos, eles
apoiam o Guia do Scrum.
Scrum: um framework dentro do qual pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto
produtiva e criativamente entregam produtos com o mais alto valor possível. Scrum é: leve, simples de entender e difícil
de dominar.
Scrum é um framework estrutural que está sendo usado para gerenciar o trabalho em produtos complexos desde o início
de 1990. Scrum não é um processo, técnica ou um método definitivo. Em vez disso, é um framework dentro do qual você
pode empregar vários processos ou técnicas. O Scrum deixa claro a eficácia relativa de suas práticas de gerenciamento de
produto e técnicas de trabalho, de modo que você possa continuamente melhorar o produto, o time e o ambiente de
trabalho.
6

Aula 04
O framework Scrum consiste de times Scrum associados a papéis, eventos, artefatos e regras. Cada componente dentro
do framework serve a um propósito específico e é essencial para o uso e sucesso do Scrum. As regras do Scrum integram
os papéis, eventos e artefatos, administrando as relações e interações entre eles. As regras do Scrum são descritas ao
longo deste documento. Estratégias específicas para o uso do framework Scrum variam e são descritas em outros
documentos.
Scrum é um framework leve que ajuda pessoas, times e organizações a gerar valor por meio de soluções adaptativas para
problemas complexos.
Em suma, Scrum requer um Scrum Master para promover um ambiente onde:
1. Um Product Owner ordena o trabalho para um problema complexo em um Product Backlog.

2. O Scrum Team transforma uma seleção do trabalho em um incremento de valor durante uma Sprint.
3. O Scrum Team e seus stakeholders inspecionam os resultados e se ajustam para a próxima Sprint.
==f219==
4. Repita
Em primeiro lugar, percebam que ele é um framework – isso significa dizer que ele agrega
processos, métodos e técnicas. Fundamentalmente, ele possui pressupostos, conceitos, valores e
práticas, mas quem utilizá-lo pode incluir outras novidades. Ele não te dirá tudo o que fazer, logo
você tem a liberdade para fazer o que melhor funcionar dentro das suas necessidades específicas.
Observem que o Scrum é aplicado no gerenciamento do “trabalho” de desenvolvimento dos

produtos, e não exatamente para gerenciar o produto em si. Ele é eficaz nas suas práticas de
gerenciamento de produto e técnicas de trabalho e se foca na melhoria contínua do produto, do
time e do ambiente de trabalho. Ele não é um método definitivo, ou seja, ele pode ser utilizado
em conjunto, ou complementado, por outras práticas, ferramentas e abordagens.
Em segundo lugar, ele é um documento bastante enxuto conforme acabamos de ver! Vocês verão
que, oficialmente e obrigatoriamente, ele é composto por três papeis, quatro eventos, três
artefatos e por um fluxo (chamado Sprint) – veremos em detalhes adiante. Ele pode comportar
outros artefatos, como Gráfico de Burndown, Documento de Visão, etc. No entanto, esses outros
não são obrigatórios – são como “plug-ins” que podem ser adicionados.
O Scrum foi inicialmente desenvolvido para gerenciar e desenvolver produtos. Iniciando no começo dos anos 90, o Scrum
tem sido usado extensivamente, mundialmente, para: 1. Pesquisar e Identificar mercados viáveis, tecnologias e
funcionalidades de produtos; 2. Desenvolver produtos e melhorias; 3. Liberar produtos e melhorias frequentes, chegando
a várias vezes por dia; 4. Desenvolver e sustentar a Nuvem (online, segura, sob demanda) e outros ambientes operacionais
para uso de produtos; e, 5. Sustentar e renovar produtos.
Scrum tem sido usado para desenvolver software, hardware, software embarcado, redes de funções interativas, veículos
autônomos, escolas, governo, marketing, gerenciar a operação da organização e quase tudo que usamos em nosso dia-
dia nas nossas vidas, como indivíduos e sociedades. Como tecnologia, mercado, complexidades ambientais e suas
interações têm aumentado rapidamente, a utilidade do Scrum em lidar com a complexidade é provada diariamente.
7

Aula 04
Scrum demonstra efetividade especialmente na transferência de conhecimento iterativo e incremental. Scrum é agora
amplamente usado para produtos, serviços e no gerenciamento da própria empresa. A essência do Scrum é um pequeno
time de pessoas. O time individual é altamente flexível e adaptativo. Essas forças continuam operando em únicos, muitos,
vários, e em redes de times que desenvolvem, liberam, operam e sustentam o trabalho e trabalham produtos de milhares
de pessoas.
Eles colaboram e interoperam através de arquiteturas sofisticadas de desenvolvimento e ambientes de liberação como
objetivo. Quando as palavras “desenvolver” e “desenvolvimento” são usadas no Guia Scrum, elas se referem a trabalho
complexo, tais como os tipos identificados acima.
Scrum é simples. Experimente como está e determine se sua filosofia, teoria e estrutura ajudam a atingir objetivos e criar
valor. O framework Scrum é propositalmente incompleto, apenas definindo as partes necessárias para implementar a
teoria Scrum. O Scrum é construído sobre a inteligência coletiva das pessoas que o utilizam. Em vez de fornecer às pessoas
instruções detalhadas, as regras do Guia do Scrum orientam seus relacionamentos e interações.
Vários processos, técnicas e métodos podem ser empregados com o framework. Scrum se acopla as práticas existentes ou
as torna desnecessárias. Scrum torna visível a eficácia relativa da gestão atual, meio ambiente e técnicas de trabalho,
para que melhorias possam ser feitas.
O Scrum é um framework para gerenciar projetos, produtos e processos, focado na adaptação em

vez de planejamento, que não utiliza muita documentação e que adota processos mais
simplificados, facilitando a adaptação às mudanças de requisitos e permitindo entregas rápidas e
menores. Ele é usado em ambientes complexos, onde os requisitos e as prioridades mudam
constantemente.
8

Aula 04
Diego, o que seria exatamente um ambiente complexo? Existe uma coisa chamada Modelo Cynefin
que explica bem os tipos de ambientes, dividindo-os em simples, complicados, complexos e
caóticos. O que vocês precisam saber é que um ambiente complexo é aquele que não é muito bem
definido, não é muito acoplado, há muitas mudanças, apresenta muitas formas de realizar um
trabalho.
Vamos ver um exemplo: McDonalds é um ambiente complexo? Não, é um ambiente simples! Ele é
muito bem definido, extremamente acoplado, não tem liberdade e não existem muitas opções
de como realizar um trabalho. Em qualquer lugar do mundo, o cardápio será praticamente o
mesmo; o cara que faz o sanduba realiza os mesmos passos; não há mudanças; não há várias formas
de realizar um trabalho.
O Scrum é um framework em que podem ser empregados vários processos e técnicas. Pode ser
definido como um conjunto de papéis, eventos, artefatos e regras associadas a uma equipe. Ele é
fundamentado em teorias empíricas de controle de processo e emprega uma abordagem
iterativa e incremental (maximizando as oportunidades de feedback) para aperfeiçoar a previsão e
controle de riscos.
9

Aula 04
Pilares Fundamentais
O Scrum se baseia no empirismo e no lean thinking. O empirismo afirma que o conhecimento

vem da experiência e da tomada de decisões com base naquilo que é verdadeiro e conhecido.
Para tal, ele emprega uma abordagem iterativa e incremental para aperfeiçoar e otimizar a
previsibilidade e controle de riscos. Já o Lean Thinking é uma espécie de estrutura mental (mindset)
que permite reduzir o desperdício e se concentrar no essencial.
O Scrum combina quatro eventos formais para inspeção e adaptação, contidos dentro de uma
sprint (que eventualmente é considerada por questões de prova como um tipo de evento). Esses
eventos funcionam porque implementam três pilares fundamentais para controle do processo
empírico: Transparência, Inspeção e Adaptação (é o famoso TIA). Vejamos adiante em mais
detalhes...
TRANSPARÊNCIA INSPEÇÃO ADAPTAÇÃO

1º PILAR
2º PILAR
3º PILAR
Transparência
Esse pilar trata de aspectos significativos (e padronizados) devem estar visíveis aos responsáveis
pelos resultados. Deve haver transparência dentro e fora da equipe, permitindo a qualquer pessoa
compreender o que realmente está ocorrendo, ocasionando melhor comunicação e confiança. Um
dos autores, Ken Schwaber, diz: “Scrum é igual sogra: chega na sua casa e esfrega todos os seus
problemas na sua cara“.
Se uma iteração falhar, todos devem ficar sabendo; se os feedbacks forem ruins, todos devem ficar
sabendo; se o projeto atrasou, todos devem ficar sabendo. O objetivo é encarar as dificuldades de
forma honesta e chegar a um consenso sobre como estes podem ser ultrapassados. Os erros são
inevitáveis e a equipe deve ser incentivada a encarar esta premissa como uma base para aprender
com os erros que são cometidos.
Aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados. A transparência requer que
estes aspectos tenham uma definição padrão comum para que os observadores compartilharem um mesmo
entendimento comum do que está sendo visto. Por exemplo: uma linguagem comum referindo-se ao processo deve ser
compartilhada por todos os participantes; e aqueles que realizam o trabalho e aqueles que inspecionam o incremento
resultado do trabalho devem compartilhar uma definição comum de “Pronto”.
10

Aula 04
O processo emergente e o trabalho devem ser visíveis tanto para quem executa o trabalho quanto para quem recebe o
trabalho. Com o Scrum, decisões importantes são baseadas no estado percebido de seus três artefatos formais. Artefatos
com baixa transparência podem levar a decisões que diminuem o valor e aumentam o risco. A transparência permite a
inspeção. A inspeção sem transparência é enganosa e gera desperdício.
Inspeção
Também chamada de verificação, os usuários devem frequentemente inspecionar os artefatos

produzidos e o progresso para detectar variações indesejáveis (claro, não pode ser extremamente
frequente ao ponto de atrapalhar a execução das tarefas). Uma vez que todos os problemas sejam
transparentes, esse é o momento de inspecionar o processo e o produto em busca de resolver o
problema. ==f219==
Galera, a ideia aqui é identificar rapidamente qualquer desvio em relação à meta que deve ser
atingida. Nós veremos mais à frente que, tanto na Reunião de Revisão quanto na Reunião de
Retrospectiva, os produtos e os processos serão devidamente inspecionados. Essas inspeções em
geral são mais benéficas quando realizadas de forma diligente e cuidadosa por inspetores
especializados no trabalho a se verificar.
Os usuários Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso em direção ao objetivo da Sprint
para detectar variações indesejadas. Esta inspeção não deve ser tão frequente que atrapalhe o objetivo dos trabalhos. As
inspeções são mais benéficas quando realizadas de forma diligente por inspetores especializados no trabalho a se verificar.
Os artefatos do Scrum e o progresso em direção às metas acordadas devem ser inspecionados com frequência e diligência
para detectar variações ou problemas potencialmente indesejáveis. Para ajudar na inspeção, o Scrum fornece cadência
na forma de seus cinco eventos. A inspeção habilita a adaptação. A inspeção sem adaptação é considerada inútil. Os
eventos Scrum são projetados para provocar mudanças.
Adaptação
Se um inspetor determina que um ou mais aspectos de um processo desviou para fora dos
limites aceitáveis, e que o produto resultado será inaceitável, o processo ou o artefato sendo
produzido deve ser ajustado. O ajuste deve ser realizado o mais breve possível para minimizar
mais desvios. Como mudanças sempre ocorrem, é recomendável se adaptar a mudanças em vez de
evitar mudanças.
11

Aula 04
Se um inspetor determina que um ou mais aspectos de um processo desviou para fora dos limites aceitáveis, e que o
resultado do produto será inaceitável, o processo ou o material sendo produzido deve ser ajustado. O ajuste deve ser
realizado o mais breve possível para minimizar mais desvios. O Scrum prescreve quatro Eventos formais para inspeção e
adaptação, como descrito na seção Eventos do Scrum deste documento: Planejamento da Sprint; Reunião diária; Revisão
da Sprint; e Retrospectiva da Sprint.
Se algum aspecto de um processo se desviar fora dos limites aceitáveis ou se o produto resultante for inaceitável, o
processo que está sendo aplicado ou os materiais que estão sendo produzidos devem ser ajustados. O ajuste deve ser feito
o mais rápido possível para minimizar novos desvios. A adaptação se torna mais difícil quando as pessoas envolvidas não
são empoderadas ou auto-gerenciadas. Espera-se que um Scrum Team se adapte no momento em que aprende algo novo
por meio da inspeção.
Vamos resumir os três pilares que sustentam o nosso framework! Tudo no Scrum deve ser
transparente e facilmente acessível. Partindo dessa premissa, podemos inspecionar e identificar
problemas e oportunidades de melhoria do produto e/ou processo – em geral, por meio de eventos
(também chamados de reuniões ou cerimônias). Feito isso, deve-se buscar ajustar e adaptar
produto e/ou processo para minimizar desvios.
Pessoal, lembrem-se que o Scrum é um framework para gerenciar projetos! Em algum momento eu
falei aqui sobre desenvolvimento de software? Não, ele é capaz de gerenciar qualquer projeto que
vise aumentar a agilidade e qualidade da sua execução. Embora tenha sido concebido
inicialmente como uma metodologia de desenvolvimento de software, ele contém elementos que
podem ajudar a formar uma equipe de alto desempenho para qualquer projeto.
O Scrum apenas fornece um framework estruturado para executar alguns princípios. As equipes
de desenvolvimento de software seguem essa metodologia porque seu trabalho é altamente
complexo, interdependente e acelerado. No entanto, se ele funciona para essas equipes,
certamente pode funcionar para outros casos. Se você é um líder de uma equipe que gerencia
projetos complexos, é interessante pensar na aplicação do Scrum!
Dito isso, notem que todos os conceitos que veremos daqui para frente podem ser aplicados a
qualquer projeto, apesar de ter sido concebido para desenvolvimento de software. O primeiro e
talvez principal conceito seja a Sprint! O que é uma Sprint? Trata-se de uma unidade de trabalho
que satisfaz um requisito de negócio. Em outras palavras, é um ciclo completo de
desenvolvimento de um incremento potencialmente entregável de um produto.
PILARES DESCRIÇÃO
Todo trabalho deve ser claramente definido e conhecido por todas as partes
TRANSPARÊNCIA
envolvidas no projeto.
Todo trabalho deve ser inspecionado com a frequência necessária para garantir a
INSPEÇÃO
qualidade do produto.
O projeto deve ser capaz de se adaptar o projeto às necessidades de negócio.
ADAPTAÇÃO
12

Aula 04
Principais Valores
==f219==
O Scrum possui basicamente cinco valores principais: coragem, foco, comprometimento,

respeito e abertura. O sucesso do uso desse framework de gerenciamento de projetos dependerá
intrinsecamente de como os membros se tornam mais familiarizados e proficientes em relação a
cada um desses valores. Vamos falar logo abaixo sobre cada um deles com um pouco mais de
detalhes. Vejamos:
Valores DESCRIÇÃO
Os integrantes de um projeto precisam ter coragem para fazer a coisa certa e
CORAGEM trabalharem juntos removendo impedimentos, buscando soluções.
Os integrantes de um projeto precisam focar no trabalho durante a sprint e nas metas
FOCO
designadas – time disperso perde produtividade e não alcança os objetivos.
Os integrantes se comprometem com o trabalho que se responsabilizou em fazer,
COMPROMETIMENTO envolvendo-se e não abandonando pela metade ou entregando sem qualidade.
Os integrantes se respeitam entre si a fim de manter a colaboração, a integração e o
RESPEITO bom ambiente de trabalho.
Os integrantes devem poder ser francos, expor ideias e propostas mesmo que elas não
ABERTURA
sejam proveitosas. Momentos de debates, discussões e sugestões são ideais.
Quando os valores de comprometimento, coragem, foco, abertura e respeito são incorporados e vividos pelo Time Scrum,
os pilares do Scrum de transparência, inspeção e adaptação tornam-se vivos e constroem a confiança para todos. Os
membros do Time Scrum aprendem e exploram estes valores à medida que trabalham com os eventos, papéis e artefatos
13

Aula 04
do Scrum. O Sucesso no uso do Scrum depende das pessoas se tornarem mais proficientes na vivência destes cinco
valores.
As pessoas se comprometem pessoalmente em alcançar os objetivos do Time Scrum. O Time Scrum precisa ter coragem
para fazer a coisa certa e trabalhar em problemas difíceis. Todos focam no trabalho da Sprint e nos objetivos do Time
Scrum. O Time Scrum e seus Stakeholders concordam em estarem abertos a todo o trabalho e aos desafios com a
execução dos trabalhos. Os membros do Time Scrum respeitam uns aos outros para serem pessoas capazes e
independentes.
O Scrum Team se compromete a atingir seus objetivos e suportar uns aos outros. Seu foco principal é o trabalho da Sprint
para fazer o melhor progresso possível em direção a essas metas. O Scrum Team e seus stakeholders são abertos quanto
ao trabalho e os desafios. Os membros do Scrum Team se respeitam quanto a serem pessoas capazes e independentes, e
são respeitados como tal pelas pessoas com quem trabalham. Os membros do Scrum Team têm a coragem de fazer a
coisa certa e trabalhar em problemas difíceis.
Esses valores orientam o Scrum Team em relação ao seu trabalho, ações e comportamento. As decisões que são tomadas,
os passos dados e a forma como o Scrum é usado devem reforçar esses valores, não diminuí-los ou miná-los. Os membros
do Scrum Team aprendem e exploram os valores à medida que trabalham com os eventos e artefatos do Scrum. Quando
esses valores são incorporados pelo Scrum Team e pelas pessoas com quem trabalham, os pilares empíricos do Scrum de
transparência, inspeção e adaptação ganham vida, construindo confiança.
(TRANSPETRO – 2018) Entre os processos de desenvolvimento de software ágeis mais

usados no Brasil está o SCRUM. Quais são os pilares do SCRUM que apoiam a
implementação de controle de processo empírico?
a) Comprometimento, coragem, foco e respeito

b) Comprometimento, transparência e adaptação
c) Coragem, inspeção e adaptação
d) Transparência, adaptação, foco e respeito
e) Transparência, inspeção e adaptação
_______________________
Comentários: a questão mistura valores (Foco, Abertura, Coragem, Comprometimento e Respeito) com pilares (Transparência,
Inspeção e Adaptação) (Letra E).
14

Aula 04
Papéis
O Scrum possui poucos papeis, mas muito bem definidos! As pessoas que desempenham esses
papeis são igualmente responsáveis e responsabilizadas pelos resultados do trabalho e, assim, se
comprometem com o projeto. Eles são membros de um mesmo time e trabalham juntos, de forma
colaborativa, para alcançarem seus resultados. Os papeis são diferentes dependendo da versão
de referência:
DEVELOPMENT TEAM DEVELOPERS

( EQUIPE DE DESENVOLVIMENTO ) ( DESENVOLVEDORES )
SCRUM TEAM (VERSÃO 2017)

( EQUIPE SCRUM )
( EQUIPE SCRUM )
PRODUCT OWNER PRODUCT OWNER
( DONO DO PRODUTO ) ( DONO DO PRODUTO )
SCRUM MASTER SCRUM MASTER

( MESTRE SCRUM ) ( MESTRE SCRUM )
O Time Scrum consiste em um Product Owner, o Time de Desenvolvimento e um Scrum Master. Times Scrum são auto-
organizáveis e multifuncionais. Times auto-organizáveis escolhem qual a melhor forma para completarem seu trabalho,
em vez de serem dirigidos por outros de fora do Time. Times multifuncionais possuem todas as competências necessárias
para completar o trabalho sem depender de outros que não fazem parte da equipe. O modelo de time no Scrum é projetado
para aperfeiçoar a flexibilidade, criatividade e produtividade.
O Time Scrum demonstra-se estar aumentando sua efetividade para todos os usos anteriormente citados, e qualquer
trabalho complexo. Times Scrum entregam produtos de forma iterativa e incremental, maximizando as oportunidades
para feedback. Entregas incrementais de produto “Pronto” garantem que uma versão potencialmente funcional do
produto do trabalho esteja sempre disponível. O tamanho ideal do Time de Desenvolvimento é pequeno o suficiente para
se manter ágil e grande o suficiente para completar um trabalho significativo dentro da Sprint.
Menos de três integrantes no Time de Desenvolvimento diminuem a interação e resultam em um menor ganho de
produtividade. Times de desenvolvimento menores podem encontrar restrições de habilidades durante a Sprint, gerando
um Time de Desenvolvimento incapaz de entregar um incremento potencialmente liberável. Havendo mais de nove
integrantes é exigida muita coordenação. Times de Desenvolvimento grandes geram muita complexidade para que um
processo empírico seja útil. Os papéis de Product Owner e de Scrum Master não são incluídos nesta contagem, a menos
que eles também executem o trabalho do Backlog da Sprint.
A unidade fundamental do Scrum é um pequeno time de pessoas, um Scrum Team. O Scrum Team consiste em um Scrum
Master, um Product Owner e Developers. Dentro de um Scrum Team, não há sub-times ou hierarquias. É uma unidade
coesa de profissionais focados em um objetivo de cada vez, a Meta do Produto. Os Scrum Teams são multifuncionais, o
15

Aula 04
que significa que os membros possuem todas as habilidades necessárias para criar valor a cada Sprint. Eles também são
autogerenciáveis, o que significa que decidem internamente quem faz o quê, quando e como.
O Scrum Team é pequeno o suficiente para permanecer ágil e grande o suficiente para concluir um trabalho significativo
dentro de uma Sprint, normalmente 10 ou menos pessoas. Em geral, descobrimos que times menores se comunicam
melhor e são mais produtivos. Se os Scrum Teams se tornarem muito grandes, eles devem considerar a reorganização em
vários Scrum Teams coesos, cada um focado no mesmo produto. Portanto, eles devem compartilhar a mesma meta do
produto, Product Backlog e Product Owner.
O Scrum Team é responsável por todas as atividades relacionadas ao produto, desde a colaboração com stakeholder,
verificação, manutenção, operação, experimentação, pesquisa e desenvolvimento, e qualquer outra coisa que possa ser
necessária. Eles são estruturados e empoderados pela organização para gerenciar seu próprio trabalho. Trabalhar em
Sprints em um ritmo sustentável melhora o foco e a consistência do Scrum Team. Todo o Scrum Team é responsável por
criar um Incremento valioso e útil a cada Sprint. Scrum define três responsabilidades específicas dentro do Scrum Team:
os Developers, o Product Owner e o Scrum Master.
==f219==
Na versão 2017, é importante não confundir Development Team com Scrum Team! A Equipe Scrum
que é um time auto-organizável e multifuncional! Ser auto-organizável significa que ela é capaz
de escolher qual a melhor forma para realizar seu próprio trabalho em vez de serem dirigidos por
outros de fora do Time. Ser multifuncional significa que ela possui todas as competências e não
depende de outros de fora da equipe.
Em outras palavras, os times de desenvolvimento não contêm subtimes dedicados a domínios

específicos de conhecimento (Ex: testadores, analistas de negócio, entre outros). A Equipe Scrum
é o responsável por entregar produtos de forma iterativa e incremental, maximizando as
oportunidades de realimentação (feedback). Uma dúvida comum é: professor, pode existir uma
sobreposição nesses papeis, isto é, uma mesma pessoa desempenhando dois papeis diferentes?
Não! Scrum Master e o Product Owner podem fazer parte do Development Team [Versão 2017],
mas um Scrum Master jamais pode ser simultaneamente Product Owner! Essa última afirmação
não está explícita no Guia Scrum, mas é possível inferir que pode haver um conflito de interesses.
Quanto à primeira afirmação: “The Product Owner and Scrum Master roles are not included in this
count unless they are also executing the work of the Sprint Backlog”.
(TJ-PE – 2017) O Scrum está sendo implantado dentro da sua empresa, portanto existe
a necessidade de se criar o Time Scrum que é formado pelo:
a) Product Backlog, o Time de Planejamento e o Scrum Master

b) Product Owner, o Time de Desenvolvimento e o Scrum Sprint
c) Product Backlog, o Time de Planejamento e o Scrum Sprint
d) Product Owner, o Time de Desenvolvimento e o Scrum Master
e) Product Backlog, o Time de Desenvolvimento e o Scrum Sprint
_______________________
Comentários: o Time Scrum é formado pelo Product Owner, Time de Desenvolvimento (Desenvolvedores) e Scrum Master
(Letra D).
16

Aula 04
Product Owner (PO)
O Product Owner é uma pessoa e, não, um comitê. Ele pode representar o desejo de um comitê
no Product Backlog, mas aqueles que quiserem uma alteração nas prioridades dos itens de
backlog devem convencer o Product Owner. Para que ele tenha sucesso, toda a organização deve
respeitar as suas decisões e elas devem ser visíveis no conteúdo e na priorização do Backlog do
Produto. Vejamos a seguir suas responsabilidades e características:
Ele é responsável pela macro-gestão e pela gestão do produto.
Ele é o responsável por maximizar o valor do produto e do trabalho dos desenvolvedores, sendo o único
que pode gerenciar o Product Backlog.
Ele pode até delegar as atividades de gerenciamento para os desenvolvedores, mas ainda será
considerado o responsável pelos trabalhos.
PRODUCT OWNER (PO)
RESPONSABILIDADES
Ele é responsável por priorizar/ordenar os itens do Product Backlog e seleciona aqueles que serão
implementados.
Ele é responsável por garantir o ROI (Returno On Investment ou Retorno sobre Investimento).
Ele é responsável por expressar claramente os itens do Product Backlog.
Ele é responsável por garantir que o Backlog do Produto seja visível, transparente, claro para todos, e
mostrar o que a Equipe Scrum vai trabalhar a seguir.
Ele é responsável por garantir que os desenvolvedores entendam os itens do Product Backlog no nível
necessário.
O Product Owner, ou dono do produto, é o responsável por maximizar o valor do produto resultado do trabalho do Time
de Desenvolvimento. Como isso é feito pode variar amplamente através das organizações, Times Scrum e indivíduos. O
Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto. O gerenciamento do Backlog do Produto
inclui:
• Expressar claramente os itens do Backlog do Produto;

• Ordenar os itens do Backlog do Produto para alcançar melhor as metas e missões;
• Otimizar o valor do trabalho que o Time de Desenvolvimento realiza;
• Garantir que o Backlog do Produto seja visível, transparente, claro para todos, e mostrar o que o Time Scrum vai
trabalhar a seguir; e,
• Garantir que o Time de Desenvolvimento entenda os itens do Backlog do Produto no nível necessário.
O Product Owner pode fazer o trabalho acima, ou delegar para o Time de Desenvolvimento fazê-lo. No entanto, o Product
Owner continua sendo o responsável pelos trabalhos. O Product Owner é uma pessoa e não um comitê. O Product Owner
pode representar o desejo de um comitê no Backlog do Produto, mas aqueles que quiserem uma alteração nas prioridades
dos itens de Backlog devem endereçar ao Product Owner. Para que o Product Owner tenha sucesso, toda a organização
deve respeitar as decisões dele(a). As decisões do Product Owner são visíveis no conteúdo e na priorização do Backlog do
Produto. Ninguém pode forçar o Time de Desenvolvimento a trabalhar em um diferente conjunto de requerimentos.
17

Aula 04
O Product Owner é responsável por maximizar o valor do produto resultante do trabalho do Scrum Team. A forma como
isso é feito pode variar amplamente entre organizações, Scrum Teams e indivíduos. O Product Owner também é
responsável pelo gerenciamento eficaz do Product Backlog , que inclui:
• Desenvolver e comunicar explicitamente a meta do produto;

• Criar e comunicar claramente os itens do Product Backlog;
• Ordenar os itens do Product Backlog; e,
• Garantir que o Product Backlog seja transparente, visível e compreensível.
O Product Owner pode fazer o trabalho acima ou pode delegar a responsabilidade a outros. Independentemente disso, o
Product Owner ainda é o responsável. Para que os Product Owners tenham sucesso, toda a organização deve respeitar
suas decisões. Essas decisões são visíveis no conteúdo e na ordem do Product Backlog e por meio do incremento
inspecionável na revisão da sprint. O Product Owner é uma pessoa, não um comitê. O Product Owner pode representar
as necessidades de muitos stakeholders no Product Backlog. Aqueles que desejam alterar o Product Backlog podem fazê-
lo tentando convencer o Product Owner.
(DETRAN-MT – 2015) No Scrum, há três papéis importantes: Product Owner, Team e

Scrum Master. É responsabilidade do Product Owner:
a) Determinar como serão a gestão e a organização dos times.

b) Desenvolver funcionalidades do projeto.
c) Assegurar que a funcionalidade mais valiosa será produzida primeiro.
d) Ensinar Scrum a todos os envolvidos no projeto.
_______________________
Comentários: (a) Errado, essa não é uma responsabilidade do Product Owner; (b) Errado, essa é uma responsabilidade dos
desenvolvedores; (c) Correto, ele é responsável por priorizar as funcionalidades no Product Backlog; (d) Errado, essa é uma
responsabilidade do Scrum Master (Letra C).
(UFRJ – 2018) No framework Scrum, o papel que tem como uma das responsabilidades,
maximizar o valor do produto e do trabalho do Time de Desenvolvimento, além de ser a
pessoa responsável por gerenciar o Backlog do Produto é denominado:
a) Product Owner.
b) Scrum Master.
c) Scrum Team.
d) Stakeholder.
e) Development Team.
_______________________
Comentários: o papel responsável por maximizar o valor do produto e do trabalho do time de desenvolvimento
(desenvolvedores), além de ser a pessoa responsável por gerenciar o Backlog do Produto é o Product Owner (Letra A).
18

Aula 04
Developers (DV)
Os Desenvolvedores consistem em profissionais que realizam o trabalho de entregar uma

versão usável que potencialmente incrementa o produto “pronto” ao final de cada sprint.
Somente Desenvolvedores criam incrementos. Ninguém tem permissão para falar com os eles
sobre diferentes configurações de prioridade e os eles não têm permissão para agir sobre o que
outras pessoas disserem.
Os Desenvolvedores só respondem ao Product Owner. Além disso, só ele pode cancelar uma
sprint. Ele deve ser pequeno o suficiente de forma a se manter ágil e produtivo, e grande o
suficiente de forma que a coordenação dos membros não cause problemas. A versão anterior do
guia recomendava que a equipe tivesse entre 3 e 9 integrantes (excluídos o Product Owner e Scrum
Master – exceto se eles também executarem o trabalho da sprint).
No Guia Scrum 2020, houve uma alteração de nomes. O termo ‘Time de Desenvolvimento’ passava
a impressão de que existia um sub-time no Time Scrum. Esse termo foi substituído por uma nova
responsabilidade: Desenvolvedores. Isso reforça a ideia de existir apenas um único time: o Time
Scrum – que é formado pelo Scrum Master, o Product Owner e os Desenvolvedores, sendo que seus
objetivos devem ser os mesmos.
A ideia por trás dessa mudança não é apenas semântica: ao remover o conceito de sub-time dentro
da equipe e deixar claro que todas essas pessoas pertencem ao mesmo time, o Time Scrum, isso
cria um compromisso mais forte entre todos para a entrega da Meta da Sprint. O Time Scrum é,
portanto, apenas uma equipe com três responsabilidades diferentes e objetivos idênticos. Fechado?
A versão anterior dizia que o Time de Desenvolvimento deveria idealmente ser composto por 3 a 9
integrantes. Com o objetivo de se tornar ainda menos prescritivo, agora não há tamanho mínimo
ou máximo para os desenvolvedores. No entanto, o Scrum Guide comenta que o Scrum Team
normalmente tem 10 ou menos integrantes – incluindo na conta o Scrum Master e o Product
Owner. Não mudou muita coisa da versão anterior, mas deixou mais aberto...
Responsável pela micro-gestão e pela criação do produto.

CARACTERÍSTICAS: desenvolvedores
Eles são auto-organizados. Ninguém (nem mesmo o SM) diz aos desenvolvedores como transformar o
RESPONSABILIDADES E
Product Backlog em incrementos de funcionalidades potencialmente utilizáveis.

Times de Desenvolvimento são multifuncionais, possuindo todas as habilidades necessárias, enquanto
equipe, para criar o incremento do Produto.
O Scrum não reconhece títulos específicos para os desenvolvedores, independentemente do trabalho que
está sendo realizado pela pessoa;
Individualmente, os desenvolvedores podem ter habilidades especializadas, mas a responsabilidade
pertence aos desenvolvedores como um todo.
Os desenvolvedores não contêm sub-times dedicados a domínios específicos de conhecimento, tais como
teste ou análise de negócios.
19

Aula 04
Os desenvolvedores são estruturados e autorizados pela organização para organizar e gerenciar seu
próprio trabalho.
O Time de Desenvolvimento consiste de profissionais que realizam o trabalho de entregar um incremento potencialmente
liberável do produto “Pronto” ao final de cada Sprint. Um incremento “Pronto” é requerido na Revisão da Sprint. Somente
integrantes do Time de Desenvolvimento criam incrementos. Os Times de Desenvolvimento são estruturados e
autorizados pela organização para organizar e gerenciar seu próprio trabalho. A sinergia resultante aperfeiçoa a eficiência
e a eficácia do Time de Desenvolvimento como um todo.
Developers são as pessoas do Scrum Team que estão comprometidas em criar qualquer aspecto de um Incremento
utilizável a cada Sprint. As habilidades específicas necessárias pelos Developers geralmente são amplas e variam de
acordo com o domínio de trabalho. No entanto, os Developers são sempre responsáveis por: criar um plano para a Sprint,
o Sprint Backlog; introduzir gradualmente qualidade aderindo a uma Definição de Pronto; adaptar seu plano a cada dia
em direção à meta da Sprint; e responsabilizar-se mutuamente como profissionais.
(Banco da Amazônia – 2018) No SCRUM, o Backlog da Sprint é “um conjunto de itens

do Backlog do Produto selecionados para Sprint, juntamente com o plano para entregar
o incremento do produto e atingir o objetivo da Sprint”
(Schwaber e Sutherland, 2017).
Durante a Sprint, quem pode alterar o Backlog da Sprint?
a) Product Owner, apenas

b) Scrum Master, apenas
c) Time de Desenvolvimento, apenas
d) Time de Desenvolvimento e o Product Owner, apenas
e) Time de Desenvolvimento e o Scrum Master, apenas
_______________________
Comentários: durante a sprint, apenas o Time de Desenvolvimento (Desenvolvedores) pode alterar o Sprint Backlog (Letra C).
(TRE-MT – 2015) Em um projeto ágil em que se utiliza Scrum, a criação e a estimação de

tarefas cabe ao:
a) gerente de projeto.
b) product owner.
c) time de desenvolvimento.
d) Scrum master.
e) time de desenvolvimento, ao Scrum master e ao product owner, em conjunto.
_______________________
Comentários: a criação e a estimação de tarefas cabem ao Time de Desenvolvimento ou Desenvolvedores (Letra C).
20

Aula 04
Scrum Master (SM)
O Scrum Master é responsável por garantir que o Scrum seja entendido e aplicado! Ele faz isso
para garantir que a Equipe Scrum adira à teoria, práticas e regras do Scrum. O Scrum Master é um
servo-líder para a Equipe Scrum. Ele ajuda aqueles que estão fora da a Equipe Scrum a entender
quais as suas interações com a Equipe Scrum são úteis e quais não são. Ademais, ele ajuda todos a
mudarem estas interações para maximizar o valor criado pela Equipe Scrum.
Responsável pela gestão de pessoas e gestão do processo.
Ele deve garantir que o Scrum seja entendido e aplicado. O Scrum Master faz isso para garantir que a
Equipe Scrum adere à teoria, práticas e regras do Scrum.
O Scrum Master ajuda aqueles que estão fora da Equipe Scrum a entender quais as suas interações com
a Equipe Scrum são úteis e quais não são.
O Scrum Master ajuda todos a mudarem estas interações para maximizar o valor criado pela Equipe
Scrum.
Ele é responsável por orientar o Product Owner na criação e ordenação do Product Backlog.
Ele é responsável por garantir que as regras do Scrum estejam sendo cumpridas e seus valores estejam
scrum master (sm)
RESPONSABILIDADES
sendo seguidos.
Ele é responsável por ajudar a remover impedimentos que o time enfrente, fazendo isso sem o uso de
qualquer autoridade.
Ele utiliza técnicas de facilitação e coaching para que os membros do time consigam visualizar os
problemas e encontrem a melhor solução.
Durante eventos, ele é responsável por fazer com que a reunião flua adequadamente, utilizando técnicas
de facilitação, embora não seja o responsável pela condução.
Ele ajuda a treinar os desenvolvedores em autogerenciamento e interdisciplinaridade.
Ele treina os desenvolvedores em ambientes organizacionais nos quais o Scrum não é totalmente
adotado e compreendido.
Ele ensina a Equipe Scrum a criar itens do Product Backlog de forma clara e concisa.
Ele comunica claramente a visão, objetivo e itens do Product Backlog para os desenvolvedores.
O Scrum Master é responsável por promover e suportar o Scrum como definido no Guia Scrum. O Scrum Master faz isso
ajudando todos a entenderem a teoria, as práticas, as regras e os valores do Scrum. O Scrum Master é um servo-líder para
o Time Scrum. O Scrum Master ajuda aqueles que estão fora do Time Scrum a entender quais as suas interações com o
Time Scrum são úteis e quais não são. O Scrum Master ajuda todos a mudarem estas interações para maximizar o valor
criado pelo Time Scrum.
O Scrum Master trabalhando para o Product Owner
O Scrum Master serve o Product Owner de várias maneiras, incluindo:
21

Aula 04
• Garantindo que objetivos, escopo e domínio do produto sejam entendidos o melhor possível por todos do Time Scrum.
• Encontrando técnicas para o gerenciamento efetivo do Backlog do Produto;
• Ajudando o Time Scrum a entender as necessidades para ter itens de Backlog do Produto claros e concisos.
• Compreendendo o planejamento do Produto em um ambiente empírico;
• Garantindo que o Product Owner saiba como organizar o Backlog do Produto para maximizar valor;
• Compreender e praticar a agilidade; e,
• Facilitar os eventos Scrum conforme exigidos ou necessários.
O Scrum Master trabalhando para o Time de Desenvolvimento
O Scrum Master serve o Time de Desenvolvimento de várias maneiras, incluindo:
• Treinando o Time de Desenvolvimento em autogerenciamento e interdisciplinaridade;

• Ajudando o Time de Desenvolvimento na criação de produtos de alto valor;
• Removendo impedimentos para o progresso do Time de Desenvolvimento;
• Facilitando os eventos Scrum conforme exigidos ou necessários; e,
• Treinando o Time de Desenvolvimento em ambientes organizacionais nos quais o Scrum não é totalmente adotado e
compreendido.
O Scrum Master trabalhando para a Organização
O Scrum Master serve a Organização de várias maneiras, incluindo:
• Liderando e treinando a organização na adoção do Scrum;

• Planejando implementações Scrum dentro da organização;
• Ajudando funcionários e partes interessadas a compreender e tornar aplicável o Scrum e o desenvolvimento de produto
empírico;
• Causando mudanças que aumentam a produtividade do Time Scrum; e,
• Trabalhando com outros Scrum Masters para aumentar a eficácia da aplicação do Scrum na organização.
O Scrum Master é responsável por estabelecer o Scrum conforme definido no Guia do Scrum. Eles fazem isso ajudando
todos a entender a teoria e a prática do Scrum, tanto no Scrum Team quanto na organização. O Scrum Master é
responsável pela eficácia do Scrum Team. Eles fazem isso permitindo que o Scrum Team melhore suas práticas, dentro
do framework Scrum Scrum Masters são verdadeiros líderes que servem ao Scrum Team e à organização como um todo.
O Scrum Master serve ao Scrum Team de várias maneiras, incluindo:
• Treinar os membros do time em autogerenciamento e cross-funcionalidade;

• Ajudar o Scrum Team a se concentrar na criação de incrementos de alto valor que atendem à Definição de Pronto;
• Provocando a remoção de impedimentos ao progresso do Scrum Team; e,
• Garantir que todos os eventos Scrum ocorram e sejam positivos, produtivos e mantidos dentro do Timebox.
O Scrum Master serve o Product Owner de várias maneiras, incluindo:
• Ajudar a encontrar técnicas para a definição eficaz de meta do Produto e gerenciamento do Product Backlog;
• Ajudar o Scrum Team a entender a necessidade de itens do Product Backlog claros e concisos;
• Ajudar a estabelecer o planejamento empírico do produto para um ambiente complexo; e,
• Facilitar a colaboração dos stakeholder, conforme solicitado ou necessário.
22

Aula 04
O Scrum Master serve a organização de várias maneiras, incluindo:
• Liderar, treinar e orientar a organização na adoção do Scrum;

• Planejar e aconselhar implementações de Scrum dentro da organização;
• Ajudar os funcionários e os stakeholders a compreender e aplicar uma abordagem empírica para trabalhos complexos;
e,
• Remover barreiras entre stakeholders e Scrum Teams.
Galera, eu só consigo explicar por metáfora, então vamos tentar entender esses papeis! Imaginem
que João deseja construir uma casa. Para tal, ele contrata uma renomada empresa de engenharia.
A empresa irá fornecer todo seu know-how por meio de uma Equipe de Construção de Casas, que
será composta por uma Equipe de Pedreiros, um Mestre de Obras e... por você! Sim, você fará
parte da Equipe de Construção de Casas como principal parte interessada.
Vamos dar um nome para você? Você ocupará o cargo de Dono da Casa. Portanto, a Equipe de
Construção de Casas será composta por uma Equipe de Pedreiros, pelo Mestre de Obras e pelo
Dono da Casa. E como será a organização e a função de cada um desses papeis? Bem, a Equipe de
Pedreiros é composta por 3 a 9 pedreiros multidisciplinares, isto é, todos dominam todas as
atividades de um pedreiro.
Galera, esses caras são os responsáveis por colocar a mão na massa, levantar parede, fazer o
concreto, alinhar o piso, entre outras atividades. Já o Mestre de Obras é o grande facilitador! Como
assim, professor? Ele é o cara que vai retirar os impedimentos que aparecem no decorrer do
nosso projeto. Um pedreiro faltou? Ficou doente? Se machucou? Ele irá buscar uma maneira de
reduzir os impactos dessa ausência.
Os pedreiros estão desmotivados, distraídos, descuidados? Ele irá arrumar uma maneira de solucionar
isso. Um pedreiro saiu na porrada com outro? Ele vai tentar intermediar o conflito. Além disso, ele
que vai trazer a demanda do Dono da Casa, entender o que ele quer e passar de maneira
simples, clara e objetiva para a Equipe de Pedreiros. Ele é o cara que mais deve conhecer os
fundamentos da construção de uma casa!
Imaginem ele como um grande estudioso da construção de casas com bastante experiência
adquirida em anos de empreendimentos. Ele saca tudo sobre como se faz para se construir uma
casa, qual é o papel de cada um, qual é a melhor ordem, quais são as melhores técnicas e é um
grande professor, capaz de ensinar a todos os outros integrantes quais são os melhores princípios
para a construção de casas. Em outras palavras, ele é um grande mestre!
Por fim, ele também é capaz de treinar a equipe de construção para que ela seja auto-gerenciável e
interdisciplinar. Legal, mas está faltando um papel nessa história. E qual é? É o seu papel! Qual a sua
função? Você é o Dono da Casa! Logo, você que gerencia o que será feito e o que não será feito,
sendo também o responsável pelo que será entregue. A Equipe de Pedreiros responde a você!
Até o Mestre de Obras responde somente a você! Viu a sua importância?
23

Aula 04
Você é o cara que tem que tentar fazer essa casa ficar da melhor forma possível – com máximo valor
agregado. Você é o cara que vai priorizar o que deve ser feito primeiro; você é o cara que coloca
ou tira tarefas da lista tarefas a serem realizadas; você é o único cara que pode cancelar
determinada tarefa; você é o cara que fiz expressamente o que deve ser feito; enfim... você ocupa
um papel importantíssimo para o sucesso do projeto de construir uma casa.
Galera, toda metáfora possui suas limitações, mas acho que vocês conseguiram captar a mensagem
aqui! A Equipe de Construção de Casas é o Scrum Team; a Equipe de Pedreiros é o Development
Team; o Mestre de Obras é o Scrum Master; e o Dono da Casa é o Product Owner. Além disso, cada
um desses tem atividades bem definidas e o controle sobre essas atividades é descentralizado.
Entendido? Seeeeeegue o jogo...
(TRE-RS – 2015) No desenvolvimento ágil de sistemas utilizando o Scrum, um integrante

da equipe é encarregado de comunicar a visão, os objetivos e os itens do product backlog
para o time de desenvolvimento, além de encontrar técnicas para o gerenciamento
efetivo do product backlog. Esse integrante é o:
a) Product Owner, sob orientação do Scrum Master.

b) próprio time de desenvolvimento, que realiza essas definições de forma auto-
organizada.
c) Scrum Master.
d) Team Leader.
e) Product Owner, diretamente.
_______________________
Comentários: o integrante encarregado de comunicar a visão, os objetivos e os itens do Product Backlog para o time de
desenvolvimento, além de encontrar técnicas para o gerenciamento efetivo do Product Backlog é o Scrum Master (Letra C).
(EPTC – 2012) No Scrum, existem papéis bem definidos. Assinalar a alternativa a qual o
trecho abaixo se refere:
Tem como função primária remover impedimentos para que a equipe consiga entregar o
objetivo do Sprint. Além dessa função, a pessoa nesse papel tem a função de assegurar que
as práticas do Scrum sejam utilizadas corretamente.
a) Scrum Product Owner.

b) Scrum Master.
c) Scrum Manager.
d) Scrum Project Manager.
_______________________
Comentários: esse é o papel do Scrum Master (Letra B).
24

Aula 04
Artefatos
Segundo o Guia do Scrum, o framework possui apenas três artefatos oficiais: Product Backlog,
Sprint Backlog e Product Increment. Um artefato é o produto de um trabalho...
Os artefatos do Scrum representam o trabalho ou o valor para o fornecimento de transparência e oportunidades para
inspeção e adaptação. Os artefatos definidos para o Scrum são especificamente projetados para maximizar a
transparência das informações chave de modo que todos tenham o mesmo entendimento dos artefatos
Os artefatos do Scrum representam trabalho ou valor. Eles são projetados para maximizar a transparência das principais
informações. Assim, todos os que os inspecionam têm a mesma base para adaptação. Cada artefato contém um
compromisso para garantir que ele forneça informações que aumentem a transparência e o foco contra o qual o progresso
pode ser medido:
• Para o Product Backlog, é a Meta do produto.

• Para o Sprint Backlog, é a Meta da Sprint.
• Para o incremento, é a Definição de Pronto.
Esses compromissos existem para reforçar o empirismo e os valores Scrum para o Scrum
Team, e seus stakeholders.
Product Backlog
Trata-se de uma lista ordenada (por valor, risco, prioridade, entre outros) de requisitos
PRODUCT BACKLOG ou funcionalidades que o produto deve conter criada pela Equipe Scrum e gerenciada
pelo Product Owner.
Antes de tudo, o que é um backlog? Galera, um backlog é basicamente uma lista, um resumo
histórico, de acumulação de trabalho num determinado período de tempo, pode ser uma pilha de
pedidos que devem ser produzidos. Já o Product Backlog é uma lista ordenada (por valor, risco,
prioridade, entre outros) de requisitos ou funcionalidades que o produto deve conter1 criada
pela Equipe Scrum.
O Product Backlog é a origem única dos requisitos para qualquer mudança a ser feita no produto.
Costuma-se dizer que ele é um artefato dinâmico que nunca estará completo e existirá
enquanto o produto também existir. Por que? Porque sempre haverá novos requisitos, novas
1
Apesar de o Scrum Team (PO, SM, DV) ser o responsável pela criação do Product Backlog, o responsável pelo artefato e o único que pode priorizar
suas funcionalidades é o Product Owner.
25

Aula 04
necessidades e mudanças a serem incorporadas. Logo, trata-se de um artefato vivo – sempre em

movimento.
O Product Backlog evolui tanto quanto o produto e o ambiente no qual ele será utilizado
evoluem. Ele muda constantemente para identificar o que o produto necessita para ser mais
apropriado, competitivo e útil para as partes interessadas. Lembrando que somente o Product
Owner pode inserir, remover ou reordenar esses itens, incluindo seu conteúdo, disponibilidade e
ordenação.
Rafael Prikladnicki afirma que o formato mais utilizado para os itens são Histórias de Usuário (User
Stories) ordenadas de acordo com o critério escolhido pelo Product Owner. O que são histórias de
usuário? É basicamente uma especificação de uma ou mais frases na linguagem de negócio ou
cotidiana do usuário do sistema que captura o que um usuário faz ou necessita fazer como parte
de sua função de trabalho.
Enfim... em geral, itens mais importantes ficam no topo do Product Backlog e são
implementados primeiro. Na maioria das vezes, esses são os itens sobre os quais há maior
conhecimento, logo são mais detalhados e refinados. Itens que precisem de maior refinamento
geralmente têm uma importância menor e ficam mais abaixo. Não existe, no entanto, uma forma
única para materializar esse artefato e descrever seus itens.
Além das Histórias de Usuário, podem ser utilizadas descrições textuais de funcionalidades,
cenários de casos de uso, etc. Galera, o Product Backlog pode apresentar itens funcionais, não-
funcionais, arquiteturais ou de infraestrutura – além de itens que representem riscos a serem
removidos. É claro que, durante o andamento do projeto, algumas funcionalidades podem acabar
perdendo a importância – não importando sob que circunstâncias isso ocorreu.
Isso é totalmente normal na maioria dos projetos, uma

vez que é impossível saber, desde o início, os detalhes
de tudo o que queremos no produto. Assim, algumas
funcionalidades podem acabar até mesmo
desaparecendo. Da mesma forma, novas
funcionalidades também podem ser adicionadas de
acordo com a necessidade. Ao lado, temos um exemplo
de Product Backlog. É nele onde eu vou armazenar todas
as necessidades que eu desejo no meu projeto, entre
outras coisas. No exemplo acima, deseja-se poder tanto
tuitar quanto remover um tuite – são duas histórias de
usuário diferentes que eu desejo que sejam
implementadas na minha aplicação. Legal, mas quando
eu sei quando um desses itens pode realmente ser
considerado pronto (também chamado ready)?
26

Aula 04
Para que um item possa ser incluído em uma sprint, ele deve ser pequeno o suficiente para que caiba
em uma única sprint e deve deixar tudo claro e transparente quanto à expectativa do Product Owner
(geralmente através de um critério de aceite). Mas até que ponto estes requisitos precisam ser
detalhados? Eles devem ser detalhados até atender ao conceito de Definition of Ready (DoR). O
que é isso, Diego?
Isso significa que o requisito tem informações suficientes para começar a ser desenvolvido
imediatamente. Esta definição é bastante específica de cada organização – não há um padrão. Vou
dar um exemplo para melhor entendimento... eu já trabalhei em um projeto em que as histórias de
usuário eram entregues aos desenvolvedores de forma muito pobres, pouco refinadas e
demasiadamente confusas.
O Product Owner estava rejeitando a conclusão das sprints, declarando que não havia sido feito
o que ele havia pedido. Os desenvolvedores reclamavam que a especificação era péssima e que
nem o próprio Product Owner sabia o que queria. A partir daí, modificamos nosso processo! A
equipe combinou critérios explícitos e visíveis do que uma história de usuário deveria conter para
ser aceita para entrar em uma sprint. Como diz o ditado, combinado não sai caro!
Dessa forma, uma vez que todos haviam concordado, as brigas reduziram bastante. Por que?
Porque eles nos disseram exatamente (por meio de um checklist) o que a história de usuário
deveria conter para que elas pudessem ser aceitas para entrar no Product Backlog e serem de
fato implementadas pelos desenvolvedores. A partir daí, essa definição de “pronto” nos ajudou a
mitigar falhas de comunicação.
O Backlog do Produto é uma lista ordenada de tudo que é conhecido ser necessário no produto. É a única origem dos
requisitos para qualquer mudança a ser feita no produto. O Product Owner é responsável pelo Backlog do Produto,
incluindo seu conteúdo, disponibilidade e ordenação. Um Backlog do Produto nunca está completo. Os primeiros
desenvolvimentos estabelecem os requisitos inicialmente conhecidos e melhor entendidos. O Backlog do Produto evolui
tanto quanto o produto e o ambiente no qual ele será utilizado evoluem.
O Backlog do Produto é dinâmico; mudando constantemente para identificar o que o produto necessita para ser mais
apropriado, competitivo e útil. Se um produto existe, seu Backlog do Produto também existe. O Backlog do Produto lista
todas as características, funções, requisitos, melhorias e correções que formam as mudanças que devem ser feitas no
produto nas futuras versões. Os itens do Backlog do Produto possuem os atributos de descrição, ordem, estimativa e
valor. Os itens do Backlog geralmente incluem descrições de testes que comprovarão sua completude quando “Prontos”.
Enquanto um produto é usado e ganha valor, e o mercado fornece feedback, o Backlog do Produto torna-se uma lista
maior e mais completa. Requisitos nunca param de mudar, então o Backlog do Produto é um artefato vivo. Mudanças nos
requisitos de negócio, condições de mercado ou tecnologia podem causar mudanças no Backlog do Produto. Múltiplos
Times Scrum frequentemente trabalham juntos no mesmo produto. Um Backlog do Produto é usado para descrever o
trabalho previsto para o produto. Um atributo do Backlog do Produto que agrupe itens pode ser então aplicado.
O refinamento do Backlog do Produto é a ação de adicionar detalhes, estimativas e ordem aos itens no Backlog do
Produto. Este é um processo contínuo no qual o Product Owner e o Time de Desenvolvimento colaboram nos detalhes dos
itens do Backlog do Produto. Durante o refinamento do Backlog do Produto, os itens são inspecionados e revisados. O
27

Aula 04
Time de Scrum decide como e quando o refinamento está “Pronto”. Este refinamento usualmente não consome mais de
10% da capacidade do Time de Desenvolvimento.
Contudo, os itens do Backlog do Produto podem ser atualizados a qualquer momento pelo Product Owner ou a critério do
Product Owner. Os itens do Backlog do Produto de ordem mais alta (topo da lista) devem ser mais claros e mais
detalhados que os itens de ordem mais baixa. Estimativas mais precisas são feitas baseadas em maior clareza e maior
detalhamento; Quanto menor a ordem na lista, menos detalhes. Os itens do Backlog do Produto que irão ocupar o Time
de Desenvolvimento na próxima Sprint são mais refinados, de modo que todos os itens possam ser “Prontos” dentro do
time-boxed da Sprint.
Os itens do Backlog do Produto que podem ser “Prontos” pelo Time de Desenvolvimento dentro de uma Sprint são
considerados “Preparados” para seleção no Planejamento da Sprint. Itens do Backlog do Produto geralmente adquirem
este grau de transparência através das atividades de refinamento descritas acima. O Time de Desenvolvimento é
responsável por todas as estimativas. O Product Owner deve influenciar o Time de Desenvolvimento, ajudando no
entendimento e nas decisões conflituosas de troca, mas as pessoas que irão realizar o trabalho fazem a estimativa final.
Monitorando o Progresso a Caminho dos Objetivos
Em qualquer ponto do tempo, o total do trabalho restante para alcançar o objetivo pode ser somado. O Product Owner
acompanha o total do trabalho restante pelo menos a cada Revisão da Sprint. O Product Owner compara este valor com
o trabalho restante nas Revisões das Sprints anteriores, para avaliar o progresso na direção de completar o trabalho
previsto pelo tempo desejado para alcançar o objetivo.
Esta informação deve ser transparente para todas as partes interessadas. Várias práticas para prever tendências foram
usadas para prever o progresso, tais como burndowns, burn-ups, ou fluxos cumulativos. Estas têm se provado úteis.
Contudo, não substituem a importância do empirismo. Em ambientes complexos, o que acontecerá é desconhecido.
Somente o que já acorreu pode ser usado para uma tomada de decisão a respeito do que virá.
O Product Backlog é uma lista ordenada e emergente do que é necessário para melhorar o produto. É a única fonte de
trabalho realizado pelo Scrum Team. Os itens do Product Backlog que podem ser realizados pelo Scrum Team em uma
Sprint são considerados preparados para seleção no evento Sprint Planning. Eles geralmente adquirem esse grau de
transparência após as atividades de refinamento. O Product Backlog refinement é o ato de quebrar e incluir definição
adicional aos itens do Product Backlog para ter itens menores e mais precisos.
Esta é uma atividade contínua para adicionar detalhes, como descrição, ordem e tamanho. Os atributos geralmente
variam de acordo com o domínio de trabalho. Os Developers que farão o trabalho são responsáveis pelo
dimensionamento. O Product Owner pode influenciar os Developers, ajudando-os a entender e selecionar trade-offs
(trocas de itens).
Compromisso: Meta do Produto
A Meta do Produto descreve um estado futuro do produto que pode servir como um alvo para o Scrum Team planejar. A
Meta do produto está no Product Backlog. O restante do Product Backlog emerge para definir “o que” cumprirá a Meta
do Produto. Um produto é um veículo para entregar valor. Tem um limite claro, stakeholders conhecidos, usuários ou
clientes bem definidos. Um produto pode ser um serviço, um produto físico ou algo mais abstrato. A Meta do Produto é o
objetivo de longo prazo para o Scrum Team. Eles devem cumprir (ou abandonar) um objetivo antes de assumir o próximo.
28

Aula 04
(TRT7 – 2017) Assinale a opção que apresenta o termo no qual constam as solicitações
de melhorias e novas funcionalidades do software no método Scrum:
a) Sprint Backlog
b) Daily Scrum
c) Sprint Planning
d) Product Backlog
_______________________
Comentários: as solicitações de melhorias e novas funcionalidades ficam no Product Backlog (Letra D).
(CREA-AC – 2016) Uma equipe de desenvolvimento está utilizando o SCRUM como

modelo de desenvolvimento ágil. Nesse caso, o componente desse modelo que
representa a visão geral do produto, definindo o que deve ser feito, assim como suas
prioridades e a ordem em que deve ser realizado, é o:
a) evaluation screen.
b) given pillar.
c) product backlog.
d) sprint backlog.
e) users visions.
_______________________
Comentários: o componente que define o que deve ser feito, assim como ordem e prioridade é o Product Backlog (Letra C).
(TRT3 – 2015) Um técnico de TI está trabalhando em um projeto de desenvolvimento de

software que utiliza o modelo Scrum, em que as funcionalidades a serem
implementadas, na forma de histórias de usuários, são mantidas em uma lista
denominada:
a) product backlog.
b) sprint.
c) chaos list.
d) sprint burndown.
e) metaphor list.
_______________________
Comentários: as funcionalidades a serem implementadas, na forma de histórias de usuários, são mantidas em uma lista
ordenada chamada de Product Backlog (Letra A).
29

Aula 04
Sprint Backlog
Trata-se de conjunto de itens selecionados do Product Backlog, mais a meta da sprint

SPRINT BACKLOG e mais um plano de ação para entregar um incremento potencialmente usável – é
criado e gerenciado pelos desenvolvedores.
O Sprint Backlog é o conjunto de itens selecionados para serem implementados durante a sprint
mais o plano para transformá-los em um incremento. Assim, ao final de cada Reunião de
Planejamento, um novo Sprint Backlog é criado. Normalmente, o plano é composto por tarefas
técnicas necessárias para transformar o item em um incremento do produto. Vamos diferenciar
Product Backlog e Sprint Backlog? Essa é uma pegadinha comum em prova!
O primeiro é uma lista ordenada dos requisitos ou funcionalidades que o software deverá possuir.
O segundo é uma lista de tarefas a serem executadas durante uma sprint para atingir a sua
meta. Trata-se do desmembramento de cada item selecionado do Product Backlog em pequenas
tarefas. O Sprint Backlog torna visível todo o trabalho que os desenvolvedores identificam como
necessário para atingir a meta da sprint.
Aliás, os desenvolvedores (e somente eles) podem adicionar novas tarefas caso descubram, no
decorrer da sprint, que mais trabalho será necessário. Da mesma forma, também podem remover
tarefas caso estas se mostrem desnecessárias. Conforme o trabalho é realizado ou completado, a
estimativa do trabalho restante é atualizada. Em qualquer ponto do tempo na sprint, o total do
trabalho remanescente dos itens pode ser somado.
O Sprint Backlog é altamente visível, uma imagem em tempo

real do trabalho que os desenvolvedores planejam completar
durante a sprint, e pertence exclusivamente os desenvolvedores.
Eles monitoram o total do trabalho restante pelo menos a cada
Reunião Diária. Os desenvolvedores acompanham estes
resumos diários e projeta a probabilidade de alcançar o
objetivo da sprint. Com o rastreamento do trabalho restante em
toda a sprint, os desenvolvedores são capazes de gerenciar o seu
progresso.
Na Versão 2017, foi incluído um texto que reforça muito a importância da melhoria contínua ao
longo dos trabalhos do Time Scrum. Passa a ser declaradamente fundamental a inserção de pelo
menos um item priorizado referente a melhoria do processo identificado na última reunião de
retrospectiva. Essa alteração reforça explicitamente que o time deve trabalhar também na melhoria
contínua do próprio time, trabalho e processos. Esse trecho foi retirado na Versão 2020.
Vejam a seguir um exemplo de Backlog da Sprint. No exemplo, a meta da Sprint 2 é que usuários
possam estar no twitter. À esquerda, temos as funcionalidades do Backlog do Produto; e à direita,
temos as tarefas ou atividades técnicas e de negócio do Backlog da Sprint que devem ser
30

Aula 04
executadas para entregar as funcionalidades e efetivamente cumprir a meta da sprint definida na

reunião de planejamento.
==f219==
O Backlog da Sprint é um conjunto de itens do Backlog do Produto selecionados para a Sprint, juntamente com o plano
para entregar o incremento do produto e atingir o objetivo da Sprint. O Backlog da Sprint é a previsão do Time de
Desenvolvimento sobre qual funcionalidade estará no próximo incremento e sobre o trabalho necessário para entregar
essa funcionalidade em um incremento “Pronto”. O Backlog da Sprint torna visível todo o trabalho que o Time de
Desenvolvimento identifica como necessário para atingir o objetivo da Sprint.
Para garantir melhoria contínua, é incluído no mínimo um item de prioridade alta sobre melhoria do processo identificado
na última Reunião de Retrospectiva. O Backlog da Sprint é um plano com detalhes suficientes que as mudanças no
progresso sejam entendidas durante a Reunião Diária. O Time de Desenvolvimento modifica o Backlog da Sprint ao longo
de toda a Sprint, e o Backlog da Sprint vai surgindo durante a Sprint. Este surgimento ocorre quando o Time de
Desenvolvimento trabalha segundo o plano e aprende mais sobre o trabalho necessário para atingir o objetivo da Sprint.
Sempre que um novo trabalho é necessário, o Time de Desenvolvimento adiciona este ao Backlog da Sprint. Conforme o
trabalho é realizado ou completado, a estimativa do trabalho restante é atualizada. Quando elementos do plano são
considerados desnecessários, eles são removidos. Somente o Time de Desenvolvimento pode alterar o Backlog da Sprint
durante a Sprint. O Backlog da Sprint é altamente visível, uma imagem em tempo real do trabalho que o Time de
Desenvolvimento planeja completar durante a Sprint, e que pertence exclusivamente ao Time de Desenvolvimento.
Monitorando o Progresso da Sprint
Em qualquer ponto do tempo na Sprint, o total do trabalho remanescente dos itens do Backlog da Sprint pode ser somado.
O Time de Desenvolvimento monitora o total do trabalho restante pelo menos a cada Reunião Diária para projetar a
probabilidade de alcançar o objetivo da Sprint. Ao acompanhar o trabalho restante ao longo de toda a Sprint, o Time de
Desenvolvimento pode gerenciar o seu progresso.
31

Aula 04
O Sprint Backlog é composto pela Meta da Sprint (por que), o conjunto de itens do Product Backlog selecionados para a
Sprint (o que), bem como um plano de ação para entregar o Incremento (como). O Sprint Backlog é um plano feito por e
para os Developers. É uma imagem altamente visível, em tempo real do trabalho que os Developers planejam realizar
durante a Sprint para atingir a Meta da Sprint. Consequentemente, o Sprint Backlog é atualizado ao longo da Sprint
conforme mais é aprendido. Deve ter detalhes suficientes para que eles possam inspecionar seu progresso na Daily Scrum.
Compromisso: Meta da Sprint
A Meta da Sprint é o único objetivo da Sprint. Embora a Meta da Sprint seja um compromisso dos Developers, esta fornece
flexibilidade em termos do trabalho exato necessário para alcançá-la. A Meta da Sprint também cria coerência e foco,
encorajando o Scrum Team a trabalhar junto ao invés de iniciativas separadas. A Meta da Sprint é criada durante o evento
Sprint Planning e então adicionada ao Sprint Backlog. Conforme os Developers trabalham durante a Sprint, eles mantêm
a Meta da Sprint em mente. Se o trabalho acabar sendo diferente do que eles esperavam, eles colaboram com o Product
Owner para negociar o escopo do Sprint Backlog dentro da Sprint sem afetar a Meta da Sprint.
(TRT-RS – 2015) No Scrum, a lista de funcionalidades a serem implementadas em cada

projeto que apresenta uma visão dos requisitos de forma mais voltada à maneira como
a equipe vai desenvolvê-los, e não em uma visão de alto nível voltada às necessidades
diretas do cliente, é conhecida como:
a) product backlog.
b) scrum backlog.
c) sprint backlog.
d) daily backlog.
e) daily sprint.
_______________________
Comentários: a questão fala que não se trata de uma lista de alto nível, logo se trata de uma lista mais detalhada. Dito isso,
estamos falando da Sprint Backlog. Lembrando que o Product Backlog apresenta uma lista de alto nível (pouco detalhada) e a
Sprint Backlog apresenta uma lista de baixo nível (muito detalhada) (Letra C).
(UFRJ – 2018) De acordo com o framework Scrum, o artefato descrito como uma lista
de tarefas que o Scrum Team se compromete a fazer em um Sprint é denominado:
a) Product Backlog.
b) Sprint Backlog.
c) Burndown chart.
d) User stories.
e) Tasks.
_______________________
Comentários: a lista de tarefas que a equipe se compromete a fazer em uma sprint é a Sprint Backlog. A minha única ressalva é
que o compromisso de fazer essa lista de tarefas é da Equipe de Desenvolvimento [Versão 2017] ou Desenvolvedores [Versão
2020] – não se trata de um compromisso do Scrum Team (Letra B).
32

Aula 04
Product Increment
Trata-se da é da soma de todos os itens do Backlog do Produto completados durante

Product increment a Sprint e o valor dos incrementos de todas as sprints anteriores – sendo validado como
“pronto”.
Ao final de cada sprint, os desenvolvedores entregam um incremento do produto – resultado

do que foi produzido ao final do trabalho realizado na sprint. Esse é um dos principais conceitos
do framework e vai ao encontro da sua natureza empírica, já que permite ao Product Owner
perceber o valor do investimento realizado e também vislumbrar outras possibilidades de novos
incrementos.
Para os desenvolvedores, é importante entender que o incremento deve ser algo potencialmente
entregável ou liberável. Por que potencialmente? Porque o cliente pode optar por disponibilizar de
imediato o incremento ou não. A equipe, portanto, deve produzir código que tenha qualidade –
e, então, chegamos à Definition of Done (DoD). O que seria isso, professor? Calma, eu vou
explicar...
Pronto significa pronto mesmo! Quando uma equipe ágil diz que uma funcionalidade está pronta,
significa que não tem aquele “veja bem…” ou “só falta uma coisinha, mas já está pronto…”. O DoD é
um acordo formal que define claramente quais são os passos mínimos para a conclusão de um
item ou funcionalidade potencialmente entregável. Trata-se de uma lista de verificação de
atividades necessárias para que um incremento seja considerado como completo.
Ele serve, mais ou menos, como um contrato entre os desenvolvedores e o Product Owner,
garantindo que todo produto gerado pelo projeto estará dentro dos padrões de qualidade
estabelecidos anteriormente. Vocês devem se lembrar que a Definition of Ready (DoR) é um
checklist de critérios acordados para que os desenvolvedores possam aceitar um requisito.
Entenderam direitinho?
Aqui acontece o contrário: trata-se de um checklist de critérios acordados para que o Product
Owner possa aceitar uma funcionalidade. Ambos tratam de critérios de aceite, mas o primeiro
trata dos critérios de aceite das histórias de usuário pelos desenvolvedores e o segundo trata dos
33

Aula 04
critérios de aceite das funcionalidades pelo Product Owner. Em suma: toda a Equipe Scrum deve
entender o que significa “pronto” para ambos os casos.
Uma funcionalidade só é considerada “pronta” se tiver passado por todas as etapas definidas
pelos desenvolvedores (Ex: codificado, passado por todos os testes unitários, passado pelos
testes de aceitação, entre outros). Uma funcionalidade que não esteja “pronta” ao final da sprint
deve retornar ao Product Backlog para que seja incluída em uma próxima sprint. Esse critério é
bastante específico, cada um escolhe o seu!
Por outro lado, é uma boa prática revisar essas definições de “pronto” a cada sprint porque elas
podem mudar ao longo do tempo. O amadurecimento organizacional e a habilidade da equipe
de resolver impedimentos podem fazer com que alguns itens sejam acrescentados com o passar
do tempo. Sempre lembrando que o Definition of Ready é opcional, já o Definition of Done é
obrigatório. Compreenderam?
Por fim, é interessante mencionar outros artefatos que não estão explícitos no guia como o Gráfico
Burndown, que torna visível a evolução diária do trabalho dos desenvolvedores, na medida em que
mostra a comparação de produtividade entre o trabalho estimado inicialmente com a quantidade
restante estimada de trabalho. Via de regra, as unidades utilizadas são de esforço (em horas)
planejado pelo tempo decorrido.
34

Aula 04
Esse gráfico ajuda os gestores a acompanharem o andamento da equipe em projetos, considerando

tempo, esforço e prazo de entrega.
O incremento é a soma de todos os itens do Backlog do Produto completados durante a Sprint e o valor dos incrementos
de todas as Sprints anteriores. Ao final da Sprint um novo incremento deve estar “Pronto”, o que significa que deve estar
na condição de ser utilizado e atender a definição de “Pronto” do Time Scrum. Um incremento é uma parte principal
inspecionável de trabalho pronto que suporta empirismo no final da sprint. O incremento é um passo na direção de uma
visão ou de um objetivo. O incremento deve estar na condição de ser utilizado independente do Product Owner decidir por
liberá-lo ou não.
Um incremento é um trampolim concreto em direção a Meta do produto. Cada incremento é adicionado a todos os
incrementos anteriores e completamente verificado, garantindo que todos os incrementos funcionem juntos. A fim de
fornecer valor, o incremento deve ser utilizável. Vários incrementos podem ser criados em uma Sprint. A soma dos
incrementos é apresentada na Sprint Review, apoiando assim o empirismo. No entanto, um incremento pode ser entregue
aos stakeholders antes do final da Sprint. A Sprint Review nunca deve ser considerada um marco para liberar valor. O
trabalho não pode ser considerado parte de um incremento a menos que atenda a Definição de Pronto.
Compromisso: Definição de Pronto
A Definição de Pronto é uma descrição formal do estado do Incremento quando ela atende às medidas de qualidade
exigidas para o produto. No momento em que um item do Product Backlog atende a Definição de Pronto, um incremento
nasce. A Definição de Pronto cria transparência ao fornecer a todos um entendimento compartilhado de qual trabalho foi
concluído como parte do Incremento. Se um item do Product Backlog não atender à Definição de Pronto, ele não poderá
ser liberado ou mesmo apresentado na Sprint Review. Em vez disso, ele retorna ao Product Backlog para consideração
futura.
Se a Definição de Pronto para um incremento faz parte dos padrões da organização, todos os Scrum Teams devem segui-
la como mínimo. Se não for um padrão organizacional, o Scrum Team deve criar uma Definição de Pronto apropriada para
o produto. Os Developers devem estar em conformidade com a Definição de Pronto. Se houver vários
Scrum Teams trabalhando juntos em um produto, eles devem definir e cumprir mutuamente a mesma Definição de
Pronto.
35

Aula 04
Eventos
Vamos falar agora sobre os eventos – também chamados em questões de provas de reuniões ou
cerimônias! Vamos começar pelo contêiner que cobre todos os outros eventos: Sprint.
Pensem comigo: estou em um projeto cujo objetivo é criar uma página de e-commerce para uma
empresa de varejo. Eu tenho que realizar diversas tarefas para construir essa página, como por
exemplo criar uma funcionalidade que permita o pagamento via cartão de crédito e débito. Essa
funcionalidade pode ser (em conjunto com outras) a unidade de trabalho que satisfaz um
requisito de negócio, logo pode ser realizada em uma sprint.
O Scrum prega que, ao fim de cada sprint, deve-se entregar um incremento potencialmente
funcional do produto ao cliente. O que seria potencialmente funcional? É aquilo que tem potencial
de entrar ser utilizado pelo cliente em seu ambiente. As sprints têm duração de até um mês,
permitindo feedbacks constantes quanto ao que está sendo desenvolvido. Ela é como um contêiner
para todos os outros eventos e cerimônias que veremos à frente.
Eu sei que está um pouco abstrato, então vamos pensar em uma metáfora! Imagina que você
contrate um marceneiro para construir os armários do apê novo que você comprou logo após passar
em um concurso público. Há duas maneiras de fazer isso: se fôssemos utilizar um método
tradicional, ele perguntaria como você quer os armários, passaria alguns meses construindo e
algum dia montaria todos os armários na sua casa de uma só vez – sem interações com você.
No método ágil, nós vamos dividir esse projeto de construção dos armários em vários ciclos de
tempo fixo. Por exemplo: nós vamos combinar com o marceneiro que a cada quinze dias eu quero
que ele entregue um incremento dos armários já potencialmente funcional, ou seja, que você já
possa utilizar na sua casa. Nos primeiros quinze dias, ele deve entregar os armários do banheiro
prontinhos para você utilizar.
36

Aula 04
Nos próximos quinze dias, ele deve entregar os armários da área de serviço também prontos para
utilizar. Nos outros quinze, não será possível entregar todos os armários do quarto, mas ele
deve entregar pelo menos o guarda-roupa já pronto para você utilizar. Vocês conseguem notar
que a cada intervalo regular de quinze dias, você vai recebendo incrementos potencialmente
funcionais? Com o software é a mesma coisa...
Qual é a grande vantagem dessa segunda opção em relação à primeira? Bem, primeiro você não
morre de ansiedade de receber os móveis somente ao final; a segunda vantagem é que você pode
mudar de ideia no meio do caminho e pedir para ele mudar o projeto. Enfim, o que importa disso
tudo que eu disse? Importa que esses ciclos regulares de tempo fixo de desenvolvimento de um
incremento potencialmente funcional são conhecidos também como Sprint!
Bem, nós já sabemos que uma sprint dura um mês ou menos e se inicia imediatamente após a
conclusão da sprint anterior. Durante a sprint, é proibido realizar mudanças que coloquem em
risco os objetivos da própria sprint. Na nossa metáfora, se eu planejei que nessa sprint eu vou
construir os armários do banheiro utilizando madeira do tipo cedro, eu não posso no meio do
caminho alterar para madeira do tipo mogno porque isso coloca em risco os objetivos da sprint.
Colocaria em risco, Diego? Sim, porque essa mudança poderia inviabilizar a entrega do produto na
data acordada e a sprint poderia falhar! Além disso, é proibido mudar a composição da equipe ou
diminuir as metas de qualidade. Apesar disso, o escopo pode ser sempre clarificado, esclarecido e
renegociado entre o Product Owner e os desenvolvedores durante a própria execução da sprint em
andamento.
Aliás, nada impede que uma sprint seja cancelada antes de seu time-box terminar e isso somente
pode ser feito pelo Product Owner (sob influência de stakeholders, desenvolvedores, etc).
Professor, por que alguém faria esse cancelamento? 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 de mercado 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. 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.
O cancelamento de Sprints consome recursos, já que todos tem que se reagrupar em outra
reunião de planejamento da sprint para iniciar outra sprint. Cancelamentos de sprints são
frequentemente traumáticos para a Equipe Scrum, e são muito incomuns. Por falar em
planejamento da sprint, vamos falar agora sobre os eventos. Por que eu fiz essa pausa para falar um
pouco mais sobre as sprints?
37

Aula 04
Porque os quatro eventos que serão detalhados a seguir compõem uma sprint – além, é claro, do
próprio trabalho de desenvolvimento. Eventos Scrum são eventos time-boxed – o que significa
que eles possuem uma duração máxima predefinida. Eles são utilizados para criar uma rotina e
minimizar a necessidade de reuniões não definidas pelo Scrum. Esses eventos são: (1) Reunião de
Planejamento da Sprint; (2) Reunião Diária; (3) Revisão da Sprint; (4) Retrospectiva da Sprint.
Eventos prescritos são usados no Scrum para criar uma regularidade e minimizar a necessidade de reuniões não definidas
no Scrum. Todos os eventos são eventos time-boxed, de tal modo que todo evento tem uma duração máxima. Uma vez
que a Sprint começa, sua duração é fixada e não pode ser reduzida ou aumentada. Os eventos restantes podem terminar
sempre que o propósito do evento é alcançado, garantindo que uma quantidade adequada de tempo seja gasta não
permitindo desperdícios no processo.
Além da Sprint, que é um container para outros eventos, cada evento no Scrum é uma oportunidade de inspecionar e
adaptar alguma coisa. Estes eventos são especificamente projetados para permitir uma transparência e inspeção
criteriosa. Falhas na inclusão de qualquer um destes eventos resultará na redução da transparência e na perda de
oportunidades para inspecionar e adaptar.
O coração do Scrum é a Sprint, um time-boxed de um mês ou menos, durante o qual um “Pronto”, incremento de produto
potencialmente liberável é criado. Sprints tem durações consistentes ao longo de todo o esforço de desenvolvimento. Uma
nova Sprint inicia imediatamente após a conclusão da Sprint anterior. As Sprints contêm e consistem de um planejamento
da Sprint, reuniões diárias, o trabalho de desenvolvimento, uma revisão da Sprint e uma retrospectiva da Sprint. Durante
a Sprint:
• Não são feitas mudanças que possam por em perigo o objetivo da Sprint;
• As metas de qualidade não diminuem; e,
• O escopo pode ser clarificado e renegociado entre o Product Owner e o Time de Desenvolvimento quanto mais for
aprendido.
Cada Sprint pode ser considerada um projeto com horizonte não maior que um mês. Como os projetos, as Sprints são
utilizadas para realizar algo. Cada Sprint tem uma meta do que é para ser construído, um plano previsto e flexível que irá
guiar a construção, o trabalho e o produto resultante do incremento. Sprints são limitadas a um mês corrido. Quando o
horizonte da Sprint é muito longo, a definição do que será construído pode mudar, a complexidade pode aumentar e o
risco pode crescer. Sprints permitem previsibilidade que garante a inspeção e adaptação do progresso em direção à meta
pelo menos a cada mês corrido. Sprints também limitam o risco ao custo de um mês corrido.
Uma Sprint pode ser cancelada antes do time-boxed da Sprint terminar. Somente o Product Owner tem a autoridade para
cancelar a Sprint, embora ele (ou ela) possa fazer isso sob influência das partes interessadas, do Time de Desenvolvimento
ou do Scrum Master. 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
liberá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.
38

Aula 04
O cancelamento de Sprints consome recursos, já que todos se reagrupam em outro planejamento da Sprint para iniciar
outra Sprint. Cancelamentos de Sprints são frequentemente traumáticos para o Time Scrum, e são muito incomuns.
A Sprint é um contêiner para todos os outros eventos. Cada evento no Scrum é uma oportunidade formal para inspecionar
e adaptar os artefatos do Scrum. Esses eventos são projetados especificamente para permitir a transparência necessária.
A falha em operar quaisquer eventos conforme prescrito resulta em oportunidades perdidas de inspeção e adaptação. Os
eventos são usados no Scrum para criar regularidade e minimizar a necessidade de reuniões não definidas no Scrum. O
ideal é que todos os eventos sejam realizados no mesmo horário e local para reduzir a complexidade.
Sprints são o coração do Scrum, onde ideias são transformadas em valor. São eventos de duração fixa de um mês ou
menos para criar consistência. Uma nova Sprint começa imediatamente após a conclusão da Sprint anterior. Todo o
trabalho necessário para atingir a meta do Produto, incluindo Sprint Planning, Daily Scrums, Sprint Review e Sprint
Retrospective, acontece dentro de Sprints. Durante a Sprint:
• Nenhuma mudança é feita que coloque em risco a meta da Sprint;

• A qualidade não diminui;
• O Product Backlog é refinado conforme necessário; e,
• O escopo pode ser esclarecido e renegociado com o Product Owner conforme mais é aprendido.
Sprints permitem previsibilidade, garantindo a inspeção e adaptação do progresso em direção a uma meta do Produto ao
menos uma vez por mês. Quando o horizonte de uma Sprint é muito longo, a meta da Sprint pode se tornar inválida, a
complexidade pode aumentar e o risco pode aumentar. Sprints mais curtas podem ser empregados para gerar mais ciclos
de aprendizagem e limitar os riscos de custo e esforço a um período de tempo menor. Cada Sprint pode ser considerado
um projeto curto.
Existem várias práticas para prever o progresso, como burn-downs, burn-ups ou cumulative flows. Embora
comprovadamente úteis, eles não substituem a importância do empirismo. Em ambientes complexos, o que acontecerá é
desconhecido. Somente o que já aconteceu pode ser usado para a tomada de decisão voltada para o futuro. Uma Sprint
pode ser cancelada se a Meta da Sprint se tornar obsoleta. Apenas o Product Owner tem autoridade para cancelar a
Sprint.
(UNIR – 2018) Os Eventos com Duração Fixa chamados Time-Boxes no Scrum são
compostos por: a reunião de planejamento da versão para entrega, a Sprint, a reunião
de planejamento da Sprint, a revisão da Sprint, a retrospectiva da Sprint e a reunião
diária.
_______________________
Comentários: a questão está correta, mas eu enfatizaria que time-boxes são tempos de duração máxima fixa (Correto).
39

Aula 04
Sprint Planning
O trabalho a ser realizado na Sprint é planejado na Reunião de Planejamento da Sprint. Este

planejamento é criado com o trabalho colaborativo de toda a Equipe Scrum. Ela possui um time-
box com no máximo oito horas para uma sprint de um mês de duração – para sprints menores, a
duração é menor. O Scrum Master garante que o evento ocorra e que os participantes entendam
seu propósito. Ela consiste em duas partes e devem responder adequadamente as perguntas:
1. O que será entregue como resultado do incremento da próxima Sprint?
2. Como o trabalho necessário para entregar o incremento será realizado?
Na primeira parte, os desenvolvedores tentam prever as funcionalidades que serão

desenvolvidas durante a sprint. O Product Owner apresenta as histórias de usuário mais
priorizados do Product Backlog aos desenvolvedores. Como ele faz isso? Em geral, ele dá um valor
de negócio para cada item do backlog, organizando-os em forma decrescente de valor de negócio.
Como assim, professor?
Imaginem que exista um item que o Product Owner deseja muito que seja implementado – ele pode
dizer que esse item tem o valor de negócio de 1000. Agora imagine que exista outro item no Product
Backlog que o Product Owner não liga tanto – ele dá um valor de negócio de 10. Dessa forma, o
Product Owner consegue ordenar os itens de acordo com o valor de negócio. Feito isso, é hora
de estimar o esforço de desenvolvimento de cada item do backlog.
Quando nós utilizamos histórias de usuário, é comum utilizarmos uma outra unidade de medida
para medir esforço, em vez do tempo – utilizado frequentemente em metodologias tradicionais.
No caso de Histórias de Usuário (User Stories), nós utilizamos Pontos de História (Story Points).
Trata-se de uma unidade de medida relativa que leva em consideração o esforço1 necessário
para realizar uma determinada funcionalidade.
Se uma funcionalidade requerer o dobro de esforço para ser implementada, ela receberá
aproximadamente o dobro de Story Points. Para fazer essa estimativa, os desenvolvedores
realizam uma comparação com outras histórias já estimadas. Caso não haja ainda nada estimado
no Product Backlog, a equipe localiza a história de usuário com o menor esforço para
desenvolvimento e o utiliza como base de comparação.
Uma das melhores formas de estimar Story Points é por meio de uma técnica chamada
Planning Poker, que não está no guia oficial, mas que é frequentemente utilizada tanto para
1
Há uma polêmica danada: alguns afirmam que ela estima complexidade e, não, esforço; outros dizem que é uma combinação de complexidade,
esforço, risco, etc.
40

Aula 04
estimar esforço como para estimar tamanho. Essa técnica busca uma abordagem dinâmica e
divertida na estimativa de Histórias de Usuário, e elimina a influência que um desenvolvedor possa
exercer sobre outros.
Feita a estimativa de cada história de usuário, os desenvolvedores decidirão a quantidade de itens

do backlog a serem realizados na sprint. Galera, vamos detalhar isso um pouco mais! Story Points
é uma unidade de medida relativa que leva em consideração o esforço necessário para realizar
uma determinada funcionalidade. Se uma funcionalidade requerer o dobro de esforço para ser
implementada, ela receberá aproximadamente o dobro de Story Points.
Para estimar a quantidade de Story Points de uma User Story, os desenvolvedores os comparam
com outros já estimados. Caso não haja ainda nada estimado no Product Backlog, os
desenvolvedores localizam o User Story com o menor esforço para o desenvolvimento, e o utiliza
como base para comparações futuras. Uma das melhores formas de se estimar Story Points é
utilizando o Planning Poker.
Isso porque se trata de uma abordagem divertida na estimativa de itens ou User Stories que elimina
a influência que um membro dos desenvolvedores possa exercer sobre os outros. Vamos entender
um pouco melhor como ele funciona? No início do Planning Poker, cada membro do time recebe um
conjunto de cartas. Cada carta exibe um dos valores válidos para a estimativa (Ex: 0, 1, 2, 3, 5, 8, 13,
20, 40, e 100).
Em geral, os valores seguem uma escala baseada na Sequência de Fibonacci. Observem: outra
sequência pode ser escolhida, porém Fibonacci é a mais utilizada. Para cada User Story a ser
estimativa, o Product Owner lê a descrição e esclarece quaisquer dúvidas que os membros do time
tenham. Entretanto, é importante lembrar que em determinado ponto, qualquer discussão
adicional não busca uma precisão maior.
Após todas as questões serem respondidas, cada membro seleciona uma carta representando sua
estimativa, mas sem mostrar aos outros. As cartas não são mostradas até o momento em que
todos, simultaneamente, exibem seus valores, de forma que todos vejam os valores selecionados
simultaneamente. Neste ponto, é normal que as estimativas sejam significativamente diferentes.
E na realidade é um bom sinal.
Quando as estimativas diferem, os membros expõem os motivos que os levaram a escolher

aqueles valores. Depois das explanações e discussões, todos recolhem suas cartas e estimam
novamente da mesma forma. O Planning Poker funciona porque se baise em diversas opiniões
durante a estimativa. Como os desenvolvedores formam um time multidisciplinar, eles são os mais
indicados para estimar as histórias do que qualquer outra pessoa.
Além disso, os diálogos e justificativas permitem uma maior acuracidade das estimativas,
especialmente nos itens com maior incerteza. E isto é de extrema importância em um projeto que
tenha um certo nível de complexidade. Finalmente, estudos mostram que a média de estimativas
individuais levam a melhores resultados, uma vez que promovem discussões em grupo.
41

Aula 04
Estas discussões em grupo são a base do Planning Poker e elas conduzem a um consenso entre os
indivíduos participantes. Mais uma vez: Fibonacci é a escala mais utilizada na estimativa de User
Story por Planning Poker. Isso se deve ao fato de a Sequência de Fibonacci ser uma função
quadrática, em vez de uma função linear. Detalhe: algumas vezes as histórias de usuário são muito
grandes para serem desenvolvidas em uma sprint – são chamadas de Épicos.
Elas precisarão ser quebradas em partes menores. Mais que isso, em alguns projetos é necessário
um nível ainda maior que um épico – chamado de Saga – para features geralmente mais complexas.
Foram selecionados os itens? Ok! Agora a Equipe Scrum definirá uma meta para a sprint que será o
guia para os desenvolvedores sobre o que estará sendo desenvolvido durante a Sprint.
Na segunda parte, os desenvolvedores decidem como irá transformar os itens selecionados em

um incremento durante a Sprint e desenvolve o Sprint Backlog. Por falar nisso... qual a diferença
entre Product e Sprint Backlog mesmo? O primeiro é uma lista de todos os
requisitos/funcionalidades de usuário levantados até o momento e mantidas pelo Product Owner,
que pode alterá-las a qualquer momento.
O segundo é um subconjunto do primeiro transformado em uma lista de tarefas técnicas e

mantidas pelos desenvolvedores, que pode alterá-las a qualquer momento. Bem, ao final do
planejamento da Sprint, os desenvolvedores devem ser capazes de explicar ao Product Owner e ao
Scrum Master como pretende trabalhar como equipe auto-organizada para completar o objetivo da
Sprint e criar o incremento previsto.
Com o Sprint Backlog criado, define-se a meta da sprint! O que seria isso, Diego? Galera, a meta
nada mais é que um objetivo definido para ser satisfeito ao final da sprint. O Product Owner pode
estar presente durante a segunda parte da reunião para clarificar itens do Backlog do Produto.
Vocês se lembram que essa é uma das principais responsabilidades desse papel, certo? Pois é... vamos
para o nosso próximo evento...
O trabalho a ser realizado na Sprint é planejado durante o planejamento da Sprint. Este plano é criado com o trabalho
colaborativo de todo o Time Scrum. O Planejamento da Sprint é um um time-boxed com no máximo oito horas para uma
Sprint de um mês de duração. Para Sprints menores, este evento é usualmente menor. O Scrum Master garante que o
evento ocorra e que os participantes entendam seu propósito. O Scrum Master ensina o Time Scrum a manter-se dentro
dos limites do time-box. O planejamento da Sprint responde as seguintes questões:
• O que pode ser entregue como resultado do incremento da próxima Sprint?

• Como o trabalho necessário para entregar o incremento será realizado?
Tópico Um: O que pode ser Pronto nesta Sprint?
O Time de Desenvolvimento trabalha para prever as funcionalidades que serão desenvolvidas durante a Sprint. O Product
Owner debate o objetivo que a Sprint deve realizar e os itens de Backlog do Produto que, se completados na Sprint,
atingirão o objetivo da Sprint. Todo o Time Scrum colabora com o entendimento do trabalho da Sprint. A entrada desta
42

Aula 04
reunião é o Backlog do Produto, o mais recente incremento do produto, a capacidade projetada do Time de
Desenvolvimento durante a Sprint e o desempenho passado do Time de Desenvolvimento.
O número de itens selecionados do Backlog do Produto para a Sprint é o único trabalho do Time de Desenvolvimento.
Somente o Time de Desenvolvimento pode avaliar o que pode ser completado ao longo da próxima Sprint. Durante o
Planejamento da Sprint, o Time Scrum também determina a meta da Sprint. A meta da Sprint é o objetivo que será
satisfeito dentro da Sprint através da implementação do Backlog do Produto, e que fornece a orientação para o Time de
Desenvolvimento sobre o porquê dele estar construindo o incremento.
Tópico Dois: Como o trabalho escolhido será Pronto?
Tendo definido o objetivo da Sprint e selecionado os itens de Backlog do Produto da Sprint, o Time de Desenvolvimento
decide como irá construir essas funcionalidades durante a Sprint e transformá-las em um incremento de produto “Pronto”.
Os itens de Backlog do Produto selecionados para a Sprint, junto com o plano de entrega destes itens é chamado de
Backlog da Sprint. O Time de Desenvolvimento frequentemente inicia o desenho do sistema e do trabalho
necessário para converter o Backlog do Produto em um incremento funcional do produto.
O trabalho pode ser de vários tamanhos ou esforços. Contudo, o trabalho suficiente é planejado durante o planejamento
da Sprint pelo Time de Desenvolvimento para prever o que este acredita que poderá fazer durante a próxima Sprint. O
trabalho planejado pelo Time de Desenvolvimento para os primeiros dias da Sprint é decomposto até o final desta reunião,
frequentemente em unidades de um dia de duração ou menos. O Time de Desenvolvimento se auto-organiza para realizar
todo o trabalho do Backlog da Sprint, tanto durante o planejamento da Sprint quanto no que for necessário durante a
Sprint.
O Product Owner pode ajudar a clarificar os itens de Backlog do Produto selecionados e nas decisões conflituosas de troca.
Se o Time de Desenvolvimento determina que tem excesso ou falta de trabalho, os itens do Backlog da Sprint podem ser
renegociados com o Product Owner. O Time de Desenvolvimento também pode convidar outras pessoas para participar
desta reunião para fornecer opinião técnica ou de domínios específicos. No final do planejamento da Sprint, o Time de
Desenvolvimento deve ser capaz de explicar ao Product Owner e ao Scrum Master como pretende trabalhar como equipe
auto-organizada para completar o objetivo da Sprint e criar o incremento previsto.
Meta da Sprint
A meta da Sprint é um objetivo definido para a Sprint que pode ser satisfeito através da implementação do Backlog do
Produto. Este fornece uma direção para o Time de Desenvolvimento sobre o porquê de estar construindo o incremento.
Este é criado durante a reunião de planejamento da Sprint. O objetivo da Sprint dá ao Time de Desenvolvimento alguma
flexibilidade a respeito da funcionalidade que será completada dentro da Sprint. Os itens do Backlog do Produto
selecionados entregam uma função coerente, que pode ser o objetivo da Sprint.
O objetivo da Sprint pode ser qualquer outro coerente que faça o Time de Desenvolvimento trabalhar em conjunto em vez
de em iniciativas separadas. Conforme o Time de Desenvolvimento trabalha, eles mantêm o objetivo da Sprint em mente.
A fim de satisfazer o objetivo da Sprint, implementando funcionalidade e tecnologia. Caso o trabalho acabe por ser
diferente do esperado pelo Time de Desenvolvimento, então eles colaboram com o Product Owner para negociar o escopo
do Backlog da Sprint dentro da Sprint.
A Sprint Planning inicia a Sprint ao definir o trabalho a ser realizado na Sprint. Este plano resultante é criado pelo trabalho
colaborativo de todo o Scrum Team. O Product Owner garante que os participantes estejam preparados para discutir os
itens mais importantes do Product Backlog e como eles são mapeados para a Meta do Produto. O Scrum
Team também pode convidar outras pessoas para participar da Sprint Planning para fornecer conselhos.
43

Aula 04
A Sprint Planning aborda os seguintes tópicos:
Tópico um: Por que esta Sprint é valiosa?
O Product Owner propõe como o produto pode aumentar seu valor e utilidade na Sprint atual. Todo o Scrum Team então
colabora para definir uma Meta da Sprint que comunica porque a Sprint é valiosa para os stakeholders. A meta da Sprint
deve ser finalizada antes do final da Sprint Planning.
Tópico dois: O que pode ser feito nesta Sprint?
Por meio de discussão com o Product Owner, os Developers selecionam itens do Product Backlog para incluir na Sprint
atual. O Scrum Team pode refinar esses itens durante este processo, o que aumenta a compreensão e a confiança.
Selecionar o quanto pode ser concluído em uma Sprint pode ser um desafio. No entanto, quanto mais os Developers sabem
sobre seu desempenho anterior, sua capacidade futura e sua Definição de Pronto, mais confiantes eles estarão em suas
previsões quanto a Sprint.
Tópico três: Como o trabalho escolhido será realizado?
Para cada item do Product Backlog selecionado, os Developers planejam o trabalho necessário para criar um Incremento
que atenda à Definição de Pronto. Isso geralmente é feito decompondo itens do Product Backlog em itens de trabalho
menores de um dia ou menos. A forma como isso é feito fica a critério exclusivo dos Developers . Ninguém mais diz a eles
como transformar itens do Product Backlog em incrementos de valor. A Meta da Sprint, os itens do Product Backlog
selecionados para a Sprint, mais o plano para entregá-los são chamados juntos de Sprint Backlog.
A Sprint Planning tem um Timebox definido com duração máxima de de oito horas para uma Sprint de um mês. Para
Sprints mais curtas, o evento geralmente é mais curto.
(TRE-BA – 2017) A reunião de planejamento da sprint do Scrum é o evento em que:
a) é definida a equipe scrum e são cancelados os itens da sprint anterior que não tenham
sido entregues e os que tenham sido entregues, mas tenham sido rejeitados pelo
usuário.
b) são escritas as histórias dos usuários por meio do planning poker.
c) é definida a meta da sprint e são selecionados os itens do product backlog que

comporão a sprint.
d) é decidido pelo PO (product owner) se haverá o cancelamento ou não da sprint em

curso.
e) participam exclusivamente o PO (product owner) e o SM (scrum master), que, por

meio do planning poker, priorizaram os itens do backlog.
_______________________
Comentários: (a) Errado, a equipe é definida antes e não se cancela nada; (b) Errado, planning poker é uma técnica de estimativa
de esforço; (c) Correto; (d) Errado, se ainda está no planejamento, a sprint não está em curso; (e) Errado, os desenvolvedores
também participam da reunião de planejamento (Letra C).
44

Aula 04
Daily Scrum
A Reunião Diária (15 minutos) é um evento que busca criar um plano para as próximas 24 horas
e inspecionar o trabalho desde a última Reunião Diária. É realizada em todos os dias da sprint e
é o evento em que os desenvolvedores planejam o trabalho para as próximas 24 horas – isso otimiza
a colaboração e a performance do time através da inspeção do trabalho desde a última Reunião
Diária, e da previsão do próximo trabalho da Sprint.
A Reunião Diária é mantida no mesmo horário e local todo dia para reduzir a complexidade e não
deve ocorrer necessariamente em pé. A Reunião Diária aumenta a probabilidade dos
desenvolvedores atingirem o objetivo da Sprint. Todos os dias, os desenvolvedores devem
entender como o mesmo pretende trabalhar em conjunto, como um time auto-organizado, para
completar o objetivo da Sprint e criar o incremento previsto até o final da Sprint.
A estrutura da reunião é definida pelos desenvolvedores e pode ser conduzida de diferentes

formas desde que estas se foquem no progresso em direção à meta da sprint. Alguns Times de
Desenvolvimento utilizarão perguntas, outros se basearão em discussões – no meu caso pessoal,
nós utilizávamos ambos: perguntas e discussões. Bem, aqui segue um exemplo do que pode ser
utilizado:
1. O que eu fiz ontem que ajudou o os desenvolvedores a atenderem a meta da Sprint?
2. O que eu farei hoje para ajudar os desenvolvedores atenderem a meta da Sprint?
3. Eu vejo algum obstáculo que impeça a mim ou aos desenvolvedores no atendimento da meta da Sprint?
As Reuniões Diárias melhoram a comunicação entre os integrantes, eliminam a necessidade de

outras reuniões, identificam e removem impedimentos, destacam e promovem rápidas tomadas
de decisão, e melhoram o nível de conhecimento da Equipe. Apesar de poder contar com a presença
de outras partes interessadas, essa é uma reunião feito pelos desenvolvedores para os próprios
desenvolvedores.
A Reunião Diária do Scrum é um evento time-boxed de 15 minutos para o Time de Desenvolvimento. A Reunião Diária é
realizada em todos os dias da Sprint. Nela o Time de Desenvolvimento planeja o trabalho para as próximas 24 horas. Isso
otimiza a colaboração e a performance do time através da inspeção do trabalho desde a última Reunião Diária, e da
previsão do próximo trabalho da Sprint. A Reunião Diária é mantida no mesmo horário e local todo dia para reduzir a
complexidade.
45

Aula 04
O Time de Desenvolvimento usa a Reunião Diária para inspecionar o progresso em direção ao objetivo da Sprint e para
inspecionar se o progresso tende na direção de completar o trabalho do Backlog da Sprint. A Reunião Diária aumenta a
probabilidade do Time de Desenvolvimento atingir o objetivo da Sprint. Todos os dias, o Time de Desenvolvimento deve
entender como o mesmo pretende trabalhar em conjunto, como um time auto-organizado, para completar o objetivo da
Sprint e criar o incremento previsto até o final da Sprint.
A estrutura da reunião é definida pelo Time de Desenvolvimento e pode ser conduzida de diferentes formas desde que
estas foquem no progresso em direção à Meta da Sprint. Alguns Times de Desenvolvimento utilizarão perguntas, outros
se basearão em discussões. Aqui segue um exemplo do que pode ser utilizado:
• O que eu fiz ontem que ajudou o Time de Desenvolvimento a atingir a meta da Sprint?
• O que eu farei hoje para ajudar o Time de Desenvolvimento atingir a meta da Sprint?
• Eu vejo algum obstáculo que impeça a mim ou o Time de Desenvolvimento no atingimento da meta da Sprint?
O Time de Desenvolvimento ou membros da equipe frequentemente se encontram imediatamente após a Reunião Diária
para discussões detalhadas, ou para adaptar, ou replanejar, o restante do trabalho da Sprint.O Scrum Master assegura
que o Time de Desenvolvimento tenha a reunião, mas o Time de Desenvolvimento é responsável por conduzir a Reunião
Diária. O Scrum Master ensina o Time de Desenvolvimento a manter a Reunião Diária dentro do time-box de 15 minutos.
A Reunião Diária é uma reunião interna do Time de Desenvolvimento. Se outros estiverem presentes, o Scrum Master
deve garantir que eles não perturbem a reunião. Reuniões Diárias melhoram as comunicações, eliminam outras reuniões,
identificam e removem impedimentos para o desenvolvimento, destacam e promovem rápidas tomadas de
decisão, e melhoram o nível de conhecimento do Time de Desenvolvimento. Esta é uma reunião chave para inspeção e
adaptação.
O propósito da Daily Scrum é inspecionar o progresso em direção a Meta da Sprint e adaptar o Sprint Backlog conforme
necessário, ajustando o próximo trabalho planejado. A Daily Scrum é um evento de 15 minutos para os Developers do
Scrum Team. Para reduzir a complexidade, é realizado no mesmo horário e local, todos os dias úteis da Sprint. Se o
Product Owner ou o Scrum Master estão trabalhando ativamente nos itens do Sprint Backlog, eles participam como
Developers.
Os Developers podem selecionar qualquer estrutura e técnicas que quiserem, desde que seu Daily Scrum se concentre no
progresso em direção a Meta da Sprint e produza um plano de ação para o próximo dia de trabalho. Isso cria foco e melhora
o autogerenciamento. As Daily Scrums melhoram as comunicações, identificam os impedimentos, promovem a rápida
tomada de decisões e consequentemente, eliminam a necessidade de outras reuniões. A Daily Scrum não é o único
momento em que os Developers podem ajustar seu plano. Eles costumam se reunir ao longo do dia para discussões mais
detalhadas sobre a adaptação ou replanejamento do resto do trabalho da Sprint.
(EBSERH – 2017) As reuniões diárias estabelecidas pelos autores do SCRUM (Jef

Sutherland e Ken Schwaber) faz com que o Scrum Master oriente o Time de
Desenvolvimento a manter a Reunião Diária dentro do time-box constante de:
a) 15 minutos b) 1 hora c) 30 minutos d) 2 horas e) 45 minutos

_______________________
Comentários: o time-box da reunião diária é de 15 minutos (Letra A).
46

Aula 04
Sprint Review
No final da sprint, ocorre a Revisão da Sprint (Proporcional a 4 horas). Embora seja utilizada para
demonstrar as novas funcionalidades desenvolvidas durante a sprint, seu principal motivo é o de
inspecionar o que os desenvolvedores produziram e colher opiniões e impressões dos presentes
para, caso seja necessário, adaptar o plano para a sprint seguinte. O foco aqui é aprimorar o
produto!
==f219==
Vocês se lembram do filme O Gladiador? Pois é! A Revisão da Sprint é o momento em que o Product
Owner valida () ou não () a sprint, de acordo com a meta que tenha sido acordada com os
desenvolvedores durante a reunião de planejamento da sprint. Discute-se os problemas e as
soluções e, após a demonstração do incremento, respondem-se quaisquer dúvidas dos
presentes.
A Revisão da Sprint é realizada no final da Sprint para inspecionar o incremento e adaptar o Backlog do Produto se
necessário. Durante a Revisão da Sprint o Time Scrum e as partes interessadas colaboram sobre o que foi feito na Sprint.
Com base nisso e em qualquer mudança no Backlog do Produto durante a Sprint, os participantes colaboram nas próximas
coisas que podem ser feitas para otimizar valor. Esta é uma reunião informal, não uma reunião de status, e a apresentação
do incremento destina-se a motivar e obter feedback e promover a colaboração.
Esta é uma reunião de no máximo 4 horas de duração para uma Sprint de um mês. Para Sprints menores, este evento é
usualmente menor. O Scrum Master garante que o evento ocorra e que os participantes entendam o seu propósito. O
Scrum Master ensina todos os envolvidos a manter a reunião dentro do Time-box. A Revisão da Sprint inclui os seguintes
elementos:
• Os participantes incluem o Time Scrum e os Stakeholders chaves convidados pelo Product Owner;
• O Product Owner esclarece quais itens do Backlog do Produto foram “Prontos” e quais não foram “Prontos”;
• O Time de Desenvolvimento discute o que foi bem durante a Sprint, quais problemas ocorreram dentro da Sprint, e como
estes problemas foram resolvidos;
• O Time de Desenvolvimento demonstra o trabalho que está “Pronto” e responde as questões sobre o incremento;
47

Aula 04
• O Product Owner discute o Backlog do Produto tal como está. Ele (ou ela) projeta os prováveis alvos e datas de entrega
baseado no progresso até a data (se necessário);
• O grupo todo colabora sobre o que fazer a seguir, e é assim que a Revisão da Sprint fornece valiosas entradas para o
Planejamento da Sprint subsequente;
• Revisão de como o mercado ou o uso potencial do produto pode ter mudado e o que é a coisa mais importante a se fazer
a seguir; e,
• Revisão da linha do tempo, orçamento, potenciais capacidades, e mercado para a próxima versão esperada de
funcionalidade ou de capacidade do produto.
O resultado da Revisão da Sprint é um Backlog do Produto revisado que define os prováveis Itens de Backlog do Produto
para a próxima Sprint. O Backlog do Produto pode também ser ajustado completamente para atender novas
oportunidades.
O propósito da Sprint Review é inspecionar o resultado da Sprint e determinar as adaptações futuras. O Scrum Team
apresenta os resultados de seu trabalho para os principais stakeholders e o progresso em direção a Meta do Produto é
discutido. Durante o evento, o Scrum Team e os stakeholders revisam o que foi realizado na Sprint e o que mudou em seu
ambiente. Com base nessas informações, os participantes colaboram sobre o que fazer a seguir. O Product Backlog
também pode ser ajustado para atender a novas oportunidades.
A Sprint Review é uma sessão de trabalho e o Scrum Team deve evitar limitá-la a uma apresentação. A Sprint Review é o
penúltimo evento da Sprint e tem um Timebox com prazo máximo de quatro horas para uma Sprint de um mês. Para
Sprints mais curtas, o evento geralmente é mais curto.
(TRE-SP – 2017) Considere, por hipótese, que uma equipe de Analistas do TRE-SP
participou de uma reunião de um projeto baseado no Scrum e, ao final, o Backlog do
Produto foi revisto e completamente ajustado para atender às novas necessidades de
verificação de contribuições para campanhas de candidatos, advindas de pessoas físicas
sob suspeita de corrupção. Os Analistas participaram da reunião:
a) de Revisão da Sprint.
b) de Retrospectiva da Sprint.
c) diária.
d) de Verificação da Sprint.
e) de Planejamento da Sprint.
_______________________
Comentários: a questão trata da revisão da sprint, que é executada no final para inspecionar o incremento e adaptar o Backlog
do Produto, se necessário (Letra A).
48

Aula 04
Sprint Retrospective
A Retrospectiva da Sprint (Proporcional a 3 horas) é uma chance para o Scrum Team inspecionar a
si próprio e criar um plano de melhorias para a próxima sprint. Ela inspeciona como foi a última
sprint em relação às pessoas, às relações, aos processos e às ferramentas. Pode identificar e ordenar
os itens que se tornaram potenciais de melhorias e cria um plano para implementar melhorias no
trabalho.
O Scrum Master garante que o evento seja positivo e produtivo. O Scrum Master ensina todos
a manter o evento dentro do time-box. O Scrum Master participa da reunião como um membro
auxiliar do time devido a sua responsabilidade pelo processo Scrum. O Scrum Master encoraja o
Time Scrum a melhorar, dentro do processo do framework do Scrum, seu processo de
desenvolvimento e suas práticas para torná-lo mais efetivo e agradável para a próxima Sprint.
Durante cada Retrospectiva da Sprint, o Time Scrum planeja formas de aumentar a qualidade do
produto melhorando o processo de trabalho ou adaptando a definição de “Pronto”, se apropriado
e sem entrar em conflito com os padrões do produto ou organização. Ao final da Retrospectiva da
Sprint, o Time Scrum deverá ter identificado melhorias que serão implementadas na próxima
Sprint.
A implementação destas melhorias na próxima Sprint é a forma de adaptação à inspeção que o

Time Scrum faz a si próprio. Apesar de que melhorias podem ser implementadas a qualquer
momento, a Retrospectiva da Sprint fornece uma oportunidade formal focada em inspeção e
adaptação. Fechou? Antes disso, vamos falar de um evento não-oficial, mas que geralmente é
realizado: Reunião de Visão! O que é isso, professor?
Trata-se do momento que visa estabelecer um ponto no processo em que o Product Owner deve
expor os detalhes do produto a ser construído. A saída dessa reunião deve ser uma visão sobre o
produto, isto é, representa como os clientes, usuários finais, gerentes, stakeholders,
executivos, entre outros, visualizam o resultado final do produto que será criado. Para tal, pode-
se utilizar diversas técnicas como: Product Vision Box, Product RoadMap ou Elevator Pitch Sentence.
Vamos ver um pouco dessa última técnica! Geoffrey Moore, no seu livro Crossing the Chasm,
apresenta um modelo interessante para a Visão do Produto, o chamado “Teste do Elevador”. A
ideia é que seja possível explicar o que é o produto durante a subida de um elevador, ou seja,
em um tempo bastante curto. Adaptado por Jim Highsmith, esse modelo tem o formato
apresentado na imagem da página seguinte.
Um exemplo de visão sobre um produto de turismo poderia ser: “Para turistas usuários de
smartphone que desejam aproveitar melhor seus locais de destino, o MyTrip é um aplicativo móvel de
viagens que sugere roteiros diários flexíveis de acordo com seu perfil de viajante. Ao contrário de guias
de viagens com roteiros predefinidos e burocráticos, nosso produto elabora trajetos personalizados e
adaptáveis”.
49

Aula 04
Lembremos que a visão do produto, de forma geral, deve permanecer estável durante todo o
projeto. Ela é criada, gerenciada e compartilhada pelo Product Owner, que garante que o Product
Backlog esteja sempre alinhado a ela. No entanto, as partes interessadas relevantes podem estar
diretamente envolvidas no refinamento dessa visão. Há outra cerimônia não-oficial (apesar de
muito comum) chamada Release Planning Meeting. O que seria isso?
Nós vimos que ao final da sprint, a equipe entrega um incremento do produto potencialmente
funcional, isto é, tem o potencial de entrar em produção. Ora, muitas vezes é desejável esperar
algumas sprints até juntas todas as funcionalidades e entregar uma release (conjunto de
funcionalidades). Essa cerimônia serve para planejar como será essa release. Isso é muito
importante, porque vocês devem saber a criticidade de colocar algo em produção.
É comum ter várias restrições, preocupações e dependências, como datas importantes, itens
contratuais, logística, entre outros. Dessa forma, a equipe precisa planejar suas entregar várias
sprints à frente. Por fim, é salutar enfatizar que o ciclo de vida do nosso framework é baseado em
três fases principais:
1. Pré-Planejamento (Pre-game Phase)
Define o sistema sendo desenvolvido. Cria-se o Product Backlog, que contém os requisitos atuais e
informações sobre o planejamento do projeto. Cria-se também uma arquitetura de alto nível.
2. Desenvolvimento (Game Phase)
50

Aula 04
O sistema é desenvolvido em sprints, por meio de uma abordagem iterativa. A cada sprint, novas
funcionalidades são adicionadas de modo tradicional, i.e., análise, projeto, implementação, etc.
3. Pós-Planejamento (Post-game Phase)
Após o desenvolvimento, são feitas reuniões para analisar o progresso do projeto e demonstrar o
software para os clientes. Aqui ocorrem as etapas de integração, testes finais e documentação.
A Retrospectiva da Sprint é uma oportunidade para o Time Scrum inspecionar a si próprio e criar um plano para melhorias
a serem aplicadas na próxima Sprint. A Retrospectiva da Sprint ocorre depois da Revisão da Sprint e antes do
planejamento da próxima Sprint. Esta é uma reunião de no máximo três horas para uma Sprint de um mês. Para Sprint
menores, este evento é usualmente menor. O Scrum Master garante que o evento ocorra e que os participantes entendam
seu propósito.
O Scrum Master garante que o evento seja positivo e produtivo. O Scrum Master ensina todos a manter o evento dentro
do time-box. O Scrum Master participa da reunião como um membro auxiliar do time devido a sua responsabilidade pelo
processo Scrum. O propósito da Retrospectiva da Sprint é:
• Inspecionar como a última Sprint foi em relação às pessoas, aos relacionamentos, aos processos e às ferramentas;
• Identificar e ordenar os principais itens que foram bem e as potenciais melhorias; e,
• Criar um plano para implementar melhorias no modo que o Time Scrum faz seu trabalho;
O Scrum Master encoraja o Time Scrum a melhorar, dentro do processo do framework do Scrum, seu processo de
desenvolvimento e suas práticas para torná-lo mais efetivo e agradável para a próxima Sprint. Durante cada
Retrospectiva da Sprint, o Time Scrum planeja formas de aumentar a qualidade do produto melhorando o processo de
trabalho ou adaptando a definição de “Pronto”, se apropriado e sem entrar em conflito com os padrões do produto ou
organização.
Ao final da Retrospectiva da Sprint, o Time Scrum deverá ter identificado melhorias que serão implementadas na próxima
Sprint. A implementação destas melhorias na próxima Sprint é a forma de adaptação à inspeção que o Time Scrum faz a
si próprio. Apesar de que melhorias podem ser implementadas a qualquer momento, a Retrospectiva da Sprint fornece
uma oportunidade formal focada em inspeção e adaptação.
O propósito da Sprint Retrospective é planejar maneiras de aumentar a qualidade e a eficácia. O Scrum Team inspeciona
como foi a última Sprint em relação a indivíduos, interações, processos, ferramentas e sua Definição de Pronto. Os
elementos inspecionados geralmente variam com o domínio de trabalho. As suposições que os desviaram são
identificadas e suas origens exploradas. O Scrum Team discute o que deu certo durante a Sprint, quais problemas
encontraram e como esses problemas foram (ou não) resolvidos.
O Scrum Team identifica as mudanças mais úteis para melhorar sua eficácia. As melhorias mais impactantes são
endereçadas o mais rápido possível. Essas podem até ser adicionadas ao Sprint Backlog para a próxima Sprint. A Sprint
Retrospective conclui a Sprint. É limitada pelo Timebox de no máximo três horas para uma Sprint de um mês. Para Sprints
mais curtas, o evento geralmente é mais curto.
51

Aula 04
(SINESP – 2015) No Scrum, o evento que ocorre no final da sprint que serve para a equipe
examinar a sprint passada e planejar melhorias é conhecido como:
a) retrospectiva da sprint.
b) avaliação da sprint.
c) lições aprendidas da sprint.
d) melhoria da sprint.
e) fechamento da sprint.
_______________________
Comentários: o evento que ocorre no final da sprint que serve para a equipe examinar a sprint passada e planejar melhorias é a
retrospectiva da sprint (Letra A).
Vamos fazer um resumão de tudo agora! Notem na imagem que tudo começa no canto superior
esquerdo. O Product Owner define o Product Backlog, isto é, uma lista com tudo que ele deseja
que tenha em seu projeto. Então, os integrantes da Equipe Scrum fazem a Reunião de
Planejamento e constroem a Sprint Backlog. O trabalho da sprint segue com reuniões diárias
realizadas pelos desenvolvedores e atualizando os artefatos.
Ao final do sprint, há uma Revisão da Sprint – responsável por analisar se o incremento do produto
entregue realmente satisfaz às expectativas dos clientes. Em seguida, realiza-se a última cerimônia,
também conhecida como Retrospectiva da Sprint! Esse evento é responsável por analisar se o
processo foi efetivamente utilizado e se há alguma sugestão de melhoria. Por fim, essas melhorias
servem de entrada para a próxima reunião de planejamento. Fechou?
52

Aula 04
Novidades do Scrum
IMPORTANTE
O Scrum passou por melhorias desde sua versão inicial – acrescentando, modificando ou retirando
conceitos. No entanto, infelizmente as bancas de concurso raramente explicitam no edital qual
versão será cobrada em prova. Dessa forma, professores e alunos ficam vendidos. De toda forma,
essa aula foi feita baseada no Scrum 2013 com atualizações do Scrum 2017 e Scrum 2020, mas
seguem abaixo resumidamente as melhorias da última versão.
Scrum 2020
SIMPLIFICAÇÃO GERAL DO GUIA
O Scrum 2020 coloca ênfase na eliminação de informações redundantes e complexas – assim como
a remoção de qualquer referência remanescente em relação a tecnologia da informação (Ex: testes,
sistemas, design, requerimento, etc), uma vez que ele pode ser utilizado para projetos de quaisquer
áreas. O Guia Scrum agora possui menos do que 13 páginas e apresenta uma linguagem mais
simplificada e compreensível para outros públicos.
Definição de scrum
Enquanto o Scrum 2017 se referia apenas a pessoas para resolução de problemas complexos, a nova
versão trata também de times e organizações. Vejamos:
Scrum é um framework leve que ajuda pessoas, times e organizações a gerar valor por meio de soluções
adaptativas para problemas complexos.
Fim das três perguntas
Removeram as famosas três perguntas da Reunião Diária, que eram um exemplo de perguntas que
poderiam ser utilizadas pelo time, mas que para muitos virou regra para dar o status do projeto. O
motivo da retirada foi que as perguntas nunca foram obrigatórias e muito menos uma forte
sugestão para que guiassem todas as reuniões diárias – era simplesmente um exemplo que os
autores utilizaram e que passou a ser visto e aplicado como regra.
Por essa razão, eles resolveram remover as perguntas por completo para que não fossem mais
interpretadas incorretamente e gerassem uma disfunção nos Times Scrum.
53

Aula 04
Artefatos e compromissos
Surgiram novas definições para artefatos, incluindo o conceito de compromissos conforme

podemos ver a seguir:
Os artefatos do Scrum representam trabalho ou valor. Eles são projetados para maximizar a transparência das
principais informações. Assim, todos os que os inspecionam têm a mesma base para adaptação. Cada artefato
contém um compromisso para garantir que ele forneça informações que aumentem a transparência e o foco
contra o qual o progresso pode ser medido:
– Para o Product Backlog, é a meta do produto;

– Para o Sprint Backlog, é a meta da sprint;
– Para o incremento, é a Definição de Pronto.
Esses compromissos existem para reforçar o empirismo e os valores Scrum para o Scrum Team, e seus
stakeholders.
A Meta da Sprint e a Definição de Pronto já existiam na versão do Guia Scrum 2017, mas era confuso
e não se sabia ao certo se eram artefatos ou não. Nesta versão, os autores fizeram questão de
reforçar que Meta da Sprint, Definição de Pronto e Meta do Produto são compromissos que o Time
Scrum deve ter em relação aos seus trabalhos e as suas entregas a fim de trazer transparência em
direção ao progresso de cada de artefato e do produto como um todo.
Compromisso: Meta do Produto – descreve um estado futuro do produto que pode servir como um alvo para o
Scrum Team planejar. A Meta do produto está no Product Backlog. O restante do Product Backlog emerge para
definir “o que” cumprirá a Meta do Produto.
Um produto é um veículo para entregar valor. Tem um limite claro, stakeholders conhecidos, usuários ou clientes
bem definidos. Um produto pode ser um serviço, um produto físico ou algo mais abstrato. A Meta do Produto é o
objetivo de longo prazo para o Scrum Team. Eles devem cumprir (ou abandonar) um objetivo antes de assumir o
próximo.
Compromisso: Meta da Sprint – é o único objetivo da Sprint. Embora a Meta da Sprint seja um compromisso dos
desenvolvedores, esta fornece flexibilidade em termos do trabalho exato necessário para alcançá-la.
A Meta da Sprint também cria coerência e foco, encorajando o Scrum Team a trabalhar junto ao invés de
iniciativas separadas. A Meta da Sprint é criada durante o evento Sprint Planning e então adicionada ao Sprint
Backlog. Conforme os desenvolvedores trabalham durante a Sprint, eles mantêm a Meta da Sprint em mente. Se
o trabalho acabar sendo diferente do que eles esperavam, eles colaboram com o Product Owner para negociar o
escopo do Sprint Backlog dentro da Sprint sem afetar a Meta da Sprint.
Compromisso: Definição de Pronto – é uma descrição formal do estado do Incremento quando ela atende às
medidas de qualidade exigidas para o produto. No momento em que um item do Product Backlog atende a
Definição de Pronto, um incremento nasce.
A Definição de Pronto cria transparência ao fornecer a todos um entendimento compartilhado de qual trabalho
foi concluído como parte do Incremento. Se um item do Product Backlog não atender à Definição de Pronto, ele
não poderá ser liberado ou mesmo apresentado na Sprint Review. Em vez disso, ele retorna ao Product Backlog
54

Aula 04
para consideração futura. Se a Definição de Pronto para um incremento faz parte dos padrões da organização,
todos os Scrum Teams devem segui-la como mínimo.
Se não for um padrão organizacional, o Scrum Team deve criar uma Definição de Pronto apropriada para o
produto. Os desenvolvedores devem estar em conformidade com a Definição de Pronto. Se houver vários Scrum
Teams trabalhando juntos em um produto, eles devem definir e cumprir mutuamente a mesma Definição de
Pronto.
Remoção do termo ‘time de desenvolvimento’
A presença de um Time de Desenvolvimento passava a impressão de existir um sub-time no Time

Scrum. Foi substituído pela responsabilidade Desenvolvedor. Isso reforça a ideia de termos apenas
um único time: o Time Scrum, formado pelo Scrum Master, o Product Owner e os Desenvolvedores
– seus objetivos devem ser o mesmo.
==f219==
A mudança não é apenas semântica: ao remover o conceito de sub-time dentro da equipe e deixar
claro que todas essas pessoas pertencem ao mesmo time, o Time Scrum, isso cria um compromisso
mais forte entre todos para a entrega da Meta da Sprint. O Time Scrum é apenas uma equipe com
três responsabilidades diferentes.
A unidade fundamental do Scrum é um pequeno time de pessoas, um Scrum Team. O Scrum Team consiste em
um Scrum Master, um Product owner e Developers. Dentro de um Scrum Team, não há sub-times ou hierarquias.
É uma unidade coesa de profissionais focados em um objetivo de cada vez, a Meta do Produto.
Tamanho da equipe
Na versão do Guia Scrum 2017, estava descrito que o Time de Desenvolvimento deveria idealmente
ser composto por 3 a 9 integrantes. Com o objetivo de se tornar ainda menos prescritivo, agora não
há tamanho mínimo ou máximo. No entanto, o Scrum Guide comenta que o Scrum Team
normalmente tem 10 ou menos integrantes – incluindo na conta o Scrum Master e o Product
Owner.
O Scrum Team é pequeno o suficiente para permanecer ágil e grande o suficiente para concluir um trabalho
significativo dentro de uma Sprint, normalmente 10 ou menos pessoas. Em geral, descobrimos que times menores
se comunicam melhor e são mais produtivos. Se os Scrum Teams se tornarem muito grandes, eles devem
considerar a reorganização em vários Scrum Teams coesos, cada um focado no mesmo produto. Portanto, eles
devem compartilhar o mesma meta do produto, Product Backlog e Product Owner.
“Por que” do Planejamento da sprint
A Sprint Planning trazia os tópicos “O que” e “Como” e, na versão 2020, um novo tópico foi o
adicionado: “Por que”. Logo, deve ser respondido “Por que esta Sprint é valiosa?” e “Por que esta
deve ser realizada?”. Muitas vezes, sabemos o que fazer, como fazer, mas não sabemos por que
fazer – o que acaba gerando produtos inúteis e promovendo o desperdício (o que não é preconizado
pelo lean thinking) por toda a organização.
55

Aula 04
Auto-organizável  auto-gerenciável
Houve uma mudança de termos: saiu o “auto-0rganizável” e entrou o “auto-gerenciável”. Neste

ponto, os autores do guia oficial quiseram passar uma forte mensagem em relação a autonomia e
responsabilidades do Scrum Team no sentido de que ele não é só responsável por escolher quem e
como farão o trabalho da sprint, mas devem ser auto-gerenciados de modo a escolher quem, como
e no que trabalhar.
O Scrum Team deve ter as responsabilidades compartilhadas de selecionar, entender e priorizar no

que vão trabalhar, quem irá trabalhar e como irão trabalhar para cumprir os compromissos.
Product owner compartilhado
Um incremento de texto importante foi o que o Product Owner pode ser compartilhado com
múltiplos times. Se os Scrum Teams se tornarem muito grandes, eles devem considerar a
reorganização em vários times menores e coesos, cada um focado no mesmo produto e devem
compartilhar a mesma Meta do Produto, Product Backlog e Product Owner. No entanto, apenas
um PO deve ser considerado, além do mesmo Backlog do Produto e Meta do Produto.
56

Aula 04
RESUMO
Scrum: um framework dentro do qual pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto
produtiva e criativamente entregam produtos com o mais alto valor possível. Scrum é: leve, simples de entender e difícil
de dominar.
Scrum é um framework leve que ajuda pessoas, times e organizações a gerar valor por meio de soluções adaptativas para
problemas complexos.
1º PILAR
2º PILAR
3º PILAR
TRANSPARÊNCIA INSPEÇÃO ADAPTAÇÃO
PILARES DESCRIÇÃO
Todo trabalho deve ser claramente definido e conhecido por todas as partes
TRANSPARÊNCIA
envolvidas no projeto.
Todo trabalho deve ser inspecionado com a frequência necessária para garantir a
INSPEÇÃO
qualidade do produto.
O projeto deve ser capaz de se adaptar o projeto às necessidades de negócio.
ADAPTAÇÃO
57

Aula 04
Valores DESCRIÇÃO
Os integrantes de um projeto precisam ter coragem para fazer a coisa certa e
CORAGEM trabalharem juntos removendo impedimentos, buscando soluções.
Os integrantes de um projeto precisam focar no trabalho durante a sprint e nas metas
FOCO designadas – time disperso perde produtividade e não alcança os objetivos.
Os integrantes se comprometem com o trabalho que se responsabilizou em fazer,
COMPROMETIMENTO
envolvendo-se e não abandonando pela metade ou entregando sem qualidade.
Os integrantes se respeitam entre si a fim de manter a colaboração, a integração e o
RESPEITO bom ambiente de trabalho.
Os integrantes devem poder ser francos, expor ideias e propostas mesmo que elas não
ABERTURA
sejam proveitosas. Momentos de debates, discussões e sugestões são ideais.
DEVELOPMENT TEAM DEVELOPERS

==f219==
( EQUIPE DE DESENVOLVIMENTO ) ( DESENVOLVEDORES )


( EQUIPE SCRUM )
( EQUIPE SCRUM )
PRODUCT OWNER PRODUCT OWNER
( DONO DO PRODUTO ) ( DONO DO PRODUTO )
SCRUM MASTER SCRUM MASTER

( MESTRE SCRUM ) ( MESTRE SCRUM )
Responsável pela gestão de pessoas e gestão do processo.
Ele deve garantir que o Scrum seja entendido e aplicado. O Scrum Master faz isso para garantir que a
Equipe Scrum adere à teoria, práticas e regras do Scrum.
O Scrum Master ajuda aqueles que estão fora da Equipe Scrum a entender quais as suas interações com
a Equipe Scrum são úteis e quais não são.
O Scrum Master ajuda todos a mudarem estas interações para maximizar o valor criado pela Equipe
Scrum.
Ele é responsável por orientar o Product Owner na criação e ordenação do Product Backlog.
scrum master (sm)
RESPONSABILIDADES
Ele é responsável por garantir que as regras do Scrum estejam sendo cumpridas e seus valores estejam
sendo seguidos.
Ele é responsável por ajudar a remover impedimentos que o time enfrente, fazendo isso sem o uso de
qualquer autoridade.
Ele utiliza técnicas de facilitação e coaching para que os membros do time consigam visualizar os
problemas e encontrem a melhor solução.
Durante eventos, ele é responsável por fazer com que a reunião flua adequadamente, utilizando técnicas
de facilitação, embora não seja o responsável pela condução.
Ele ajuda a treinar os desenvolvedores em autogerenciamento e interdisciplinaridade.
Ele treina os desenvolvedores em ambientes organizacionais nos quais o Scrum não é totalmente
adotado e compreendido.
Ele ensina a Equipe Scrum a criar itens do Product Backlog de forma clara e concisa.
58

Aula 04
Ele comunica claramente a visão, objetivo e itens do Product Backlog para os desenvolvedores.
Responsável pela micro-gestão e pela criação do produto.
Eles são auto-organizados. Ninguém (nem mesmo o SM) diz aos desenvolvedores como transformar o
Product Backlog em incrementos de funcionalidades potencialmente utilizáveis.
RESPONSABILIDADES
Times de Desenvolvimento são multifuncionais, possuindo todas as habilidades necessárias, enquanto

desenvolvedores
equipe, para criar o incremento do Produto.

O Scrum não reconhece títulos específicos para os desenvolvedores, independentemente do trabalho
que está sendo realizado pela pessoa;
Individualmente, os desenvolvedores podem ter habilidades especializadas, mas a responsabilidade
pertence aos desenvolvedores como um todo.
Os desenvolvedores não contêm sub-times dedicados a domínios específicos de conhecimento, tais
como teste ou análise de negócios.
Os desenvolvedores são estruturados e autorizados pela organização para organizar e gerenciar seu
próprio trabalho.
Ele é responsável pela macro-gestão e pela gestão do produto.
Ele é o responsável por maximizar o valor do produto e do trabalho dos desenvolvedores, sendo o único
que pode gerenciar o Product Backlog.
Ele pode até delegar as atividades de gerenciamento para os desenvolvedores, mas ainda será
PRODUCT OWNER (PO)
considerado o responsável pelos trabalhos.

RESPONSABILIDADES
Ele é responsável por priorizar/ordenar os itens do Product Backlog e seleciona aqueles que serão
implementados.
Ele é responsável por garantir o ROI (Return On Investment ou Retorno sobre Investimento).
Ele é responsável por expressar claramente os itens do Product Backlog.
Ele é responsável por garantir que o Backlog do Produto seja visível, transparente, claro para todos, e
mostrar o que a Equipe Scrum vai trabalhar a seguir.
Ele é responsável por garantir que os desenvolvedores entendam os itens do Product Backlog no nível
necessário.
Trata-se de uma lista ordenada (por valor, risco, prioridade, entre outros) de requisitos
PRODUCT BACKLOG ou funcionalidades que o produto deve conter criada pela Equipe Scrum e gerenciada
pelo Product Owner.
Trata-se de conjunto de itens selecionados do Product Backlog, mais a meta da sprint
SPRINT BACKLOG e mais um plano de ação para entregar um incremento potencialmente usável – é
criado e gerenciado pelos desenvolvedores.
Trata-se da é da soma de todos os itens do Backlog do Produto completados durante
SPRINT REVIEW a Sprint e o valor dos incrementos de todas as sprints anteriores – sendo validado como
“pronto”.
59

Aula 04
Conjunto de critérios que indicam que já existem informações suficientes para um

DEFINIÇÃO DE ready
requisito começar a ser desenvolvido.
Conjunto de critérios que indicam que uma determinada história de usuário atende a
DEFINIÇÃO DE done
todos os requisitos de aceitação para se tornar um incremento.
Reunião dividida em duas partes que possui duração de até 8 horas. Na primeira parte,
a equipe seleciona, alinha e detalha os itens que vão ser desenvolvidos na próxima
SPRINT PLANNING
sprint. Na segunda parte, cada item é estimado e decomposto nas tarefas necessárias
para produzir as entregas.
Reunião diária para alinhar a comunicação do projeto, inspecionar o progresso para a
DAILY SCRUM meta, identificar impedimentos e adaptar o backlog da sprint, se necessário. Não pode
ter mais que 15 minutos de duração, ocorrendo sempre no mesmo local e horário.
Reunião de até 4h de duração realizada ao final de cada sprint para apresentar ao
Product Owner as funcionalidades implementadas para que ele possa validá-las e
Sprint review eventualmente adaptar futuras modificações. Trata-se de um evento informal para
apresentação do incremento e colaboração sobre os próprios passos.
Reunião de até 3h de duração realizada após a Sprint Review. No entanto, em vez de
validar o produto, a equipe busca revisar e validar o processo executado para gerar as
SPRINT RETROSPECTIVE funcionalidades. A ideia é planejar maneiras de aumentar a qualidade e efetividade do
processo.
PARA MAIS DICAS: www.instagram.com/professordiegocarvalho
60

Aula 04
QUESTÕES COMENTADAS – CESPE
1. (CESPE / Petrobrás - 2022) O conceito de sprint tem sua origem no RUP a partir da execução
das fases, cada uma delas com seu marco; cada ciclo no RUP tinha uma sprint considerada,
assim como um projeto curto.
Comentários:
O conceito de sprint tem origem no SCRUM, e não no RUP.
Gabarito: Errado
2. (CESPE / Petrobrás - 2022) No Scrum, todo o trabalho necessário para atingir a meta do
produto está embutido nas sprints, inclusive as daily scrums e as sprint retrospective.
Comentários:
Uma Sprint trata-se de uma unidade de trabalho que satisfaz um requisito de negócio. Em outras
palavras, é um ciclo completo de desenvolvimento de um incremento potencialmente entregável
de um produto. Como cada Sprint contém uma meta do que deve ser desenvolvido, o conjunto das
sprints trata-se da meta do produto. Ademais, as daily scrums e as sprint restropectives também
fazem parte das sprints. A primeira é uma reunião de 15 minutos e a segunda uma reunião mais
longa, de 3 horas.
Gabarito: Correto
3. (CESPE / Petrobrás - 2022) O Scrum usa um conjunto de “padrões de processo de software”,

que são adequados para projetos com prazos apertados e requisitos que mudam
frequentemente.
Comentários:
De acordo com Pressman, o Scrum enfatiza o uso de um conjunto de padrões de processos de

software que provaram ser eficazes para projetos com prazos de entrega apertados, requisitos
mutáveis e urgência do negócio. Lembrem-se que o Scrum é um framework para gerenciar
projetos, ele é capaz de gerenciar qualquer projeto que vise aumentar a agilidade e qualidade da
sua execução.
Gabarito: Correto
4. (CESPE / FUNPRESP-EXE - 2022) Na fase de desenvolvimento do Scrum, os requisitos são

escritos no product backlog.
61

Aula 04
Comentários:
Na verdade, o product backlog é definido na fase de pré-planejamento.
Gabarito: Errado
5. (CESPE / FUNPRESP-EXE - 2022) No desenvolvimento de software ágil com base em

prototipação, é essencial que todos os requisitos do sistema tenham sido definidos
previamente.
Comentários:
Opa... os requisitos de um sistema podem mudar a qualquer momento, eles estão em constante
evolução. De acordo com o Guia Scrum, requisitos nunca param de mudar, então o Backlog do
Produto é um artefato vivo.
Gabarito: Errado
6. (CESPE / FUNPRESP-EXE - 2022) As fases do processo tradicional de engenharia de software,

como análise, projeto, implementação e testes, podem estar representadas dentro de uma
sprint do Scrum.
Comentários:
Perfeito! Todas as fases podem ser representadas dentro de uma Sprint.
Gabarito: Correto
7. (CESPE / SEFAZ-SE – 2022) De acordo com a metodologia Scrum, a reunião em que são
apresentados os pontos positivos e negativos da sprint é a:
a) sprint planning.
b) retrospective.
c) daily.
d) backlog refinement.
e) sprint review.
Comentários:
A reunião em que são apresentados os pontos positivos e negativos da sprint, isto é, do processo
(e, não, do produto) é a sprint retrospective.
Gabarito: Letra B
62

Aula 04
8. (CESPE / TJ-RJ - 2021) Na metodologia Scrum, o rito que tem como finalidade refletir sobre o
andamento das atividades na sprint é conhecido como:
a) review.
b) daily.
c) backlog.
d) retrospectiv.
e) planning.
Comentários:
Isso ocorre na etapa de Retrospectiva da Sprint (que tem duração aproximada de 3 horas), em que
o Scrum Team inspeciona a si mesmo e cria um plano de melhoria para a próxima Sprint. Em suma,
é feita uma inspeção sobre como tudo ocorreu na última sprint em relação às pessoas, relações,
processos e às ferramentas.
Gabarito: Letra D
9. (CESPE / TJ-RJ - 2021) A metodologia Scrum estabelece vários papéis a serem desempenhados
pelo time; o responsável por controlar o progresso do desenvolvimento do projeto e ser o
guardião dos ritos é o:
a) product owner.
b) scrum master.
c) patrocinador do projeto.
d) stakeholder.
e) gerente do time de desenvolvimento.
Comentários:
O Scrum Master é o responsável por garantir que a metodologia Scrum seja entendida e aplicada.
Além disso, ele é responsável pela eficácia do Scrum Team. Por fim, o gráfico de Burndown é uma
maneira de medir o progresso de uma Sprint no Scrum.
Gabarito: Letra B
10. (CESPE / TELEBRÁS - 2021) Ao se usar a metodologia Scrum, recomenda-se que, ao final do
sprint, ocorra uma reunião (sprint review) em que a equipe Scrum e todas as partes interessadas
se encontrem, preferencialmente de modo informal, com os objetivos de validar as entregas da
equipe Scrum e verificar se os critérios estabelecidos no planejamento foram executados.
Comentários:
63

Aula 04
Corretíssimo! A Revisão da Sprint (sprint review) ocorre ao final de uma sprint, ela é utilizada para
demonstrar as novas funcionalidades desenvolvidas durante a sprint e seu principal motivo é o de
inspecionar o que os desenvolvedores produziram e colher opiniões, de modo que o foco é
aprimorar o produto. Além disso, essa reunião deve ocorrer – preferencialmente - de maneira
informal.
Gabarito: Correto
11. (CESPE / TELEBRÁS - 2021) Em Scrum, na Sprint planning, o product owner seleciona os itens
do product backlog para incluir na Sprint e determina detalhadamente aos developers a forma
de trabalho a ser aplicada para viabilizar a criação de um incremento de valor.
Comentários:
O Sprint Planning é o planejamento dos trabalhos a serem realizados na Sprint. Esse planejamento
é realizado por toda a Equipe Scrum. O Product Owner não seleciona os itens que serão inclusos na
Sprint, ele apenas dá um valor de negócio para cada item e apresenta aos desenvolvedores, que
decidirão a quantidade de itens do backlog que serão realizados na Sprint.
Gabarito: Errado
12. (CESPE / TELEBRÁS - 2021) Para o método Scrum, o Product Backlog consiste em uma lista de
necessidades do cliente, ou seja, uma lista com as funcionalidades desejadas para um produto
Comentários:
O Product Backlog é uma lista ordenada (por valor, risco, prioridade, entre outros) de requisitos ou
funcionalidades que o produto deve conter criada pela Equipe Scrum e gerenciada pelo Product
Owner.
Gabarito: Correto
13. (CESPE / TELEBRÁS - 2021) Eliminar desperdício, amplificar o aprendizado e decidir o mais
tarde possível são alguns dos princípios do método Lean.
Comentários:
O método o Lean Thinking é uma espécie de estrutura mental (mindset) que permite reduzir o
desperdício e se concentrar no essencial. Ele é composto por sete princípios, entre eles está: a
amplificação do aprendizado que se trata de priorizar a comunicação e o feedback contínuos entre
equipes e usuários durante o desenvolvimento; além disso, também temos o princípio que trata-se
de adiar decisões, desse modo, deixa-se as decisões e comprometimentos para o último momento
possível, permitindo coletar informações e ter experiências para fortalecer a tomada de decisão.
64

Aula 04
Gabarito: Correto
14. (CESPE / TCE-RJ – 2021) O SCRUM é composto por quatro atividades: planeamento, projeto,
codificação e testes, as quais normalmente são repetidas iteração a iteração.
Comentários:
Scrum é composto por Planejamento da Sprint, Execução da Sprint, Reunião Diária, Revisão da
Sprint e Retrospectiva da Sprint. As fases apresentadas na questão são de outra metodologia ágil
também conhecida como XP (Extreme Programming).
Gabarito: Errado
15. (CESPE / CODEVASF – 2021) Na metodologia Scrum, é feita na sprint planning a seleção dos
itens do backlog que serão desenvolvidos durante a sprint; depois de fechado o seu escopo,
a sprint não poderá mais ser alterada.
Comentários:
O Planejamento da Sprint é a cerimônia que permite selecionar itens do Backlog do Produto que
serão desenvolvidos durante a execução da sprint. O problema da questão está em afirmar que,
depois de fechado o seu escopo, a sprint não poderá mais ser alterada. Na verdade, é possível
realizar alterações que não coloquem em risco a meta da sprint. Logo, discordo do gabarito da
questão veementemente.
Gabarito: Correto
16. (CESPE / SERPRO – 2021) Daily Scrum é o único momento do dia em que os developers se
reúnem para discutir detalhadamente a adaptação ou o replanejamento do trabalho da sprint.
Comentários:
Essa é uma cerimônia diária de discussão, mas desenvolvedores podem se reunir sempre que
desejarem e, não, o único.
Gabarito: Errado
17. (CESPE / APEX-BRASIL – 2021) Em Scrum, um item do Product Backlog incluído em uma Sprint
e que não atenda à Definição de Pronto:
a) será retornado ao Product Backlog para consideração futura.

b) será encaminhado com prioridade ao Sprint Backlog.
65

Aula 04
c) será liberado com ressalvas, desde que haja acordo no Scrum Team.
d) será apresentado na Sprint Review para uma segunda avaliação do Scrum Team
Comentários:
Se um item do Product Backlog não atender à Definição de Pronto, ele não poderá ser liberado ou
mesmo apresentado na Sprint Review. Em vez disso, ele retorna ao Product Backlog para
consideração futura.
Gabarito: Letra A
18. (CESPE / APEX-BRASIL – 2021) No Scrum, cada artefato tem um compromisso, para assegurar
que a informação fornecida aumente a transparência e o foco, possibilitando a mensuração do
progresso. No caso do Increment, esse compromisso é o:
a) Product Goal.
b) Sprint Goal.
c) Definition of Done.
d) Burn Down.
Comentários:
(a) Errado, esse é o compromisso do Product Backlog; (b) Errado, esse é o compromisso da Sprint
Backlog; (c) Correto, a Definition of Done é o compromisso do Increment; (d) Errado, esse não é o
compromisso de nada.
Gabarito: Letra C
19. (CESPE / Ministério da Economia – 2020) Os métodos ágeis de desenvolvimento

de software têm duas unidades principais de entrega: lançamentos e iterações.
Comentários:
De fato, lançamentos (releases) e iterações são componentes de métodos ágeis, no entanto não
vejo como se pode afirmar que são as unidades principais. Ora, são principais em que sentido? Enfim,
questão correta, mas com ressalvas...
Gabarito: Correto
20. (CESPE / Ministério da Economia – 2020) O responsável direto pelo backlog da sprint é o time
de desenvolvimento, que decide sobre as adições e(ou) remoções e os ajustes de tarefas durante
a execução da sprint; no entanto, se algum item for retirado, o dono do produto deve ser avisado
o mais breve possível.
66

Aula 04
Comentários:
De fato, o Sprint Backlog é um plano feito por e para os desenvolvedores. É uma imagem altamente
visível, em tempo real do trabalho que os desenvolvedores planejam realizar durante a Sprint para
atingir a meta da sprint. E realmente o Product Owner deve ser avisado o mais breve possível caso
algum item seja retirado – lembrando aqui do princípio da transparência.
Gabarito: Correto
21. (CESPE / Ministério da Economia – 2020) O Scrum Master é diretamente responsável por
manter e priorizar o backlog do produto, além de colaborar com o time de desenvolvimento.
Comentários:
Na verdade, essa é uma responsabilidade do Product Owner e, não, do Scrum Master. O Product
Owner é responsável pelo gerenciamento eficaz do Product Backlog, que inclui: (1) desenvolver e
comunicar explicitamente a meta do produto; (2) criar e comunicar claramente os itens do Product
Backlog; (3) ordenar os itens do Product Backlog; (4) e, garantir que o Product Backlog seja
transparente, visível e compreensível.
Gabarito: Errado
22. (CESPE / Ministério da Economia – 2020) Um dos artefatos do Scrum, o backlog do produto é
gerenciado, exclusivamente, pelo dono do produto e representa o conteúdo, a disponibilidade
e a ordenação do trabalho a ser realizado, sendo a única porta de entrada para todos os registros
de requisitos de mudança a serem realizados no produto.
Comentários:
O Backlog do Produto é uma lista ordenada de tudo que é conhecido como necessário no produto
– trata-se da única fonte de requisitos para quaisquer alterações a serem feitas no produto. O
Product Owner é responsável pelo Product Backlog, incluindo seu conteúdo, disponibilidade,
ordenação e requisitos de mudança.
Gabarito: Correto
23. (CESPE / Ministério da Economia – 2020) Sprint é o ciclo de desenvolvimento de poucas

semanas sobre o qual se estrutura o Scrum e durante o qual cabe ao scrum master manter
o sprint backlog atualizado, indicando as tarefas já concluídas e aquelas ainda por concluir.
Comentários:
67

Aula 04
Sprint é o ciclo de desenvolvimento de poucas semanas sobre o qual se estrutura o Scrum e durante
o qual cabe ao scrum master desenvolvedores manter o sprint backlog atualizado, indicando as
tarefas já concluídas e aquelas ainda por concluir.
Gabarito: Errado
24. (CESPE / Ministério da Economia – 2020) Uma forma de acompanhar a produtividade é fazer
uso de um gráfico de Burndown, no qual é possível visualizar a expectativa de produtividade
ideal do projeto e comparar com a produtividade real.
Comentários:
Perfeito! O Gráfico de Burndown torna visível a evolução diária do trabalho da equipe de

desenvolvimento, na medida em que mostra a comparação de produtividade entre o trabalho
estimado inicialmente com a quantidade restante estimada de trabalho. Dessa forma, é possível
visualizar a expectativa de produtividade ideal do projeto e comparar com a produtividade real.
Gabarito: Correto
25. (CESPE / Ministério da Economia – 2020) Backlog da sprint é diferente do backlog do produto,
já que o primeiro é um conjunto de itens selecionados a partir do segundo, sendo parte do
planejamento da equipe para entregar um incremento do produto.
Comentários:
Perfeito! O Backlog da Sprint é selecionado a partir do Backlog do Produto. Ele é composto pela
Meta da Sprint (por que), o conjunto de itens do Product Backlog selecionados para a Sprint (o que),
bem como um plano de ação para entregar o Incremento (como).
Gabarito: Correto
26. (CESPE / Ministério da Economia – 2020) As histórias são consideradas pequenos requisitos de
um projeto na perspectiva do usuário final.
Comentários:
Histórias de usuário são basicamente especificações no formato de uma ou mais frases na

linguagem de negócio ou cotidiana do usuário do sistema que captura o que um usuário faz ou
necessita fazer como parte de sua função de trabalho. Logo, podem ser consideradas como
pequenos requisitos ou solicitações de um projeto sob a perspectiva do usuário final.
Gabarito: Correto
68

Aula 04
27. (CESPE / Ministério da Economia – 2020) Pequenas partes do trabalho com a perspectiva do
patrocinador são artefatos denominados Epics.
Comentários:
Algumas vezes, as histórias de usuário são muito grandes para serem desenvolvidas em uma única
sprint. Essas histórias de usuário são chamadas de Épicos e podem ser divididas em duas ou mais
histórias de tamanho menor. Não há nenhuma relação com pequenas partes de trabalho com a
perspectiva do patrocinados – são grandes histórias de usuário sob a perspectiva do usuário.
Gabarito: Errado
28. (CESPE / Ministério da Economia – 2020) O scrum master possui autoridade para cancelar
uma sprint antes de o time-boxed da sprint terminar.
Comentários:
Na verdade, apenas o Product Owner tem autoridade para cancelar a sprint.
Gabarito: Errado
29. (CESPE / SLU-DF – 2019) Entre os processos da gestão de projetos com Scrum, as inspeções
constituem os processos mais complexos e formais e, por isso, ocorrem somente ao fim de um
ciclo de várias sprints, após a liberação de uma funcionalidade plena e o seu reconhecimento
pelo demandante.
Comentários:
De acordo com o Scrum, os usuários devem, frequentemente, inspecionar os artefatos Scrum e o

progresso em direção ao objetivo da Sprint para detectar variações indesejadas. Esta inspeção não
deve ser tão frequente que atrapalhe o objetivo dos trabalhos. As inspeções são mais benéficas
quando realizadas de forma diligente por inspetores especializados no trabalho a se verificar.
Gabarito: Errado
30. (CESPE / TCE-RO – 2019) No Scrum,
a) os times de desenvolvimento ou times Scrum são auto-organizáveis e responsáveis por

gerenciar o backlog do produto.
b) cabe ao product owner dizer ao time de desenvolvimento como transformar o backlog do

produto em incrementos operacionais para o cliente.
69

Aula 04
c) que consiste de um framework para desenvolver e manter produtos complexos, utiliza-se

uma abordagem iterativa e incremental para aperfeiçoar o controle de riscos.
d) as sprints consistem exclusivamente de reuniões diárias e do trabalho de desenvolvimento,

com duração superior a um mês.
e) após o planejamento da sprint, o backlog do produto torna-se completo, o que impede a

ocorrência de alterações posteriores.
Comentários:
(a) Errado. Times de Desenvolvimento e Time Scrum são diferentes – o primeiro está contido no
segundo. Eles são, de fato, auto-organizáveis, mas o responsável por gerenciar o backlog do
produto é Product Owner; (b) Errado, essa é uma responsabilidade do próprio Time de
Desenvolvimento; (c) Correto; (d) Errado, ela é composta de uma reunião de planejamento da
sprint, reuniões diárias, trabalho de desenvolvimento em si, uma revisão da Sprint e a retrospectiva
da Sprint – além disso, a duração é inferior a um mês; (e) Errado, um Backlog do Produto nunca está
completo e o restante da questão também não faz sentido algum.
Gabarito: Letra C
31. (CESPE / MPC-PA – 2019) A gestão ágil é uma das tendências nos projetos de desenvolvimento
de software. O backlog é um dos artefatos que auxiliam na organização do projeto, em especial
na definição das características tanto do produto (Product Backlog) quanto das Sprints (Sprint
Backlog). Com relação a esses conceitos, assinale a opção correta:
a) O backlog da Sprint não pode ser alterado após sua elaboração.

b) O backlog do produto deve ser atualizado diariamente, para refletir novos requisitos a serem
incorporados ao produto.
c) O backlog do produto é um dos produtos do backlog da Sprint .
d) O backlog da Sprint não deve ser embasado em Sprints anteriores, pois o tempo estimado
para cada Sprint depende do Product Backlog.
e) O backlog da Sprint deve prever a duração de, no máximo, um mês para cada Sprint.
Comentários:
(a) Errado, o Time de Desenvolvimento modifica o Backlog da Sprint ao longo de toda a Sprint; (b)
Errado, ele deve ser atualizado quando houver alguma necessidade de negócio; (c) Errado, ele é o
insumo do backlog da sprint; (d) Errado, o dono do produto compara o total do trabalho restante
na Reunião de Revisão da Sprint comparando o valor da Revisão da Sprint anterior, para avaliar o
progresso; (e) Correto.
Gabarito: Letra E
70

Aula 04
32. (CESPE / FUB – 2018) No método Scrum, ao final de cada período de duas a quatro semanas de
um Sprint backlog, pode-se planejar uma entrega periódica ao cliente.
Comentários:
Sprint Backlog não é um período – é um conjunto de itens selecionados para serem implementados
durante a sprint, mais o plano para transformá-los em um incremento. A redação correta da
questão seria: No método Scrum, ao final de cada período de duas a quatro semanas de um Sprint
backlog, pode-se planejar realizar uma entrega periódica ao cliente.
Gabarito: Errado
33. (CESPE / BNB – 2018) No Scrum, o Product Owner é a pessoa que define os itens que compõem
o product backlog.
Comentários:
Perfeito! O Product Owner é responsável por definir os itens que compõem o Product Backlog.
Gabarito: Correto
34. (CESPE / ANTT – 2013) Entre os vários papéis do SCRUM, o product owner é a única pessoa
responsável por gerenciar o backlog do produto, possuindo, ainda, a responsabilidade de
maximizar o valor do produto e do trabalho da equipe de desenvolvimento.
Comentários:
De acordo com Guia Scrum [Versão 2013]: “O Product Owner, ou dono do produto, é o responsável
por maximizar o valor do produto e do trabalho do Time de Desenvolvimento. Como isso é feito pode
variar amplamente através das organizações, Times Scrum e indivíduos”.
Gabarito: Correto
35. (CESPE / SERPRO – 2013) Scrum é um processo de desenvolvimento que tem como ponto de
partida um conjunto de requisitos bem definidos.
Comentários:
Conjunto de requisitos bem definidos? Não, ele tem como ponto de partida geralmente um conjunto
de requisitos pouco definidos. Ao longo das cerimônias, melhora-se a definição dos requisitos. Se
os requisitos fossem bem definidos, o Product Backlog seria quase imutável e não é isso que nós
verificamos empiricamente.
71

Aula 04
Gabarito: Errado
36. (CESPE / TCE-RO - 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.
Comentários:
Perfeito! Lembrem-se de que não há cargos, mas papéis ou responsabilidades!
Gabarito: Correto
37. (CESPE / BASA – 2012) Em um projeto gerido com a metodologia Scrum, um produto estará,
ao final de cada sprint, completamente testado, estando 100% completos todos os requisitos
do product backlog.
Comentários:
Nenhum produto jamais estará completamente testado! Não há como testar todas as
possibilidades de defeitos em um produto qualquer – é impossível! Além disso, o Product Backlog
também nunca estará completo – lembrem-se que ele é um organismo vivo.
Gabarito: Errado
38. (CESPE / BASA – 2012) O escopo, a importância e a estimativa de um Sprint do Scrum são
definidos pelo Product Owner.
Comentários:
Product Owner não trata de estimativas. Entendam: escopo e importância são definidos pelo
Product Owner, no entanto quem define as estimativas é a Equipe de Desenvolvimento [Versão
2017].
Gabarito: Errado
39. (CESPE / BASA – 2012) A metodologia Scrum, ágil para gerência de projetos, baseia-se em
ciclos de 30 dias, denominados sprints, em que se trabalha para alcançar objetivos bem
definidos.
Comentários:
Scrum é uma metodologia ágil para gerência de projetos? Sim. Baseia-se em ciclos de 30 dias
denominados sprints? Sim, o ideal seria a questão ter falado menor que um mês, mas podemos
72

Aula 04
relevar! Nas sprints, trabalha-se para alcançar objetivos bem definidos? Sim, a meta da Sprint deve
ser alcançada.
Gabarito: Correto
40. (CESPE / ECT – 2011) Para que se obtenha sucesso na utilização do Scrum, o cliente deve se
tornar parte da equipe de desenvolvimento do software, participando diretamente do processo.
Comentários:
O cliente não se torna parte da equipe de desenvolvimento. Há – sim – uma forte integração, no
entanto dizer que faz parte da equipe de desenvolvimento é um completo absurdo. No entanto,
infelizmente a banca não entendeu dessa maneira :(
Gabarito: Correto
41. (CESPE / MEC – 2011) O framework scrum engloba conceitos como times scrum, eventos com
duração fixa (time-boxes), artefatos e regras. São exemplos de eventos que têm duração fixa: a
reunião de planejamento da versão para entrega, a sprint, a reunião diária, a revisão da sprint e
a retrospectiva da sprint.
Comentários:
Questão correta, porém peca em afirmar que se trata de um evento com duração fixa. Por que,
professor? Porque o conceito de time-box é aquilo que tem uma duração máxima fixa (Ex: Sprint <=
30 dias). Logo, eu entendo que caberia recurso nessa questão.
Gabarito: Correto
42. (CESPE / MEC 2011) Produto da metodologia Scrum, o documento product backlog contém os
requisitos definidos a partir da visão do cliente e é utilizado novamente no final do sprint para
revisão ou modificações dos requisitos inicialmente definidos.
Comentários:
Perfeito! A Sprint Backlog é derivada do Product Backlog, que é derivado do Documento de Visão.
No final da Sprint, durante a cerimônia de Revisão da Sprint, é verificado se o que foi feito está de
acordo com o que foi previamente definido.
Gabarito: Correto
43. (CESPE / ABIN – 2010) 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
73

Aula 04
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.
Comentários:
Não é necessariamente para um software. Ele pode alterá-la a qualquer momento, desde que a
alteração não coloque em risco a meta da sprint. Por fim, são estruturas similares em qual sentido?
Ambos são listas, mas um é derivado do outro: Product Backlog é uma lista de funcionalidades (alto
nível) e a Sprint Backlog é um conjunto de tarefas que devem ser feitas para entregar um
incremento potencialmente entregável (baixo nível).
Gabarito: Errado
74

Aula 04
QUESTÕES COMENTADAS – FCC
44.(FCC / SEFAZ-AP – 2022) No modelo ágil de gestão de projetos Scrum, um dos conceitos mais
importantes é o:
a) product backlog, um diagrama que mostra a quantidade de trabalho a fazer e a quantidade

feita ao longo do tempo.
b) daily sprint meeting, uma reunião de cerca de uma hora para se obter ideias para solução de
problemas encontrados no projeto.
c) sprint, que consiste em um ciclo de desenvolvimento que, em geral, vai de duas semanas a um
mês.
d) pair programming, prática que consiste na programação realizada por duas pessoas em cada
computador.
e) test driven development, prática que consiste em definir e implementar os testes de unidade
antes da programação.
Comentários:
(a) Errado, a questão trata do Gráfico de Burndown; (b) Errado, a descrição se aproxima mais da
Sprint Retrospective e ela dura um máximo de três horas; (c) Correto, elas são eventos de um mês
ou menos em que ideias se tornam efetivamente valor para o cliente; (d) Errado, são duas pessoas
em um único computador e isso não é uma prática preconizada pelo Scrum; (e) Errado, isso também
não é uma prática preconizada pelo Scrum.
Gabarito: Letra C
45. (FCC / TRF - 3ª REGIÃO – 2019) SCRUM atende aos princípios do Manifesto Ágil porque:
a) pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o

projeto.
b) não aceita mudanças nos requisitos durante o desenvolvimento e por isso as entregas são
mais ágeis.
c) as entregas ocorrem sempre no prazo, nunca adiantadas ou atrasadas.
d) mais importante que a motivação dos desenvolvedores é a disciplina gerencial imposta que
organiza e agiliza o desenvolvimento.
e) não admite a comunicação direta entre os desenvolvedores, pessoalmente. Isso só pode ser
feito por intermédio de um gerente ou coordenador.
75

Aula 04
Comentários:
(a) Correto, indivíduos e interações valorizam mais processos e ferramentas; (b) Errado, ele aceita
mudanças nos requisitos; (c) Errado, entregas podem ser adiadas ou atrasadas; (d) Errado,
indivíduos são mais valorizados do que processos; (e) Errado, a comunicação direta ocorre
frequentemente.
Gabarito: Letra A
46.(FCC / TRF - 3ª REGIÃO – 2019) A Reunião Diária do Scrum é:
a) executada no final da Sprint para inspecionar o incremento e adaptar o Backlog do Produto,

se necessário.
b) um time-boxed de 15 minutos, durante o qual um “Pronto”, versão incremental
potencialmente utilizável do produto, é criado.
c) uma oportunidade para o Time Scrum inspecionar a si próprio e criar um plano para melhorias
a serem aplicadas na próxima Sprint.
d) um time-boxed de 15 minutos, para que o Time de Desenvolvimento possa sincronizar as
atividades e criar um plano para as próximas 24 horas.
e) um time-boxed de 60 minutos, durante o qual os produtos de uma Sprint são definidos.
Comentários:
(a) Errado, essa seria a Revisão da Sprint; (b) Errado, ela realmente dura 15 minutos, mas não busca
criar uma versão potencialmente utilizável do produto; (c) Errado, essa seria a Retrospectiva da
Sprint; (d) Correto; (e) Errado, ela dura 15 minutos e não busca definir os produtos de uma sprint.
Gabarito: Letra D
47. (FCC / TRF - 3ª REGIÃO – 2019) No roteiro SCRUM, de gerenciamento Ágil, a atividade que
discute funcionalidades de modo a atualizar o que já foi feito, o que será feito e dificuldades é:
a) Sprint Review que pretende validar a entrega do momento quando termina uma Sprint.
Realiza-se a reunião que fará a demonstração do produto ou funcionalidade sendo entregue.
b) Sprint Backlog, onde o conjunto planejado, selecionado junto ao Backlog do Produto, é

definido para compor uma Sprint. Somente as entregas que compõem a Sprint serão detalhas
em atividades menores e as restantes serão “congeladas”, não sendo detalhadas ainda.
c) Sprint Goal resultado da negociação entre o time de desenvolvimento e o Product Owner -

PO reconhecido como necessidade(s) fundamental(ais) do cliente nesse momento.
76

Aula 04
d) Daily Scrum, reunião que ocorre diariamente, durante 15 minutos, com todos participantes
em pé, onde se atualiza a situação presente da Sprint sendo trabalhada.
e) Product Backlog onde se produz uma lista contendo todas as funcionalidades desejadas para
um produto em sua situação atual.
Comentários:
O que foi feito? O que será feito? Quais são as dificuldades? Essas são as três perguntas realizadas na
Daily Scrum [Versão 2017].
Gabarito: Letra D
48.(FCC / SANASA Campinas – 2019) Um Analista de TI tem como tarefas ordenar os itens do
Backlog do Produto visando o alcance das metas e missões do projeto, buscando garantir que o
Backlog do Produto esteja claro de forma a mostrar no que o Time Scrum vai trabalhar a seguir
e ainda visando garantir que o Time de Desenvolvimento entenda os itens do Backlog do
Produto no nível necessário. Considerando que o projeto é baseado no Scrum, o Analista está
no papel de:
a) Scrum Master.
b) Gerente do Produto.
c) Sprint Manager.
d) Product Owner.
e) Development Team Leader.
Comentários:
Quem ordena os itens do Product Backlog é o Product Owner.
Gabarito: Letra D
49.(FCC / TRF - 4ª REGIÃO – 2019) Uma Analista de TI está atuando como Product Owner em um
projeto Scrum. Ela está trabalhando na formulação de um acordo para definir quais são os
passos mínimos para a conclusão de um item potencialmente entregável, que serve como um
contrato entre o Scrum Team e o Product Owner, de forma que os integrantes tenham um
entendimento compartilhado do que significa o trabalho estar completo, assegurando a
transparência e os padrões de qualidade estabelecidos entre eles. O acordo, denominado:
a) Scrum rules, integra os eventos, papéis e artefatos, administrando as relações e interações

entre eles, e é criado na 1ª sessão do Sprint Review Meeting.
77

Aula 04
b) incremento, pode evoluir normalmente ao longo do projeto, porém é recomendável que a

primeira versão seja criada durante a primeira sessão de Sprint Planning, após a realização da
primeira Sprint do projeto.
c) DoD, é a soma de todos os itens do Product Backlog completados durante a Sprint e o valor
dos incrementos de todas as Sprints anteriores.
d) Scrum rules, é um conjunto de itens do Product Backlog selecionados para a Sprint que forma
o plano para entregar o incremento do produto e atingir o objetivo da Sprint.
e) DoD, também orienta o Scrum Team no conhecimento de quantos itens do Product

Backlog podem ser selecionados durante a Sprint Planning Meeting.
Comentários:
(a) Errado, as regras integram os eventos, papéis e artefatos, administrando as relações e

interações entre eles. No entanto, ele não é criado na Sprint Review Planning – isso nem faz sentido;
(b) Errado, incremento é a versão potencialmente utilizável do produto – ele é criado no final da
Sprint; (c) Errado, o incremento é a soma de todos os itens do Backlog do Produto completados
durante a Sprint e o valor dos incrementos de todas as Sprints anteriores; (d) Errado, essa seria a
Sprint Backlog; (e) Correto. Ela orienta o Time de Desenvolvimento no conhecimento de quantos
itens do Backlog do Produto podem ser selecionados durante o Planejamento da Sprint. O
propósito de cada Sprint é entregar incrementos de funcionalidades potencialmente liberáveis que
aderem à definição atual de “Pronto” do Time Scrum.
Gabarito: Letra E
50. (FCC / TJ-MA – 2019) Um Analista Judiciário, no papel de Scrum Master, esclarece que:
a) o gerenciamento do Product Backlog não fica unicamente na responsabilidade do Product

Owner, mas deve ser compartilhado com o Product Backlog Committee.
b) o Product Owner é uma pessoa ou um comitê. Quando o Product Owner é representado por
um comitê, aqueles que quiserem uma alteração nas prioridades dos itens do Product
Backlog devem endereçá-la ao Committee’s Coordinator.
c) somente integrantes do Development Team criam incrementos e um incremento “Pronto” é

requerido na Revisão da Sprint.
d) o Scrum recomenda que haja apenas quatro subtimes no Development Team relativos aos
domínios de conhecimento: teste, arquitetura, operação e análise de negócios.
78

Aula 04
e) o Scrum Team consiste de profissionais que realizam o trabalho de entregar um incremento

potencialmente liberável do produto “Pronto” no início de cada Sprint.
Comentários:
(a) Errado, ele é o único responsável pelo gerenciamento do Backlog do Produto; (b) Errado. O
Product Owner é uma pessoa e não um comitê. O Product Owner pode representar o desejo de um
comitê no Backlog do Produto, mas aqueles que quiserem uma alteração nas prioridades dos itens
de Backlog devem endereçar ao Product Owner; (c) Correto; (d) Errado. Scrum não reconhece sub-
times no Time de Desenvolvimento, independente dos domínios de conhecimento que precisam
ser abordados, tais como teste, arquitetura, operação ou análise de negócios; (e) Errado. O Time de
Desenvolvimento consiste de profissionais que realizam o trabalho de entregar um incremento
potencialmente liberável do produto “Pronto” ao final de cada Sprint.
Gabarito: Letra C
51. (FCC / SEGEP-MA – 2018) O Scrum prescreve quatro eventos formais, contidos dentro dos
limites da Sprint, para inspeção e adaptação. Dois desses eventos são:
a) revisão do backlog e orientação do Scrum Master.

b) preleção do Product Owner e revisão dos requisitos.
c) reunião de revisão da Sprint e descrição de requisitos no backlog.
d) revisão das especificações e reunião de planejamento da Sprint.
e) reunião diária e retrospectiva da Sprint.
Comentários:
A questão insere vários eventos que não existem – os únicos eventos formais listados são: reunião
diária e retrospectiva da sprint.
Gabarito: Letra E
52. (FCC / TRT-MG – 2015) Com relação ao Scrum, considere:
I. O Product Owner, ou dono do produto, é responsável por garantir que o Scrum seja entendido
e aplicado. Faz isso para garantir que o Time Scrum adere à teoria, práticas e regras do Scrum.
É um servo-líder para o Time Scrum.
II. O Scrum Master é o responsável por maximizar o valor do produto e do trabalho do Time de
Desenvolvimento. Como isso é feito pode variar amplamente nas organizações, Times Scrum e
indivíduos.
79

Aula 04
III. O coração do Scrum é a Sprint, um time-boxed de um mês ou menos, durante o qual um

“Pronto", versão incremental potencialmente utilizável do produto, é criado.
Está correto o que consta APENAS em:
a) I e II.
b) III
c) II e III.
d) II.
e) I e III.
Comentários:
(I) Errado, esse seria o Scrum Master; (II) Errado, essa é uma responsabilidade do Product Owner;
(III) Correto.
Gabarito: Letra B
53. (FCC / TRT-SC – 2013) SCRUM é um framework baseado no modelo ágil. No SCRUM,
a) o scrum team é a equipe de desenvolvimento, necessariamente dividida em papéis como

analista, designer e programador. Em geral o scrum team tem de 10 a 20 pessoas.
b) as funcionalidades a serem implementadas em cada projeto (requisitos ou histórias de

usuários) são mantidas em uma lista chamada de scrum board.
c) o scrum master é um gerente no sentido dos modelos prescritivos. É um líder, um facilitador

e um solucionador de conflitos. É ele quem decide quais requisitos são mais importantes.
d) um dos conceitos mais importantes é o sprint , que consiste em um ciclo de desenvolvimento

que, em geral, tem duração de 4 a 7 dias.
e) o product owner tem, entre outras atribuições, a de indicar quais são os requisitos mais
importantes a serem tratados em cada sprint. É responsável por conhecer e avaliar as
necessidades dos clientes.
Comentários:
(a) Errado, esse é o Development Team – que não é dividido em papéis (é multifuncional) e tem
entre 3 e 9 pessoas [Versão 2017]; (b) Errado, são mantidas em uma lista chamada Product Backlog;
(c) Errado, quem decide os requisitos mais importantes é o Product Owner; (d) Errado, a duração é
menos de um mês; (e) Correto.
80

Aula 04
Gabarito: Letra E
54. (FCC / TRE-CE – 2012) No SCRUM, sprint é:
a) um representante dos stakeholders e do negócio.

b) uma lista de requisitos que tipicamente vêm do cliente.
c) uma lista de itens priorizados a serem desenvolvidos para um software.
d) uma iteração que segue um ciclo (PDCA) e entrega incremento de software pronto.
e) um conjunto de requisitos, priorizado pelo Product Owner.
Comentários:
(a) Errado, isso é o Product Owner; (b) Errado, isso é o Product Backlog; (c) Errado, isso é o Product
Backlog; (d) Correto; (e) Errado, isso é o Product Backlog.
Gabarito: Letra D
55. (FCC / TRT-SP – 2012) Analise o texto:
O Scrum enfatiza o uso de um conjunto de padrões de processos de software que provaram ser
eficazes para projetos com prazo de entrega apertados, requisitos mutáveis e críticos de
negócio. Cada um desses padrões de processos define um conjunto de ações de
desenvolvimento. Uma dessas ações consiste em manter uma lista com prioridades dos
requisitos ou funcionalidades do projeto que fornecem valor comercial ao cliente. Os itens
podem ser adicionados a esse registro em qualquer momento. O gerente de produto avalia o
registro e atualiza as prioridades conforme requisitado. A lista citada no texto é conhecida
como:
a) urgências scrum.
b) registro ágil de requisitos.
c) alterações scrum.
d) registro pendente de trabalhos (Backlog).
e) registro iterativo de desenvolvimento (sprint).
Comentários:
De acordo com Roger Pressman: “O Registro Pendente de Trabalhos (Backlog) consiste em uma lista
com prioridades dos requisitos ou funcionalidades do projeto que fornecem valo comercial ao cliente.
Os itens podem ser adicionados a esse registro em qualquer momento (é assim que as alterações são
introduzidas). O gerente do produto avalia o registro e atualiza as prioridades conforme requisitado”.
Gabarito: Letra D
81

Aula 04
56. (FCC / TRF-2 – 2012) Segundo Roger S. Pressman, em seu livro Engenharia de Software, 7a
edição, os princípios do Scrum são consistentes com o manifesto ágil e são usados para orientar
as atividades de desenvolvimento dentro de um processo que incorpora as atividades
estruturais de requisitos, análise, projeto, evolução e entrega. Em cada atividade metodológica,
ocorrem tarefas a realizar dentro de um padrão de processo chamado:
a) process backlog.
b) scrum master.
c) product owner.
d) backlog.
e) sprint.
Comentários:
Em cada atividade metodológica, ocorrem tarefas a realizar dentro de um padrão de processo

chamado: Sprint. Ciclos completos de desenvolvimento em que, ao final, temos incrementos
potencialmente entreváveis do produto.
Gabarito: Letra E
57. (FCC / INFRAERO – 2011) Um dos principais conceitos do Scrum para atacar a complexidade do
desenvolvimento e gerenciamento de software é a implantação de um controle
descentralizado, capaz de lidar mais eficientemente com contextos pouco previsíveis. Para
tanto, o gerenciamento é distribuído por meio de três agentes independentes que são:
a) Product Owner, Scrum Team e Scrum Master.

b) Product Owner, Product Backlog e Planning Meeting.
c) Product Owner, Sprint e Planning Meeting.
d) Sprint, Scrum Master e Planning Meeting.
e) Sprint, Scrum Team e Product Backlog.
Comentários:
O Guia Scrum [Versão 2017] afirma que o Scrum Team é dividido em Product Owner, Scrum Master
e Development Team. No entanto, a banca considerou como resposta correta: Product Owner,
Scrum Team e Scrum Master. Viagem completa da banca...
Gabarito: Letra A
58. (FCC / INFRAERO – 2011) Em relação às regras do Scrum, é INCORRETO afirmar:
a) O Sprint deve ser realizado num período máximo de 40 dias e ter uma equipe de trabalho não
superior a 10 pessoas.
82

Aula 04
b) Se o Sprint tomar um rumo não desejado, é possível dissolvê-lo e começar um novo Sprint,
baseando num novo Sprint Backlog.
c) As reuniões durante um Sprint devem ser diárias, sempre à mesma hora e no mesmo local e
não devem durar mais que 30 minutos.
d) Toda conversação restringe as respostas dos participantes às três perguntas do Scrum

Master: O que desenvolveu desde a última reunião? Que dificuldades encontrou durante o seu
trabalho? O que planeja desenvolver até a próxima reunião?
e) Com base nas respostas às três perguntas, o Scrum Master deve imediatamente tomar
decisões, quando necessárias, para remover todas as situações que impeçam a agilidade do
trabalho.
Comentários:
(a) Errado. O período máximo é de 30 dias e a equipe de trabalho varia de 3 a 9 pessoas [Versão
2017]; (b) Correto. É possível dissolver uma sprint e começar outra baseando-se em um novo sprint
backlog – quem pode fazer isso é o Product Owner; (c) Correto. Essa questão foi muito polêmica e
eu acho uma sacanagem! A Daily Scrum deve ter no máximo 15 minutos? Sim, mas a questão apenas
afirma que ela não deve durar mais que 30 minutos. Se ela dura no máximo 15 minutos, ela não dura
mais que 30 minutos. Sendo bastante rigoroso no julgamento, o item não está errado, mas isso
prejudica quem estudou e sabe que a reunião tem no máximo 15 minutos; (d) Correto, essas são –
de fato – as perguntas a serem feitas [Versão 2017]; (e) Correto, é exatamente isso que o Scrum
Master deve fazer.
Gabarito: Letra A
59. (FCC / TCE-SE – 2011) Aceita a imprevisibilidade do desenvolvimento de software e a contorna

através da adaptação constante. Destaca-se das demais metodologias ágeis por dar mais
enfoque à área de gerenciamento. Seu nome tem origem em um esporte quando jogadores de
cada time colaboram entre si numa tentativa de avançar juntos pelo campo adversário. Tais
características estão presentes no processo:
a) UP.
b) Crystal.
c) XP.
d) DSDM.
e) Scrum.
Comentários:
83

Aula 04
A questão deu duas dicas: primeiro, ela fala em gerenciamento; segundo, ela fala que o nome é
inspirado em um esporte. Logo, trata-se do Scrum!
Gabarito: Letra E
60.(FCC / TRT-RS – 2011) Para utilizar o processo de estimativa por Story Points em Scrum,
inicialmente:
a) o Product Owner deve atribuir valores de negócio para cada um dos itens do Product Backlog.
b) o Product Backlog deve considerar todos os fatores de Sprint contidos no Backlog Owner.
c) os Stakeholders devem atribuir os riscos do Product Owner para cada Sprint Planning.
d) os Stakeholders devem atribuir valores de negócio do Product Owner para cada Sprint.
e) o Product Planning deve avaliar cada Sprint contida no Backlog transacional e decidir pela
prioridade de atividades.
Comentários:
Essa questão é até engraçada! Os quatro últimos itens não fazem absolutamente nenhum sentido
– o examinador aparentemente saiu trocando palavras de forma aleatória. Não existem os
conceitos de Product Planning, Backlog Transacional, etc. Além disso, os Story Points são uma
unidade de estimativa em relação ao Product Backlog e, não, ao Sprint Backlog.
Gabarito: Letra A
61. (FCC / TRT-RJ – 2011) No SCRUM, o processo de desenvolvimento inicia com uma reunião de
planejamento na qual o Product Owner e a equipe decidem, em conjunto, o que deverá ser
implementado do Product Backlog. Assim, a equipe planeja seu trabalho, definindo o Sprint
Backlog, na:
a) primeira parte da Sprint Planning Meeting.

b) segunda parte da Sprint Planning Meeting.
c) terceira parte da Sprint Planning Meeting.
d) Sprint.
e) Sprint Burndown.
Comentários:
Na primeira parte, os desenvolvedores trabalham para prever as funcionalidades que serão

desenvolvidas durante a Sprint. O Product Owner debate a meta a Sprint deve realizar e os itens de
84

Aula 04
Backlog do Produto que, se completados na Sprint, atingirão a meta. Na segunda parte, tendo
definido o objetivo da Sprint e selecionado os itens de Backlog do Produto da Sprint, os
desenvolvedores decidem como irão construir essas funcionalidades durante a Sprint e transformá-
las em um incremento de produto “Pronto”. Ainda nessa parte: os itens do Backlog do Produto
selecionados para a Sprint junto com o plano de entrega destes itens é chamado de Backlog da
Sprint.
Gabarito: Letra B
62. (FCC / TRE-ES – 2010) Os princípios Scrum são usados para guiar as atividades de
desenvolvimento dentro de um processo que incorpora as seguintes atividades de arcabouço:
requisitos, análise, projeto, evolução e entrega. Em cada atividade de arcabouço, as tarefas de
trabalho ocorrem dentro de um padrão de processo chamado:
a) pendência.
b) iterator.
c) demo.
d) história de usuário.
e) sprint.
Comentários:
O Scrum realiza ciclos completos de desenvolvimento em que, ao final, temos incrementos

potencialmente entregáveis do produto – o nome desses ciclos de desenvolvimento em que tarefas
de trabalho ocorrem é chamado: Sprint!
Gabarito: Letra E
63. (FCC / TRF 4ª – 2010) Na fase de desenvolvimento do Scrum, o software é desenvolvido em

processos iterativos denominados:
a) Building Products.
b) Product Backlog.
c) Sprint.
d) Product Owner.
e) Product Backlog Cycle.
Comentários:
O Scrum realiza ciclos completos de desenvolvimento em que, ao final, temos incrementos

potencialmente entregáveis do produto – o nome desses ciclos de desenvolvimento em que o
software é desenvolvido em processos iterativos é chamado: Sprint.
85

Aula 04
Gabarito: Letra C
64.(FCC / TRE-RS – 2010) Em reunião, toda conversação é restringida às respostas dos elementos
às perguntas colocadas pelo Scrum Master, sendo uma delas: "O que planeja desenvolver até a
próxima reunião?". As Scrum meetings ocorrem:
a) sempre que necessário.

b) ocasionalmente.
c) uma vez por semana.
d) duas vezes por semana.
e) diariamente.
Comentários:
Essa é uma das três perguntas feitas pelo Scrum Master [Versão 2017] e a Scrum Meeting citada é
a Daily Scrum Meeting – também chamada de Reunião Diária.
Gabarito: Letra E
65. (FCC / TRE-RS – 2010) No contexto das regras do SCRUM, é correto afirmar:
a) Durante a realização do Sprint, o Backlog pode ser modificado por qualquer um dos
elementos da equipe, desde que acordado nas reuniões semanais.
b) O Sprint deve ser realizado num período não superior a 30 dias e ter um objetivo bem claro,
baseado no Backlog.
c) Modificação no Backlog é prerrogativa do Scrum Master, quando achar necessário, em

qualquer momento no decorrer do Sprint.
d) Não é possível dissolver um Sprint. Se houver algum risco de ele tomar um rumo não
desejável, novas funcionalidades devem ser implementadas para garantir o prazo do projeto.
e) O foco na produtividade se estende às Scrum meetings e a conversação é pautada em

discussões por toda a equipe.
Comentários:
(a) Errado. Backlog? Qual Backlog? Da Sprint? Do Produto? A questão não especificou! De todo
modo, o Product Backlog só pode ser modificado pelo Product Owner e o Sprint Backlog só pode
ser modificado pelo Development Team [Versão 2017]; (b) Correto; (c) Errado. Scrum Master é
apenas um facilitador – quem pode modificar o Product Backlog é o Product Owner; (d) Errado. É
86

Aula 04
possível, sim, dissolver uma sprint; (e) Errado. Na verdade, as discussões ocorrem mais entre os
desenvolvedores.
Gabarito: Letra B
66. (FCC / TRE-RS – 2010) No SCRUM, o produto final, a data final e o custo do projeto são
determinados:
a) respectivamente, no planejamento, ao longo do projeto, no início do projeto.

b) ao longo do projeto.
c) no planejamento.
d) respectivamente, nas fases intermediárias, no planejamento, no final do projeto.
e) em função das iterações.
Comentários:
No Scrum, o tempo e o custo geralmente são fixos e o escopo é variável, isto é, eu não parto do
escopo fixo para descobrir um tempo variável – eu parto do tempo fixo para descobrir um escopo
variável. Ser fixo não significa que é determinado antes. Eu posso dizer que minha data final é daqui
três meses e a equipe de projeto vai fazer quantas funcionalidades conseguir dentro desse período.
Ao longo do projeto, eu posso dizer que tenho mais três meses para entregar e a equipe dirá que dá
para fazer mais algumas funcionalidades. Então, eu sempre parto do tempo para decidir o escopo
e não do escopo para definir o tempo. Por que? Porque senão o projeto poderia durar eternamente
dado que os requisitos são como organismos vivos e nunca têm fim. O Product Owner
frequentemente pode mudar de ideia, pedir mudanças, adicionar requisitos e o escopo final do
projeto nunca será alcançado, logo nunca chegará ao fim do projeto. Então, o produto final, a data
final e o custo do projeto são determinados.
Gabarito: Letra B
67. (FCC / DPE-SP – 2010) Na engenharia de software, um processo iterativo denominado sprint,
que segue o ciclo PDCA para entregar, num período de 30 dias aproximadamente, um
incremento do software pronto, caracteriza a metodologia ágil:
a) SCRUM.
b) DSDM.
c) Crystal.
d) FDD.
e) XP.
Comentários:
87

Aula 04
Palavras-chave: processo iterativo, sprint, 30 dias, incremento pronto... essas palavras tratam de
uma metodologia ágil chamada Scrum.
Gabarito: Letra A
68. (FCC / AFR-SP – 2009) O conceito de sprint aplica-se ao modelo ágil do processo de
engenharia de software denominado:
a) Crystal.
b) XP.
c) DAS.
d) DSDM.
e) Scrum.
Comentários:
O conceito de sprint é um inerentemente do processo de engenharia de software chamado Scrum!
Gabarito: Letra E
88

Aula 04
QUESTÕES COMENTADAS – FGV
69. (FGV / TJDFT – 2022) Uma equipe de analista de sistemas está desenvolvendo o software
ProgramaTJ aplicando a metodologia Lean. A equipe decidiu implementar apenas as
funcionalidades formalmente requisitadas pelo cliente, evitando adicionar qualquer
funcionalidade extra à ProgramaTJ por conta própria.
Essa decisão da equipe remete, de forma direta, ao princípio da metodologia Lean para o
desenvolvimento de software de:
a) otimização do todo;
b) adiar comprometimento;
c) eliminação de desperdícios;
d) respeitar as pessoas;
e) criação de conhecimento.
Comentários:
Trata-se do princípio de eliminar desperdícios! Esse princípio afirma que se deve eliminar tudo que
não é percebido pelo cliente. Funcionalidades extras não são requisitadas pelo cliente, logo devem
ser eliminadas.
Gabarito: Letra C
70. (FGV / TJDFT – 2022) Uma equipe de desenvolvimento de sistemas de software (EDSS) está
trabalhando no desenvolvimento de uma nova aplicação Web utilizando práticas ágeis
alinhadas com o Scrum. Algumas funcionalidades da aplicação Web já foram disponibilizadas
aos clientes, porém um dos Product Owners solicitou mudanças em algumas delas. Sabendo-se
que a EDSS está no meio do andamento de uma Sprint de 4 semanas cujo Sprint Goal não tem
relação direta com as funcionalidades entregues, para atender à solicitação do Product Owner,
a EDSS deve:
a) alterar o prazo planejado para desenvolvimento da Sprint de modo a adicionar a alteração

solicitada;
b) realizar uma Sprint Retrospective para decidir quando adicionar a alteração solicitada;
c) executar uma Sprint Review para determinar as adaptações para adicionar a alteração
solicitada;
89

Aula 04
d) manter o prazo planejado para desenvolvimento da Sprint, removendo um dos itens do Sprint
Backlog para adicionar a alteração solicitada;
e) manter o prazo planejado para desenvolvimento da Sprint, adicionando a alteração solicitada

no Product Backlog.
Comentários:
O guia nos diz que, durante a sprint, não são feitas alterações que possam pôr em perigo o Sprint
Goal e o enunciado afirma que o Sprint Goal não tem relação direta com as funcionalidades
entregues, logo não há que se alterar prazo, remover itens, realizar retrospectivas ou revisões –
basta manter o prazo e adicionar a alteração solicitada.
Alguns alunos argumentaram que o responsável por adicionar itens no Product Backlog é o Product
Owner. No entanto, o guia nos diz que o Product Owner pode fazê-lo ou poderá delegar essa
atividade a outros, mantendo-se responsável pelo Product Backlog. Ainda não saiu o gabarito
definitivo, mas eu acho um recurso difícil.
Gabarito: Letra E
71. (FGV / FUNSAÚDE - 2021) Analise a frase a seguir.
Funciona criando ciclos, conhecidos como sprints, que são os intervalos de tempo para o
desenvolvimento de cada etapa.
Assinale a metodologia ágil de desenvolvimento à qual a frase acima diz respeito.
a) Crystal.
b) Kanban.
c) Lean.
d) Scrum.
e) XP.
Comentários:
Ciclos (Sprints) que funcionam como intervalos de tempo para o desenvolvimento de cada etapa é
uma característica típica do Scrum.
Gabarito: Letra D
72. (FGV / COMPESA – 2018) O SCRUM é um framework para gerenciamento de projetos

complexos, sendo um dos métodos ágeis mais populares do mundo. Uma das dinâmicas
90

Aula 04
definidas no SCRUM é a retrospectiva. Assinale a opção que melhor descreve o objetivo da

retrospectiva definida no SCRUM.
a) Planejar medidas que possam trazer, no próximo Sprint, melhorias relacionadas à

colaboração entre as pessoas, processos ou ferramentas.
b) Inspecionar o resultado do trabalho realizado em um Sprint e ajustar o Backlog do produto,

se necessário.
c) Rever as prioridades dos itens que compõem o Backlog do produto.
d) Planejar como o time construirá as funcionalidades definidas para um Sprint com base nos
resultados obtidos nos Sprints anteriores.
e) Disseminar conhecimento sobre o que foi feito no dia anterior para poder priorizar o trabalho
a ser realizado no dia que se inicia.
Comentários:
A Retrospectiva da Sprint (Proporcional a 3 horas) é uma chance para o Scrum Team inspecionar a
si próprio e criar um plano de melhorias para a próxima sprint. Ela inspeciona como foi a última
sprint em relação às pessoas, às relações, aos processos e às ferramentas. Pode identificar e ordenar
os itens que se tornaram potenciais de melhorias e cria um plano para implementar melhorias no
trabalho.
Dessa forma, temos que: (a) Correto; (b) Errado, isso é a Revisão da Sprint; (c) Errado, isso é
Planejamento da Sprint; (d) Errado, isso é Planejamento da Spring; (e) Errado, isso é Reunião Diária.
Gabarito: Letra A
73. (FGV / AL-RO – 2018) Para o desenvolvimento do Sistema de Informações ao Cidadão (SIC), foi
decidida a utilização de uma metodologia ágil. Segundo o Manifesto Ágil, esta decisão indica
que foi dado maior valor:
a) aos processos e ferramentas.

b) à resposta a modificações.
c) à documentação abrangente.
d) à negociação do contrato.
e) ao cumprimento do plano.
Comentários:
91

Aula 04
Segundo o Manifesto Ágil, esta decisão indica que foi dado maior valor à resposta a modificações.
Vamos relembrar: (1) os indivíduos e suas interações acima de procedimentos e ferramentas; (2) o
funcionamento do software acima de documentação abrangente; (3) a colaboração com o cliente
acima da negociação e contrato; (4) a capacidade de resposta a mudanças acima de um plano pré-
estabelecido.
Gabarito: Letra B
74. (FGV / Banestes – 2018) Com relação aos valores relacionados ao desenvolvimento ágil de
software, NÃO se pode incluir:
a) colaboração do cliente mais que negociação de contratos;

b) indivíduos e iterações mais que processos e ferramentas;
c) rapidez na construção mais que excelência técnica;
d) responder a mudanças mais que seguir um plano;
e) software funcional mais que documentação abrangente.
Comentários:
Todos os itens estão de acordo com o Manifesto Ágil, exceto rapidez na construção mais que
excelência técnica! Isso não faz parte dos valores do desenvolvimento ágil – excelência técnica deve
ser mais importante que a rapidez na construção.
Gabarito: Letra C
75. (FGV / Banestes – 2018) Um dos valores relacionados ao ambiente ágil de desenvolvimento é:
a) documentação abrangente mais que software funcional;

b) negociação de contratos mais que colaboração do cliente;
c) processos e ferramentas mais que indivíduos e iterações;
d) rapidez na construção mais que excelência técnica;
e) responder a mudanças mais que seguir um plano.
Comentários:
O Manifesto Ágil afirma que estavam sendo descobertas maneiras melhores de desenvolver
software. Através do manifesto ágil, passa-se a valorizar: (1) Indivíduos e interações mais que
processos e ferramentas; (2) Software em funcionamento mais que documentação abrangente; (3)
Colaboração com o cliente mais que negociação de contratos; (4) Responder a mudanças mais que
seguir um plano.
Gabarito: Letra E
92

Aula 04
76. (FGV / TJ-SC – 2015) O SCRUM, processo para o desenvolvimento de software ágil, estrutura-
se sobre:
a) plan, documentaton, test;

b) roles, artifacts, activities;
c) requisites, code, products;
d) client team, development team, deliverables;
e) interface, data, code.
Comentários:
O Scrum trata de Papeis (Roles), Artifacts (Artefatos) e Eventos (Activities). A tradução desse último
termo ficou péssima infelizmente.
Gabarito: Letra B
77. (FGV / PGE-RO – 2015) Durante 5 anos gerenciando o desenvolvimento de sistemas de

informação, Claudia teve que lidar com diversas insatisfações de seus usuários pois os sistemas
não atendiam as suas necessidades. Claudia decidiu, então, implantar métodos ágeis de
desenvolvimento e definiu os seguintes princípios:
I. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento.
II. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de
desenvolvimento é através da documentação.
III. Simplicidade é essencial.
Dentre os princípios definidos por Claudia, o que infringe os princípios do manifesto para
Desenvolvimento Ágil de Software é o que se afirma em:
a) somente I;
b) somente II;
c) somente III;
d) somente I e III;
e) I, II e III.
Comentários:
NÓS SEGUIMOS ESSES PRINCÍPIOS...

Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram
vantagem das mudanças visando vantagem competitiva para o cliente. As Metodologias Tradicionais são
preditivas – já vimos que esse cenário é ilusório.
93

Aula 04
O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento é
através de conversa face a face. As Metodologias Tradicionais utilizam documentos, diagramas, relatórios,
telefonemas para promover a comunicação no projeto.
Simplicidade – a arte de maximizar a quantidade de trabalho não realizado – é essencial. As Metodologias
Tradicionais, algumas vezes, recorriam a implementações desnecessariamente complexas, a planejamentos
exageradamente detalhados, entre outros.
(I) Correto. Mudanças são sempre bem-vindas; (II) Errado, o método mais eficiente é frente-a-
frente; (III) Correto. Como a questão pede os princípios que infringem o manifesto ágil, trata-se da
segunda opção.
Gabarito: Letra B
78. (FGV / TJ-RO – 2015) O manifesto ágil tem por princípio que:
a) mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento;
b) a contínua atenção à excelência técnica reduz a agilidade;
c) a redução do backlog é a medida primária de progresso;
d) as melhores arquiteturas, requisitos e designs emergem de equipes que possuem um bom

líder;
e) pessoas de negócio e desenvolvedores devem trabalhar em ambientes separados para reduzir

as interferências no processo de desenvolvimento.
Comentários:
NÓS SEGUIMOS ESSES PRINCÍPIOS...

Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento. Processos ágeis tiram
vantagem das mudanças visando vantagem competitiva para o cliente. As Metodologias Tradicionais são
preditivas – já vimos que esse cenário é ilusório.
Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto. As
Metodologias Tradicionais não valorizavam essa colaboração intensa entre clientes e desenvolvedores,
como faz o Ágil.
Software funcionando é a medida primária de progresso. As Metodologias Tradicionais propunham a

entrega de artefatos (Ex: Documentação) que, em geral, não agregavam valor algum aos clientes, como
também uma forma de medir o progresso do projeto.
Contínua atenção à excelência técnica e bom design aumenta a agilidade. As Metodologias Tradicionais
acreditavam que, para se obter máxima velocidade e flexibilidade no desenvolvimento de software, poder-
se-ia sacrificar a qualidade deste software.
94

Aula 04
As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis. As Metodologias

Tradicionais geralmente precisam de um gerente de projetos responsável por organizar o trabalho da equipe
como um todo, sendo também responsável pela tomada de decisões.
O único princípio correto é que mudanças nos requisitos são bem-vindas, mesmo tardiamente no
desenvolvimento.
Gabarito: Letra A
79. (FGV / Câmara Municipal de Caruaru - PE – 2015) O desenvolvimento ágil de software é guiado
por metodologias que compartilham um conjunto comum de valores e de princípios, conforme
definido pelo Manifesto Ágil. Assinale a opção que indica um princípio do desenvolvimento ágil.
a) As mudanças nos requisitos devem ocorrer dentro do quadro de tempo estabelecido para a
iteração.
b) O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de
desenvolvimento é por meio de conversa face a face.
c) Os intervalos regulares devem ser evitados para tornar a equipe mais eficaz e maximizar a
quantidade de trabalho realizado.
d) As pessoas de negócio e desenvolvedores devem interagir somente no início de cada iteração.
e) A entrega contínua e adiantada de software, mesmo que o conjunto de funcionalidades
desenvolvidas não agregue valor, deve ser feita para satisfazer o cliente.
Comentários:
(a) Errado, idealmente devem ser feitas antes do início da iteração ou podem ser feitas durante o
período da iteração desde que não afetem os objetivos dela; (b) Correto; (c) Errado, os intervalos
regulares devem ser incentivados e, não, evitados; (d) Errado, devem interagir durante todo
período do projeto; (e) Errado, as entregas devem sempre agregar algum valor.
Gabarito: Letra B
80.(FGV / DPE-RO – 2015) O Manifesto Ágil é uma declaração que reúne os princípios e práticas
que fundamentam o desenvolvimento ágil de software. É um dos princípios desse manifesto:
a) defeitos no software são a medida primária de progresso;

b) pessoas de negócio e desenvolvedores devem trabalhar isoladamente e se reunir somente ao
final de cada iteração para validação do software;
c) atenção contínua à excelência técnica deve ser evitada para não afetar a agilidade uma vez
que simplicidade é essencial;
d) os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo
constante indefinidamente evitando interrupções e intervalos regulares;
e) as melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.
95

Aula 04
Comentários:
(a) Errado, software funcional é a medida primária de progresso; (b) Errado, pessoas relacionadas à
negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do
projeto; (c) Errado, contínua atenção à excelência técnica e bom design, aumenta a agilidade; (d)
Errado, em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e
otimizam seu comportamento de acordo; (e) Correto, as melhores arquiteturas, requisitos e
designs emergem de equipes auto-organizáveis. As metodologias tradicionais geralmente
precisam de um gerente de projetos responsável por organizar o trabalho da equipe como um todo,
sendo também responsável pela tomada de decisões. Nas metodologias ágeis, as equipes são auto-
organizadas.
Gabarito: Letra E
81. (FGV / DPE-RO – 2015) Uma metodologia de desenvolvimento de software é um conjunto

estruturado de práticas que auxiliam o processo de produção de software. Em geral, a adoção
de uma metodologia é significativamente melhor do que uma abordagem casual de
desenvolvimento de software. Em relação a metodologias de desenvolvimento de software,
analise as afirmativas a seguir:
I - O Scrum é uma metodologia de desenvolvimento ágil que emprega uma abordagem iterativa
e incremental para aperfeiçoar a previsibilidade e o controle de riscos.
II - A programação em dupla num único computador é uma característica da metodologia RUP

(Rational Unified Process) como uma forma de evitar e diminuir a possibilidade de defeitos.
III - Metodologias ágeis tentam minimizar o risco por meio do desenvolvimento do software em
longos períodos, evitando que funcionalidades do software sejam entregues frequentemente.
Está correto o que se afirma em:
a) somente I;
b) somente II;
c) somente III;
d) somente I e II;
e) I, II e III.
Comentários:
(I) Correto, todas essas são características do Scrum; (II) Errado, essa é uma característica do XP
(Extreme Programming) e, não, do RUP; (III) Errado, o desenvolvimento ocorre em curtos períodos,
incentivando a entrega frequente de funcionalidades de software.
96

Aula 04
Gabarito: Letra A
82. (FGV / PROCEMPA – 2014) O Manifesto Ágil é uma declaração de princípios que fundamentam
o desenvolvimento ágil de software. A respeito desses princípios, assinale a afirmativa correta.
a) As melhores arquiteturas, requisitos e designs emergem de equipes lideradas pelo

profissional mais sênior.
b) Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e
ajusta seu comportamento de acordo.
c) Pessoas de negócio e desenvolvedores devem trabalhar separadamente por todo o projeto.
d) Entregar software quando há poucas semanas de desenvolvimento deve ser evitado para não
afetar a satisfação do cliente.
e) Mudanças nos requisitos são bem-vindas, desde que não impactem o desenvolvimento.
Comentários:
(a) Errado, emergem de equipes auto-organizáveis; (b) Correto; (c) Errado, devem trabalhar em
conjunto; (d) Errado, deve ser incentivado a entrega frequente desde o início; (e) Errado, mudanças
são bem-vindas mesmo que impactem o desenvolvimento.
Gabarito: Letra B
83. (FGV / TJ-GO – 2014) O Manifesto Ágil lista valores seguidos por desenvolvedores com a
finalidade de melhorar a maneira pela qual o software é desenvolvido. A alternativa que se
encontra no manifesto é:
a) seguir um plano mais que responder a mudanças;

b) indivíduos e interações mais que processos e ferramentas;
c) documentação abrangente mais que software em funcionamento;
d) negociação de contratos mais que colaboração com o cliente;
e) negociação de contratos mais que indivíduos e interações.
Comentários:
(a) Errado, está invertido; (b) Correto; (c) Errado, está invertido; (d) Errado, está invertido; (e)
Errado, indivíduos e interações mais que processos e ferramentas.
Gabarito: Letra B
84.(FGV / DPE-RJ – 2014) Uma das características da metodologia ágil Scrum é:
a) focar nas práticas de engenharia.
97

Aula 04
b) focar na documentação formal do software.

c) ser um método iterativo e incremental.
d) exigir o planejamento do projeto, de acordo com as práticas do PMBOK.
e) não exigir interação com o cliente.
Comentários:
(a) Errado, ele se foca no empirismo e experiências práticas; (b) Errado, ele se foca no software em
funcionamento; (c) Correto; (d) Errado, ele se foca mais em responder rapidamente a mudanças do
que seguir um planejamento; (e) Errado, a colaboração com cliente é mais importante até que
negociações e contratos.
Gabarito: Letra C
85. (FGV / TJ-AM – 2013) Com relação aos princípios do modelo ágil de processo Scrum, analise as
afirmativas a seguir.
I. O processo precisa ser adaptável tanto a modificações técnicas quanto de negócios "para
garantir que o melhor produto possível seja produzido".
II. O trabalho de desenvolvimento e o pessoal que o realiza é dividido "em partições claras, de
baixo acoplamento ou em pacotes".
III. O processo produz frequentes incrementos de software "que podem ser inspecionados,
ajustados, testados, documentados e expandidos".
Assinale:
a) se somente a afirmativa I estiver correta.

b) se somente a afirmativa II estiver correta.
c) se somente a afirmativa III estiver correta
d) se somente as afirmativas I e II estiverem corretas.
e) se todas as afirmativas estiverem corretas.
Comentários:
(I) Correto, é exatamente por essa razão que ele é considerado um modelo ágil; (II) Correto, mas
com uma enorme ressalva: a fonte dessa questão foi o livro do Roger Pressman e ele realmente
afirma exatamente o que está escrito no item. No entanto, a fonte oficial deveria ser sempre o Guia
Oficial, justamente para evitar problemas! O que o Pressman afirma não faz nenhum sentido: pode-
se até afirmar que o trabalho é dividido em partições contidas nas sprints, mas o pessoal/equipe não
se divide – o próprio guia afirma que times de desenvolvimento não contém sub-times dedicados a
domínios específicos de conhecimento, logo a questão está flagrantemente errada. No entanto,
98

Aula 04
como a banca retirou a questão literalmente do Pressman, foi considerada como correta; (III)
Correto, o incremento é parte fundamental do modelo ágil.
Gabarito: Letra E
86. (FGV / MPE-MS – 2013) Em Scrum, pode-se utilizar diversas técnicas para estimar o que será
feito durante o projeto ou na próxima “Sprint”. A respeito da estimativa chamada de “Story
Points”, analise as afirmativas a seguir.
I. A estimativa de uma “User Story” com “Story Points” pode ser feita através da dinâmica
chamada de “Planning Poker”.
II. As estimativas usando “Story Points” são feitas por especialistas em estimativas e, em
seguida, validadas por todo o time.
III. A escala (1, 2, 3, 5, 8, 13, 20, 40, 100), usada para definir os “Story Points”, é inspirada na
sequência de Fibonnacci.
Assinale:
a) se somente a afirmativa III estiver correta

b) se somente as afirmativas I e III estiverem corretas
c) se somente as afirmativas II, III estiverem corretas
d) se somente as afirmativas I e II estiverem corretas
e) se todas as afirmativas estiverem corretas
Comentários:
(I) Correto. Uma das melhores formas de estimar Story Points é por meio de uma técnica chamada
Planning Poker, que não está no guia oficial, mas que é frequentemente utilizada tanto para estimar
esforço como para estimar tamanho; (II) Errado. A questão dá a entender que as estimativas são
feitas por especialistas externos, quando são feitas pelos próprios desenvolvedores e são validadas
por todo o time de desenvolvimento – a questão não especificou qual time. (III) Correto. Em geral,
os valores seguem uma escala baseada na Sequência de Fibonacci.
Gabarito: Letra B
87. (FGV / Senado Federa l – 2012) Com relação ao método ágil de desenvolvimento conhecido
como Scrum, analise as afirmativas a seguir.
I. Cada iteração do processo de desenvolvimento é denominada Sprint.

II. O Backlog do Produto é uma lista de itens priorizados, composta por requisitos e
funcionalidades que devem ser construídos para concretizar a visão.
99

Aula 04
III. No início de cada Sprint, a equipe se reúne para escolher os itens a serem desenvolvidos até
o final dessa iteração, o que dá origem ao Backlog do Sprint.

c) se somente a afirmativa III estiver correta.
Comentários:
(I) Correto, uma sprint é basicamente uma iteração; (II) Correto, o backlog do produto contém
requisitos de funcionalidades priorizadas para concretizar a visão; (III) Correto, trata-se do
planejamento da sprint.
Gabarito: Letra E
88. (FGV / MEC – 2009) Scrum é uma metodologia ágil para gestão e planejamento de projetos
de software. No Scrum, os projetos são divididos em ciclos chamados:
a) Product Backlog.
b) Sprint Backlog.
c) Scrum Master.
d) Daily Scrum.
e) Sprints.
Comentários:
No Scrum, os projetos são divididos em ciclos chamados sprints.
Gabarito: Letra E
100

Aula 04
QUESTÕES COMENTADAS – DIVERSAS BANCAS
A questão 86 baseia-se na Figura 11, que exibe a imagem de um gráfico elaborado no framework
Scrum, sobre o qual, considere os seguintes aspectos: (1) o eixo horizontal mostra, da esquerda para
a direita, os dias de uma Sprint; (2) o eixo vertical exibe, de cima para baixo, em porcentagem, a
quantidade de trabalho que ainda precisa ser feita; e (3) a linha tracejada exibe o esforço estimado,
enquanto a linha contínua mostra o esforço atual.
89. (FUNDATEC / ISS-Porto Alegre – 2022) No framework "Scrum", a equipe pode monitorar
seu progresso ao final de cada Sprint por meio do gráfico mostrado na Figura 17, o qual é
chamado de:
a) Sprint Planning Meeting.

b) Release Burndown Chart.
c) Release Planning Meeting.
d) Sprint Retrospective Chart.
e) Sprint Review Meeting Chart.
Comentários:
O artefato que permite que a equipe monitore seu progresso ao final de cada sprint é o Gráfico de
Burndown ou Release Burndown Chart. Todas as outras opções apresentam eventos!
Gabarito: Letra B
90.(FUNDATEC / ISS-Porto Alegre – 2022) No framework "Scrum", elabora-se uma lista ordenada
de tudo que é conhecido ser necessário no produto. Sobre essa lista, considere, ainda, as
seguintes características: (1) ela é a única origem dos requisitos para qualquer mudança a ser
feita no produto; (2) essa lista é dinâmica, mudando constantemente para identificar o que o
produto necessita para ser mais apropriado, competitivo e útil; (3) ela evolui tanto quanto o
101

Aula 04
produto e o ambiente no qual ele será utilizado; (4) nessa lista, constam todas as características,
funções, requisitos, melhorias e correções que formam as mudanças que devem ser feitas no
produto nas futuras versões. Nesse caso, pode-se afirmar que tal lista é chamada de:
a) Incremento.
b) Sprint Backlog.
c) Backlog Planning.
d) Product Backlog.
e) Definição de Pronto.
Comentários:
Única origem de requisitos para qualquer mudança a ser feita no produto? Pronto! Já dava para matar
a questão: Product Backlog!
Gabarito: Letra D
91. (CESGRANRIO / Banco da Amazônia – 2021) “O Scrum é um arcabouço que ajuda pessoas,
times e organizações a gerar valor por meio de soluções adaptativas para problemas
complexos.”
SCHWABER, K. ; SUTHERLAND, J. O Guia do Scrum, O Guia Definitivo para o Scrum: As Regras do Jogo. Nov. 2020. p 3. Adaptado.
Para cumprir seu objetivo, o Scrum se baseia em quatro eventos formais, contidos dentro de um
evento de maior duração: a Sprint. Tais eventos formais implementam os três pilares empíricos
do Scrum, que são:
a) compromisso, abertura e adaptação

b) respeito, coragem e foco
c) respeito, inspeção e adaptação
d) transparência, compromisso e respeito
e) transparência, inspeção e adaptação
Comentários:
Os três pilares são o TIA (Transparência, Inspeção e Adaptação).
Gabarito: Letra E
92. (COMPERVE / TJ-RN – 2020) O Scrum é um framework dentro do qual as pessoas podem tratar
e resolver problemas de forma ágil. O coração do Scrum são suas sprints. Segundo
o Scrum Guide, em um projeto que adota Scrum, a autoridade de cancelar uma sprint cabe ao:
a) Time scrum.
b) Scrum Master.
102

Aula 04
c) Product Owner.
d) Team manager.
Comentários:
Apenas o Product Owner tem autoridade para cancelar a sprint.
Gabarito: Letra C
93. (INSTITUTO AOCP / Prefeitura de Novo Hamburgo - RS – 2020) Assinale a alternativa que
apresenta uma metodologia para desenvolvimento de software:
a) BIM
b) BALANCED SCORECARD
c) COBIT
d) SCRUM
e) ISACA
Comentários:
(a) Errado, desconheço essa sigla; (b) Errado, trata-se de uma metodologia para medição e gestão
de desempenho; (c) Errado, trata-se de um framework de boas práticas para governança de
tecnologia da informação; (d) Correto; (e) Errado, trata-se de uma associação internacional que
suporta e patrocina o desenvolvimento de metodologias e certificações para o desempenho das
atividades de auditoria e controle em sistemas de informação.
Gabarito: Letra D
94.(UFCG / UFCG – 2019) A respeito do framework de trabalho Scrum, marque a alternativa

correta:
a) O eixo X do gráfico de burn-down representa a entrega planejada, em horas de trabalho ou

em pontos de histórias.
b) Essa framework não prevê acompanhamento diário, logo, a equipe se reúne somente no final
de uma sprint.
c) O Product Backlog é uma lista de funcionalidades esperadas para um produto.
d) Foco, comprometimento e respeito não fazem parte dos valores de Scrum.
e) Uma equipe Scrum é composta exclusivamente por um Product Owner e desenvolvedores,
sem ninguém responsável pelo treinamento desses desenvolvedores.
Comentários:
103

Aula 04
(a) Errado. O gráfico possui um eixo X que representa o tempo, que pode ser medido em dias,
semanas, sprints, entre outros. Enquanto o eixo Y demonstra a entrega planejada, que pode ser em
horas de trabalho ou em pontos de histórias; (b) Errado, uma das cerimônias é justamente a reunião
diária; (c) Correto; (d) Errado, os valores são justamente foco, comprometimento e respeito – além
de abertura e coragem; (e) Errado, há também o Scrum Master.
Gabarito: Letra C
95. (VUNESP / Prefeitura de Campinas – SP – 2019) No método ágil Scrum, há um artefato

denominado backlog, aplicado a diversas etapas do método. Em particular, o backlog do
produto corresponde a:
a) um conjunto de todos os produtos de software já desenvolvidos com o uso do Scrum.

b) uma lista das funcionalidades a serem implementadas no produto.
c) uma relação dos analistas envolvidos no desenvolvimento do produto.
d) um conjunto de normas seguidas pela empresa proprietária do produto.
e) uma relação dos futuros usuários do produto.
Comentários:
O Backlog do Produto é uma lista das funcionalidades a serem implementadas no produto –

nenhum dos outros itens faz qualquer sentido.
Gabarito: Letra B
96. (INSTITUTO AOCP / IBGE – 2019) O time de desenvolvimento de software do IBGE está
utilizando o método ágil Scrum para desenvolvimento de software. Sabendo disso, analise as
assertivas a respeito do framework do Scrum e assinale a alternativa que aponta a(s) correta(s).
I. Os papéis definidos pelo Scrum são: times de desenvolvimento, gerente de projetos e product
owner (PO).
II. A sprint retrospective proporciona ao time do Scrum uma oportunidade de avaliar o que foi
bem e o que pode ser melhorado na sprint que acabou de ser finalizada.
III. Apesar da importância do product backlog, ele não é o verdadeiro artefato do Scrum.
Assim, o seu verdadeiro artefato é o requisito do usuário.
a) Apenas I.
b) Apenas II.
c) Apenas III.
d) Apenas I e II.
e) Apenas II e III.
104

Aula 04
Comentários:
(I) Errado, é Product Owner, Scrum Master e Time de Desenvolvimento [Versão 2017] ou
Desenvolvedores [Versão 2020]; (II) Correto; (III) Errado, é claro que é um verdadeiro artefato.
Gabarito: Letra B
97. (INSTITUTO AOCP / EMPREL – 2019) Assinale a alternativa que apresenta uma das
características do Scrum referente ao Scrum Team (Time Scrum):
a) O time valida com o cliente as características (features) ou requisitos do produto.

b) Um líder determina como é a distribuição das tarefas e a programação aos pares.
c) O líder do time Scrum deve priorizar as funcionalidades que serão desenvolvidas.
d) É auto-organizável e não ultrapassa sete pessoas em sua composição.
e) Reuniões diárias são realizadas para possibilitar a interatividade das tarefas.
Comentários:
(a) Errado, o Product Owner valida com o cliente as características; (b) Errado, os desenvolvedores
são auto-organizados [Versão 2017] ou auto-gerenciados [Versão 2020]; (c) Errado, não existe um
líder e quem prioriza as funcionalidades é o Product Owner; (d) Errado, é realmente auto-
organizado [Versão 2017] ou auto-gerenciados [Versão 2020], mas a sua composição é de 5 a 11
pessoas [Versão 2017] ou normalmente 10 pessoas ou menos [Versão 2020]. Logo, não vejo essa
limitação de sete pessoas; (e) Errado, são realizadas para possibilitar a interatividade dos
desenvolvedores.
Gabarito: Letra D
98. (CESGRANRIO / UNIRIO – 2019) Uma equipe de desenvolvimento adota o método SCRUM
para gerenciar seu projeto. Para iniciar a reunião de planejamento da Sprint, deve(m)-se definir
e atualizar:
a) o Backlog do Produto
b) o plano de revisão da Sprint
c) o plano de retrospectiva da Sprint
d) a função de cada membro da equipe de desenvolvimento
e) as tarefas necessárias para cada história do usuário
Comentários:
Para iniciar a Reunião de Planejamento da Sprint, deve-se atualizar o backlog do produto.
Gabarito: Letra A
105

Aula 04
99. (CS-UFG / Prefeitura de Goianira - GO – 2019) De acordo com o Guia do Scrum,

uma sprint tem um período de duração de um mês aproximadamente, em que uma entrega,
versão incremental potencialmente utilizável, do produto é criada. Quais são, respectivamente
no tempo, os quatro eventos que constituem a sprint?
a) Reunião de escolha do backlog, reunião diária, reunião de refinamento e acompanhamento.

b) Reunião de planejamento, reunião diária, revisão e acompanhamento.
c) Reunião de escolha do backlog, reunião diária, reunião de refinamento e retrospectiva.
d) Reunião de planejamento, reunião diária, revisão e retrospectiva.
Comentários:
A ordem correta é: (1) Reunião de Planejamento da Sprint; (2) Reunião Diária; (3) Revisão da Sprint;
(4) Retrospectiva da Sprint.
Gabarito: Letra D
100. (IF-MT / IF-MT– 2019) Sutherland (2016), co-criador do Scrum, sugere que, para a
implementação de um projeto Ágil Scrum, algumas definições são a chave para sua condução e
sucesso.
I - Existe e evolui ao longo de toda a vida do produto, é o mapa do produto, é a visão única e
definitiva de "tudo que a equipe poderia um dia vir a realizar, em ordem de prioridade".
II - Tem a visão do que a equipe fará, produzirá ou realizará. Leva em consideração os riscos e
recompensas.
III - Treinará e ajudará outros integrantes da equipe a eliminarem qualquer coisa que esteja
diminuindo seu ritmo.
IV - Tem uma duração determinada que deve ser de menos do que um mês. Possui meta para
cada ciclo, e os ciclos são planejados para que nada seja alterado até sua conclusão.
Essas sentenças referem-se, respectivamente:
a) Scrum Master, Sprint, Product Owner e Backlog.

b) Sprint, Product Owner, Scrum Master e Backlog.
c) Backlog, Scrum Master, Product Owner e Sprint.
d) Sprint, Scrum Master, Product Owner e Backlog.
e) Backlog, Product Owner, Scrum Master e Sprint.
Comentários:
(I) Backlog do Produto: existe e evolui ao longo de toda a vida do produto, é o mapa do produto, é
a visão única e definitiva de "tudo que a equipe poderia um dia vir a realizar, em ordem de
106

Aula 04
prioridade"; (II) Product Owner: tem a visão do que a equipe fará, produzirá ou realizará. Leva em
consideração os riscos e recompensas; (III) Scrum Master: treinará e ajudará outros integrantes da
equipe a eliminarem qualquer coisa que esteja diminuindo seu ritmo; (IV) Sprint: tem uma duração
determinada que deve ser de menos do que um mês. Possui meta para cada ciclo, e os ciclos são
planejados para que nada seja alterado até sua conclusão.
Gabarito: Letra E
101. (IF-PE / IF-PE – 2019) A reunião de balanço sobre o que foi realizado durante uma sprint e
onde o time deve mostrar ao product owner os resultados obtidos é chamada de:
a) planejamento da sprint.
b) retrospectiva da sprint.
c) reunião diária.
d) revisão da sprint.
e) reunião de estimativas.
Comentários:
O enunciado trata da Revisão da Sprint – ela avalia o produto em si.
Gabarito: Letra D
102. (IF-PE / IF-PE – 2019) São características inerentes ao SCRUM:
I. implementação do conceito interativo e incremental no desenvolvimento de software e/ou

produtos.
II. a programação em pares.
III. valorização dos indivíduos envolvidos na construção do software.
Está(ão) CORRETO(S), apenas, o(s) item(ns):
a) I.
b) I e III.
c) I e II.
d) II e III.
e) I,II e III.
Comentários:
(I) Correto, apesar do deslize de chamar de interativo em vez de iterativo; (II) Errado, essa é uma
característica de uma metodologia ágil de desenvolvimento de software chamada Extreme
Progamming; (III) Correto, valorizam-se mais os indivíduos do que processos e ferramentas.
107

Aula 04
Gabarito: Letra B
103. (COMPERVE / UFRN – 2019) O Scrum é um framework no qual as pessoas podem abordar
problemas adaptativos complexos ao mesmo tempo em que entregam, de maneira produtiva e
criativa, produtos de mais alto valor possível. Nesse framework, existem três papéis
importantes, que são:
a) product owner, development team e scrum master.

b) product manager, scrum team e scrum master.
c) product leader, development team e scrum master.
d) product scrum, development team e development master.
Comentários:
Os três papeis importantes são: Product Owner, Scrum Master e Development Team [Versão 2017]
ou Developers [Versão 2020].
Gabarito: Letra A
104. (COSEAC / UFF – 2019) Em relação aos métodos ágeis, o responsável por garantir que a
equipe está aderindo aos valores do Scrum é representado por:
a) product owner.
b) time.
c) scrum master.
d) gerente de projetos.
e) stakeholders.
Comentários:
O responsável por garantir que a equipe está aderindo aos valores do Scrum é o Scrum Master.
Gabarito: Letra C
105. (IF-PA / IF-PA – 2019) A gestão de projetos é um dos grandes desafios no desenvolvimento
de produtos de software, pois uma gestão padronizada, aliada às boas práticas de
desenvolvimento minimizam os fracassos nos projetos de softwares. O Scrum é um dos
frameworks mais utilizados na gestão de projetos de software e sobre ele é correto afirmar.
a) Por definição, o seu ciclo é composto pela seguinte sequência: “Sprint”, “Sprint View” e “Daily
Scrum”.
108

Aula 04
b) Por definição, “Sprint Review” é uma reunião informal que ocorre ao final de cada “Sprint”
para avaliar o que foi feito, e se necessário, adaptar o “Backlog do Produto”.
c) O “Sprint Retrospective” é um plano feito pelo “Product Owner”, que demonstra como se
espera que o produto evolua ao longo do tempo.
d) O “Daily Review” é um evento de curta duração realizado todos os dias durante um “Sprint”,
neste evento, a equipe de desenvolvimento planeja o trabalho das próximas 24 horas.
e) É de responsabilidade exclusiva do “Scrum Master” a gerência dos itens do “Product Backlog”,

bem como as suas prioridades e objetivos do projeto.
Comentários:
(a) Errado, a sequência é Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospective; (b)
Correto, o guia afirma que se trata de uma reunião informal, não uma reunião de status, e a
apresentação do incremento destina-se a motivar e obter feedback e promover a colaboração; (c)
Errado, não é um plano, não é um feito pelo Product Owner e não demonstra como se espera que
o produto evolua ao longo do tempo – tudo errado no item; (d) Errado, não existe evento chamado
Daily Review; (e) Errado, é de responsabilidade do Product Owner.
Gabarito: Letra B
106. (FUNDATEC / Prefeitura de Gramado – RS – 2019) De acordo com o guia Scrum, analise as
assertivas a seguir:
I. Scrum é um framework para planejamento, programação e manutenção de produtos simples.

II. Três são os pilares para toda a implementação de um controle de processo empírico:
transparência, inspeção e adaptação.
III. O Scrum Team consiste de um Product Owner, o Development Team, e de um Scrum
Master.
IV. A Product Backlog é uma lista ordenada de tudo o que é conhecido como necessário ao
produto.
Quase estão corretas?
a) Apenas I e II.
b) Apenas II e III.
c) Apenas III e IV.
d) Apenas II, III e IV
e) I, II, III e IV.
Comentários:
109

Aula 04
(I) Errado, Scrum é um framework leve, simples de entender e extremamente difícil de dominar,
para desenvolver e manter produtos complexos e adaptativos, enquanto entrega produtiva e
criativamente produtos com o mais alto valor possível; (II) Correto; (III) Correto, sendo que na última
versão temos Desenvolvedores em vez de Time de Desenvolvimento; (IV) Correto.
Gabarito: Letra D
107. (CESGRANRIO / TRANSPETRO – 2018) Quando ocorre, no SCRUM, a reunião de

Retrospectiva da Sprint?
a) No fim da Sprint, antes da Reunião de Revisão

b) Entre a Reunião de Revisão da Sprint e a de Planejamento da próxima Sprint
==f219==
c) No início da Sprint, após a Reunião de Planejamento

d) No final de cada dia da Sprint
e) No início de cada dia da Sprint
Comentários:
A Retrospectiva da Sprint é a última reunião do Scrum, ocorrendo logo após a Revisão da Sprint. A
Revisão da Sprint busca avaliar o produto e a Retrospectiva da Sprint busca avaliar o Processo.
Gabarito: Letra B
108. (CESGRANRIO / TRANSPETRO – 2018) No uso de alguns métodos ágeis, como o SCRUM,
é comum que o esforço de desenvolvimento seja avaliado por meio de Pontos de História (Story
Points). Essa metodologia usa cartas, semelhantes a cartas de baralho, onde cada uma
apresenta um valor de uma escala de valores numéricos, que, normalmente, segue a seguinte
sequência:
a) 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10.
b) 0, 1, 2, 3, 5, 8, 13, 20, 40 e 100.
c) 0, 1, 2, 4, 8, 16, 32, 64, 128.
d) 1, 2, 3, 6, 12, 24, 48, 96.
e) 1, 5, 10, 50, 100, 500, 1000.
Comentários:
No início do Planning Poker, cada membro do time recebe um conjunto de cartas. Cada carta exibe
um dos valores válidos para a estimativa (0, 1, 2, 3, 5, 8, 13, 20, 40, e 100, por exemplo). Em geral,
os valores seguem uma escala baseada na Sequência de Fibonacci. Nota: outra sequência pode ser
escolhida, porém Fibonacci é a mais utilizada.
110

Aula 04
Gabarito: Letra B
109. (FAURGS / TJ-RS - 2018) Considere as seguintes afirmações sobre SCRUM.
I - Um sprint do SCRUM é uma unidade de planejamento na qual o trabalho a ser feito é avaliado,
os recursos para o desenvolvimento são selecionados e o software é implementado.
II - O ponto de partida para o planejamento é o backlog do produto, que é a lista do trabalho que
será feito no projeto. Durante a fase de avaliação do sprint, esta lista é revista e as prioridades e
os riscos são identificados. O cliente está totalmente envolvido nesse processo e, no início de
cada sprint, pode introduzir novos requisitos ou tarefas.
III - No SCRUM, há o papel do product owner, que é um facilitador que organiza reuniões diárias,
controlando o backlog de trabalho, registrando decisões, medindo o progresso, comparando-o
ao backlog e se comunica com os clientes e a gerência externa à equipe.
Quais estão corretas?
a) Apenas I.
b) Apenas I e II.
c) Apenas I e III.
d) Apenas II e III.
e) I, II e III.
Comentários:
(I) Correto, é durante a sprint que o software (ou outro produto) é implementado e avaliado com os
recursos necessários; (II) Correto, perfeita definição; (III) Errado, o facilitador é o Scrum Master e,
não, Product Owner.
Gabarito: Letra B
110. (Instituto Excelência / Prefeitura de São Carlos - SP – 2018) Considerando o Scrum, e os

papeis de partes interessadas, equipe e usuários. Avaliando as descrições abaixo defina os
papeis nas alternativas a seguir.
I) Atua como uma ponte entre a área de negócios, participa do planejamento das tarefas e do
objetivo define critérios de aceitação, este se compromete a não trazer mudanças dentro de
uma Sprint.
II) Assegura para que a equipe siga os valores e práticas, protege a equipe de alterações da Sprint
atua como facilitador removendo qualquer obstáculo ou algo levantado pela equipe
111

Aula 04
III) Lista contendo todas as funcionalidades desejada dos produtos com o tempo cresce ou muda
de acordo que se aprende sobre o usuário e seu produto:
a) I. Scrum Master II. Product Owner III. Product Backlog

b) I. Product Owner. II. Scrum Master. III. Product Backlog.
c) I. Sprint Master. II. Product Backlog. III. Scrum Master.
d) I. Product Backlog. II. Scrum Owner. III. Product Master.
e) Nenhuma das alternativas.
Comentários:
(I) Product Owner; (II) Scrum Master; (III) Product Backlog.
Gabarito: Letra B
111. (INSTITUTO AOCP / PRODEB – 2018) O SCRUM é um método ágil que caracteriza-se por
ter bem definido quais são os papéis que precisam estar envolvidos no desenvolvimento do
projeto. Sendo estes:
a) Scrum Master, Gerente do Projeto, Analista de Negócio e Product Owner.

b) Equipe do Projeto, Gerente do Projeto e Analista de Requisitos.
c) Gerente do Projeto, Product Owner e Gerente de Recursos Humanos.
d) Scrum Master, Product Owner e Equipe do Projeto.
e) Product Owner, Gerente de Projetos, PMO e Analista de Negócios.
Comentários:
Os papeis são: Scrum Master, Product Owner e Development Team [Versão 2017] ou Developers
[Versão 2020]. A questão viajou e trocou Equipe de Desenvolvimento por Equipe do Projeto.
Gabarito: Letra D
112. (INSTITUTO AOCP / PRODEB – 2018) Consiste de profissionais que realizam o trabalho de
entregar uma versão usável que potencialmente incrementa o produto “Pronto” ao final de cada
Sprint:
a) Time de Desenvolvimento.
b) Product Owner.
c) Scrum Master.
d) Stakeholder.
e) Sprintholder.
Comentários:
112

Aula 04
Os profissionais que realizam o trabalho de entregar uma versão usável que potencialmente
incrementa o produto “Pronto” ao final de cada sprint é o Time de Desenvolvimento [Versão 2017]
ou Desenvolvedores [Versão 2020].
Gabarito: Letra A
113. (INSTITUTO AOCP / PRODEB – 2018) O Product Owner exerce um papel fundamental para
a execução de um produto de sucesso dentro de um determinado método ágil. Ele é responsável
por realizar a comunicação entre o cliente e a equipe que está desenvolvendo o projeto. Em qual
método o Product Owner é considerado um dos três papéis que constituem a equipe?
a) Cascata.
b) Lean.
c) Scrum.
d) Espiral.
e) Prototipação.
Comentários:
Product Owner é um papel do Scrum!
Gabarito: Letra C
114. (INSTITUTO AOCP / ADAF - AM – 2018) Scrum é uma metodologia ágil para gestão e
planejamento de projetos de software. No Scrum, os projetos são divididos em ciclos e tendem
a ser mais rápidos que a metodologia tradicional. No Scrum, existem três papéis. São eles:
a) Sprint; Stakeholders; Secretária.

b) Artefatos; Linguagem de Programação; Reuniões.
c) Product Owner; Scrummaster; Equipe.
d) Programador; Analista; Tester.
e) Gerente de sistemas; Sprint; Planejamento.
Comentários:
Os papeis são: Scrum Master, Product Owner e Development Team [Versão 2017] ou Developers
[Versão 2020]. A questão viajou e trocou Equipe de Desenvolvimento por Equipe do Projeto.
Gabarito: Letra C
115. (INSTITUTO AOCP / UFOB – 2018) Scrum é um método de desenvolvimento ágil. Esse
método envolve as etapas de requisitos, análise, projeto, evolução e entrega do software.
113

Aula 04
Comentários:
Não existem essas etapas, não há nada sobre isso no Guia Scrum. No entanto, a banca considerou
a questão como correta.
Gabarito: Correto
116. (AOCP / UNIR – 2018) O Backlog da Sprint é a recomendação do trabalho que o Time
identifica como necessário para alcançar a meta da Sprint. Os itens do Backlog da Sprint devem
ser íntegros.
Comentários:
Backlog da Sprint é uma lista do trabalho a ser desenvolvida pela Equipe de Desenvolvimento
[Versão 2017] ou Desenvolvedores [Versão 2020]. Trata-se de uma previsão sobre qual
funcionalidade estará no próximo incremento e sobre o trabalho necessário para entregar essa
funcionalidade em um incremento “Pronto”. Logo, não se trata de uma recomendação. Por fim,
não entendi o que o examinador quis dizer com itens íntegros.
Gabarito: Errado
117. (AOCP / UNIR – 2018) O Product Owner é um comitê responsável pelo gerenciamento do
Backlog do Produto e por garantir o valor do trabalho realizado pelo Time Scrum.
Comentários:
O Product Owner é uma pessoa e não um comitê. O Product Owner pode representar o desejo de
um comitê no Backlog do Produto, mas aqueles que quiserem uma alteração nas prioridades dos
itens de Backlog devem endereçar ao Product Owner.
Gabarito: Errado
118. (AOCP / UNIR – 2018) O ScrumMaster é responsável por garantir que o Time Scrum esteja
aderindo aos valores do Scrum, às práticas e às regras. Também ajuda o Time Scrum e a
organização a adotarem o Scrum e treina e leva o Time Scrum a ser mais produtivo e a
desenvolver produtos de maior qualidade.
Comentários:
O Scrum Master é responsável por garantir que o Scrum seja entendido e aplicado. Ele faz isso para
garantir que o Time Scrum adere à teoria, práticas e regras do Scrum. Ele é um servo-líder para o
Time Scrum e ajuda aqueles que estão fora do Time Scrum a entender quais as suas interações com
114

Aula 04
o Time Scrum são úteis e quais não são. Ele também ajuda todos a mudarem estas interações para
maximizar o valor criado pelo Time Scrum.
Gabarito: Correto
119. (AOCP / UNIR – 2018) O framework Scrum consiste em um conjunto formado por Times
Scrum e seus papéis associados, Eventos com Duração Fixa (Time-Boxes), Artefatos e Regras.
Comentários:
Eu novamente enfatizaria que são eventos com duração máxima fixa, mas a questão está correta.
Gabarito: Correto
120. (INSTITUTO AOCP / UFOB – 2018) No Scrum, são utilizados encontros diários, os
chamados Daily Scrum, para disseminar o conhecimento desenvolvido no dia anterior.
Comentários:
Perfeito! A Reunião Diária do Scrum é um evento time-boxed de 15 minutos para o Time de

Desenvolvimento. A Reunião Diária é realizada em todos os dias da Sprint. Nela o Time de
Desenvolvimento planeja o trabalho para as próximas 24 horas. Isso otimiza a colaboração e a
performance do time através da inspeção do trabalho desde a última Reunião Diária, e da previsão
do próximo trabalho da Sprint.
Gabarito: Correto
121. (INSTITUTO AOCP/ PRODEB – 2018) Sobre a retrospectiva de Sprint usando Scrum,
assinale a alternativa correta:
a) Ocorre depois da Revisão da Sprint.

b) Equivale à Revisão da Sprint.
c) É uma oportunidade para o Time Scrum inspecionar outros times.
d) Tem como objetivo resolver os itens que não foram concluídos durante a sprint.
e) É onde se planeja a próxima Sprint.
Comentários:
(a) Correto; (b) Errado, revisão avalia o produto e retrospectiva avalia o processo; (c) Errado, é uma
oportunidade para inspecionar o processo do próprio time; (d) Errado, não faz sentido algum; (e)
Errado, isso ocorre no planejamento da sprint.
Gabarito: Letra A
115

Aula 04
122. (FUNDATEC / SPGG – RS – 2018) O framework Scrum prescreve os seguintes eventos

formais para inspeção e adaptação:
a) Sprint e Daily Scrum.

b) Sprint Backlog e Daily Scrum.
c) Sprint Review e Sprint Backlog.
d) Product Backlog e Sprint Backlog.
e) Sprint Retrospective e Daily Scrum.
Comentários:
(a) Errado, Sprint não é um evento formal; (b) Errado, Sprint Backlog é um artefato; (c) Errado,
Sprint Backlog é um artefato; (d) Errado, ambos são artefatos; (e) Correto, ambos são eventos
formais para inspeção e adaptação.
Gabarito: Letra E
123. (FUNDATEC / SPGG – RS – 2018) Considere as seguintes assertivas sobre o framework

Scrum:
I. Emprega uma abordagem iterativa e incremental para aperfeiçoar a previsibilidade e o

controle de riscos.
II. Fundamenta-se em teorias empíricas de controle de processo, como, por exemplo, na
transparência.
III. São valores fundamentais do Scrum: comprometimento, coragem, foco, transparência e
respeito.
a) Apenas I.
b) Apenas III.
c) Apenas I e II.
d) Apenas II e III.
e) I, II e III.
Comentários:
(I) Correto, ele realmente utiliza uma abordagem iterativa e incremental, o que ajuda a gerenciar os
riscos do projeto; (II) Correto, é baseado no empirismo e um de seus pilares é a transparência; (III)
Correto, todos esses realmente são valores fundamentais.
Gabarito: Letra E
116

Aula 04
124. (FUNDATEC / SPGG - RS – 2018) Sobre o cancelamento de uma Sprint,

no framework Scrum, afirma-se que:
a) Somente o Scrum Master tem a autoridade para cancelar uma Sprint.

b) Somente o Product Owner tem a autoridade para cancelar uma Sprint.
c) Uma Sprint não pode ser cancelada antes de terminar o seu time-boxed.
d) Uma Sprint somente pode ser cancelada pelo cliente caso o seu time-boxed ainda não tenha
iniciado.
e) Uma Sprint somente pode ser cancelada pelo Time de Desenvolvimento caso o seu time-
boxed ainda não tenha iniciado.
Comentários:
(a) Errado, somente o Product Owner; (b) Correto; (c) Errado, pode ser cancelada, sim; (d) Errado,
ela pode ser cancelada ainda que ele já tenha iniciado; (e) Errado, ela não pode ser cancelada pelo
Time de Desenvolvimento [Versão 2017] ou Desenvolvedores [Versão 2020].
Gabarito: Letra B
125. (FAPEC / UFMS – 2018) Assinale a alternativa correta considerando as responsabilidades e

os papéis na metodologia SCRUM.
a) O responsável por gerenciar o Product Backlog (garantindo que esteja visível para todos),
gerar e disseminar os requisitos do projeto, assim como o plano para as entregas sucessivas,
priorizando os resultados que trarão maior valor agregado ao projeto, é o Product Owner.
b) O responsável por implementar o método Scrum, assim como por ensiná-lo a todos os
envolvidos nos projetos e assegurar que todos sigam as suas regras e práticas é
denominado Time Scrum.
c) O grupo de desenvolvedores que é coletivamente responsável pelo sucesso de cada iteração

e do projeto como um todo é conhecido como Scrum Masters.
d) O grupo de gerentes com responsabilidade de avaliar os custos do projeto é

denominado Scrum Cost.
e) O grupo de usuários finais do produto desenvolvido durante o projeto é denominado Scrum

Users.
Comentários:
117

Aula 04
(a) Correto; (b) Errado, é o Scrum Master; (c) Errado, é conhecido como Equipe de Desenvolvimento
[Versão 2017] ou Desenvolvedores [Versão 2020]; (d) Errado, esse papel não existe no Guia Scrum;
(e) Errado, esse papel não existe no Guia Scrum.
Gabarito: Letra A
126. (FAPEC / UFMS – 2018) Considere as afirmações a seguir sobre as fases da metodologia
SCRUM.
I - Product Backlog é uma lista ordenada por prioridade, produzida antes do início do
desenvolvimento, de itens que representam o que será produzido ao longo do projeto.
II - Cada ciclo de Sprint inicia com uma reunião de Sprint Planning.
III - Em cada ciclo de Sprint a reunião de Sprint Retrospective é realizada antes da reunião
de Daily Scrum.
Está(ão) correta(s):
a) Apenas I.
b) Apenas II.
c) Apenas I e II.
d) Apenas II e III.
e) I, II e III.
Comentários:
(I) Correto; (II) Correto; (III) Errado, é realizada ao final da sprint – é a última cerimônia da sprint.
Gabarito: Letra C
127. (INSTITUTO AOCP/ PRODEB – 2018) Considerando a metodologia Scrum, assinale a

alternativa que discorre corretamente sobre o que significa quando o item do Backlog do
Produto ou um incremento é descrito como “Pronto”:
a) A interpretação varia significativamente de um extremo ao outro para cada Time Scrum.

b) Cada integrante do time tem sua própria interpretação.
c) Significa Pronto para ser testado.
d) Significa Pronto para liberação em produção.
e) Significa que está pronto para ser implementado, ou seja, especificado.
Comentários:
De acordo com o guia: “Quando um item do Backlog do Produto ou um incremento é descrito como
“Pronto”, todos devem entender o que o “Pronto” significa. Embora, isso possa variar por Time Scrum,
118

Aula 04
os integrantes devem ter um entendimento compartilhado do que significa o trabalho estar completo,
assegurando a transparência. Esta é a “Definição de Pronto” para o Time Scrum e é usado para
assegurar quando o trabalho está completado no incremento do produto”.
(a) Correto, cada Time Scrum pode interpretar o que será o “pronto”; (b) Errado, a interpretação
dentro do time deve ser a mesma; (c) Errado, significa que o trabalho do incremento está completo;
(d) Errado, significa que o trabalho do incremento está completo; (e) Errado, significa que o trabalho
do incremento está completo.
Gabarito: Letra A
128. (INSTITUTO AOCP/ PRODEB – 2018) Sobre as características gerais do Scrum, assinale a
alternativa correta:
a) Não prioriza feedback.

b) Seus princípios são consistentes com o manifesto ágil.
c) Foi proposto após os anos 2000.
d) Incorpora desenvolvimento mas não requisitos.
e) Não se adapta bem a requisitos mutáveis.
Comentários:
(a) Errado, tanto prioriza que a cerimônia de retrospectiva tem esse objetivo; (b) Correto; (c) Errado,
foi proposto no início dos anos 1990; (d) Errado, incorpora ambos; (e) Errado, pelo contrário, ele se
adapta super bem a requisitos mutáveis.
Gabarito: Letra B
129. (INSTITUTO AOCP/ PRODEB – 2018) Sobre o método ágil denominado SCRUM, faça uma
análise das assertivas e assinale a alternativa que apresente somente práticas do método
SCRUM.
I. Sprint Planning Meeting (Reunião de Planejamento da Sprint).

II. Spikes Solution (Spikes de Planejamento).
III. Sprint Backlog (Backlog da Sprint).
IV. Client on Site (Clientes no Local).
a) Apenas I e II.
b) Apenas III.
c) Apenas II e IV.
d) Apenas II e III.
e) Apenas I e III.
119

Aula 04
Comentários:
A questão chama de prática o que seria idealmente chamado de evento. Logo, Sprint Planning
Meeting e Sprint Backlog são os eventos formais. Já o Client On Site e Spike Solution são realmente
práticas, mas do Extreme Programming e, não, do Scrum.
Gabarito: Letra E
130. (CESGRANRIO / Transpetro – 2018) A metodologia de desenvolvimento SCRUM é

caracterizada por ser ágil e rápida nas entregas. Um dos elementos-chave do processo SCRUM
é o Sprint, que é uma fase que acontece:
a) no fim do projeto, onde todos se esforçam para compensar os atrasos e cumprir o prazo.
b) no início do projeto, onde se procura entregar logo um grande volume de itens do projeto
para não arriscar atrasos.
c) sempre que necessário para compensar um atraso.
d) recorrentemente, ocorrendo de forma cíclica, várias vezes, até que se atinja o escopo do
projeto.
e) eventualmente, se necessário, caso ocorram eventos adversos não previstos que atrasem o
projeto.
Comentários:
Sprints ocorre recorrentemente, ocorrendo de forma cíclica, várias vezes, até que se atinja o escopo
do projeto – nenhum dos outros itens faz qualquer sentido.
Gabarito: Letra D
131. (INSTITUTO AOCP / PRODEB – 2018) Sobre a definição de Scrum, assinale a alternativa
correta.
a) Scrum é um processo para construir produtos.

b) Scrum é um framework dentro do qual você pode empregar vários processos ou técnicas.
c) Scrum é uma técnica para construir produtos de software.
d) Scrum não permite resolver problemas complexos.
e) Scrum é considerado extremamente fácil de dominar.
Comentários:
(a) Errado, não é um processo ou uma técnica para construir produtos – em vez disso, é um
framework dentro do qual você pode empregar vários processos ou técnicas; (b) Correto; (c) Errado,
ele não é uma técnica; (d) Errado, ele é um framework dentro do qual pessoas podem tratar e
resolver problemas complexos e adaptativos, enquanto produtiva e criativamente entregam
120

Aula 04
produtos com o mais alto valor possível; (e) Errado, ele é leve, simples de entender e extremamente
difícil de dominar.
Gabarito: Letra B
132. (INSTITUTO AOCP / PRODEB – 2018) Em relação ao Backlog do Produto utilizando Scrum,
assinale a alternativa INCORRETA.
a) É uma lista ordenada de tudo que deve ser necessário no produto.

b) É uma origem única dos requisitos para qualquer mudança a ser feita no produto.
Requisitos nunca param de mudar, então o Backlog do Produto é um artefato vivo.
c) Mudanças de condições de mercado ou tecnologia podem causar mudanças no Backlog do
Produto.
d) Um Backlog do Produto deve estar completo antes do início da primeira Sprint.
Comentários:
Todos os itens estão corretos, exceto o último! Um Backlog do Produto nunca está completo. Os
primeiros desenvolvimentos estabelecem os requisitos inicialmente conhecidos e melhor
entendidos. O Backlog do Produto evolui tanto quanto o produto e o ambiente no qual ele será
utilizado evoluem. O Backlog do Produto é dinâmico; mudando constantemente para identificar o
que o produto necessita para ser mais apropriado, competitivo e útil. Se um produto existe, seu
Backlog do Produto também existe.
Gabarito: Letra E
133. (INSTITUTO AOCP / PRODEB – 2018) Considerando a realização de Reuniões diárias

utilizando Scrum, assinale a alternativa correta.
a) Serve para sincronizar as atividades e criar um plano para as próximas 12 horas.

b) Deve ser mantido no mesmo horário e local todo dia a fim de reduzir a complexidade.
c) Deve ter um time-box de, no máximo, 2h.
d) Não há regra clara sobre quem deve participar dessas reuniões.
e) Discussões detalhadas após a reunião diária são desencorajadas.
Comentários:
(a) Errado, o plano é para as próximas 24 horas; (b) Correto; (c) Errado, é de no máximo 15 minutos;
(d) Errado, somente desenvolvedores podem participar; (e) Errado, elas são incentivadas.
Gabarito: Letra B
121

Aula 04
134. (FUNDATEC / CIGA-SC – 2018) Para responder à questão, considere a Figura 7, obtida a
partir do site <>, mostra, esquematicamente, uma visão geral do framework ou metodologia
ágil chamada Scrum. Nessa Figura, inseriu-se, em alguns locais, um retângulo, de modo a
ocultar inscrições existentes em tais locais.
Analise as seguintes assertivas sobre a metodologia ou framework ágil Scrum mostrada na

Figura 7:
I. A seta nº 1 aponta para uma etapa do framework chamada Product Backlog, que é uma lista
das funcionalidades desejadas para um produto. No Scrum, o conteúdo dessa lista é definido e
mantido pelo Scrum Master.
II. A seta nº 2 aponta para uma atividade chamada de Daily Scrum, que consiste em reuniões
diárias envolvendo, sempre que possível, toda a equipe de projeto, como, por exemplo, Product
Owner, Scrum Master, Scrum Team e Representante do Cliente, para avaliarem, em conjunto,
o andamento do projeto, assim como na identificação e resolução imediata dos problemas, de
modo que eles não evoluam e comprometam o andamento dos trabalhos.
III. No Scrum, a equipe monitora seu progresso em relação a um plano estabelecido, por meio
da atualização de um Release Burndown Chart, ao final de cada Sprint.
a) Apenas I.
b) Apenas II.
c) Apenas III.
d) Apenas I e III.
e) I, II e III.
Comentários:
(I) Errado. Ela realmente aponta para o Product Backlog, mas ele não é uma etapa – é um artefato.
Além disso, ele é mantido pelo Product Owner e, não, pelo Scrum Master; (II) Errado. Ela envolve
apenas os desenvolvedores e, não, toda a equipe do projeto; (III) Correto.
122

Aula 04
Gabarito: Letra C
135. (FUNRIO / Câmara de São João de Meriti - RJ – 2018) SCRUM é um framework dentro do
qual pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva
e criativamente entregam produtos com o mais alto valor possível. O SCRUM chama seus
eventos de timeboxes, uma vez que são eventos de duração fechada, sendo o componente
principal conhecido por Sprint, havendo alguns tipos, dos quais quatro são detalhados a seguir:
( I ) Time-boxe de 8h, de acordo com o tamanho da Sprint. Nesta reunião é onde o Product
Owner é ouvido em relação às prioridades e os objetivos. É nela também onde o time irá
deliberar sobre o que conseguem fazer em relação às necessidades, formalizando o Sprint
Backlog.
( II ) Time-box de 4h, onde o incremento do produto que está pronto para uso, é apresentado
ao Product Owner para apreciação. Também é nesta reunião, que deve ser facilitada pelo Scrum
Master, que o Product Owner apresentará os números, gráficos e tudo o mais que for
importante à equipe saber sobre o produto. Novas prioridades e movimentos do mercado, tudo
focado em manter os objetivos coerentes ao longo das sprints. Esse é o evento que melhor
representa o pilar de inspeção do Scrum.
( III ) Time-box de 3h onde o time de desenvolvedores e o Scrum Master, que atua apenas como
facilitador, falam sobre os resultados obtidos na Sprint que passou e as lições tiradas, para a
partir daí melhorar o processo, fortemente arraigado ao pilar de adaptação.
( IV ) Time-boxe de 15 min, sempre no mesmo local e horário para gerar consistência e evitar
perda de tempo, facilitada pelo Scrum Master. Nesta reunião, que deve ser muito dinâmica e
que popularmente é feita em pé, para evitar prolongamentos e distrações, cada membro do
time deve responder apenas três perguntas: o que eu fiz ontem, o que eu vou fazer hoje e se tem
algo me impedindo.
Os tipos (I), (II), (III) e (IV) são denominados respectivamente:
a) Sprint Retrospective, Daily Scrum, Sprint Planning e Sprint Review.

b) Sprint Planning, Sprint Rewiew, Daily Scrum e Sprint Retrospective.
c) Sprint Planning, Sprint Review, Sprint Retrospective e Daily Scrum.
d) Sprint Planning, Sprint Retrospective, Sprint Review e Daily Scrum.
e) Daily Scrum, Sprint Planning, Sprint Retrospective e Sprint Review.
Comentários:
(Sprint Planning) Time-boxe de 8h, de acordo com o tamanho da Sprint. Nesta reunião é onde
o Product Owner é ouvido em relação às prioridades e os objetivos. É nela também onde o time irá
deliberar sobre o que conseguem fazer em relação às necessidades, formalizando o Sprint Backlog.
123

Aula 04
(Sprint Review) Time-box de 4h, onde o incremento do produto que está pronto para uso, é
apresentado ao Product Owner para apreciação. Também é nesta reunião, que deve ser facilitada
pelo Scrum Master, que o Product Owner apresentará os números, gráficos e tudo o mais que for
importante à equipe saber sobre o produto. Novas prioridades e movimentos do mercado, tudo
focado em manter os objetivos coerentes ao longo das sprints. Esse é o evento que melhor
representa o pilar de inspeção do Scrum.
(Sprint Retrospective) Time-box de 3h onde o time de desenvolvedores e o Scrum Master, que atua
apenas como facilitador, falam sobre os resultados obtidos na Sprint que passou e as lições tiradas,
para a partir daí melhorar o processo, fortemente arraigado ao pilar de adaptação.
(Daily Scrum) Time-boxe de 15 min, sempre no mesmo local e horário para gerar consistência e
evitar perda de tempo, facilitada pelo Scrum Master. Nesta reunião, que deve ser muito dinâmica e
que popularmente é feita em pé, para evitar prolongamentos e distrações, cada membro do time
deve responder apenas três perguntas: o que eu fiz ontem, o que eu vou fazer hoje e se tem algo
me impedindo.
Gabarito: Letra C
136. (FAURGS / UFCSPA - RS – 2018) ____________ é uma metodologia ágil que fornece
um framework de gerenciamento de projetos. É centralizada em torno de um conjunto
de sprints, que são períodos determinados de tempo, quando um incremento de sistema é
desenvolvido. O planejamento é baseado na priorização de um backlog de trabalho e na seleção
das tarefas mais importantes para um sprint.
a) MDE – Engenharia Dirigida a Modelos

b) XP
c) SCRUM
d) MDA – Arquitetura Dirigida a Modelos
e) Programação em Pares
Comentários:
Scrum é uma metodologia ágil que fornece um framework de gerenciamento de projetos. É

centralizada em torno de um conjunto de sprints, que são períodos determinados de tempo,
quando um incremento de sistema é desenvolvido. O planejamento é baseado na priorização de
um backlog de trabalho e na seleção das tarefas mais importantes para um sprint.
Gabarito: Letra C
124

Aula 04
137. (IADES / APEX-BRASIL – 2018) Na metodologia Scrum, existem times que tipicamente
consistem de um dono do produto, um mestre Scrum e um time de desenvolvimento. Acerca
das respectivas responsabilidades, é correto afirmar que o:
a) mestre Scrum é o responsável por maximizar o valor do produto que resulta do trabalho do
time de desenvolvimento.
b) mestre Scrum é responsável por gerenciar o backlog do produto.
c) time de desenvolvimento tem autonomia para organizar e gerenciar seu próprio trabalho.
d) dono do produto é responsável por promover e suportar o Scrum, ajudando a todos

entenderem a teoria.
e) time de desenvolvimento garante que o dono do produto saiba como organizar o backlog do
produto para maximar o valor.
Comentários:
(a) Errado, esse seria o Product Owner; (b) Errado, esse seria o Product Owner; (c) Correto; (d)
Errado, esse seria o Scrum Master; (e) Errado, esse seria o Scrum Master.
Gabarito: Letra C
138. (PR4 / UFRJ – 2018) Assinale a alternativa que apresenta apenas papéis recomendados no
Framework Scrum.
a) Time Scrum, Scrum Master, Product Owner.

b) Time Scrum, Scrum Tester, Product Owner.
c) Time Scrum, Scrum Manager, Product Owner.
d) Scrum Manager, Scrum Tester, Product Owner.
e) Scrum Manager, Scrum Tester, Scrum Master.
Comentários:
Para mim, não há resposta! Os papeis são: Scrum Master, Product Owner e Time de
Desenvolvimento [Versão 2017] ou Desenvolvedores [Versão 2020]. Não existe o papel de Time
Scrum – esse é apenas o conjunto dos outros papeis.
Gabarito: Letra A
139. (UFG / SANEAGO – 2017) Na metodologia SCRUM, quais são os itens registrados dentro de
uma “Retrospectiva”?
125

Aula 04
a) Pontos positivos, negativos e melhorias para a próxima iteração.

b) Itens entregues e itens a serem desenvolvidos.
c) Itens não entregues a serem desenvolvidos na próxima iteração.
d) Estimativas para o desenvolvimento de funcionalidades escolhidas pelo cliente
Comentários:
A Restrospectiva da Sprint busca inspecionar como a última sprint realizada em relação às pessoas,
aos relacionamentos, aos processos e às ferramentas; identificar e ordenar os principais itens que
foram bem e as potenciais melhorias; e criar um plano para implementar melhorias no modo que o
Time Scrum faz seu trabalho. Em suma, registram-se os pontos positivos, negativos e melhorias
para a próxima iteração.
Gabarito: Letra A
140. (UFG / SANEAGO – 2017) O pré-planejamento (também conhecido como pré-game) é uma
das cerimônias conhecidas da metodologia SCRUM. Por definição, é objetivo deste pré-
planejamento:
a) integração do software entregue na última interação com a versão que será desenvolvida.
b) distribuição dos pacotes de trabalho entre os membros da equipe.
c) detalhamento, priorização e estimativa de desenvolvimento dos pacotes de trabalho.
d) levantamento de pontos positivos, negativos e melhorias no processo.
Comentários:
O pré-planejamento define o sistema sendo desenvolvido. Cria-se o Product Backlog, que contém
todos os requisitos atuais e informações sobre o planejamento do projeto. Cria-se também uma
arquitetura de alto nível. No entanto, essa questão foi anulada porque o pré-planejamento não é
uma das quatro cerimônias tradicionais do Scrum!
Gabarito: Anulada
141. (UFG / SANEAGO – 2017) Dentro do método SCRUM, quais são as informações utilizadas
para criar o gráfico burndown?
a) Tempo total da sprint e esforço estimado para as tarefas não realizadas.

b) Tempo gasto na resolução das tarefas do projeto e estimativas para as tarefas não realizadas.
c) Tempo gasto na sprint anterior e esforço de tarefas já realizadas.
d) Tempo total na resolução de impedimentos e estimativas para finalização do projeto.
Comentários:
126

Aula 04
O Gráfico de Burndown torna visível a evolução diária do trabalho da equipe de desenvolvimento,

na medida em que mostra a comparação entre o trabalho estimado inicialmente com a quantidade
restante estimada de trabalho (estimado x realizado). Via de regra, as unidades utilizadas são de
esforço (em horas) planejado pelo tempo decorrido. Em suma: ele mostra o tempo/esforço
realizado versus o tempo/esforço estimado. A primeira opção é a que mais se aproxima disso, mas
as questões dessa banca são bastante confusas.
Gabarito: Letra A
142. (UFG / SANEAGO – 2017) Faz parte do conjunto de eventos do SCRUM um encontro
conhecido em inglês por Daily SCRUM. O Daily Scrum:
a) tem a duração fixa de 15 minutos.

b) é o instrumento empregado para relatar o progresso do projeto.
c) ocorre uma vez por semana.
d) é um encontro do qual o Scrum Master não participa.
Comentários:
(a) Errado, a Daily Scrum tem uma duração de até 15 minutos; (b) Errado, essa reunião não tem esse
objetivo; (c) Errado, essa reunião é diária; (d) Errado, ele participa, sim.
No entanto, a questão foi anulada porque todos os itens são errados com a seguinte justificativa:
“Depreende-se que a time-box de 15 minutos não é fixa, mas sim um intervalo de até 15 minutos”.
Gabarito: Anulada
143. (UFG / SANEAGO – 2017) Em uma equipe que trabalha orientada pelo Scrum,
a) a descoberta de um "erro" ou "defeito" recebe máxima prioridade e justifica a extensão da

Sprint por até 15 dias.
b) a identificação de novos requisitos pode ser feita durante reunião (Daily Scrum), na qual estão
presentes clientes do futuro produto.
c) o Scrum Master é responsável por orientar a equipe de desenvolvimento e definir como

transformar itens do backlog no incremento proposto para a sprint em questão.
d) a responsabilidade pela produção do incremento cabe a toda a equipe de desenvolvimento,

a despeito de um determinado membro da equipe possuir habilidades específicas.
Comentários:
127

Aula 04
(a) Errado, não se estende prazo de sprint; (b) Errado, Product Owner é o único responsável por
identificar novos requisitos; (c) Errado, Scrum Master é um facilitador e especialista no Scrum – ele
não tem essa prerrogativa; (d) Correto, a responsabilidade é da equipe de desenvolvimento e, não,
de um desenvolvedor em particular [Versão 2017].
Gabarito: Letra D
144. (ESAF / ESAF – 2015) O SCRUM é uma metodologia ágil para gestão e planejamento de
projetos de software. Nele, as funcionalidades a serem implementadas em um projeto são
mantidas em uma lista que é conhecida como ____________. No início de cada Sprint, faz-se
um ____________ na qual o ____________ prioriza os itens do ____________ e a equipe
seleciona as atividades que ela será capaz de implementar durante o Sprint que se inicia. As
tarefas alocadas em um Sprint são transferidas do ____________ para o ____________ .
a) Product Backlog, Sprint Backlog, Product Owner, Product Backlog, Sprint Planning Meeting
e Product Backlog.
b) Sprint Planning Meeting, Product Backlog, Product Owner, Product Backlog, Product
Backlog e Sprint Backlog.
c) Product Backlog, Sprint Planning Meeting, Product Owner, Product Backlog, Sprint Backlog
e Product Backlog.
d) Product Backlog, Sprint Planning Meeting, Product Backlog, Sprint Backlog, Product
Backlog, e Product Owner.
e) Product Backlog, Sprint Planning Meeting, Product Owner, Product Backlog, Product
Comentários:
O Scrum é uma metodologia ágil para gestão e planejamento de projetos de software. Nele, as
funcionalidades a serem implementadas em um projeto são mantidas em uma lista que é conhecida
como Product Backlog No início de cada Sprint, faz-se um Sprint Planning Meeting na qual o Product
Owner prioriza os itens do Product Backlog e a equipe seleciona as atividades que ela será capaz de
implementar durante o Sprint que se inicia. As tarefas alocadas em um Sprint são transferidas do
Product Backlog para o Sprint Backlog.
Gabarito: Letra E
145. (CESGRANRIO / CEFET-RJ – 2014) No Scrum, segundo o guia 2013, o responsável pelo
trabalho de expressar claramente os itens do Backlog do Produto é o:
128

Aula 04
a) Product Master
b) Product Owner
c) Scrum Master
d) Scrum Owner
e) Time de Desenvolvimento
Comentários:
O Product Owner é o responsável por definir os itens que compõem o Product Backlog e também
por priorizá-los nas Sprint Planning Meetings (Reuniões de Planejamento da Sprint).
Gabarito: Letra B
146. (CESGRANRIO / EPE – 2014) No planejamento de projetos de software, e principalmente

em metodologias ágeis de desenvolvimento, muitos autores defendem a técnica conhecida
como “timebox”, que:
a) estima o menor e o maior tempo de desenvolvimento para cada funcionalidade a ser

desenvolvida, definindo uma “caixa” de tempo em vez de um prazo fixo.
b) parte do tempo disponível em uma fábrica de software para especificar versões consecutivas
de um produto, conhecidas como “caixas”
c) divide um produto de software em versões de complexidade crescente, conhecidas como

“caixas”, especificando o tempo de desenvolvimento de cada caixa do mais rápido para o mais
longo.
d) define um tempo para cada função a ser desenvolvida e as aloca em “caixas” de igual tempo
de desenvolvimento que são escolhidas pelos desenvolvedores.
e) define o tempo a ser utilizado em um ciclo de desenvolvimento e depois define a

funcionalidade que pode ser desenvolvida naquela “caixa” de tempo.
Comentários:
Todas as atividades do Scrum são time-boxed, isto é, ocorrem sob um segmento de tempo de
“duração fixa” para um evento ou atividade específica. Essa unidade de tempo é chamada de Time
Box. O objetivo é definir e limitar a quantidade máxima de tempo dedicado para executar um
conjunto de atividades. Dessa forma, em vez de começar a trabalhar em algo até sua finalização de
forma indefinida, é acordado de antemão o tempo limite para cada tarefa de projeto (tempo fixo e
escopo variável).
129

Aula 04
Gabarito: Letra E
147. (UNIRIO / UNIRIO – 2014) De acordo com o autor Schwaber, o Scrum é um framework para
desenvolvimento e manutenção de produtos complexos baseado em três pilares, que são:
a) simplicidade, reflexão, organização.

b) transparência, inspeção e adaptação.
c) Scrum master, product owner, time de desenvolvimento.
d) backlog (do produto e do sprint), gráfico de burndown, incremento do produto.
e) controle, documentação, previsibilidade.
Comentários:
Os três pilares são: Transparência, Inspeção e Adaptação.
Gabarito: Letra B
130

Aula 04
LISTA DE QUESTÕES – CESPE
1. (CESPE / Petrobrás - 2022) O conceito de sprint tem sua origem no RUP a partir da execução
das fases, cada uma delas com seu marco; cada ciclo no RUP tinha uma sprint considerada,
assim como um projeto curto.
2. (CESPE / Petrobrás - 2022) No Scrum, todo o trabalho necessário para atingir a meta do
produto está embutido nas sprints, inclusive as daily scrums e as sprint retrospective.
3. (CESPE / Petrobrás - 2022) O Scrum usa um conjunto de “padrões de processo de software”,

que são adequados para projetos com prazos apertados e requisitos que mudam
frequentemente.
4. (CESPE / FUNPRESP-EXE - 2022) Na fase de desenvolvimento do Scrum, os requisitos são

escritos no product backlog.
5. (CESPE / FUNPRESP-EXE - 2022) No desenvolvimento de software ágil com base em

prototipação, é essencial que todos os requisitos do sistema tenham sido definidos
previamente.
6. (CESPE / FUNPRESP-EXE - 2022) As fases do processo tradicional de engenharia de software,

como análise, projeto, implementação e testes, podem estar representadas dentro de uma
sprint do Scrum.
7. (CESPE / SEFAZ-SE – 2022) De acordo com a metodologia Scrum, a reunião em que são
apresentados os pontos positivos e negativos da sprint é a:
a) sprint planning.
b) retrospective.
c) daily.
d) backlog refinement.
e) sprint review.
8. (CESPE / TJ-RJ - 2021) Na metodologia Scrum, o rito que tem como finalidade refletir sobre o
andamento das atividades na sprint é conhecido como:
a) review.
b) daily.
c) backlog.
d) retrospectiv.
e) planning.
131

Aula 04
9. (CESPE / TJ-RJ - 2021) A metodologia Scrum estabelece vários papéis a serem desempenhados
pelo time; o responsável por controlar o progresso do desenvolvimento do projeto e ser o
guardião dos ritos é o:
a) product owner.
b) scrum master.
c) patrocinador do projeto.
d) stakeholder.
e) gerente do time de desenvolvimento.
10. (CESPE / TELEBRÁS - 2021) Ao se usar a metodologia Scrum, recomenda-se que, ao final do
sprint, ocorra uma reunião (sprint review) em que a equipe Scrum e todas as partes interessadas
se encontrem, preferencialmente de modo informal, com os objetivos de validar as entregas da
equipe Scrum e verificar se os critérios estabelecidos no planejamento foram executados.
11. (CESPE / TELEBRÁS - 2021) Em Scrum, na Sprint planning, o product owner seleciona os itens
do product backlog para incluir na Sprint e determina detalhadamente aos developers a forma
de trabalho a ser aplicada para viabilizar a criação de um incremento de valor.
12. (CESPE / TELEBRÁS - 2021) Para o método Scrum, o Product Backlog consiste em uma lista de
necessidades do cliente, ou seja, uma lista com as funcionalidades desejadas para um produto
13. (CESPE / TELEBRÁS - 2021) Eliminar desperdício, amplificar o aprendizado e decidir o mais
tarde possível são alguns dos princípios do método Lean.
14. (CESPE / TCE-RJ – 2021) O SCRUM é composto por quatro atividades: planeamento, projeto,
codificação e testes, as quais normalmente são repetidas iteração a iteração.
15. (CESPE / CODEVASF – 2021) Na metodologia Scrum, é feita na sprint planning a seleção dos
itens do backlog que serão desenvolvidos durante a sprint; depois de fechado o seu escopo,
a sprint não poderá mais ser alterada.
16. (CESPE / SERPRO – 2021) Daily Scrum é o único momento do dia em que os developers se
reúnem para discutir detalhadamente a adaptação ou o replanejamento do trabalho da sprint.
17. (CESPE / APEX-BRASIL – 2021) Em Scrum, um item do Product Backlog incluído em uma Sprint
e que não atenda à Definição de Pronto:
a) será retornado ao Product Backlog para consideração futura.

b) será encaminhado com prioridade ao Sprint Backlog.
c) será liberado com ressalvas, desde que haja acordo no Scrum Team.
d) será apresentado na Sprint Review para uma segunda avaliação do Scrum Team
132

Aula 04
18. (CESPE / APEX-BRASIL – 2021) No Scrum, cada artefato tem um compromisso, para assegurar
que a informação fornecida aumente a transparência e o foco, possibilitando a mensuração do
progresso. No caso do Increment, esse compromisso é o:
a) Product Goal.
b) Sprint Goal.
c) Definition of Done.
d) Burn Down.
19. (CESPE / Ministério da Economia – 2020) Os métodos ágeis de desenvolvimento

de software têm duas unidades principais de entrega: lançamentos e iterações.
20. (CESPE / Ministério da Economia – 2020) O responsável direto pelo backlog da sprint é o time
de desenvolvimento, que decide sobre as adições e(ou) remoções e os ajustes de tarefas durante
a execução da sprint; no entanto, se algum item for retirado, o dono do produto deve ser avisado
o mais breve possível.
21. (CESPE / Ministério da Economia – 2020) O Scrum Master é diretamente responsável por
manter e priorizar o backlog do produto, além de colaborar com o time de desenvolvimento.
22. (CESPE / Ministério da Economia – 2020) Um dos artefatos do Scrum, o backlog do produto é
gerenciado, exclusivamente, pelo dono do produto e representa o conteúdo, a disponibilidade
e a ordenação do trabalho a ser realizado, sendo a única porta de entrada para todos os registros
de requisitos de mudança a serem realizados no produto.
23. (CESPE / Ministério da Economia – 2020) Sprint é o ciclo de desenvolvimento de poucas

semanas sobre o qual se estrutura o Scrum e durante o qual cabe ao scrum master manter
o sprint backlog atualizado, indicando as tarefas já concluídas e aquelas ainda por concluir.
24. (CESPE / Ministério da Economia – 2020) Uma forma de acompanhar a produtividade é fazer
uso de um gráfico de Burndown, no qual é possível visualizar a expectativa de produtividade
ideal do projeto e comparar com a produtividade real.
25. (CESPE / Ministério da Economia – 2020) Backlog da sprint é diferente do backlog do produto,
já que o primeiro é um conjunto de itens selecionados a partir do segundo, sendo parte do
planejamento da equipe para entregar um incremento do produto.
26. (CESPE / Ministério da Economia – 2020) As histórias são consideradas pequenos requisitos de
um projeto na perspectiva do usuário final.
27. (CESPE / Ministério da Economia – 2020) Pequenas partes do trabalho com a perspectiva do
patrocinador são artefatos denominados Epics.
133

Aula 04
28. (CESPE / Ministério da Economia – 2020) O scrum master possui autoridade para cancelar
uma sprint antes de o time-boxed da sprint terminar.
29. (CESPE / SLU-DF – 2019) Entre os processos da gestão de projetos com Scrum, as inspeções
constituem os processos mais complexos e formais e, por isso, ocorrem somente ao fim de um
ciclo de várias sprints, após a liberação de uma funcionalidade plena e o seu reconhecimento
pelo demandante.
30. (CESPE / TCE-RO – 2019) No Scrum,
a) os times de desenvolvimento ou times Scrum são auto-organizáveis e responsáveis por

gerenciar o backlog do produto.
b) cabe ao product owner dizer ao time de desenvolvimento como transformar o backlog do

produto em incrementos operacionais para o cliente.
c) que consiste de um framework para desenvolver e manter produtos complexos, utiliza-se

uma abordagem iterativa e incremental para aperfeiçoar o controle de riscos.
d) as sprints consistem exclusivamente de reuniões diárias e do trabalho de desenvolvimento,

com duração superior a um mês.
e) após o planejamento da sprint, o backlog do produto torna-se completo, o que impede a

ocorrência de alterações posteriores.
31. (CESPE / MPC-PA – 2019) A gestão ágil é uma das tendências nos projetos de desenvolvimento
de software. O backlog é um dos artefatos que auxiliam na organização do projeto, em especial
na definição das características tanto do produto (Product Backlog) quanto das Sprints (Sprint
Backlog). Com relação a esses conceitos, assinale a opção correta:
a) O backlog da Sprint não pode ser alterado após sua elaboração.

b) O backlog do produto deve ser atualizado diariamente, para refletir novos requisitos a serem
incorporados ao produto.
c) O backlog do produto é um dos produtos do backlog da Sprint .
d) O backlog da Sprint não deve ser embasado em Sprints anteriores, pois o tempo estimado
para cada Sprint depende do Product Backlog.
e) O backlog da Sprint deve prever a duração de, no máximo, um mês para cada Sprint.
32. (CESPE / FUB – 2018) No método Scrum, ao final de cada período de duas a quatro semanas de
um Sprint backlog, pode-se planejar uma entrega periódica ao cliente.
33. (CESPE / BNB – 2018) No Scrum, o Product Owner é a pessoa que define os itens que compõem
o product backlog.
134

Aula 04
34. (CESPE / ANTT – 2013) Entre os vários papéis do SCRUM, o product owner é a única pessoa
responsável por gerenciar o backlog do produto, possuindo, ainda, a responsabilidade de
maximizar o valor do produto e do trabalho da equipe de desenvolvimento.
35. (CESPE / SERPRO – 2013) Scrum é um processo de desenvolvimento que tem como ponto de
partida um conjunto de requisitos bem definidos.
36. (CESPE / TCE-RO - 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.
37. (CESPE / BASA – 2012) Em um projeto gerido com a metodologia Scrum, um produto estará,
ao final de cada sprint, completamente testado, estando 100% completos todos os requisitos
do product backlog.
38. (CESPE / BASA – 2012) O escopo, a importância e a estimativa de um Sprint do Scrum são
definidos pelo Product Owner.
39. (CESPE / BASA – 2012) A metodologia Scrum, ágil para gerência de projetos, baseia-se em
ciclos de 30 dias, denominados sprints, em que se trabalha para alcançar objetivos bem
definidos.
40. (CESPE / ECT – 2011) Para que se obtenha sucesso na utilização do Scrum, o cliente deve se
tornar parte da equipe de desenvolvimento do software, participando diretamente do processo.
41. (CESPE / MEC – 2011) O framework scrum engloba conceitos como times scrum, eventos com
duração fixa (time-boxes), artefatos e regras. São exemplos de eventos que têm duração fixa: a
reunião de planejamento da versão para entrega, a sprint, a reunião diária, a revisão da sprint e
a retrospectiva da sprint.
42. (CESPE / MEC 2011) Produto da metodologia Scrum, o documento product backlog contém os
requisitos definidos a partir da visão do cliente e é utilizado novamente no final do sprint para
revisão ou modificações dos requisitos inicialmente definidos.
43. (CESPE / ABIN – 2010) 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.
135

Aula 04
LISTA DE QUESTÕES – FCC
44.(FCC / SEFAZ-AP – 2022) No modelo ágil de gestão de projetos Scrum, um dos conceitos mais
importantes é o:
a) product backlog, um diagrama que mostra a quantidade de trabalho a fazer e a quantidade

feita ao longo do tempo.
b) daily sprint meeting, uma reunião de cerca de uma hora para se obter ideias para solução de
problemas encontrados no projeto.
c) sprint, que consiste em um ciclo de desenvolvimento que, em geral, vai de duas semanas a um
mês.
d) pair programming, prática que consiste na programação realizada por duas pessoas em cada
computador.
e) test driven development, prática que consiste em definir e implementar os testes de unidade
antes da programação.
45. (FCC / TRF - 3ª REGIÃO – 2019) SCRUM atende aos princípios do Manifesto Ágil porque:
a) pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o

projeto.
b) não aceita mudanças nos requisitos durante o desenvolvimento e por isso as entregas são
mais ágeis.
c) as entregas ocorrem sempre no prazo, nunca adiantadas ou atrasadas.
d) mais importante que a motivação dos desenvolvedores é a disciplina gerencial imposta que
organiza e agiliza o desenvolvimento.
e) não admite a comunicação direta entre os desenvolvedores, pessoalmente. Isso só pode ser
feito por intermédio de um gerente ou coordenador.
46.(FCC / TRF - 3ª REGIÃO – 2019) A Reunião Diária do Scrum é:
a) executada no final da Sprint para inspecionar o incremento e adaptar o Backlog do Produto,

se necessário.
b) um time-boxed de 15 minutos, durante o qual um “Pronto”, versão incremental
potencialmente utilizável do produto, é criado.
c) uma oportunidade para o Time Scrum inspecionar a si próprio e criar um plano para melhorias
a serem aplicadas na próxima Sprint.
d) um time-boxed de 15 minutos, para que o Time de Desenvolvimento possa sincronizar as
atividades e criar um plano para as próximas 24 horas.
136

Aula 04
e) um time-boxed de 60 minutos, durante o qual os produtos de uma Sprint são definidos.
47. (FCC / TRF - 3ª REGIÃO – 2019) No roteiro SCRUM, de gerenciamento Ágil, a atividade que
discute funcionalidades de modo a atualizar o que já foi feito, o que será feito e dificuldades é:
a) Sprint Review que pretende validar a entrega do momento quando termina uma Sprint.
Realiza-se a reunião que fará a demonstração do produto ou funcionalidade sendo entregue.
b) Sprint Backlog, onde o conjunto planejado, selecionado junto ao Backlog do Produto, é

definido para compor uma Sprint. Somente as entregas que compõem a Sprint serão detalhas
em atividades menores e as restantes serão “congeladas”, não sendo detalhadas ainda.
c) Sprint Goal resultado da negociação entre o time de desenvolvimento e o Product Owner -

PO reconhecido como necessidade(s) fundamental(ais) do cliente nesse momento.
d) Daily Scrum, reunião que ocorre diariamente, durante 15 minutos, com todos participantes
em pé, onde se atualiza a situação presente da Sprint sendo trabalhada.
e) Product Backlog onde se produz uma lista contendo todas as funcionalidades desejadas para
um produto em sua situação atual.
48.(FCC / SANASA Campinas – 2019) Um Analista de TI tem como tarefas ordenar os itens do
Backlog do Produto visando o alcance das metas e missões do projeto, buscando garantir que o
Backlog do Produto esteja claro de forma a mostrar no que o Time Scrum vai trabalhar a seguir
e ainda visando garantir que o Time de Desenvolvimento entenda os itens do Backlog do
Produto no nível necessário. Considerando que o projeto é baseado no Scrum, o Analista está
no papel de:
a) Scrum Master.
b) Gerente do Produto.
c) Sprint Manager.
d) Product Owner.
e) Development Team Leader.
49.(FCC / TRF - 4ª REGIÃO – 2019) Uma Analista de TI está atuando como Product Owner em um
projeto Scrum. Ela está trabalhando na formulação de um acordo para definir quais são os
passos mínimos para a conclusão de um item potencialmente entregável, que serve como um
contrato entre o Scrum Team e o Product Owner, de forma que os integrantes tenham um
entendimento compartilhado do que significa o trabalho estar completo, assegurando a
transparência e os padrões de qualidade estabelecidos entre eles. O acordo, denominado:
a) Scrum rules, integra os eventos, papéis e artefatos, administrando as relações e interações

entre eles, e é criado na 1ª sessão do Sprint Review Meeting.
137

Aula 04
b) incremento, pode evoluir normalmente ao longo do projeto, porém é recomendável que a

primeira versão seja criada durante a primeira sessão de Sprint Planning, após a realização da
primeira Sprint do projeto.
c) DoD, é a soma de todos os itens do Product Backlog completados durante a Sprint e o valor
dos incrementos de todas as Sprints anteriores.
d) Scrum rules, é um conjunto de itens do Product Backlog selecionados para a Sprint que forma
o plano para entregar o incremento do produto e atingir o objetivo da Sprint.
e) DoD, também orienta o Scrum Team no conhecimento de quantos itens do Product

Backlog podem ser selecionados durante a Sprint Planning Meeting.
50. (FCC / TJ-MA – 2019) Um Analista Judiciário, no papel de Scrum Master, esclarece que:
a) o gerenciamento do Product Backlog não fica unicamente na responsabilidade do Product

Owner, mas deve ser compartilhado com o Product Backlog Committee.
b) o Product Owner é uma pessoa ou um comitê. Quando o Product Owner é representado por
um comitê, aqueles que quiserem uma alteração nas prioridades dos itens do Product
Backlog devem endereçá-la ao Committee’s Coordinator.
c) somente integrantes do Development Team criam incrementos e um incremento “Pronto” é

requerido na Revisão da Sprint.
d) o Scrum recomenda que haja apenas quatro subtimes no Development Team relativos aos
domínios de conhecimento: teste, arquitetura, operação e análise de negócios.
e) o Scrum Team consiste de profissionais que realizam o trabalho de entregar um incremento

potencialmente liberável do produto “Pronto” no início de cada Sprint.
51. (FCC / SEGEP-MA – 2018) O Scrum prescreve quatro eventos formais, contidos dentro dos
limites da Sprint, para inspeção e adaptação. Dois desses eventos são:
a) revisão do backlog e orientação do Scrum Master.

b) preleção do Product Owner e revisão dos requisitos.
c) reunião de revisão da Sprint e descrição de requisitos no backlog.
d) revisão das especificações e reunião de planejamento da Sprint.
e) reunião diária e retrospectiva da Sprint.
52. (FCC / TRT-MG – 2015) Com relação ao Scrum, considere:
138

Aula 04
I. O Product Owner, ou dono do produto, é responsável por garantir que o Scrum seja entendido
e aplicado. Faz isso para garantir que o Time Scrum adere à teoria, práticas e regras do Scrum.
É um servo-líder para o Time Scrum.
II. O Scrum Master é o responsável por maximizar o valor do produto e do trabalho do Time de
Desenvolvimento. Como isso é feito pode variar amplamente nas organizações, Times Scrum e
indivíduos.
III. O coração do Scrum é a Sprint, um time-boxed de um mês ou menos, durante o qual um

“Pronto", versão incremental potencialmente utilizável do produto, é criado.
Está correto o que consta APENAS em:
a) I e II.
b) III
c) II e III.
d) II.
e) I e III.
53. (FCC / TRT-SC – 2013) SCRUM é um framework baseado no modelo ágil. No SCRUM,
a) o scrum team é a equipe de desenvolvimento, necessariamente dividida em papéis como

analista, designer e programador. Em geral o scrum team tem de 10 a 20 pessoas.
b) as funcionalidades a serem implementadas em cada projeto (requisitos ou histórias de

usuários) são mantidas em uma lista chamada de scrum board.
c) o scrum master é um gerente no sentido dos modelos prescritivos. É um líder, um facilitador

e um solucionador de conflitos. É ele quem decide quais requisitos são mais importantes.
d) um dos conceitos mais importantes é o sprint , que consiste em um ciclo de desenvolvimento

que, em geral, tem duração de 4 a 7 dias.
e) o product owner tem, entre outras atribuições, a de indicar quais são os requisitos mais
importantes a serem tratados em cada sprint. É responsável por conhecer e avaliar as
necessidades dos clientes.
54. (FCC / TRE-CE – 2012) No SCRUM, sprint é:
a) um representante dos stakeholders e do negócio.

b) uma lista de requisitos que tipicamente vêm do cliente.
c) uma lista de itens priorizados a serem desenvolvidos para um software.
d) uma iteração que segue um ciclo (PDCA) e entrega incremento de software pronto.
e) um conjunto de requisitos, priorizado pelo Product Owner.
139

Aula 04
55. (FCC / TRT-SP – 2012) Analise o texto:
O Scrum enfatiza o uso de um conjunto de padrões de processos de software que provaram ser
eficazes para projetos com prazo de entrega apertados, requisitos mutáveis e críticos de
negócio. Cada um desses padrões de processos define um conjunto de ações de
desenvolvimento. Uma dessas ações consiste em manter uma lista com prioridades dos
requisitos ou funcionalidades do projeto que fornecem valor comercial ao cliente. Os itens
podem ser adicionados a esse registro em qualquer momento. O gerente de produto avalia o
registro e atualiza as prioridades conforme requisitado. A lista citada no texto é conhecida
como:
a) urgências scrum.
b) registro ágil de requisitos.
c) alterações scrum.
d) registro pendente de trabalhos (Backlog).
e) registro iterativo de desenvolvimento (sprint).
56. (FCC / TRF-2 – 2012) Segundo Roger S. Pressman, em seu livro Engenharia de Software, 7a
edição, os princípios do Scrum são consistentes com o manifesto ágil e são usados para orientar
as atividades de desenvolvimento dentro de um processo que incorpora as atividades estruturais
de requisitos, análise, projeto, evolução e entrega. Em cada atividade metodológica, ocorrem
tarefas a realizar dentro de um padrão de processo chamado:
a) process backlog.
b) scrum master.
c) product owner.
d) backlog.
e) sprint.
57. (FCC / INFRAERO – 2011) Um dos principais conceitos do Scrum para atacar a complexidade do
desenvolvimento e gerenciamento de software é a implantação de um controle
descentralizado, capaz de lidar mais eficientemente com contextos pouco previsíveis. Para
tanto, o gerenciamento é distribuído por meio de três agentes independentes que são:
a) Product Owner, Scrum Team e Scrum Master.

b) Product Owner, Product Backlog e Planning Meeting.
c) Product Owner, Sprint e Planning Meeting.
d) Sprint, Scrum Master e Planning Meeting.
e) Sprint, Scrum Team e Product Backlog.
58. (FCC / INFRAERO – 2011) Em relação às regras do Scrum, é INCORRETO afirmar:
140

Aula 04
a) O Sprint deve ser realizado num período máximo de 40 dias e ter uma equipe de trabalho não
superior a 10 pessoas.
b) Se o Sprint tomar um rumo não desejado, é possível dissolvê-lo e começar um novo Sprint,
baseando num novo Sprint Backlog.
c) As reuniões durante um Sprint devem ser diárias, sempre à mesma hora e no mesmo local e
não devem durar mais que 30 minutos.
d) Toda conversação restringe as respostas dos participantes às três perguntas do Scrum

Master: O que desenvolveu desde a última reunião? Que dificuldades encontrou durante o seu
trabalho? O que planeja desenvolver até a próxima reunião?
e) Com base nas respostas às três perguntas, o Scrum Master deve imediatamente tomar
decisões, quando necessárias, para remover todas as situações que impeçam a agilidade do
trabalho.
59. (FCC / TCE-SE – 2011) Aceita a imprevisibilidade do desenvolvimento de software e a contorna

através da adaptação constante. Destaca-se das demais metodologias ágeis por dar mais
enfoque à área de gerenciamento. Seu nome tem origem em um esporte quando jogadores de
cada time colaboram entre si numa tentativa de avançar juntos pelo campo adversário. Tais
características estão presentes no processo:
a) UP.
b) Crystal.
c) XP.
d) DSDM.
e) Scrum.
60.(FCC / TRT-RS – 2011) Para utilizar o processo de estimativa por Story Points em Scrum,
inicialmente:
a) o Product Owner deve atribuir valores de negócio para cada um dos itens do Product Backlog.
b) o Product Backlog deve considerar todos os fatores de Sprint contidos no Backlog Owner.
c) os Stakeholders devem atribuir os riscos do Product Owner para cada Sprint Planning.
d) os Stakeholders devem atribuir valores de negócio do Product Owner para cada Sprint.
e) o Product Planning deve avaliar cada Sprint contida no Backlog transacional e decidir pela
prioridade de atividades.
141

Aula 04
61. (FCC / TRT-RJ – 2011) No SCRUM, o processo de desenvolvimento inicia com uma reunião de
planejamento na qual o Product Owner e a equipe decidem, em conjunto, o que deverá ser
implementado do Product Backlog. Assim, a equipe planeja seu trabalho, definindo o Sprint
Backlog, na:
a) primeira parte da Sprint Planning Meeting.

b) segunda parte da Sprint Planning Meeting.
c) terceira parte da Sprint Planning Meeting.
d) Sprint.
e) Sprint Burndown.
62. (FCC / TRE-ES – 2010) Os princípios Scrum são usados para guiar as atividades de
desenvolvimento dentro de um processo que incorpora as seguintes atividades de arcabouço:
requisitos, análise, projeto, evolução e entrega. Em cada atividade de arcabouço, as tarefas de
trabalho ocorrem dentro de um padrão de processo chamado:
a) pendência.
b) iterator.
c) demo.
d) história de usuário.
e) sprint.
63. (FCC / TRF 4ª – 2010) Na fase de desenvolvimento do Scrum, o software é desenvolvido em

processos iterativos denominados:
a) Building Products.
b) Product Backlog.
c) Sprint.
d) Product Owner.
e) Product Backlog Cycle.
64.(FCC / TRE-RS – 2010) Em reunião, toda conversação é restringida às respostas dos elementos
às perguntas colocadas pelo Scrum Master, sendo uma delas: "O que planeja desenvolver até a
próxima reunião?". As Scrum meetings ocorrem:
a) sempre que necessário.

b) ocasionalmente.
c) uma vez por semana.
d) duas vezes por semana.
e) diariamente.
65. (FCC / TRE-RS – 2010) No contexto das regras do SCRUM, é correto afirmar:
142

Aula 04
a) Durante a realização do Sprint, o Backlog pode ser modificado por qualquer um dos
elementos da equipe, desde que acordado nas reuniões semanais.
b) O Sprint deve ser realizado num período não superior a 30 dias e ter um objetivo bem claro,
baseado no Backlog.
c) Modificação no Backlog é prerrogativa do Scrum Master, quando achar necessário, em

qualquer momento no decorrer do Sprint.
d) Não é possível dissolver um Sprint. Se houver algum risco de ele tomar um rumo não
desejável, novas funcionalidades devem ser implementadas para garantir o prazo do projeto.
e) O foco na produtividade se estende às Scrum meetings e a conversação é pautada em

discussões por toda a equipe.
66. (FCC / TRE-RS – 2010) No SCRUM, o produto final, a data final e o custo do projeto são
determinados:
a) respectivamente, no planejamento, ao longo do projeto, no início do projeto.

b) ao longo do projeto.
c) no planejamento.
d) respectivamente, nas fases intermediárias, no planejamento, no final do projeto.
e) em função das iterações.
67. (FCC / DPE-SP – 2010) Na engenharia de software, um processo iterativo denominado sprint,
que segue o ciclo PDCA para entregar, num período de 30 dias aproximadamente, um
incremento do software pronto, caracteriza a metodologia ágil:
a) SCRUM.
b) DSDM.
c) Crystal.
d) FDD.
e) XP.
68. (FCC / AFR-SP – 2009) O conceito de sprint aplica-se ao modelo ágil do processo de
engenharia de software denominado:
a) Crystal.
b) XP.
c) DAS.
d) DSDM.
e) Scrum.
143

Aula 04
LISTA DE QUESTÕES – FGV
69. (FGV / TJDFT – 2022) Uma equipe de analista de sistemas está desenvolvendo o software
ProgramaTJ aplicando a metodologia Lean. A equipe decidiu implementar apenas as
funcionalidades formalmente requisitadas pelo cliente, evitando adicionar qualquer
funcionalidade extra à ProgramaTJ por conta própria.
Essa decisão da equipe remete, de forma direta, ao princípio da metodologia Lean para o
desenvolvimento de software de:
a) otimização do todo;
b) adiar comprometimento;
c) eliminação de desperdícios;
d) respeitar as pessoas;
e) criação de conhecimento.
70. (FGV / TJDFT – 2022) Uma equipe de desenvolvimento de sistemas de software (EDSS) está
trabalhando no desenvolvimento de uma nova aplicação Web utilizando práticas ágeis
alinhadas com o Scrum. Algumas funcionalidades da aplicação Web já foram disponibilizadas
aos clientes, porém um dos Product Owners solicitou mudanças em algumas delas. Sabendo-se
que a EDSS está no meio do andamento de uma Sprint de 4 semanas cujo Sprint Goal não tem
relação direta com as funcionalidades entregues, para atender à solicitação do Product Owner,
a EDSS deve:
a) alterar o prazo planejado para desenvolvimento da Sprint de modo a adicionar a alteração

solicitada;
b) realizar uma Sprint Retrospective para decidir quando adicionar a alteração solicitada;
c) executar uma Sprint Review para determinar as adaptações para adicionar a alteração
solicitada;
d) manter o prazo planejado para desenvolvimento da Sprint, removendo um dos itens do Sprint
Backlog para adicionar a alteração solicitada;
e) manter o prazo planejado para desenvolvimento da Sprint, adicionando a alteração solicitada

no Product Backlog.
71. (FGV / FUNSAÚDE - 2021) Analise a frase a seguir.
Funciona criando ciclos, conhecidos como sprints, que são os intervalos de tempo para o
desenvolvimento de cada etapa.
144

Aula 04
Assinale a metodologia ágil de desenvolvimento à qual a frase acima diz respeito.
a) Crystal.
b) Kanban.
c) Lean.
d) Scrum.
e) XP.
72. (FGV / COMPESA – 2018) O SCRUM é um framework para gerenciamento de projetos

complexos, sendo um dos métodos ágeis mais populares do mundo. Uma das dinâmicas
definidas no SCRUM é a retrospectiva. Assinale a opção que melhor descreve o objetivo da
retrospectiva definida no SCRUM.
a) Planejar medidas que possam trazer, no próximo Sprint, melhorias relacionadas à

colaboração entre as pessoas, processos ou ferramentas.
b) Inspecionar o resultado do trabalho realizado em um Sprint e ajustar o Backlog do produto,

se necessário.
c) Rever as prioridades dos itens que compõem o Backlog do produto.
d) Planejar como o time construirá as funcionalidades definidas para um Sprint com base nos
resultados obtidos nos Sprints anteriores.
e) Disseminar conhecimento sobre o que foi feito no dia anterior para poder priorizar o trabalho
a ser realizado no dia que se inicia.
73. (FGV / AL-RO – 2018) Para o desenvolvimento do Sistema de Informações ao Cidadão (SIC), foi
decidida a utilização de uma metodologia ágil. Segundo o Manifesto Ágil, esta decisão indica
que foi dado maior valor:
a) aos processos e ferramentas.

b) à resposta a modificações.
c) à documentação abrangente.
d) à negociação do contrato.
e) ao cumprimento do plano.
74. (FGV / Banestes – 2018) Com relação aos valores relacionados ao desenvolvimento ágil de
software, NÃO se pode incluir:
a) colaboração do cliente mais que negociação de contratos;

b) indivíduos e iterações mais que processos e ferramentas;
c) rapidez na construção mais que excelência técnica;
145

Aula 04
d) responder a mudanças mais que seguir um plano;

e) software funcional mais que documentação abrangente.
75. (FGV / Banestes – 2018) Um dos valores relacionados ao ambiente ágil de desenvolvimento é:
a) documentação abrangente mais que software funcional;

b) negociação de contratos mais que colaboração do cliente;
c) processos e ferramentas mais que indivíduos e iterações;
d) rapidez na construção mais que excelência técnica;
e) responder a mudanças mais que seguir um plano.
76. (FGV / TJ-SC – 2015) O SCRUM, processo para o desenvolvimento de software ágil, estrutura-
se sobre:
a) plan, documentaton, test;

b) roles, artifacts, activities;
c) requisites, code, products;
d) client team, development team, deliverables;
e) interface, data, code.
77. (FGV / PGE-RO – 2015) Durante 5 anos gerenciando o desenvolvimento de sistemas de

informação, Claudia teve que lidar com diversas insatisfações de seus usuários pois os sistemas
não atendiam as suas necessidades. Claudia decidiu, então, implantar métodos ágeis de
desenvolvimento e definiu os seguintes princípios:
I. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento.
II. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de
desenvolvimento é através da documentação.
III. Simplicidade é essencial.
Dentre os princípios definidos por Claudia, o que infringe os princípios do manifesto para
Desenvolvimento Ágil de Software é o que se afirma em:
a) somente I;
b) somente II;
c) somente III;
d) somente I e III;
e) I, II e III.
78. (FGV / TJ-RO – 2015) O manifesto ágil tem por princípio que:
a) mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento;
146

Aula 04
b) a contínua atenção à excelência técnica reduz a agilidade;
c) a redução do backlog é a medida primária de progresso;
d) as melhores arquiteturas, requisitos e designs emergem de equipes que possuem um bom

líder;
e) pessoas de negócio e desenvolvedores devem trabalhar em ambientes separados para reduzir

as interferências no processo de desenvolvimento.
79. (FGV / Câmara Municipal de Caruaru - PE – 2015) O desenvolvimento ágil de software é guiado
por metodologias que compartilham um conjunto comum de valores e de princípios, conforme
definido pelo Manifesto Ágil. Assinale a opção que indica um princípio do desenvolvimento ágil.
a) As mudanças nos requisitos devem ocorrer dentro do quadro de tempo estabelecido para a
iteração.
b) O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de
desenvolvimento é por meio de conversa face a face.
c) Os intervalos regulares devem ser evitados para tornar a equipe mais eficaz e maximizar a
quantidade de trabalho realizado.
d) As pessoas de negócio e desenvolvedores devem interagir somente no início de cada iteração.
e) A entrega contínua e adiantada de software, mesmo que o conjunto de funcionalidades
desenvolvidas não agregue valor, deve ser feita para satisfazer o cliente.
80.(FGV / DPE-RO – 2015) O Manifesto Ágil é uma declaração que reúne os princípios e práticas
que fundamentam o desenvolvimento ágil de software. É um dos princípios desse manifesto:
a) defeitos no software são a medida primária de progresso;

b) pessoas de negócio e desenvolvedores devem trabalhar isoladamente e se reunir somente ao
final de cada iteração para validação do software;
c) atenção contínua à excelência técnica deve ser evitada para não afetar a agilidade uma vez
que simplicidade é essencial;
d) os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo
constante indefinidamente evitando interrupções e intervalos regulares;
e) as melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.
81. (FGV / DPE-RO – 2015) Uma metodologia de desenvolvimento de software é um conjunto

estruturado de práticas que auxiliam o processo de produção de software. Em geral, a adoção
de uma metodologia é significativamente melhor do que uma abordagem casual de
desenvolvimento de software. Em relação a metodologias de desenvolvimento de software,
analise as afirmativas a seguir:
147

Aula 04
I - O Scrum é uma metodologia de desenvolvimento ágil que emprega uma abordagem iterativa
e incremental para aperfeiçoar a previsibilidade e o controle de riscos.
II - A programação em dupla num único computador é uma característica da metodologia RUP

(Rational Unified Process) como uma forma de evitar e diminuir a possibilidade de defeitos.
III - Metodologias ágeis tentam minimizar o risco por meio do desenvolvimento do software em
longos períodos, evitando que funcionalidades do software sejam entregues frequentemente.
Está correto o que se afirma em:
a) somente I;
b) somente II;
c) somente III;
d) somente I e II;
e) I, II e III.
82. (FGV / PROCEMPA – 2014) O Manifesto Ágil é uma declaração de princípios que fundamentam
o desenvolvimento ágil de software. A respeito desses princípios, assinale a afirmativa correta.
a) As melhores arquiteturas, requisitos e designs emergem de equipes lideradas pelo

profissional mais sênior.
b) Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e
ajusta seu comportamento de acordo.
c) Pessoas de negócio e desenvolvedores devem trabalhar separadamente por todo o projeto.
d) Entregar software quando há poucas semanas de desenvolvimento deve ser evitado para não
afetar a satisfação do cliente.
e) Mudanças nos requisitos são bem-vindas, desde que não impactem o desenvolvimento.
83. (FGV / TJ-GO – 2014) O Manifesto Ágil lista valores seguidos por desenvolvedores com a
finalidade de melhorar a maneira pela qual o software é desenvolvido. A alternativa que se
encontra no manifesto é:
a) seguir um plano mais que responder a mudanças;

b) indivíduos e interações mais que processos e ferramentas;
c) documentação abrangente mais que software em funcionamento;
d) negociação de contratos mais que colaboração com o cliente;
e) negociação de contratos mais que indivíduos e interações.
84.(FGV / DPE-RJ – 2014) Uma das características da metodologia ágil Scrum é:
a) focar nas práticas de engenharia.

b) focar na documentação formal do software.
148

Aula 04
c) ser um método iterativo e incremental.

d) exigir o planejamento do projeto, de acordo com as práticas do PMBOK.
e) não exigir interação com o cliente.
85. (FGV / TJ-AM – 2013) Com relação aos princípios do modelo ágil de processo Scrum, analise as
afirmativas a seguir.
I. O processo precisa ser adaptável tanto a modificações técnicas quanto de negócios "para
garantir que o melhor produto possível seja produzido".
II. O trabalho de desenvolvimento e o pessoal que o realiza é dividido "em partições claras, de
baixo acoplamento ou em pacotes".
III. O processo produz frequentes incrementos de software "que podem ser inspecionados,
ajustados, testados, documentados e expandidos".
Assinale:

c) se somente a afirmativa III estiver correta
86. (FGV / MPE-MS – 2013) Em Scrum, pode-se utilizar diversas técnicas para estimar o que será
feito durante o projeto ou na próxima “Sprint”. A respeito da estimativa chamada de “Story
Points”, analise as afirmativas a seguir.
I. A estimativa de uma “User Story” com “Story Points” pode ser feita através da dinâmica
chamada de “Planning Poker”.
II. As estimativas usando “Story Points” são feitas por especialistas em estimativas e, em
seguida, validadas por todo o time.
III. A escala (1, 2, 3, 5, 8, 13, 20, 40, 100), usada para definir os “Story Points”, é inspirada na
sequência de Fibonnacci.
Assinale:
a) se somente a afirmativa III estiver correta

b) se somente as afirmativas I e III estiverem corretas
c) se somente as afirmativas II, III estiverem corretas
d) se somente as afirmativas I e II estiverem corretas
e) se todas as afirmativas estiverem corretas
149

Aula 04
87. (FGV / Senado Federa l – 2012) Com relação ao método ágil de desenvolvimento conhecido
como Scrum, analise as afirmativas a seguir.
I. Cada iteração do processo de desenvolvimento é denominada Sprint.

II. O Backlog do Produto é uma lista de itens priorizados, composta por requisitos e
funcionalidades que devem ser construídos para concretizar a visão.
III. No início de cada Sprint, a equipe se reúne para escolher os itens a serem desenvolvidos até
o final dessa iteração, o que dá origem ao Backlog do Sprint.

c) se somente a afirmativa III estiver correta.
88. (FGV / MEC – 2009) Scrum é uma metodologia ágil para gestão e planejamento de projetos
de software. No Scrum, os projetos são divididos em ciclos chamados:
a) Product Backlog.
b) Sprint Backlog.
c) Scrum Master.
d) Daily Scrum.
e) Sprints.
150

Aula 04
LISTA DE QUESTÕES – DIVERSAS BANCAS
A questão 86 baseia-se na Figura 11, que exibe a imagem de um gráfico elaborado no framework
Scrum, sobre o qual, considere os seguintes aspectos: (1) o eixo horizontal mostra, da esquerda para
a direita, os dias de uma Sprint; (2) o eixo vertical exibe, de cima para baixo, em porcentagem, a
quantidade de trabalho que ainda precisa ser feita; e (3) a linha tracejada exibe o esforço estimado,
enquanto a linha contínua mostra o esforço atual.
89. (FUNDATEC / ISS-Porto Alegre – 2022) No framework "Scrum", a equipe pode monitorar
seu progresso ao final de cada Sprint por meio do gráfico mostrado na Figura 17, o qual é
chamado de:
a) Sprint Planning Meeting.

b) Release Burndown Chart.
c) Release Planning Meeting.
d) Sprint Retrospective Chart.
e) Sprint Review Meeting Chart.
90.(FUNDATEC / ISS-Porto Alegre – 2022) No framework "Scrum", elabora-se uma lista ordenada
de tudo que é conhecido ser necessário no produto. Sobre essa lista, considere, ainda, as
seguintes características: (1) ela é a única origem dos requisitos para qualquer mudança a ser
feita no produto; (2) essa lista é dinâmica, mudando constantemente para identificar o que o
produto necessita para ser mais apropriado, competitivo e útil; (3) ela evolui tanto quanto o
produto e o ambiente no qual ele será utilizado; (4) nessa lista, constam todas as características,
funções, requisitos, melhorias e correções que formam as mudanças que devem ser feitas no
produto nas futuras versões. Nesse caso, pode-se afirmar que tal lista é chamada de:
a) Incremento.
b) Sprint Backlog.
c) Backlog Planning.
d) Product Backlog.
151

Aula 04
e) Definição de Pronto.
91. (CESGRANRIO / Banco da Amazônia – 2021) “O Scrum é um arcabouço que ajuda pessoas,
times e organizações a gerar valor por meio de soluções adaptativas para problemas
complexos.”
SCHWABER, K. ; SUTHERLAND, J. O Guia do Scrum, O Guia Definitivo para o Scrum: As Regras do Jogo. Nov. 2020. p 3. Adaptado.
Para cumprir seu objetivo, o Scrum se baseia em quatro eventos formais, contidos dentro de um
evento de maior duração: a Sprint. Tais eventos formais implementam os três pilares empíricos
do Scrum, que são:
a) compromisso, abertura e adaptação

b) respeito, coragem e foco
c) respeito, inspeção e adaptação
d) transparência, compromisso e respeito
e) transparência, inspeção e adaptação
92. (COMPERVE / TJ-RN – 2020) O Scrum é um framework dentro do qual as pessoas podem tratar
e resolver problemas de forma ágil. O coração do Scrum são suas sprints. Segundo
o Scrum Guide, em um projeto que adota Scrum, a autoridade de cancelar uma sprint cabe ao:
a) Time scrum.
b) Scrum Master.
c) Product Owner.
d) Team manager.
93. (INSTITUTO AOCP / Prefeitura de Novo Hamburgo - RS – 2020) Assinale a alternativa que
apresenta uma metodologia para desenvolvimento de software:
a) BIM
b) BALANCED SCORECARD
c) COBIT
d) SCRUM
e) ISACA
94.(UFCG / UFCG – 2019) A respeito do framework de trabalho Scrum, marque a alternativa

correta:
a) O eixo X do gráfico de burn-down representa a entrega planejada, em horas de trabalho ou

em pontos de histórias.
b) Essa framework não prevê acompanhamento diário, logo, a equipe se reúne somente no final
de uma sprint.
c) O Product Backlog é uma lista de funcionalidades esperadas para um produto.
d) Foco, comprometimento e respeito não fazem parte dos valores de Scrum.
152

Aula 04
e) Uma equipe Scrum é composta exclusivamente por um Product Owner e desenvolvedores,

sem ninguém responsável pelo treinamento desses desenvolvedores.
95. (VUNESP / Prefeitura de Campinas – SP – 2019) No método ágil Scrum, há um artefato

denominado backlog, aplicado a diversas etapas do método. Em particular, o backlog do
produto corresponde a:
a) um conjunto de todos os produtos de software já desenvolvidos com o uso do Scrum.

b) uma lista das funcionalidades a serem implementadas no produto.
c) uma relação dos analistas envolvidos no desenvolvimento do produto.
d) um conjunto de normas seguidas pela empresa proprietária do produto.
e) uma relação dos futuros usuários do produto.
96. (INSTITUTO AOCP / IBGE – 2019) O time de desenvolvimento de software do IBGE está
utilizando o método ágil Scrum para desenvolvimento de software. Sabendo disso, analise as
assertivas a respeito do framework do Scrum e assinale a alternativa que aponta a(s) correta(s).
I. Os papéis definidos pelo Scrum são: times de desenvolvimento, gerente de projetos e product
owner (PO).
II. A sprint retrospective proporciona ao time do Scrum uma oportunidade de avaliar o que foi
bem e o que pode ser melhorado na sprint que acabou de ser finalizada.
III. Apesar da importância do product backlog, ele não é o verdadeiro artefato do Scrum.
Assim, o seu verdadeiro artefato é o requisito do usuário.
a) Apenas I.
b) Apenas II.
c) Apenas III.
d) Apenas I e II.
e) Apenas II e III.
97. (INSTITUTO AOCP / EMPREL – 2019) Assinale a alternativa que apresenta uma das
características do Scrum referente ao Scrum Team (Time Scrum):
a) O time valida com o cliente as características (features) ou requisitos do produto.

b) Um líder determina como é a distribuição das tarefas e a programação aos pares.
c) O líder do time Scrum deve priorizar as funcionalidades que serão desenvolvidas.
d) É auto-organizável e não ultrapassa sete pessoas em sua composição.
e) Reuniões diárias são realizadas para possibilitar a interatividade das tarefas.
98. (CESGRANRIO / UNIRIO – 2019) Uma equipe de desenvolvimento adota o método SCRUM
para gerenciar seu projeto. Para iniciar a reunião de planejamento da Sprint, deve(m)-se definir
e atualizar:
153

Aula 04
a) o Backlog do Produto
b) o plano de revisão da Sprint
c) o plano de retrospectiva da Sprint
d) a função de cada membro da equipe de desenvolvimento
e) as tarefas necessárias para cada história do usuário
99. (CS-UFG / Prefeitura de Goianira - GO – 2019) De acordo com o Guia do Scrum,

uma sprint tem um período de duração de um mês aproximadamente, em que uma entrega,
versão incremental potencialmente utilizável, do produto é criada. Quais são, respectivamente
no tempo, os quatro eventos que constituem a sprint?
a) Reunião de escolha do backlog, reunião diária, reunião de refinamento e acompanhamento.

b) Reunião de planejamento, reunião diária, revisão e acompanhamento.
c) Reunião de escolha do backlog, reunião diária, reunião de refinamento e retrospectiva.
d) Reunião de planejamento, reunião diária, revisão e retrospectiva.
100. (IF-MT / IF-MT– 2019) Sutherland (2016), co-criador do Scrum, sugere que, para a
implementação de um projeto Ágil Scrum, algumas definições são a chave para sua condução e
sucesso.
I - Existe e evolui ao longo de toda a vida do produto, é o mapa do produto, é a visão única e
definitiva de "tudo que a equipe poderia um dia vir a realizar, em ordem de prioridade".
II - Tem a visão do que a equipe fará, produzirá ou realizará. Leva em consideração os riscos e
recompensas.
III - Treinará e ajudará outros integrantes da equipe a eliminarem qualquer coisa que esteja
diminuindo seu ritmo.
IV - Tem uma duração determinada que deve ser de menos do que um mês. Possui meta para
cada ciclo, e os ciclos são planejados para que nada seja alterado até sua conclusão.
Essas sentenças referem-se, respectivamente:
a) Scrum Master, Sprint, Product Owner e Backlog.

b) Sprint, Product Owner, Scrum Master e Backlog.
c) Backlog, Scrum Master, Product Owner e Sprint.
d) Sprint, Scrum Master, Product Owner e Backlog.
e) Backlog, Product Owner, Scrum Master e Sprint.
101. (IF-PE / IF-PE – 2019) A reunião de balanço sobre o que foi realizado durante uma sprint e
onde o time deve mostrar ao product owner os resultados obtidos é chamada de:
a) planejamento da sprint.
b) retrospectiva da sprint.
c) reunião diária.
d) revisão da sprint.
154

Aula 04
e) reunião de estimativas.
102. (IF-PE / IF-PE – 2019) São características inerentes ao SCRUM:
I. implementação do conceito interativo e incremental no desenvolvimento de software e/ou

produtos.
II. a programação em pares.
III. valorização dos indivíduos envolvidos na construção do software.
Está(ão) CORRETO(S), apenas, o(s) item(ns):
a) I.
b) I e III.
c) I e II.
d) II e III.
e) I,II e III.
103. (COMPERVE / UFRN – 2019) O Scrum é um framework no qual as pessoas podem abordar
problemas adaptativos complexos ao mesmo tempo em que entregam, de maneira produtiva e
criativa, produtos de mais alto valor possível. Nesse framework, existem três papéis
importantes, que são:
a) product owner, development team e scrum master.

b) product manager, scrum team e scrum master.
c) product leader, development team e scrum master.
d) product scrum, development team e development master.
104. (COSEAC / UFF – 2019) Em relação aos métodos ágeis, o responsável por garantir que a
equipe está aderindo aos valores do Scrum é representado por:
a) product owner.
b) time.
c) scrum master.
d) gerente de projetos.
e) stakeholders.
105. (IF-PA / IF-PA – 2019) A gestão de projetos é um dos grandes desafios no desenvolvimento
de produtos de software, pois uma gestão padronizada, aliada às boas práticas de
desenvolvimento minimizam os fracassos nos projetos de softwares. O Scrum é um dos
frameworks mais utilizados na gestão de projetos de software e sobre ele é correto afirmar.
a) Por definição, o seu ciclo é composto pela seguinte sequência: “Sprint”, “Sprint View” e “Daily
Scrum”.
155

Aula 04
b) Por definição, “Sprint Review” é uma reunião informal que ocorre ao final de cada “Sprint”
para avaliar o que foi feito, e se necessário, adaptar o “Backlog do Produto”.
c) O “Sprint Retrospective” é um plano feito pelo “Product Owner”, que demonstra como se
espera que o produto evolua ao longo do tempo.
d) O “Daily Review” é um evento de curta duração realizado todos os dias durante um “Sprint”,
neste evento, a equipe de desenvolvimento planeja o trabalho das próximas 24 horas.
e) É de responsabilidade exclusiva do “Scrum Master” a gerência dos itens do “Product Backlog”,

bem como as suas prioridades e objetivos do projeto.
106. (FUNDATEC / Prefeitura de Gramado – RS – 2019) De acordo com o guia Scrum, analise as
assertivas a seguir:
I. Scrum é um framework para planejamento, programação e manutenção de produtos simples.

II. Três são os pilares para toda a implementação de um controle de processo empírico:
transparência, inspeção e adaptação.
III. O Scrum Team consiste de um Product Owner, o Development Team, e de um Scrum
Master.
IV. A Product Backlog é uma lista ordenada de tudo o que é conhecido como necessário ao
produto.
Quase estão corretas?
a) Apenas I e II.
b) Apenas II e III.
c) Apenas III e IV.
d) Apenas II, III e IV
e) I, II, III e IV.
107. (CESGRANRIO / TRANSPETRO – 2018) Quando ocorre, no SCRUM, a reunião de

Retrospectiva da Sprint?
a) No fim da Sprint, antes da Reunião de Revisão

b) Entre a Reunião de Revisão da Sprint e a de Planejamento da próxima Sprint
c) No início da Sprint, após a Reunião de Planejamento
d) No final de cada dia da Sprint
e) No início de cada dia da Sprint
108. (CESGRANRIO / TRANSPETRO – 2018) No uso de alguns métodos ágeis, como o SCRUM,
é comum que o esforço de desenvolvimento seja avaliado por meio de Pontos de História (Story
Points). Essa metodologia usa cartas, semelhantes a cartas de baralho, onde cada uma
156

Aula 04
apresenta um valor de uma escala de valores numéricos, que, normalmente, segue a seguinte
sequência:
a) 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10.
b) 0, 1, 2, 3, 5, 8, 13, 20, 40 e 100.
c) 0, 1, 2, 4, 8, 16, 32, 64, 128.
d) 1, 2, 3, 6, 12, 24, 48, 96.
e) 1, 5, 10, 50, 100, 500, 1000.
109. (FAURGS / TJ-RS - 2018) Considere as seguintes afirmações sobre SCRUM.
I - Um sprint do SCRUM é uma unidade de planejamento na qual o trabalho a ser feito é avaliado,
os recursos para o desenvolvimento são selecionados e o software é implementado.
II - O ponto de partida para o planejamento é o backlog do produto, que é a lista do trabalho que
será feito no projeto. Durante a fase de avaliação do sprint, esta lista é revista e as prioridades e
os riscos são identificados. O cliente está totalmente envolvido nesse processo e, no início de
cada sprint, pode introduzir novos requisitos ou tarefas.
III - No SCRUM, há o papel do product owner, que é um facilitador que organiza reuniões diárias,
controlando o backlog de trabalho, registrando decisões, medindo o progresso, comparando-o
ao backlog e se comunica com os clientes e a gerência externa à equipe.
a) Apenas I.
b) Apenas I e II.
c) Apenas I e III.
d) Apenas II e III.
e) I, II e III.
110. (Instituto Excelência / Prefeitura de São Carlos - SP – 2018) Considerando o Scrum, e os

papeis de partes interessadas, equipe e usuários. Avaliando as descrições abaixo defina os
papeis nas alternativas a seguir.
I) Atua como uma ponte entre a área de negócios, participa do planejamento das tarefas e do
objetivo define critérios de aceitação, este se compromete a não trazer mudanças dentro de
uma Sprint.
II) Assegura para que a equipe siga os valores e práticas, protege a equipe de alterações da Sprint
atua como facilitador removendo qualquer obstáculo ou algo levantado pela equipe
III) Lista contendo todas as funcionalidades desejada dos produtos com o tempo cresce ou muda
de acordo que se aprende sobre o usuário e seu produto:
157

Aula 04
a) I. Scrum Master II. Product Owner III. Product Backlog

b) I. Product Owner. II. Scrum Master. III. Product Backlog.
c) I. Sprint Master. II. Product Backlog. III. Scrum Master.
d) I. Product Backlog. II. Scrum Owner. III. Product Master.
e) Nenhuma das alternativas.
111. (INSTITUTO AOCP / PRODEB – 2018) O SCRUM é um método ágil que caracteriza-se por
ter bem definido quais são os papéis que precisam estar envolvidos no desenvolvimento do
projeto. Sendo estes:
a) Scrum Master, Gerente do Projeto, Analista de Negócio e Product Owner.

b) Equipe do Projeto, Gerente do Projeto e Analista de Requisitos.
c) Gerente do Projeto, Product Owner e Gerente de Recursos Humanos.
d) Scrum Master, Product Owner e Equipe do Projeto.
e) Product Owner, Gerente de Projetos, PMO e Analista de Negócios.
112. (INSTITUTO AOCP / PRODEB – 2018) Consiste de profissionais que realizam o trabalho de
entregar uma versão usável que potencialmente incrementa o produto “Pronto” ao final de cada
Sprint:
a) Time de Desenvolvimento.
b) Product Owner.
c) Scrum Master.
d) Stakeholder.
e) Sprintholder.
113. (INSTITUTO AOCP / PRODEB – 2018) O Product Owner exerce um papel fundamental para
a execução de um produto de sucesso dentro de um determinado método ágil. Ele é responsável
por realizar a comunicação entre o cliente e a equipe que está desenvolvendo o projeto. Em qual
método o Product Owner é considerado um dos três papéis que constituem a equipe?
a) Cascata.
b) Lean.
c) Scrum.
d) Espiral.
e) Prototipação.
114. (INSTITUTO AOCP / ADAF - AM – 2018) Scrum é uma metodologia ágil para gestão e
planejamento de projetos de software. No Scrum, os projetos são divididos em ciclos e tendem
a ser mais rápidos que a metodologia tradicional. No Scrum, existem três papéis. São eles:
a) Sprint; Stakeholders; Secretária.

b) Artefatos; Linguagem de Programação; Reuniões.
158

Aula 04
c) Product Owner; Scrummaster; Equipe.

d) Programador; Analista; Tester.
e) Gerente de sistemas; Sprint; Planejamento.
115. (INSTITUTO AOCP / UFOB – 2018) Scrum é um método de desenvolvimento ágil. Esse
método envolve as etapas de requisitos, análise, projeto, evolução e entrega do software.
116. (AOCP / UNIR – 2018) O Backlog da Sprint é a recomendação do trabalho que o Time
identifica como necessário para alcançar a meta da Sprint. Os itens do Backlog da Sprint devem
ser íntegros.
117. (AOCP / UNIR – 2018) O Product Owner é um comitê responsável pelo gerenciamento do
Backlog do Produto e por garantir o valor do trabalho realizado pelo Time Scrum.
118. (AOCP / UNIR – 2018) O ScrumMaster é responsável por garantir que o Time Scrum esteja
aderindo aos valores do Scrum, às práticas e às regras. Também ajuda o Time Scrum e a
organização a adotarem o Scrum e treina e leva o Time Scrum a ser mais produtivo e a
desenvolver produtos de maior qualidade.
119. (AOCP / UNIR – 2018) O framework Scrum consiste em um conjunto formado por Times
Scrum e seus papéis associados, Eventos com Duração Fixa (Time-Boxes), Artefatos e Regras.
120. (INSTITUTO AOCP / UFOB – 2018) No Scrum, são utilizados encontros diários, os chamados
Daily Scrum, para disseminar o conhecimento desenvolvido no dia anterior.
121. (INSTITUTO AOCP/ PRODEB – 2018) Sobre a retrospectiva de Sprint usando Scrum,
assinale a alternativa correta:
a) Ocorre depois da Revisão da Sprint.

b) Equivale à Revisão da Sprint.
c) É uma oportunidade para o Time Scrum inspecionar outros times.
d) Tem como objetivo resolver os itens que não foram concluídos durante a sprint.
e) É onde se planeja a próxima Sprint.
122. (FUNDATEC / SPGG – RS – 2018) O framework Scrum prescreve os seguintes eventos

formais para inspeção e adaptação:
a) Sprint e Daily Scrum.

b) Sprint Backlog e Daily Scrum.
c) Sprint Review e Sprint Backlog.
d) Product Backlog e Sprint Backlog.
e) Sprint Retrospective e Daily Scrum.
159

Aula 04
123. (FUNDATEC / SPGG – RS – 2018) Considere as seguintes assertivas sobre o framework

Scrum:
I. Emprega uma abordagem iterativa e incremental para aperfeiçoar a previsibilidade e o

controle de riscos.
II. Fundamenta-se em teorias empíricas de controle de processo, como, por exemplo, na
transparência.
III. São valores fundamentais do Scrum: comprometimento, coragem, foco, transparência e
respeito.
a) Apenas I.
b) Apenas III. ==f219==
c) Apenas I e II.
d) Apenas II e III.
e) I, II e III.
124. (FUNDATEC / SPGG - RS – 2018) Sobre o cancelamento de uma Sprint,

no framework Scrum, afirma-se que:
a) Somente o Scrum Master tem a autoridade para cancelar uma Sprint.

b) Somente o Product Owner tem a autoridade para cancelar uma Sprint.
c) Uma Sprint não pode ser cancelada antes de terminar o seu time-boxed.
d) Uma Sprint somente pode ser cancelada pelo cliente caso o seu time-boxed ainda não tenha
iniciado.
e) Uma Sprint somente pode ser cancelada pelo Time de Desenvolvimento caso o seu time-
boxed ainda não tenha iniciado.
125. (FAPEC / UFMS – 2018) Assinale a alternativa correta considerando as responsabilidades e

os papéis na metodologia SCRUM.
a) O responsável por gerenciar o Product Backlog (garantindo que esteja visível para todos),
gerar e disseminar os requisitos do projeto, assim como o plano para as entregas sucessivas,
priorizando os resultados que trarão maior valor agregado ao projeto, é o Product Owner.
b) O responsável por implementar o método Scrum, assim como por ensiná-lo a todos os
envolvidos nos projetos e assegurar que todos sigam as suas regras e práticas é
denominado Time Scrum.
c) O grupo de desenvolvedores que é coletivamente responsável pelo sucesso de cada iteração

e do projeto como um todo é conhecido como Scrum Masters.
160

Aula 04
d) O grupo de gerentes com responsabilidade de avaliar os custos do projeto é

denominado Scrum Cost.
e) O grupo de usuários finais do produto desenvolvido durante o projeto é denominado Scrum

Users.
126. (FAPEC / UFMS – 2018) Considere as afirmações a seguir sobre as fases da metodologia
SCRUM.
I - Product Backlog é uma lista ordenada por prioridade, produzida antes do início do
desenvolvimento, de itens que representam o que será produzido ao longo do projeto.
II - Cada ciclo de Sprint inicia com uma reunião de Sprint Planning.
III - Em cada ciclo de Sprint a reunião de Sprint Retrospective é realizada antes da reunião
de Daily Scrum.
Está(ão) correta(s):
a) Apenas I.
b) Apenas II.
c) Apenas I e II.
d) Apenas II e III.
e) I, II e III.
127. (INSTITUTO AOCP/ PRODEB – 2018) Considerando a metodologia Scrum, assinale a

alternativa que discorre corretamente sobre o que significa quando o item do Backlog do
Produto ou um incremento é descrito como “Pronto”:
a) A interpretação varia significativamente de um extremo ao outro para cada Time Scrum.

b) Cada integrante do time tem sua própria interpretação.
c) Significa Pronto para ser testado.
d) Significa Pronto para liberação em produção.
e) Significa que está pronto para ser implementado, ou seja, especificado.
128. (INSTITUTO AOCP/ PRODEB – 2018) Sobre as características gerais do Scrum, assinale a
alternativa correta:
a) Não prioriza feedback.

b) Seus princípios são consistentes com o manifesto ágil.
c) Foi proposto após os anos 2000.
d) Incorpora desenvolvimento mas não requisitos.
e) Não se adapta bem a requisitos mutáveis.
161

Aula 04
129. (INSTITUTO AOCP/ PRODEB – 2018) Sobre o método ágil denominado SCRUM, faça uma
análise das assertivas e assinale a alternativa que apresente somente práticas do método
SCRUM.
I. Sprint Planning Meeting (Reunião de Planejamento da Sprint).

II. Spikes Solution (Spikes de Planejamento).
III. Sprint Backlog (Backlog da Sprint).
IV. Client on Site (Clientes no Local).
a) Apenas I e II.
b) Apenas III.
c) Apenas II e IV.
d) Apenas II e III.
e) Apenas I e III.
130. (CESGRANRIO / Transpetro – 2018) A metodologia de desenvolvimento SCRUM é

caracterizada por ser ágil e rápida nas entregas. Um dos elementos-chave do processo SCRUM
é o Sprint, que é uma fase que acontece:
a) no fim do projeto, onde todos se esforçam para compensar os atrasos e cumprir o prazo.
b) no início do projeto, onde se procura entregar logo um grande volume de itens do projeto
para não arriscar atrasos.
c) sempre que necessário para compensar um atraso.
d) recorrentemente, ocorrendo de forma cíclica, várias vezes, até que se atinja o escopo do
projeto.
e) eventualmente, se necessário, caso ocorram eventos adversos não previstos que atrasem o
projeto.
131. (INSTITUTO AOCP / PRODEB – 2018) Sobre a definição de Scrum, assinale a alternativa
correta.
a) Scrum é um processo para construir produtos.

b) Scrum é um framework dentro do qual você pode empregar vários processos ou técnicas.
c) Scrum é uma técnica para construir produtos de software.
d) Scrum não permite resolver problemas complexos.
e) Scrum é considerado extremamente fácil de dominar.
132. (INSTITUTO AOCP / PRODEB – 2018) Em relação ao Backlog do Produto utilizando Scrum,
assinale a alternativa INCORRETA.
a) É uma lista ordenada de tudo que deve ser necessário no produto.

b) É uma origem única dos requisitos para qualquer mudança a ser feita no produto.
Requisitos nunca param de mudar, então o Backlog do Produto é um artefato vivo.
162

Aula 04
c) Mudanças de condições de mercado ou tecnologia podem causar mudanças no Backlog do

Produto.
d) Um Backlog do Produto deve estar completo antes do início da primeira Sprint.
133. (INSTITUTO AOCP / PRODEB – 2018) Considerando a realização de Reuniões diárias

utilizando Scrum, assinale a alternativa correta.
a) Serve para sincronizar as atividades e criar um plano para as próximas 12 horas.

b) Deve ser mantido no mesmo horário e local todo dia a fim de reduzir a complexidade.
c) Deve ter um time-box de, no máximo, 2h.
d) Não há regra clara sobre quem deve participar dessas reuniões.
e) Discussões detalhadas após a reunião diária são desencorajadas.
134. (FUNDATEC / CIGA-SC – 2018) Para responder à questão, considere a Figura 7, obtida a
partir do site <>, mostra, esquematicamente, uma visão geral do framework ou metodologia
ágil chamada Scrum. Nessa Figura, inseriu-se, em alguns locais, um retângulo, de modo a
ocultar inscrições existentes em tais locais.
Analise as seguintes assertivas sobre a metodologia ou framework ágil Scrum mostrada na

Figura 7:
I. A seta nº 1 aponta para uma etapa do framework chamada Product Backlog, que é uma lista
das funcionalidades desejadas para um produto. No Scrum, o conteúdo dessa lista é definido e
mantido pelo Scrum Master.
II. A seta nº 2 aponta para uma atividade chamada de Daily Scrum, que consiste em reuniões
diárias envolvendo, sempre que possível, toda a equipe de projeto, como, por exemplo, Product
Owner, Scrum Master, Scrum Team e Representante do Cliente, para avaliarem, em conjunto,
o andamento do projeto, assim como na identificação e resolução imediata dos problemas, de
modo que eles não evoluam e comprometam o andamento dos trabalhos.
III. No Scrum, a equipe monitora seu progresso em relação a um plano estabelecido, por meio
da atualização de um Release Burndown Chart, ao final de cada Sprint.
163

Aula 04
a) Apenas I.
b) Apenas II.
c) Apenas III.
d) Apenas I e III.
e) I, II e III.
135. (FUNRIO / Câmara de São João de Meriti - RJ – 2018) SCRUM é um framework dentro do
qual pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva
e criativamente entregam produtos com o mais alto valor possível. O SCRUM chama seus
eventos de timeboxes, uma vez que são eventos de duração fechada, sendo o componente
principal conhecido por Sprint, havendo alguns tipos, dos quais quatro são detalhados a seguir:
( I ) Time-boxe de 8h, de acordo com o tamanho da Sprint. Nesta reunião é onde o Product
Owner é ouvido em relação às prioridades e os objetivos. É nela também onde o time irá
deliberar sobre o que conseguem fazer em relação às necessidades, formalizando o Sprint
Backlog.
( II ) Time-box de 4h, onde o incremento do produto que está pronto para uso, é apresentado
ao Product Owner para apreciação. Também é nesta reunião, que deve ser facilitada pelo Scrum
Master, que o Product Owner apresentará os números, gráficos e tudo o mais que for importante
à equipe saber sobre o produto. Novas prioridades e movimentos do mercado, tudo focado em
manter os objetivos coerentes ao longo das sprints. Esse é o evento que melhor representa o
pilar de inspeção do Scrum.
( III ) Time-box de 3h onde o time de desenvolvedores e o Scrum Master, que atua apenas como
facilitador, falam sobre os resultados obtidos na Sprint que passou e as lições tiradas, para a
partir daí melhorar o processo, fortemente arraigado ao pilar de adaptação.
( IV ) Time-boxe de 15 min, sempre no mesmo local e horário para gerar consistência e evitar
perda de tempo, facilitada pelo Scrum Master. Nesta reunião, que deve ser muito dinâmica e
que popularmente é feita em pé, para evitar prolongamentos e distrações, cada membro do
time deve responder apenas três perguntas: o que eu fiz ontem, o que eu vou fazer hoje e se tem
algo me impedindo.
Os tipos (I), (II), (III) e (IV) são denominados respectivamente:
a) Sprint Retrospective, Daily Scrum, Sprint Planning e Sprint Review.

b) Sprint Planning, Sprint Rewiew, Daily Scrum e Sprint Retrospective.
c) Sprint Planning, Sprint Review, Sprint Retrospective e Daily Scrum.
d) Sprint Planning, Sprint Retrospective, Sprint Review e Daily Scrum.
e) Daily Scrum, Sprint Planning, Sprint Retrospective e Sprint Review.
164

Aula 04
136. (FAURGS / UFCSPA - RS – 2018) ____________ é uma metodologia ágil que fornece
um framework de gerenciamento de projetos. É centralizada em torno de um conjunto
de sprints, que são períodos determinados de tempo, quando um incremento de sistema é
desenvolvido. O planejamento é baseado na priorização de um backlog de trabalho e na seleção
das tarefas mais importantes para um sprint.
a) MDE – Engenharia Dirigida a Modelos

b) XP
c) SCRUM
d) MDA – Arquitetura Dirigida a Modelos
e) Programação em Pares
137. (IADES / APEX-BRASIL – 2018) Na metodologia Scrum, existem times que tipicamente
consistem de um dono do produto, um mestre Scrum e um time de desenvolvimento. Acerca
das respectivas responsabilidades, é correto afirmar que o:
a) mestre Scrum é o responsável por maximizar o valor do produto que resulta do trabalho do
time de desenvolvimento.
b) mestre Scrum é responsável por gerenciar o backlog do produto.
c) time de desenvolvimento tem autonomia para organizar e gerenciar seu próprio trabalho.
d) dono do produto é responsável por promover e suportar o Scrum, ajudando a todos

entenderem a teoria.
e) time de desenvolvimento garante que o dono do produto saiba como organizar o backlog do
produto para maximar o valor.
138. (PR4 / UFRJ – 2018) Assinale a alternativa que apresenta apenas papéis recomendados no
Framework Scrum.
a) Time Scrum, Scrum Master, Product Owner.

b) Time Scrum, Scrum Tester, Product Owner.
c) Time Scrum, Scrum Manager, Product Owner.
d) Scrum Manager, Scrum Tester, Product Owner.
e) Scrum Manager, Scrum Tester, Scrum Master.
139. (UFG / SANEAGO – 2017) Na metodologia SCRUM, quais são os itens registrados dentro de
uma “Retrospectiva”?
a) Pontos positivos, negativos e melhorias para a próxima iteração.

b) Itens entregues e itens a serem desenvolvidos.
c) Itens não entregues a serem desenvolvidos na próxima iteração.
165

Aula 04
d) Estimativas para o desenvolvimento de funcionalidades escolhidas pelo cliente
140. (UFG / SANEAGO – 2017) O pré-planejamento (também conhecido como pré-game) é uma
das cerimônias conhecidas da metodologia SCRUM. Por definição, é objetivo deste pré-
planejamento:
a) integração do software entregue na última interação com a versão que será desenvolvida.
b) distribuição dos pacotes de trabalho entre os membros da equipe.
c) detalhamento, priorização e estimativa de desenvolvimento dos pacotes de trabalho.
d) levantamento de pontos positivos, negativos e melhorias no processo.
141. (UFG / SANEAGO – 2017) Dentro do método SCRUM, quais são as informações utilizadas
para criar o gráfico burndown?
a) Tempo total da sprint e esforço estimado para as tarefas não realizadas.

b) Tempo gasto na resolução das tarefas do projeto e estimativas para as tarefas não realizadas.
c) Tempo gasto na sprint anterior e esforço de tarefas já realizadas.
d) Tempo total na resolução de impedimentos e estimativas para finalização do projeto.
142. (UFG / SANEAGO – 2017) Faz parte do conjunto de eventos do SCRUM um encontro
conhecido em inglês por Daily SCRUM. O Daily Scrum:
a) tem a duração fixa de 15 minutos.

b) é o instrumento empregado para relatar o progresso do projeto.
c) ocorre uma vez por semana.
d) é um encontro do qual o Scrum Master não participa.
143. (UFG / SANEAGO – 2017) Em uma equipe que trabalha orientada pelo Scrum,
a) a descoberta de um "erro" ou "defeito" recebe máxima prioridade e justifica a extensão da

Sprint por até 15 dias.
b) a identificação de novos requisitos pode ser feita durante reunião (Daily Scrum), na qual estão
presentes clientes do futuro produto.
c) o Scrum Master é responsável por orientar a equipe de desenvolvimento e definir como

transformar itens do backlog no incremento proposto para a sprint em questão.
d) a responsabilidade pela produção do incremento cabe a toda a equipe de desenvolvimento, a

despeito de um determinado membro da equipe possuir habilidades específicas.
144. (ESAF / ESAF – 2015) O SCRUM é uma metodologia ágil para gestão e planejamento de
projetos de software. Nele, as funcionalidades a serem implementadas em um projeto são
mantidas em uma lista que é conhecida como ____________. No início de cada Sprint, faz-se um
166

Aula 04
____________ na qual o ____________ prioriza os itens do ____________ e a equipe seleciona

as atividades que ela será capaz de implementar durante o Sprint que se inicia. As tarefas
alocadas em um Sprint são transferidas do ____________ para o ____________ .
a) Product Backlog, Sprint Backlog, Product Owner, Product Backlog, Sprint Planning Meeting
e Product Backlog.
b) Sprint Planning Meeting, Product Backlog, Product Owner, Product Backlog, Product
c) Product Backlog, Sprint Planning Meeting, Product Owner, Product Backlog, Sprint Backlog
e Product Backlog.
d) Product Backlog, Sprint Planning Meeting, Product Backlog, Sprint Backlog, Product
Backlog, e Product Owner.
e) Product Backlog, Sprint Planning Meeting, Product Owner, Product Backlog, Product Backlog
e Sprint Backlog.
145. (CESGRANRIO / CEFET-RJ – 2014) No Scrum, segundo o guia 2013, o responsável pelo
trabalho de expressar claramente os itens do Backlog do Produto é o:
a) Product Master
b) Product Owner
c) Scrum Master
d) Scrum Owner
e) Time de Desenvolvimento
146. (CESGRANRIO / EPE – 2014) No planejamento de projetos de software, e principalmente

em metodologias ágeis de desenvolvimento, muitos autores defendem a técnica conhecida
como “timebox”, que:
a) estima o menor e o maior tempo de desenvolvimento para cada funcionalidade a ser

desenvolvida, definindo uma “caixa” de tempo em vez de um prazo fixo.
b) parte do tempo disponível em uma fábrica de software para especificar versões consecutivas
de um produto, conhecidas como “caixas”
c) divide um produto de software em versões de complexidade crescente, conhecidas como

“caixas”, especificando o tempo de desenvolvimento de cada caixa do mais rápido para o mais
longo.
d) define um tempo para cada função a ser desenvolvida e as aloca em “caixas” de igual tempo
de desenvolvimento que são escolhidas pelos desenvolvedores.
167

Aula 04
e) define o tempo a ser utilizado em um ciclo de desenvolvimento e depois define a

funcionalidade que pode ser desenvolvida naquela “caixa” de tempo.
147. (UNIRIO / UNIRIO – 2014) De acordo com o autor Schwaber, o Scrum é um framework para
desenvolvimento e manutenção de produtos complexos baseado em três pilares, que são:
a) simplicidade, reflexão, organização.

b) transparência, inspeção e adaptação.
c) Scrum master, product owner, time de desenvolvimento.
d) backlog (do produto e do sprint), gráfico de burndown, incremento do produto.
e) controle, documentação, previsibilidade.
168

Aula 04
GABARITO
1. ERRADO 41. CORRETO 81. LETRA A
2. CORRETO 42. CORRETO 82. LETRA B
3. CORRETO 43. ERRADO 83. LETRA B
4. ERRADO 44. LETRA C 84. LETRA C
5. ERRADO 45. LETRA A 85. LETRA E
6. CORRETO 46. LETRA D 86. LETRA B
7. LETRA B 47. LETRA D 87. LETRA E
8. LETRA D 48. LETRA D 88. LETRA E
9. LETRA B 49. LETRA E 89. LETRA B
10. CORRETO 50. LETRA C 90. LETRA D
11. ERRADO 51. LETRA E 91. LETRA E
12. CORRETO 52. LETRA B 92. LETRA C
13. CORRETO 53. LETRA E 93. LETRA D
14. ERRADO 54. LETRA D 94. LETRA C
15. CORRETO 55. LETRA D 95. LETRA B
16. ERRADO 56. LETRA E 96. LETRA B
17. LETRA A 57. LETRA A 97. LETRA D
18. LETRA C 58. LETRA A 98. LETRA A
19. CORRETO 59. LETRA E 99. LETRA D
20. CORRETO 60. LETRA A 100. LETRA E
21. ERRADO 61. LETRA B 101. LETRA D
22. CORRETO 62. LETRA E 102. LETRA B
23. ERRADO 63. LETRA C 103. LETRA A
24. CORRETO 64. LETRA E 104. LETRA C
25. CORRETO 65. LETRA B 105. LETRA B
26. CORRETO 66. LETRA B 106. LETRA D
27. ERRADO 67. LETRA A 107. LETRA B
28. ERRADO 68. LETRA E 108. LETRA B
29. ERRADO 69. LETRA C 109. LETRA B
30. LETRA C 70. LETRA E 110. LETRA B
31. LETRA E 71. LETRA D 111. LETRA D
32. ERRADO 72. LETRA A 112. LETRA A
33. CORRETO 73. LETRA B 113. LETRA C
34. CORRETO 74. LETRA C 114. LETRA C
35. ERRADO 75. LETRA E 115. CORRETO
36. CORRETO 76. LETRA B 116. ERRADO
37. ERRADO 77. LETRA B 117. ERRADO
38. ERRADO 78. LETRA A 118. CORRETO
39. CORRETO 79. LETRA B 119. CORRETO
40. CORRETO 80. LETRA E 120. CORRETO
169

Aula 04
121. LETRA A 130. LETRA D 139. LETRA A

122. LETRA E 131. LETRA B 140. ANULADA
123. LETRA E 132. LETRA E 141. LETRA A
124. LETRA B 133. LETRA B 142. ANULADA
125. LETRA A 134. LETRA C 143. LETRA D
126. LETRA C 135. LETRA C 144. LETRA E
127. LETRA A 136. LETRA C 145. LETRA B
128. LETRA B 137. LETRA C 146. LETRA E
129. LETRA E 138. LETRA A 147. LETRA B
170

Scrum: conceitos básicos e origem do nome

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Scrum: conceitos básicos e origem do nome

Enviado por

Direitos autorais:

Formatos disponíveis

Aula 04

MP-MG (Analista do Ministério Público -

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

2) Metodologias Ágeis - Scrum - Pilares Fundamentais

3) Metodologias Ágeis - Scrum - Principais Valores

4) Metodologias Ágeis - Scrum - Papeis

5) Metodologias Ágeis - Scrum - Artefatos

6) Metodologias Ágeis - Scrum - Eventos

7) Metodologias Ágeis - Scrum - Novidades do Scrum

8) Resumo - Metodologias Ágeis - Scrum

9) Questões Comentadas - Metodologias Ágeis - Scrum - Multibancas

10) Lista de Questões - Metodologias Ágeis - Scrum - Multibancas

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

PROFESSOR DIEGO CARVALHO - www.instagram.com/professordiegocarvalho

INCIDÊNCIA EM PROVA: baixíssima

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

Scrum é um framework leve, simples de entender e extremamente difícil de dominar, para

[Guia Scrum - Versão 2017]

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

[Guia Scrum - Versão 2020]

Em suma, Scrum requer um Scrum Master para promover um ambiente onde:

1. Um Product Owner ordena o trabalho para um problema complexo em um Product Backlog.

Observem que o Scrum é aplicado no gerenciamento do “trabalho” de desenvolvimento dos

[Guia Scrum - Versão 2017]

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

[Guia Scrum - Versão 2020]

O Scrum é um framework para gerenciar projetos, produtos e processos, focado na adaptação em

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

O Scrum se baseia no empirismo e no lean thinking. O empirismo afirma que o conhecimento

TRANSPARÊNCIA INSPEÇÃO ADAPTAÇÃO

[Guia Scrum - Versão 2017]

[Guia Scrum - Versão 2020]

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

Também chamada de verificação, os usuários devem frequentemente inspecionar os artefatos

[Guia Scrum - Versão 2017]

[Guia Scrum - Versão 2020]

[Guia Scrum - Versão 2017]

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

[Guia Scrum - Versão 2020]

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

O Scrum possui basicamente cinco valores principais: coragem, foco, comprometimento,

[Guia Scrum - Versão 2017]

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

[Guia Scrum - Versão 2020]

(TRANSPETRO – 2018) Entre os processos de desenvolvimento de software ágeis mais

a) Comprometimento, coragem, foco e respeito

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

DEVELOPMENT TEAM DEVELOPERS

SCRUM TEAM (VERSÃO 2020)

SCRUM MASTER SCRUM MASTER

[Guia Scrum - Versão 2017]

[Guia Scrum - Versão 2020]

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

Em outras palavras, os times de desenvolvimento não contêm subtimes dedicados a domínios

a) Product Backlog, o Time de Planejamento e o Scrum Master

81286384591 - JUCIMAR CERQUEIRA DOS SANTOS

Product Owner (PO)

Ele é responsável pela macro-gestão e pela gestão do produto.

Ele é responsável por expressar claramente os itens do Product Backlog.

[Guia Scrum - Versão 2017]