Scrum - SFPC

Prévia do material em texto

SMPC (Scrummaster Certifield Professional): Prova aplicada pela CertiProf, em português, com 
Retake. São 40 questões, com uma hora, e com percentual mínimo de 60% para passar. 
O que é um projeto? 
Segundo o Pimbok, o "projeto é um esforço temporário empreendido para ciar um produto, 
serviço ou resultado exclusivo." 
Projetos são temporários porque tem início e fim definidos. 
O que é ser ágil? 
Evitar retrabalhos, basicamente. Ser ágil não está ligado a velocidade de processos, mas a 
evitar desperdícios. Evitando desperdícios, você se torna ágil. O planejamento é uma etapa 
crucial para que se obtenha agilidade. 
Modelo cascata de gerenciamento: 
Cascata ou waterfall é o modelo de gerenciamento de projetos onde uma etapa só se inicia 
após o término de outra, entregando o resultado consequentemente. Geralmente, este 
modelo tem bem definidas as etapas, e a quantidade de etapas pode variar. Até mesmo seu 
nome pode variar. 
Este modelo de gerenciamento é o mais utilizado 
O modelo ágil! 
Basicamente é um modelo interativo de gerenciamento de projeto. Ele é mais utilizado para 
projetos intangíveis, como softwares, pois em modelos de gerenciamento em cascata o cliente 
sabe o que esperar já no começo da execução do projeto. 
Em projetos ágeis, o cliente verifica cada implementação ou incremento que gerará o software 
final, de forma a saber cada parte do produto final desejado, e assim, poder acompanhar a 
criação do seu produto. Sendo assim, cada interação entrega uma parte utilizável do software 
ao cliente. Cada interação terá a análise, o projeto, a implementação e o teste daquela parte 
utilizável do software para o cliente. Os requisitos são divididos, de forma a cada incremento 
dar ao cliente uma visão do software, e agiliza processos do próprio cliente. 
 
 
Tipos de projetos - Modelo Cynefin (se pronuncia Cunefin) 
Cada ambiente pode ser classificado de quatro modos, sendo eles: 
SIMPLES, COMPLICADO, COMPLEXO E CAÓTICO. 
O ambiente SIMPLES é aquele onde sabemos exatamente o que precisamos fazer. São 
ambientes tranquilos, onde o que temos de fazer é bastante objetivo. 
O ambiente COMPLICADO é o que necessita de planejamento prévio, para a execução. 
Maiores mudanças podem ocorrer no processo. O que é planejado no início, será o entregue 
no final, mesmo que com poucas alterações, pois no momento de análise, podem ser vistos 
todos os requisitos necessários. 
O ambiente COMPLEXO é o ambiente de desenvolvimentos do software. É um ambiente 
imprevisível, pois não sabemos sempre previamente o que acontecerá. Definições podem 
mudar, planejamentos podem mudar de acordo com os erros e acertos... Mudanças são 
naturais neste ambiente, pois o resultado dependerá disso. Softwares são desejos de usuários, 
e os desejos mudam com facilidade ímpar. É necessário ter uma rotina de feedbacks rápidos 
ao cliente, de forma a saber sempre a direção a se tomar. Este é o ambiente perfeito para o 
Scrum. 
Já o ambiente CAÓTICO é o ambiente onde a criatividade brilha, e não existem padrões, 
melhores práticas ou práticas. Planos não fazem sentido. 
O mercado de ações segue este ritmo. Geralmente produtos inovadores que nunca antes 
foram vistos semelhantes, que geralmente são desenvolvidos em Startups seguem este 
modelo. Este tipo de projeto, quando estiver estabelecido para entregar a clientes, poderá ser 
migrado para o complexo, para que se tenha alguma previsibilidade de entrega, 
planejamentos... A arte faz parte desde cenário. 
No centro desde modelo, temos a DESORDEM, que é a classificação errônea do projeto. é, por 
exemplo, quando consideramos que fazer um software de CRM é um projeto simples, ou 
quando consideramos que trocar o pneu de um carro é um projeto caótico. 
MVP (Minimium Viable Product - produto mínimo viável) 
A etapa inicial de qualquer projeto é esta, onde temos a versão mínima do produto. Assim, se 
testa a eficiencia, usabilidade, aceitação de mercado e outros pontos que estruturam os 
problemas que o projeto se propõe a resolver. As vantagens são que as correções podem ser 
feitas bem precocemente e evita se grandes investimentos. 
O MVP não se trata de entregar funcionalidades capengas, mas entregar o necessário, sem 
desperdícios e com qualidade. 
O perigo do MVP é a entrega de "não produtos", onde o cliente não poderá usar a 
funcionalidade criada, e com isso não se mensura o resultado. Esse perigo desobedece ao 
título, pois significa não entregar algo viável. Como exemplo, posso colocar que, para 
solucionar o problema de locomoção para pessoas, não adianta nada primeiro entregar uma 
roda, depois outra, depois o banco, até montar um carro. O que adianta é entregar modais 
para locomoção, como bicicleta, patinete elétrico, motocicleta, até chegar no carro. 
 
Os valores do manifesto ágil 
"Estamos descobrindo maneiras melhores de desenvolver softwares, fazendo-o nós mesmos e 
ajudando outros a fazê-lo. Por meio deste trabalho, passamos a valorizar: 
. INDIVÍDUOS e INTERAÇÔES mais que PROCESSOS e FERRAMENTAS. 
. Software em funcionamento mais que documentação abrangente. 
. Colaboração com o cliente mais que negociação de contratos. 
. Responder a mudanças mais que seguir um plano." 
Os princípios ágeis 
1) Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de 
software de valor. 
2) Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se 
adequam a mudanças, para que o cliente possa tirar vantagens competitivas. 
3) Entregar software funcionando com frequência, na escala de semanas até meses, com 
preferência aos períodos mais curtos. 
4) Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e 
diariamente, durante todo o curso do projeto. 
5) Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte 
necessário, e confiar que farão seu trabalho. 
6) O método mais eficiente e eficaz de transmitir informações para, e por dentro de um time 
de desenvolvimento, é através de uma conversa cara a cara. 
7) Software funcional é a medida primária de progresso. 
8) Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e 
usuários, devem ser capazes de manter indefinidamente, passos constantes. 
9) Contínua atenção à excelência técnica e bom design, aumenta a agilidade. 
10) Simplicidade: A arte de maximizar a quantidade de trabalho que não precisou ser feito. 
11) As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis. 
12) Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e 
otimizam seu comportamento de acordo. 
 
 
A declaração de interdependência 
Aumentamos o retorno do investimento, fazendo com que o fluxo contínuo de valor seja o 
nosso foco. 
Fornecemos resultados confiáveis ao envolver os clientes em interações frequentes e 
propriedade compartilhada. 
Esperamos incerteza e administramos isso por meio de interações, antecipações e adaptações. 
Desencadeamos a criatividade e a inovação, reconhecendo que os indivíduos são a fonte 
suprema de valor e criamos um ambiente onde eles possam fazer a diferença. 
Aumentamos o desempenho através da responsabilização do grupo pelos resultados, bem 
como a eficácia da equipe a partir da responsabilidade compartilhada. 
Melhoramos a eficácia e a confiabilidade por meio de estratégias, processos e práticas 
específicos para cada situação. 
Lean Thinking - Identificar problemas e saber como resolver 
Metodologia de negócio que propõe uma estratégia de negócios voltada a satisfação do 
cliente. Toda a iniciativa precisa ser baseada no cliente. 
Essa forma de gestão visa a maior qualidade no menor prazo possível e com o menor custo, 
eliminando desperdícios. Esse sistema também é conhecido pela sigla TPS (Toyota Production 
System), que em português significa sistema de produção da Toyota. Esse sistema de produçãotem como bases os sistemas Just in Time e Jidoka. Com isso, a intervenção na produção, em 
caso de falhas é possível. 
Essa forma de gestão deve ser aceita por todos os times de uma empresa. 
Para alcançar a excelência nesta metodologia, que visa criar valor eliminando desperdícios, 
essas três perguntas devem ser respondidas: 
1) Como melhorar o trabalho? 
2) Qual é o problema que precisamos resolver? 
3) Como desenvolver pessoas? 
Essa metodologia surgiu no Japão, através do Taiichi Ohno, engenheiro e chefe de produção da 
Toyota após a segunda guerra mundial. Ele liderou este modelo de gestão entre 1950 a 1960. 
A gestão Lean tem cinco princípios, que são a base da metodologia. Eles são: 
1) Valor 
2) Fluxo de valor 
3) Fluxo contínuo 
4) Produção puxada 
5) Perfeição 
 
O Valor é definido de acordo com as necessidades do cliente, pois satisfará as suas 
necessidades. 
O Fluxo de Valor é a melhoria contínua do Valor, eliminando desperdícios. 
Após a definição do Valor, o Fluxo Contínuo garante a qualidade e agilidade da entrega, 
continuamente. 
A Produção Puxada garante que os desperdícios não acontecerão, pois, a produção do que 
garante valor é o foco. Pensado para o modelo Just In Time, por permitir agilidade e fluidez. 
A Perfeição é a busca pela melhoria contínua, de forma a focar sempre no valor. 
 
O que muda em uma empresa que implanta a metodologia Lean: 
O Problema vira Oportunidade, permitindo as intervenções humanas no processo em busca da 
perfeição. 
O Aprendizado Contínuo permite que a equipe sempre evolua, eliminando gastos e tendo 
objetivos em prol do valor a ser entregue. 
A Satisfação do Cliente como foco dos processos, em busca de melhor valor a ser entregue, 
sendo assim, os esforços são voltados sempre para o consumidor final. 
Os oito desperdícios do Lean 
No Lean, o desperdício é o consumo de recursos sem resultados ao consumidor final. Porém, 
não são todas as atividades que não agregam valor direto que podem ser retiradas, por conta 
de particularidades da operação de cada empresa. Testes de software, por exemplo, são 
necessários, portanto, existem: 
 
Desperdícios Necessários; aqueles que podem agregar valor no produto final, corrigindo 
possíveis erros ou falhas no processo, entregando um maior valor no produto ao consumidor 
final. 
 
Desperdício Puro; aquele desperdício que não agrega valor ao produto. Espera por entrega de 
partes de um produto, por exemplo. 
 
Porque é necessário reduzir os desperdícios comuns a metodologia Lean? 
Porque o produto final pode ter um custo menor, o tempo investido pode ser menor, a 
produtividade pode ser maior e a satisfação dos colaboradores pode ser maior. 
 
Os oito desperdícios do Lean são: 
 
1) Transporte; caso o transporte seja excessivo, o custo e tempo são maiores, deixando a 
produção mais lenta. Otimizar o transporte, e se possível evitar várias etapas dele é crucial. 
2) Inventário: Possuir muito inventário reduz a produtividade, aumenta a quantidade de 
colaboradores e o custo de estoque. 
3) Movimentação Desnecessária; Movimentação de maquinário ou pessoas durante o 
processo de desenvolvimento do produto causam um maior tempo para a entrega, e também 
podem gerar mais erros durante o processo. O ideal é ter pouca ou nenhuma movimentação, e 
os funcionários serem alocados em um só local, a fim de obter maior foco. 
4) Espera; O desperdício mais fácil de ser identificado. A espera atrasa a entrega do produto 
final. 
5) Produção Excessiva; quando se produz mais do que o consumidor final pede, você leva mais 
tempo e eleva seu gasto. Quando produz mais que o mercado consome, também. Manter 
alinhadas as expectativas de mercado e a produção é essencial. 
6) Processamento excessivo; aumentar processos para a entrega de um produto, entregando 
mais do que o cliente final quer, gera maior custo e maior tempo para a entrega. 
7) Defeitos e retrabalho; cada correção e retrabalho gera mais custo e demora na entrega dos 
resultados. 
8) Capital intelectual; não faz parte da lista original, mas deveria ser. A não utilização do capital 
intelectual gera demora na entrega de valor. 
O Lean no Desenvolvimento de Software 
Os sete princípios do Lean para desenvolvimento de software: 
1) Eliminar o Desperdício; quando os esforços não são direcionados a entrega de valor 
para o cliente, mas são direcionados a algo no sistema que o cliente não pediu ou não 
terá uso, como por exemplo a criação de um player de audio em sistema de caixa de 
mercado. O desperdício vem também de má comunicação, como a mania de informar 
que o trabalho está quase pronto, quando os processos são muitos para o 
desenvolvimento a ser feito, quando o funcionário se torna multitarefas, quando ele 
precisa esperar demais por uma entrega, quando a comunicação não é clara e direta e 
quando ele precisa corrigir muitos erros. 
2) Integrar Qualidade; A qualidade é a premissa do Lean, e com isso ela deve ser 
desenvolvida continuamente, a fim de entregar sempre o melhor produto para o 
cliente final, da forma mais rápida, e sem defeitos. Com isso, inspeções são 
necessárias. Elas devem ser feitas de forma corretiva e preventiva. Testar cada 
pequena implementação antes da consolidação em uma entrega é uma boa forma de 
buscar erros e os corrigir antes do cliente sofrer com isso, e é a forma mais rápida de 
tratar dos erros. Por isso que os testes feitos assim são uma função preventiva, pois 
funções corretivas se dão quando o cliente aponta os erros. Gigantescos backlogs de 
problemas são um erro também! Os erros devem ser corrigidos rapidamente. 
3) Criar Conhecimento; quanto mais desenvolvemos o projeto a ser entregue, mais 
descobrimos sobre ele, e mais conhecimento deve ser gerado, de forma a tornar as 
etapas mais fáceis para a entrega de qualidade. 
4) Adiar Comprometimentos; um comprometimento é uma tomada de decisão, 
basicamente. O deadline de um processo é um comprometimento. Adiar 
comprometimentos atrasa etapas, e atrasa a entrega do produto, deixando de gerar 
valor. O comprometimento é uma decisão sem volta, por assim dizer. Não podemos 
adiar, pois isso aponta ao cliente irresponsabilidade. 
5) Entregar Rápido; entregar rápido maximiza o ROI (Return On Investiment). Entrega em 
curtos prazos de tempo partes do produto faz com que o cliente veja as 
funcionalidades e aderência ao negócio, do produto a ser desenvolvido, além de trazer 
o cliente para perto de você, o que faz com que o produto necessário ao cliente 
sempre seja entregue, aumentando o valor percebido. 
6) Respeitar as Pessoas; não apenas tratar bem, mas deixar orgulho e ego fora do 
trabalho, para correr atrás da entrega do produto para o cliente, com o maior valor 
possível. Isso inclui ouvir opiniões dos desenvolvedores acerca do desenvolvimento, 
por exemplo. 
7) Otimizar o Todo; uma cadeia produtiva toda otimizada para que o produto seja 
entregue traz agilidade nos processos. Assim o fluxo de valor é otimizado. 
 
De onde surgiu o Scrum??? 
 
Hirotaka Takeuchi e Nonaka Ikujiro definiram uma estratégia de desenvolvimento de produtos, 
onde o time de desenvolvimento trabalha como uma unidade, um só corpo. Essa abordagem é 
chamada de Rúgbi, onde um time tenta percorrer uma distância como uma só unidade, 
passando a bola para frente e também para trás. O termo Scrum vem do Rúgbi, mas 
especificamente de uma formação de oito jogadores de cada time, após uma falta, para definir 
a posse de bola. A proposta deles é que o desenvolvimento de produto não deve ser uma 
corrida de bastão, onde um corredor corre por vez, ou um desenvolvedor performa por vez, 
mas como um time de rúgbi, onde todos correm em prol de um objetivo bem definido. 
Nos anos 90, Ken Schwaber e Jeff Sutherland desenvolveram o conceito do Scrum e a sua 
aplicabilidade para desenvolvimento de software. 
Os pilares do Scrum 
TRANSPARÊNCIA, INSPEÇÃO E ADAPTAÇÃO. 
O Scrum se baseia em Empirismo.Não se fixa o escopo e nem os processos de como construir 
o produto. Ao invés disso, em ciclos curtos, criamos partes entregáveis deste produto, 
inspecionando, corrigindo erros durante o processo e melhorando o desenvolvimento dele. 
Assim, mecanismos de transparência de inspeção são criados. Dessa forma, o produto sempre 
se tornará melhor. 
Transparência 
garantir que os aspectos dos processos devem ser visíveis e compreensíveis aos que controlam 
o resultado. 
Inspeção 
os processos devem ser inspecionados com uma frequência que detecte as alterações feitas. O 
processo pode ser alterado pela inspeção. Porém a inspeção não pode ter uma frequência 
exagerada, que atrapalhe a execução do projeto. Inspeção sem transparência gera desperdício, 
ou seja, inspeção sem ninguém saber de eventuais problemas não é Scrum. 
Adaptação 
as variações detectadas pela inspeção geram as adaptações. E as adaptações geram melhor 
valor ao cliente. Qualquer ajuste deve ser corrigido o mais rápido possível, para não atrapalhar 
próximos ciclos de entrega. 
Valores do Scrum 
Assim como no manifesto ágil, o Scrum também tem seus valores, que dão sustentação a ele. 
São cinco os valores do Scrum: 
Coragem 
O time Scrum precisa ter coragem para fazer a coisa certa e trabalhar em problemas difíceis; 
Foco 
Todos focam no trabalho da sprint e nos objetivos do Time Scrum 
Comprometimento 
As pessoas se comprometem pessoalmente em alcançar os objetivos do time scrum. 
Respeito 
os membros do time scrum respeitam uns aos outros, para serem pessoas capazes e 
independentes. 
Abertura 
O time Scrum e seus Stakeholders concordam em estarem abertos a todo o trabalho e aos 
desafios com a execução dos trabalhos. 
É de suma importância que os valores do Scrum sejam afixados em local onde todos possam 
ver, para que sejam sempre lembrados do motivo de adotarem esta metodologia de trabalho! 
O Ciclo Scrum 
Um projeto Scrum envolve um processo de colaboração para a criação de um produto, serviço 
ou qualquer outro resultado. Os projetos são afetados pelas restrições de tempo, custo, 
escopo, qualidade e diversos outros fatores. Tendo em vista que todo projeto é afetado assim, 
temos de escolher uma metodologia de trabalho que melhor mitigue esses problemas. 
O Scrum tem a proposta de ser um framework leve que ajuda pessoas, times e organizações a 
gerar valor por meio de soluções adaptativas para problemas complexos. A transparência na 
comunicação é garantida, criando um ambiente de responsabilidade coletiva com progresso 
contínuo. 
Um dos pontos fortes do Scrum está em usar times multifuncionais, autogerenciados e 
empoderados, que dividem o trabalho em ciclos curtos e concentrados chamados de SPRINTS. 
Cada SPRINT é um intervalo de tempo em que uma certa quantidade de trabalho deverá ser 
feito. 
O ciclo se inicia na fase pré sprint, onde as partes interessadas se reúnem e criam a META DO 
PRODUTO, que contém as metas e ideias que o produto a ser desenvolvido deverá entregar. 
Em seguida, o ROADMAP DO PRODUTO é desenvolvido. Ele é uma representação gráfica das 
entregas parciais ao longo de uma linha do tempo. O dono do produto é quem desenvolve este 
item. 
O Roadmap do Produto gera o BACKLOG DO PRODUTO. O Backlog do Produto é um conjunto 
vivo de histórias, escritas pelo dono do produto com informações fornecidas pelo cliente e 
partes interessadas. Este Backlog do produto não precisa ser definido em 100% logo no início 
do projeto, até proque, ele poderá ser modificado ao longo do desenvolvimento do produto. 
As Sprints se iniciam assim que o Backlog do Produto estiver maduro o suficiente para isso, o 
que significa que quando partes significativas das histórias dos usuários estiverem definidas. 
Com o Backlog do Produto maduro o suficiente, começamos as SPRINTS. Elas sempre se 
iniciam pelas reuniões de planejamento da Sprint. Nesta reunião, vemos as histórias a serem 
feitas na Sprint, e desta forma é gerado o BACKLOG DA SPRINT. Basicamente, com duração de, 
no máximo 4 semanas, o time Scrum trabalha para entregar incrementos utilizáveis. 
Uma reunião diária é feita, a fim de alinhar o progresso, saber o que precisa ser feito, como 
será feito... 
No fim de uma Sprint é realizada a reunião de revisão da Sprint, com o objetivo de demonstrar 
ao dono do produto e partes interessadas os entregáveis gerados. O dono do produto aceita 
apenas o que cumprir os critérios de aceitação predefinidos. 
O ciclo da Sprint termina com uma reunião de retrospectiva da Sprint, onde o time apresenta 
como melhorar seu desempenho e processos. Após isso, um novo ciclo se inicia. 
 
Planejamento em Camadas (Planning Onion) 
E um projeto ágil existem diversos níveis de planejamento, dispostos em diferentes camadas. 
Todas as camadas devem estar alinhadas entre si. Como exemplo, a camada de produto tem 
de estar alinhada com a cama de estratégia. Os níveis citados abaixo devem ser imaginados 
como camadas, e a cada camada citada, mais profundo é o planejamento: 
• Estratégia: é a primeira forma de planejamento. Ela define o que a empresa é, onde 
quer chegar e o que ela deseja se tornar. Essa camada define todo o restante da 
execução. Essa camada trata pouco sobre a confecção de um produto, mas trata de 
prazos e objetivos estratégicos. 
• Portifólio: Essa camada representa o portifólio de projetos, que consiste em 
ferramentas e como elas devem interagir, buscando sempre a integração. Geralmente 
a gerência geral ou cargo similar é quem cuida desta camada, por ter uma visão geral e 
ampla sobre as diversas linhas de produtos, no qual as decisões devem apoiar a visão 
estratégica e os objetivos como prazo e orçamentos dos projetos. 
• Produto: É a camada do produto que o projeto está desenvolvendo. Os portifólios 
geram projetos que geram produtos. Cada equipe define uma visão sobre o produto a 
ser desenvolvido e cria um roteiro de execução. 
• Release ou entrega: Camada de backlog priorizado com os planos definidos na camada 
de produto. É a camada de entregas de valor ao cliente. Uma entrega é composta por 
uma ou mais interações. 
• Sprint ou interação: Etapa de planejamento do conjunto de funcionalidades que serão 
entregues ao cliente. Ao se planejar as entregas, define-se a quantidade de interações 
de cada entrega. Essa é a etapa de elaboração do produto a ser entregue. 
• Daily: Essa é a menor camada, onde a equipe deve se reunir diariamente em cerca de 
15 minutos, fazendo uso da reunião diária do Scrum, onde relatam o que foi concluído 
e não, quais os planos diários e possíveis obstáculos ao cumprimento do plano diário. 
 
Framework ou Metodologia? 
Existe uma certa confusão sobre se o Scrum é uma metodologia ou framework. 
Para o Guia do Scrum, da Scrum.org, o Scrum é um framework. Segundo ele, o Scrum se baseia 
no Controle de Processos empíricos e o que isso quer dizer? Quer dizer que com Controle de 
Processos Empíricos nós não fixamos o escopo do produto e nem os processos de como 
construí-lo. Em vez disso, em ciclos curtos, criamos uma pequena parte utilizável do produto, 
inspecionamos o que o criamos, adaptamos o produto e a forma de como o construímos e 
criamos mecanismos de transparência para permitir uma clara inspeção. 
E como não são definidos os processos, ou seja, o passo a passo de criação de um produto, 
então não temos uma metodologia, e sim um framework. 
 
Papéis e responsabilidades 
O Framework Scrum tem três papéis bem definidos, sendo eles os Desenvolvedores, o Scrum 
Master e o Product Owner. Esse framework não tem como necessário um gerente de 
projetos. 
Time scrum (Scrum Team) 
Essa é a unidade fundamental do Scrum. A partir dela, o time conseguirá desenvolver produtos 
com excelência. Esse time é composto por três papéis somente, sem a possíbilidade de 
alterações, pois o framework só funciona obedecendo esta regra. 
O tamanho ideal do time scrum é de dez ou menos pessoas. É grande o suficientepara ter 
pessoas e habilidades para desenvolver os projetos apresentados e pequeno o suficiente para 
facilitar a comunicação. Caso se sinta a necessidade de um time grande demais, o necessário é 
reorganizar, de forma a criar diversos times alinhados com a entrega que deverá ser feita, sem 
perder a facilidade gerencial e a comunicabilidade dentro de cada time. 
Esse time deve ser empoderado pela organização a gerenciar o seu próprio trabalho, de forma 
a entregar incrementos de valor a cada final de sprint. 
O time Scrum é composto por: 
Product Owner, ou dono do produto. Apenas uma pessoa, envolvida em tempo total ou 
integral. É um integrante voltado a negócios, e não lider técnico. 
Scrum Master. Também, somente um integrante. Ele pode estar envolvido em tempo parcial 
ou integral ao time scrum. Ele é o especialista nas práticas do Scrum, e também não é um lider 
técnico. 
Developers, ou desenvolvedores. O nome é autoexplicativo. As habilidades geralmente são 
amplas, de acordo com o projeto e os incrementos entregáveis a serem desenvolvidos. 
 
Os times scrum devem ser: 
Multifuncionais, o que significa que o time é capaz de entregar valor a cada sprint, 
independente do que lhes é confiado. 
Autogerenciados, o que significa que decidem entre si quem faz o que, como e quando. 
O time scrum não tem hierarquias ou diversos times, pois todos devem focar em um objetivo 
por sprint. 
 
A coordenação e comunicação entre os times scrum podem ser feitas de diversas maneiras, 
mas a mais comum é a Reunião de Scrum de Scrums, onde representantes de cada time se 
reúnem para trocarem informações sobre seus projetos. 
 
Scrum Master 
Este papel é o de um facilitador. É o responsável por entregar um ambiente aos 
desenvolvedores propício ao desenvolvimento dos entregáveis. 
Ele é o responsável por guiar, facilitar e ensinar as práticas do Scrum para todos os envolvidos 
no projeto. Ele remove os impedimentos encontrados e assegura que os componentes do 
Scrum estejam sendo seguidos. Ele é o responsável por identificar se a equipe tem o 
conhecimento necessário para desenvolver o produto, ou se precisam de treinamento, 
contratação etc. 
O papel de um Scrum Master é de lider servidor, aquele que não delega papéis, e serve a 
equipe de forma a garantir o necessário para o desenvolvimento do entregável. Ele também é 
um coach. A responsabilidade de gerenciamento da equipe não é atribuição do Scrum Master, 
pois o time de desenvolvedores é autogerenciado. 
Um Scrum Master serve ao time de diversas maneiras. Algumas são: 
• Treinamento dos membros do time 
• Auxílio em concentrar a criação do objetivo do incremento a ser criado na Sprint. 
• Removendo quiser impedimentos. 
• Garantindo que todos os eventos Scrum ocorram 
O Scrum Master auxilia o Product Owner de diversas maneiras, tais como: 
• Ajuda a encontrar técnicas para a definição de meta do produto e gerenciamento do 
backlog do produto. 
• Ajudando ao Product Owner a apresentar ao time de desenvolvedores a necessidade 
de itens do backlog do produto claros e concisos. 
• Ajudando a estabelecer o planejamento empírico do produto em um ambiente 
complexo. 
• Facilitando a colaboração das partes interessadas conforme necessário ou solicitado. 
Além disso, o Scrum Master pode servir a organização de diversas maneiras, tais como: 
• Liderar, treinar e orientar a organização nas práticas Scrum. 
• Planejar e aconselhar implementações do Scrum na organização. 
• Ajudar a todos da organização e as partes interessadas a compreender e aplicar uma 
abordagem empírica para trabalhos complexos. 
• Remover barreiras entre as partes interessadas e outros times Scrum. 
A responsabilidade do sucesso da implementação e uso do framework não é papel exclusivo 
do Scrum Master, contudo o conhecimento dele é peça fundamental para o sucesso de um 
time Scrum. 
Existe a preferência de que um Scrum Master seja alguém com experiência em 
desenvolvimento, porém um conflito inerente é a escolha de realizar uma tarefa para não 
perder um prazo ou retirar um impedimento do time, que acarrete a um atraso na entrega do 
incremento. 
O Scrum Master tem de participar de todos os eventos do Scrum, menos a reunião diária, 
composta somente pelos desenvolvedores. 
 
Product Owner 
Este é o responsável por alcançar o maior valor de negócio para o produto. Ele é o 
coordenador das necessidades dos clientes. É ele quem garante a comunicação do time Scrum 
sobre requisitos de funcionalidades do produto ou serviço, definindo os critérios de aceitação 
e garantindo o cumprimento desses critérios. É papel de uma só pessoa, mesmo podendo ter 
um comitê para lidar com as responsabilidades deste papel, mas uma única pessoa representa 
este comitê no time Scrum. Somente ele tem a permissão para falar com os desenvolvedores 
sobre mudanças de prioridades. O Scrum Master ou os Developers não podem alterar ou 
definir as prioridades. 
Os desenvolvedores são responsáveis pela qualidade técnica do produto, mas se ele não 
cumpre os objetivos de valor para o cliente, o responsável é o Product Owner, por isso ele 
pode definir as prioridades do que será entregue. 
Ele tem como responsabilidade o Backlog do Produto, que é a lista de itens, ou PBI’S ou 
Product Backlog items que o cliente espera do projeto. Esta é a principal ferramenta de 
planejamento do Scrum, inclusive. 
Existem outras responsabilidades do Produto Owner, que são? 
• Desenvolver e comunicar explicitamente a meta do produto. 
• Criar e comunicar claramente os itens do Product Backlog. 
• Ordenar e priorizar os itens do Product Backlog. 
• Garantir que o Product Backlog seja transparente, visível e compreensível. 
• Acompanhar o progresso do projeto e prever datas de entrega. 
• Controlar o orçamento do projeto. 
Ele precisa entender do negócio do produto a ser feito, para poder priorizar cada item de 
acordo com o que o cliente espera, com base em seu ROI (Return of Investiment) ou qualquer 
fator que seja relevante para o cliente, do ponto de vista comercial do projeto. 
A organização deve respeitar as decisões do Product Owner para que o projeto seja bem-
sucedido. Ninguém, nem mesmo o dono da empresa deve anular as suas decisões, e ninguém 
deve dizer no lugar dele quais itens os desenvolvedores entregarão. As suas decisões podem 
ser influenciadas por terceiros, mas para o bom andamento do time Scrum, ele quem deve 
decidir as prioridades. 
Ele pode delegar algumas funções a outras pessoas, como itens do Product Backlog a um 
desenvolvedor, porém, a responsabilidade de entrega e dos dados será inteiramente dele. 
O Product Owner pode ser um analista de negócios, gerente de produto, usuário final do 
cliente ou um desenvolvedor. Nunca é aconselhável que seja um desenvolvedor, por existir 
iminente risco de conflito de papéis em momentos de decisão, priorização e definição de valor 
a ser entregue. 
 
Developers, ou desenvolvedores 
Eles são os responsáveis por criar um incremento utilizável em cada Sprint. Eles trabalham na 
Sprint Backlog e possuem habilidades amplas, que variam de acordo com o trabalho. 
É um grupo necessariamente multifuncional ou Cross-funcional, capaz de desenvolver o que 
for necessário para a entrega do incremento no final da Sprint. 
Eles são autogerenciados. Devem se auto-organizar para desempenhar sua função como um 
organismo só, sem a necessidade de serem ordenados por terceiros. Eles devem ter uma visão 
bem clara das metas do projeto. 
Mesmo que uma tarefa seja designada a um desenvolvedor do time, todos são responsáveis 
pela entrega, por isso é necessário que trabalhem e equipe sempre. Não existe trabalho 
individual. Todos colaboram! 
Eles precisam trabalhar em tempo integral em um único projeto, pois isso mantém o foco e 
agilidade da entrega. 
O time não pode ser alterado com frequência, e nunca deve ser alterado durante uma Sprint. 
Uma troca de pessoas sempre acarretaqueda de produtividade, devido ao entrosamento da 
equipe e a necessidade de treinamento do novo integrante da equipe. 
É aconselhável ter sempre mais de três desenvolvedores, embora não citado em guias do 
Scrum. Menos de três desenvolvedores pode acarretar queda da multifuncionalidade. Se 
alguma habilidade estiver faltando, a Sprint é prejudicada. Também é aconselhável ter menos 
de dez membros, pois muita gente acarreta dificuldade de autogerencia do grupo. 
Como o time não tem sub-times, não existem papéis diferentes no time de desenvolvimento, 
por exemplo, micro time de designers, de programadores, de testadores etc. Todos são 
desenvolvedores. Claro que todos não exercerão a mesma função no time, mas a 
responsabilidade sempre é coletiva. E o importante a salientar é que o papel de desenvolvedor 
não é somente de programador, mas de parte integrante do time para desenvolver o 
incremento a ser entregado no fim da Sprint. E como eles são auto-organizados e 
autogerenciados, ninguém aloca tarefas a eles. As tarefas são claras em cada Sprint, para o 
time, onde cada um se voluntaria para fazer o que melhor faz, para desenvolver o incremento, 
em unidade. 
Sendo assim, o Scrum Master e o Product Owner não podem alocar tarefas aos 
desenvolvedores. 
 
Artefatos do Scrum 
Dentro do Framework Scrum, alguns documentos são essenciais para que o trabalho consiga 
ser realizado com sucesso. A documentação e outros elementos gráficos utilizados ao longo de 
um projeto Scrum são denominados artefatos. Eles são projetados para maximizar a 
transparência das informações chave necessárias para assegurar que o Time Scrum tenha 
sucesso nas entregas do projeto. 
Os artefatos são o Product Backlog, Sprint Backlog, Incrementos, História de Usuário, Quadro 
de Tarefas e o Gráfico de Burndown. 
Oficialmente, somente a Sprint Backlog, Product Backlog e o Incremento são oficiais no 
Framework Scrum, pois constam no seu guia. Os demais são adotados pelos praticantes do 
Scrum. 
Product Backlog ou Backlog do produto 
É uma lista ordenada e emergente do que é necessário para construir ou melhorar um produto 
já existente. 
É uma origem única dos requisitos do produto, que precisam ser entregues, bem como todo o 
entendimento necessário para atender aos requisitos, produzir funcionalidades e, por fim, 
entregar um produto completo, incluindo mudanças e evoluções em produtos já existentes. 
Segundo o Guia do scrum, 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 alfo mais abstrato. 
No Backlog do Produto temos uma lista ordenada de itens a fazer, composta por todas as 
características, funções, tecnologias, melhorias e correções que constituem a versão futura de 
um produto. 
Uma das características dele é ser dinâmico, ou seja, está constantemente mudando para 
identificar o que o produto precisa para ser apropriado, competitivo e útil ao cliente final. Por 
isso, enquanto existir um produto, o backlog dele também existirá. E por isso, um backlog de 
um produto raramente está completo, pois ao iniciar o desenvolvimento dos primeiros 
incrementos do produto, estarão estabelecidos apenas os requisitos inicialmente conhecidos e 
mais bem compreendidos. 
Os artefatos oficiais do Scrum possuem uma meta a ser atingida. Sem essa meta, o artefato 
pode se desviar do seu principal objetivo. Por isso, ao se criar o Backlog do Produto, devemos 
estabelecer um compromisso a ser alcançado, que é a Meta do Produto, ou Product Goal. 
Essa meta é um objetivo ou necessidade de negócios de alto nível que fornece contexto, 
orientação, motivação e inspiração para o trabalho de desenvolvimento do produto durante 
todo o projeto. É o objetivo maior a ser alcançado pelo Time Scrum, que se traduz na satisfação 
dos clientes. Esta meta pode ser escrita pelo cliente e entregue diretamente ao Product 
Owner, ou os dois descrevem juntos. A descrição conjunta é a forma mais comum de 
determinar a Meta do Produto, pois do Product Owner entende os valores desejados pelo 
cliente para a entrega do produto. 
 
Sprint Backlog ou Backlog da Sprint 
É um plano de trabalho criado pelos desenvolvedores, uma imagem em tempo real do 
trabalho que eles planejam realizar durante a Sprint para atingir a sua meta. 
O Backlog da Sprint é composto por três objetos, sendo eles: 
• Meta da sprint, ou motivo de trabalho da Sprint. 
• Um conjunto de itens do Backlog do produto, a serem desenvolvidos, ou o que iremos 
desenvolver pra atingir a meta. 
• Plano de ação, para que seja possível fazer tudo e entregar o incremento desejado. 
Para a entrega do incremento que a Sprint Backlog se propõe a entregar, as tarefas e 
atividades propostas devem ser feitas. Elas estão incluídas somente no Sprint Backlog e só 
podem ser excluídas, movidas ou alteradas pelos Desenvolvedores, se necessário. 
Novas tarefas podem ser adicionadas somente pelos Desenvolvedores, caso haja necessidade. 
Os itens do Sprint Backlog, oriundos do Product Backlog não podem ser alterados durante o 
curso da Sprint. 
Este Sprint Backlog é de propriedade dos desenvolvedores, e eles são os responsáveis pela sua 
gestão. Ele pode ser atualizado durante o aprendizado obtido na Sprint e deve ter detalhes 
suficientes para que os desenvolvedores supervisionem o seu trabalho na reunião diária. 
A Sprint Goal, ou Meta da Sprint é a única meta na Sprint. Ela dá o Norte para o time, criando 
foco sobre o que é necessário ser entregue, sempre validando a importância de trabalho em 
conjunto e autogerenciado. Esta meta é criada no planejamento da Sprint. 
 
Incremento 
É uma parte utilizável de um produto final. Dentro de uma Sprint, um ou mais incrementos 
podem ser criados, a fim de entregar valor ao cliente. Basicamente um ou mais incrementos 
são entregues como o alcance de uma meta, que é o Sprint Backlog concluído. 
O nome Incremento é usado, pois são pequenas partes de um produto que dão forma a ele e o 
completam, sendo adicionados quando concluídos. 
A soma dos incrementos é apresentada na Sprint Review, mesmo com vários tendo sido 
liberados. 
A Sprint Review não é um marco de entrega de valor. A entrega de valor é feita 
continuamente em cada Incremento sendo usado pelo cliente. 
Todo Incremento, quando pronto, tem a Definition of Done, ou Definição de Pronto quando 
atende as medidas de qualidade exigidas para o produto. Ele gera transparência, ao apresentar 
sempre ao cliente e partes envolvidas quando um Incremento está pronto para uso. E, para 
um produto ser considerado pronto, as avaliações podem incluir: 
• Avaliação da funcionalidade por outros membros do time. 
• Conclusão do teste unitário. 
• Conclusão de testes de qualidade. 
• Conclusão de toda a documentação relacionada a história de usuário. 
• Demonstração bem-sucedida para as partes interessadas e representantes do negócio. 
Todas as definições de pronto devem ser satisfeitas, para que o item do Product Backlog seja 
considerado pronto. Existe uma necessidade de definição de “pronto” por causa disso, pois a 
ambiguidade é eliminada e o time adere facilmente aos padrões de qualidade exigidos pelo 
cliente. E alguns critérios de “pronto” são: 
• O design foi aprovado pelo especialista em usabilidade. 
• A funcionalidade passou por todos os testes mandatórios. 
• Os Helps foram disponibilizados. 
Sem isso, um item não deve ser apresentado na Sprint Review e assim retorna ao Product 
Backlog para futura avaliação. 
Se a Definição de Pronto fizer parte dos padrões da organização, todos os times Scrum devem 
segui-la. Caso não exista, o time scrum deve criar a sua própria. E os desenvolvedores devem 
estar de acordo e sempre seguir a Definição de Pronto. 
Caso vários times Scrum trabalhem sem uma Definição de Pronto, uma deve ser criada, e 
todos os times devem estar de acordo e obedecer.História de usuário 
Uma história curta e objetiva de uma funcionalidade requerida para atender os critérios de 
aceitação do Incremento a ser entregue, sempre partindo do ponto de vista do usuário final. 
Essa história não é necessariamente um texto contendo a funcionalidade completa, mas uma 
promessa de discussão da funcionalidade ou um lembrete de que a discussão já aconteceu. 
É essencial que as histórias caibam em um Post It. Como exemplo, caso um produto fosse um 
sistema de video on demmand, como Netflix, a história poderia ser: “Como um cliente, eu 
quero ver os filmes para escolha, para assistir.” 
Quando a História de Usuário é grande demais, a chamamos de épicos. São histórias que 
podemos quebrar, de maneira a caberem em post its e serem mais simples de entendimento 
pelo time de desenvolvimento. A única regra é que a história deva ser pequena, sendo o 
conceito de pequeno a cargo do time de desenvolvimento. E como dicas, temos: 
• Se não cabe em uma Sprint, é um épico. 
• Se eu consigo quebrar em dois ou mais post its, é um épico. 
• Se, durante uma estimativa, a discordância foi grande entre o time, é um épico. 
Scrum Board, ou Scrum Taskboard 
Conforme apresentado abaixo, um quadro onde o time coloca as tarefas do Backlog em post 
its de forma organizada e ordenada. 
O objetivo deste quadro é o entendimento rápido e claro do andamento do trabalho. E o 
funcionamento é bem simples: 
• Estórias de usuário; elas compõem o Sprint Backlog. 
• A fazer; as estórias são divididas em tarefas. 
• Em andamento; tarefas sendo feitas por algum membro do time de desenvolvimento. 
• Em testes; ao findar do desenvolvimento, o incremento é testado. 
• Pronto; O incremento está pronto para ser entregue e validado em uma Sprint Review 
Gráfico de Burndown 
A ferramenta mais utilizada no monitoramento do progresso de um projeto. 
 
Este gráfico a direita apresenta de forma clara e objetiva os dados da planilha a sua esquerda. 
Existem dois tipos de gráfico Burndown, sendo eles: 
 
 
• Burndown do produto, ou release. Registra a some dos esforços restantes do backlog 
do produto ao longo do tempo. O esforço estimado pode estar em qualquer unidade 
de medida que o time julgar necessário, mas geralmente a unidade de medida são 
Sprints. 
• Burndown da Sprint. Apresenta a quantidade de trabalho restante do Sprint Backlog 
ao longo dos dias de duração da Sprint. O esforço estimado pode estar em qualquer 
unidade de medida, mas geralmente a medida é de horas ou dias. 
Eventos 
Cada evento no Scrum é uma oportunidade formal para inspecionar e adaptar os Artefatos do 
Scrum. Os Eventos são projetados especificamente para permitir a transparência necessária. A 
falha em ter os eventos acarreta oportunidades perdidas de inspeção e adaptação, o que pode 
resultar em perda de entrega de qualidade ao cliente. 
Os eventos geram regularidade e redução de reuniões não definidas. E é ideal que eles 
ocorram em mesmo horário e local, tornando tudo mais simples. 
Time Boxing 
Conceito de caixa de tempo, ou tempo limitado. É um evento com tempo limitado, sem a 
possibilidade de extensão por não finalizar o trabalho a ser feito. O time deve se adaptar ao 
Time Box para a entrega do que é desejado, e caso não seja possível, abandonamos as 
atividades de menor importância. E existem duas modalidades de Time Box, sendo elas: 
• Duração fixa, ou seja, caso as atividades sejam concluídas bem antes do tempo se 
encerrar, mais atividades são inseridas neste Time Box. 
• Duração máxima, ou seja, a duração do TimeBox tem um limite, mas se não o 
alcançar, ele é encerrado. 
O conceito de reuniões em TimeBox tem como metas: 
• Reuniões mais focadas e objetivas, por conta da limitação de tempo. 
• Melhor noção da velocidade de trabalho. 
• Equipe mais focada. 
• Eliminação do desperdício de tempo. 
• Valorização do tempo de trabalho. 
• Dedicação exclusiva para a atividade dentro do TimeBox. 
Sala de guerra 
Os eventos Scrum são ferramentas de comunicação. Por conta disso, um ambiente adequado 
para a realização dos eventos é essencial. 
No Scrum, é essencial que o time esteja alocado em um mesmo ambiente de trabalho. O 
termo usado para este ambiente é Sala de Guerra ou War Room. Geralmente, este ambiente é 
pensado para que se possa circula e trocar informações livremente. Geralmente, é uma sala 
barulhenta, devido a conversa do time, mas as conversas sempre são acerca do projeto. E o 
barulho é a chamada Comunicação osmótica, pois se temos dois integrantes do time 
conversando sobre um problema, qualquer outro membro pode ouvir a conversa e ajudar na 
solução ou aprender coisas novas pelo ato de ouvir a conversa mesmo. 
Esta sala não deve ter divisórias, o que permitirá que a comunicação seja mais clara, com olho 
no olho, se preciso. 
No caso de trabalho a distância que é a realidade atual, o bom uso de ferramentas como 
Google Meetings, Zoom, Discord, Teams e outros é o que torna este trabalho possível, com 
criação de grupos ou salas com o mesmo conceito, sendo preferencialmente com a 
comunicação por voz. 
 
Sprint 
Este é o coração do Scrum! É onde as ideias são transformadas em valor, pelos 
desenvolvedores. É um container para todos os demais eventos do Scrum. 
Sprint é a fase de desenvolvimento do incremento a ser entregue ao cliente. É um evento de 
TimeBox interativo de duração fixa. A duração varia de uma a até no máximo 4 semanas e 
possuem meta estabelecida de entrega de parte de funcionalidade ao cliente, sendo este o 
incremento. 
Dentro da Sprint todo o trabalho necessário para atingir a meta acontece, sendo eles a Sprint 
Planning, Daily Scrum, Sprint Review e Sprint Retrospective. 
É importante salientar que: 
• Nenhuma mudança que coloque em risco a meta da Sprint pode ser realizada. 
• A qualidade não diminui, ou seja, deixar de testar um item porque o TimeBox está se 
esgotando não é permitido. 
• O Product Backlog deve ser refinado continuamente. 
• O escopo pode ser esclarecido e renegociado com o Product Owner conforme mais é 
aprendido. 
Sprint 0 
O time Scrum, em conjunto, deve delinear todos os trabalhos da próxima Sprint. Porém, é na 
Sprint 0 que se prepara o ambiente de trabalho antes de iniciar a reunião de planejamento da 
Sprint, com o objetivo de eliminar impedimentos em sua execução. É uma etapa pequena e 
rápida. 
Antes de trabalhar em sua cerimônia, é bom conhecer alguns conceitos sobre esta Sprint. 
Deixar tudo pronto para esta Sprint ser rodada, organizando todo necessário, para não ocorrer 
pausa ou rompimento da Sprint, como hardware, sala, software, materiais de escritório e tudo 
mais que for necessário, incluindo a disponibilidade da equipe. E está etapa não é prevista no 
guia do Scrum. 
Podemos cancelar uma Sprint? 
O Product Owner tem a autoridade para cancelar uma Sprint, e poderá ocorrer quando o 
incremento a ser entregue se torna obsoleto. 
Quando uma Sprint é cancelada, os itens já finalizados são revisados e aceitos, e o restante dos 
itens que ainda não foram terminados voltam para o Product Backlog para serem executados 
em algum ponto do futuro. 
Itens do Sprint Backlog podem mudar? 
Esse Backlog pertence somente aos desenvolvedores, e somente eles podem alterar. 
Muitas vezes um item do backlog do produto escolhido para a Sprint, para ser corretamente 
desenvolvido precisará ser decomposto em várias tarefas. Assim, quando novas tarefas forem 
necessárias, os desenvolvedores poderão adicioná-las a qualquer momento da Sprint. Da 
mesma forma, se uma tarefa não for necessária, ela deverá ser retirada da Sprint Backlog. 
Itens do Product Backlog comprometidos para a Sprint só podem ser alterados depois de serem 
negociados com o Product Owner. 
 
Reunião de planejamento da Sprint, ou Sprint Planning Meeting 
É sempre o início de uma Sprint. É a reunião em que se planeja toda uma Sprint. 
Geralmente, são reuniões de 8 horas de duração para uma sprint de ummês de duração, ou 
seja, duas horas para cada semana de Sprint. O valor é sempre proporcional, de forma que 
uma Sprint de três semanas tem três horas de duração de Sprint Planning Meeting. 
O Product Owner precisa garantir que os participantes estejam preparados para discutir os 
itens mais importantes do Product Backlog, que provavelmente farão parte da Sprint que está 
a iniciar. Além disso, os itens do Product Backlog devem estar alinhados a meta do Produto, 
caso contrário, não faz sentido eles entrarem em uma Sprint. 
O Time Scrum é livre para convidar mais pessoas a participarem desta reunião, e auxiliar no 
entendimento de itens mais complexos ou obscuros ao entendimento. 
Obrigatoriamente, o Sprint Planning deve abordar: 
• Porque esta Sprint é valiosa (Meta da Sprint)? 
• O que pode ser feito nesta sprint (itens do backlog do produto selecionados)? 
• Como o trabalho escolhido será realizado (plano de ação para entregar o incremento)? 
Não é indicado no guia do Scrum, mas geralmente esta reunião é dividida em duas etapas, em 
casos de sprints de 4 semanas. E temos: 
Sprint Planning 1 
Basicamente, as perguntas a serem respondidas são: 
“Porque será feito? E o que será feito?” 
E as respostas geram ações, sendo: 
• Definição da meta e escolha dos itens: O Product Owner explica como o produto pode 
aumentar seu valor, e a sua importância na Sprint atual. 
• Sprint Goal, ou Meta da sprint: Eles devem responder a questão porque esta sprint é 
valiosa durante esta etapa. 
• Seleção de itens do Product Backlog: Os desenvolvedores selecionam os itens 
necessários para a Sprint, respondendo a pergunta o que pode ser feito nesta sprint. 
Sprint Planning 2 
Basicamente, existe uma pergunta a ser respondida. Ela é: 
“Como será feito?” 
E essa resposta é dada gerando o seguinte conjunto de ações dos desenvolvedores: 
• Estimativa de trabalho: Os desenvolvedores respondem a pergunta como o trabalho 
escolhido será realizado. Dessa forma, os desenvolvedores planejam o trabalho 
necessário visando a definição de pronto do incremento a ser entregue. Assim, eles 
dividem itens do Product Backlog em trabalhos a serem entregues em prazos curtos, 
como um dia ou menos. O critério para essa divisão é dos desenvolvedores, e eles 
quem sabem como transformar itens do backlog em produtos de valor. Sugestões 
podem ser passadas pelo Product Owner, mas eles, como desenvolvedores, decidem 
como trabalhar. 
Ao final da reunião, teremos a Sprint Backlog, composta por: 
• Meta da Sprint. 
• Conjunto de itens do Product Backlog. 
• Plano de ação para entregar o incremento. 
Não existem regras para documentar a Sprint Backlog. Um quadro no estilo Kanban é o 
mais usual. 
 
Reunião Diária, ou Daily Scrum 
É uma reunião de 15 minutos, feita no início do dia, para que a equipe possa avaliar e 
acompanhar o progresso do trabalho em relação a meta da Sprint corrente, e se necessário 
for, adequar a Sprint Backlog ajustando o próximo trabalho planejado. 
É uma reunião com formato definido pelos desenvolvedores, podendo ser conduzida de 
diferentes formas, desde que focadas na meta e no sucesso da entrega de valor da Sprint. 
Devemos levar em conta as seguintes regras: 
• O TimeBox será SEMPRE de 15 minutos. 
• Deve ser realizada sempre no mesmo horário e local. 
A responsabilidade de respeito do TimeBox é do Scrum master. 
Não existem obrigatoriedades de perguntas a serem feitas, porém existe uma maior 
incidência, pelo tipo de reunião, que elas sejam semelhantes a: 
• O que eu fiz desde a última reunião? 
• O que farei até a próxima reunião? 
• Quais os impedimentos? 
Essas perguntas são geralmente feitas, e até aconselháveis, pois visam buscar o entendimento 
de: 
• Avaliar o progresso atual. 
• Planejar as próximas ações. 
• Mostrar os potenciais riscos. 
É uma reunião exclusiva para os desenvolvedores. Ela pode ser assistida por outras pessoas, se 
assim os desenvolvedores permitirem. Porém, esses convidados não podem opinar ou 
comentar. 
Caso um assunto necessite de debate com mais profundidade, esse debate deve ocorrer após 
a Daily Scrum, em outra reunião exclusiva para isso. E é importante enfatizar que O Scrum não 
proíbe que outras reuniões aconteçam. Ele nos orienta a não desperdiçarmos o tempo do time 
Scrum como um todo. 
 
Revisão da Sprint e Retrospectiva da Sprint 
Revisão da Sprint, ou Sprint Review 
Reunião com tempo de uma hora para cada semana de Sprint. 
Ela tem como propósito inspecionar o resultado da Sprint e determinar as adaptações futuras. 
O Time Scrum apresenta os resultados do seu trabalho para as principais partes interessadas e 
o progresso em direção a meta do produto é discutido. Durante o evento, o time Scrum e as 
partes interessadas revisam o que foi realizado durante este Sprint e o que mudou em relação 
as novas funcionalidades disponibilizadas. De acordo com o Feedback recebido, os 
participantes colaboram sobre decidir sobre o que fazer a seguir, ou seja, o cliente, a partir do 
que viu, pode pedir alterações, inclusões de novas funcionalidades e ainda pedir que itens 
pedidos para as próximas Sprints sejam retirados. Dessa forma, o Product Backlog será 
ajustado para refletir essas solicitações. 
O Time Scrum só deve apresentar itens que estão 100% finalizados, de acordo com a definição 
de pronto. 
Retrospectiva da Sprint, ou Sprint Retrospective 
No Scrum, sempre existem formas de se melhorar, mesmo que a melhoria seja bem pequena. 
Por isso, após a Sprint Retrospective ocorre uma reunião de sprint Retrospective. Essa 
reunião tem uma duração de três horas para uma Sprint de um mês. E essa reunião tem como 
finalidade inspecionar como correu a última Sprint, se tratando de pessoas, das relações entre 
elas, dos processos, das ferramentas e da definição de pronto. É avaliado o que funcionou, 
para que seja usado novamente e o que não funcionou, para não acontecer mais. 
 
Refinamento do Backlog 
É um evento não oficial, ou seja, não está no Guia do Scrum. E basicamente, não é um evento. 
Deve ser feito a todo momento durante o projeto. 
Durante este processo o backlog é constantemente e continuamente revisado e mantido. 
Diferente dos demais eventos Scrum, que são no padrão TimeBox, esse evento não é. Ele é um 
processo contínuo de responsabilidade do Product Owner. Essa atividade envolve: 
• Adicionar detalhes. 
• Novas estimativas. 
• Reordenar. 
• Re-priorizar. 
O Product Owner é o responsável por priorizar itens do backlog e os desenvolvedores estimam 
o tempo. 
 
Scrum de Scrums 
Grandes projetos precisam de diversos times Scrum trabalhando em paralelo. Para que eles 
trabalhem em sintonia, existe o Scrum de Scrums. 
Reuniões são feitas para que os times discutam seus trabalhos, focando em áreas de 
sobreposição e integração. Com vários Times trabalhando em paralelo, existe a necessidade de 
sincronização das informações. 
Como funciona? 
Todos os times são representados nesta reunião, com o objetivo de fornecer atualizações 
sobre o progresso, discutir os desafios enfrentados durante o projeto e coordenar as 
atividades. Além disso, os impedimentos que um time enfrenta pode ser considerado 
impedimento para outros times. 
Não existem regras quanto a frequência das reuniões, tanto que alguns fatores que 
determinam esta frequência podem ser: 
• Quantidade de dependências entre os times 
• Tamanho do projeto 
• Recomendações de processos internos 
• Nível de complexidade do projeto 
 Ela é uma reunião similar a Daily Scrum, com TimeBox de 15 minutos, sendo facilitada pelo 
Scrum Master chefe. E o Scrum Master chefe atende a todos os Times, basicamente. 
As perguntas mais frequentes desta reunião são: 
• No que o seu time tem trabalhado desde a última reunião? 
• O que o seu time irá concluir até a próxima reunião? 
• Quais são os seus impeditivos, e como os outros times podem te ajudar? 
• Quais são as decisões tomadas pelo seu time que podemimpactar outros times? 
O papel de cada um 
Cada time pode escolher o seu representante, que será enviado para esta reunião. Não existe 
obrigatoriedade de serem os Scrum Masters de cada time, embora seja recomendável que eles 
também participem. O Scrum Master Chefe coordena a reunião, que pode ser o Scrum Master 
de um dos times ou um Scrum master dedicado a essa função. 
 
Tópicos avançados – iniciando 
Basicamente, veremos de forma aprofundada o início do Scrum. Veremos como criar a meta 
do produto, como formar um time, o que são épicos e temas, como criar o Backlog do 
Produto, como refiná-lo, quais os itens estarão presentes neste backlog, dentre outras coisas 
mais. 
A partir de agora, o treinamento servirá para quem quer ter o certificado de Scrum Master. 
O projeto exemplo que será apresentado no curso da Udemy é o se uma empresa, chamada 
Sport4u. 
A proposta inicial do aplicativo é: 
Para esportistas amadores que desejam aproveitar melhor suas horas de lazer, o Sport4u é um 
aplicativo móvel de vendas de material esportivo que sugere roupas e equipamentos de acordo 
com seu perfil.