Apostila-scrum-master

Prévia do material em texto

SCRUM
PRINCÍPIOS 
E PRATICAS
Conteúdo
Experiência do Cliente ................................... 3
Metodologia Tradicional de Gestão de Projeto 
5
Processo Empírico .......................................... 9
O que é ser Ágil ............................................... 11
Manifesto Ágil ................................................. 13
Métodos Ágeis................................................. 17
Entrega Iterativa e Incremental ..................... 19
Satisfação do Cliente ...................................... 23
Framework Scrum .......................................... 27
Pilares do Scrum ............................................ 33
Valores do Scrum............................................ 37
Estrutura do Scrum ........................................ 39
Papéis do Scrum ............................................. 43
Time Scrum .................................................... 45
Product Owner ............................................... 49
Scrum Master .................................................. 53
Time de Desenvolvimento ............................. 57
Tamanho do Time Scrum ............................... 60
Papéis e Responsabilidades ........................... 63
Artefatos do Scrum ........................................ 67
Product Backlog ............................................. 69
Sprint Backlog ................................................ 77
Incremento ..................................................... 81
Product Backlog DEEP ................................... 87
Refinamento dos itens do Product Backlog 
(Grooming) ...................................................... 89
Planning Poker ............................................... 93
Velocidade do time scrum.............................. 97
A Sprint ........................................................... 105
Planejamento da Sprint ................................. 109
Cancelamento da Sprint ................................ 115
 Reunião diária ................................................ 117
Revisão da Sprint ............................................ 123
Retrospectiva da Sprint ................................. 125
Burndown ....................................................... 133
Kanban ............................................................ 135
Cultura ágil..................................................... 143
Mindset agil..................................................... 144
2
EXPERIÊNCIA 
DO CLIENTE
4
Experiência do 
Cliente
Quando se trata do feedback do produto, o cliente tem sempre a razão. Isto é uma lei universal.
Hoje, as empresas têm buscado maneiras de receber este feedback de forma positiva, ou seja, 
criando uma experiência única para o cliente. Única aqui no sentido de ser especial: uma jornada 
que, desde o primeiro contato do cliente com a empresa até a finalização do serviço, tenha sido 
executada de maneira exímia.
Para que isso aconteça, é necessário estar atento a uma pergunta básica: O que o cliente busca?
Tomando como base grandes players da tecnologia do mercado, a experiência positiva do cliente 
está ligada a um produto de qualidade, funcional e incremental, ou seja, que evolua com o tempo, 
que supra suas necessidades e que, para adquiri-lo, tenha tido um relacionamento fantástico com a 
empresa – rápido, seguro, intuitivo, fácil e descomplicado.
A Amazon, por exemplo, está lentamente se tornando a líder mundial em cumprir sua promessa de 
marca: “Ser a empresa mais focada em seus clientes do mundo”.
O que a Amazon tem que outras empresas não possuem é a obsessão pelo cliente, é dar o que ele 
busca, com o intuito de deixá-lo feliz e, assim, proporcionar a melhor experiência que poderia ter 
adquirindo seu produto.
Diferentemente da Google, a questão é: por que as empresas não conseguem suprir a necessidade 
do cliente com a forma como trabalham? É o que será explicado adiante.
Como o cliente 
explicou
Como o analista de 
negócios entendeu
Como o programador 
desenvolveu
Com o projeto foi 
documentado
Como o cliente foi cobrado Como o produto foi 
mantido
O que o cliente 
realmente queria
METODOLOGIA 
TRADICIONAL 
DE GESTÃO DE 
PROJETO
6
Metodologia Tradicional 
de Gestão de Projeto
A metodologia tradicional tem etapas bem definidas, estáticas e nada abertas a mudanças de 
escopo. Na metodologia tradicional, segue-se um modelo sequencial, ou seja, uma etapa deve ser 
executada após a outra, sendo assim, uma tarefa não pode ser iniciada enquanto a anterior não for 
concluída.
Na metodologia tradicional de gestão de projetos, pode-se dizer que:
» Requisitos levantados no início
» Planejamento detalhado
» Documentação abundante
» Orientado ao plano de projeto
» Forte resistência a mudanças
» Preditivo - Cada etapa de desenvolvimento é baseada na etapa anterior, requisitos são
estáveis.
Para ser um sucesso, é necessário entregar no prazo, dentro do orçamento e da qualidade 
esperada. Na metodologia tradicional, o produto é entregue e disponibilizado ao cliente quando ele 
estiver 100% concluído.
No gerenciamento tradicional, a entrega é feita no final e a prioridade é seguir o plano, guiado pelas 
restrições. Já no ágil, a prioridade é invertida: o objetivo é gerar valor e entregar produtos com 
qualidade, ao final de ciclos curtos, para que o cliente possa participar da construção do produto e 
oferecer feedback frequente.
Levantamento 
de Requisitos
Planejamento
Desenvolvimento
Testes
Homologação
Entrega
1º mês 2º mês 3º mês 4º mês 5º mês 6º mês
Tempo do Projeto
7
Introdução à Metodologia Ágil
Metodologia Tradicional 
de Gestão de Projetos
Responder a mudanças é mais que seguir um plano.
Isso não significa que, no desenvolvimento de software, não haja um plano, ou ainda, que não se 
deva segui-lo. A questão-chave é: se houver a possibilidade de escolher entre aplicar uma mudança 
para gerar valor para o cliente ou seguir cegamente um plano, certamente a escolha será a primeira 
opção.
As mudanças são inevitáveis dentro de um projeto. O modelo cascata foca no acompanhamento 
do plano e, principalmente, nas restrições de escopo, tempo e custos. O sucesso é medido pela 
adequação a estas variáveis, deixando para segundo plano a satisfação e o valor para o cliente.
Na gestão ágil, o foco é receber, compreender e se adaptar às mudanças da melhor forma, certo de 
que elas irão acontecer.
Planejamento x Realidade
Ajustes nos planos são inevitáveis
O Planejado
A Realidade
8
Introdução à Metodologia Ágil
PROCESSO 
EMPÍRICO
10
Introdução à Metodologia Ágil
Processo 
Empírico
O empirismo afirma que o conhecimento vem da experiência e da tomada de decisões baseadas no 
que é conhecido. Ele se apoia em experiências vividas, na observação de coisas e não em teorias e 
métodos científicos.
Para problemas considerados complexos, o uso do empirismo é recomendado, visto que:
» Não é preditivo: não se conhecem todas as variáveis e haverá mudanças que não são
previsíveis.
» As tomadas de decisão: são baseados na experiência e conhecimento de quem executa.
O Scrum emprega uma abordagem iterativa e incremental para aperfeiçoar a previsibilidade e o 
controle de riscos.
Re
qu
is
ito
s
Longe de
acordo
Perto de
acordo
Perto de certeza Tecnologia Longe de certeza
Processos 
emp ricos
Scrum emprega uma abordagem iterativa e incremental para aperfeiçoar a previsibilidade e o controle de riscos
O QUE É 
SER ÁGIL
12
O que é ser Ágil
Foguete e helicóptero: qual será o mais ágil?
O foguete, veloz e robusto, porém falta-lhe um ingrediente: a capacidade de mudar de direção, 
adaptar o caminho a ser percorrido.
O helicóptero, além de ser rápido, responde às mudanças de forma precisa e se adapta à situação.
Ágil não tem a ver com rapidez ou velocidade!
A diferença fundamental entre os dois está na previsibilidade do “destino final”. No caso do 
helicóptero, seu objetivo muda de direção o tempo todo enquanto que, para o foguete, o destinoé 
fixo.
O “caminho” para a “entrega de valor” é previsível para um e caótico para o outro. Mas isso não 
significa que um é melhor do que o outro.
Em um ambiente em que se deseja utilizar um método ágil, os problemas, provavelmente, são 
complexos e imprevisíveis. Logo, ser adaptativo e saber pivotar sua solução é essencial.
O contexto em que se encontra o foguete não exige agilidade, basta velocidade e, então, constrói-se 
uma estrutura altamente robusta e rígida para chegar o mais rápido possível ao destino, afinal, ele é 
previsível, preditivo e imutável.
Então, não basta ser veloz. São necessárias as habilidades do helicóptero para reagir de modo 
flexível e veloz.
Em resumo, ser ágil é responder, com rapidez, às mudanças e responder à mudança mais que seguir 
um plano.
AGILIDADE
Vamos pensar...
VELOCIDADE Ser ágil é responder... 
...com rapidez as mudanças
...a mudança mais que seguir um plano
MANIFESTO 
ÁGIL
14
Valores do 
Manifesto Ágil
O Manifesto Ágil é uma declaração de valores e princípios essenciais para o desenvolvimento 
de software. Foi criado em fevereiro de 2001, quando 17 profissionais, que já trabalhavam com 
métodos ágeis (XP, DSDM, Scrum etc.), decidiram que havia chegado a hora de mudar o cenário 
atual de desenvolvimento de software e de propor algo novo, alinhado às necessidades das 
organizações.
Após incessantes conversas, os desenvolvedores acharam importante documentar a reunião. Foi 
por este motivo que eles resolveram elaborar o documento que se transformou em algo muito 
maior do que eles poderiam imaginar: o Manifesto Ágil (Agile Manifesto).
O Manifesto Ágil acredita que:
 » Indivíduos e interações entre eles são mais do que processos e ferramentas: desenvolver 
software é uma atividade humana, e a comunicação colabora positivamente durante todo 
o processo de desenvolvimento, diminuindo ruídos e aproximando pessoas. Processos e 
ferramentas são importantes, mas devem ser usados de forma pragmática.
 » Software funcionando mais do que documentação abrangente: Software em pleno 
funcionamento é o melhor indicador de trabalho bem executado.
 » Clientes não pagam por um plano bem elaborado que nunca vai sair do papel, eles querem 
resultados.
 » Colaboração com o cliente mais do que negociação de contratos: nunca ir contra o cliente 
ou colocá-lo contra o time de desenvolvimento. A tomada de decisões deve sempre estar de 
acordo com os objetivos do cliente.
 » Adaptação a mudanças mais do que seguir um plano: utilizar feedbacks obtidos durante o 
processo são fatores fundamentais para respostas rápidas.
Indivíduos e interações mais que que processos e ferramentas
Software funcionando mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Adaptação a mudanças mais que seguir um plano
15
Introdução à Metodologia Ágil
Valores do 
Manifesto Ágil
O Manifesto Ágil não extingue os valores que estão à direita, ele somente vê mais valor àqueles à 
esquerda.
Para completar valores ágeis, criaram-se os doze princípios. São eles:
1. Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de 
software com valor agregado.
2. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento.
3. Processos ágeis tiram vantagem das mudanças visando à vantagem competitiva para o 
cliente.
4. Entregar, frequentemente, software funcionando, de poucas semanas a poucos meses, 
com preferência à menor escala de tempo.
5. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo 
o projeto.
6. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte 
necessários e confie neles para fazer o trabalho.
7. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de 
desenvolvimento é concretizado através de conversa frente a frente.
8. Software funcionando é a medida primária de progresso. Os processos ágeis promovem 
desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser 
capazes de manter um ritmo constante indefinidamente.
9. Contínua atenção à excelência técnica e ao bom design aumenta a agilidade.
10. Simplicidade, a arte de maximizar a quantidade de trabalho não realizado é essencial.
11. As melhores arquiteturas, requisitos e designs emergem de equipes auto- organizáveis.
12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e, então, refina e 
ajusta seu comportamento de acordo.
16
Introdução à Metodologia Ágil
MÉTODOS 
ÁGEIS
18
Métodos Ágeis
A gestão ágil de projetos de software está definida na literatura como uma família de métodos sob 
um “guarda-chuva”, os principais incluem: Scrum, Crystal Methods, Dynamic Systems Development 
Method - DSDM, Feature-Driven Development - FDD, Lean, Extreme Programming – XP e Adaptive 
Software Development – ASD.
Alguns métodos são mais voltados para o gerenciamento de projetos e processos, tais como: 
Scrum, Crystal, Lean e Kanban. E outros para engenharia de software, como: Dynamic Systems 
Development Method, Extreme Programming e Extreme Programming.
Scrum
Lean
Crystal
Kaban
Dynamic Systems Development 
Method (DSDM)
Extreme Programming (XP)
Extreme Programming(TDD)
Gerenciamento Engenharia
ENTREGA 
ITERATIVA E 
INCREMENTAL
20
Entrega Iterativa e 
Incremental
Em entregas iterativas e incrementais, o produto pronto chamado de incremento, é entregue após 
um ciclo de atividade em um período curto de tempo. Neste ciclo de atividades, que tem duração 
de, no máximo, um mês, todas as etapas do projeto são executadas: levantamento dos requisitos, 
planejamento, desenvolvimento, testes e entrega.
A adoção desta forma de trabalho é importante quando se executam projetos empíricos, nos quais 
a solução é adaptativa e complexa.
 » Iterativo significa: repetido, reiterado, feito mais de uma vez.
Neste caso, ele informa que cada ciclo irá se repetir até atingir o objetivo e encerrar o projeto.
Esta repetição sempre gerará um refinamento, que é crucial para a saúde e a evolução do produto.
 » Incremental significa: aprimorar gradualmente, em etapas.
Neste caso, ele informa que o produto pronto ao final de cada ciclo iterativo será um incremento ao 
anterior, ou seja, o produto entregue é a soma de seus anteriores além dele mesmo.
Um dos pontos importantes deste método de trabalho é que se planeja somente o necessário, para 
poucas semanas, desenvolve-se o que é solicitado, recebe-se o feedback e,
Então, reinicia-se o ciclo, ocasionando a diminuição de desperdício (tempo, recurso e produto 
obsoleto), reduzindo os riscos (porque são antecipados) e aumentando o valor agregado (o cliente 
recebe o produto muito mais rápido e com qualidade).
Ciclos Iterativos e incrementais dão margem para mudanças e trabalham com feedback constante, 
o que possibilita a entrega de forma mais rápida e com maior valor agregado.
Levantamento de 
Requisitos
Planejamento
Desenvolvimento
Testes
Entrega
Levantamento de 
Requisitos
Planejamento
Desenvolvimento
Testes
Entrega
Levantamento de 
Requisitos
Planejamento
Desenvolvimento
Testes
Entrega
Fu
nc
io
na
lid
ad
es
 d
o 
Pr
od
ut
o
Tempo do Projeto
Iteração 1
Iteração 2
Iteração n
Incremento 1
Incremento 2
Incremento n
FEEDBACK
FEEDBACK
21
Introdução à Metodologia Ágil
Entrega Iterativa 
e Incremental
Testes
Levantamento de 
Requisitos
Planejamento
Desenvolvimento
Entrega
Iteração n
Incremento n
Desenvolva 
o solicitado
Planeje o necessário 
para poucas semanas
Entrega e 
feedback
Entregas 
pequenas
Reduzir os riscos
Requisitos do 
produto Início 
Iteração 1
Aumentar o valor 
agregado
 » Tenha um plano de projeto de alto nível
 » Crie planos de iteração detalhados com base no JIT (Just In Time)
 » Envolva todos da equipe no planejamento
 » Foque nas pessoas
22
Levantamento
de Requisitos Planejamento Desenvolvimento Testes Entrega
Entrega Iterativa e 
Incremental
Levantamento
de RequisitosPlanejamento Desenvolvimento Testes Entrega
O Scrum emprega uma abordagem iterativa e incremental para aperfeiçoar a 
previsibilidade e o controle de riscos.
Tempo do Projeto
1º mês 2º mês 3º mês 4º mês 5º mês
1º mês 2º mês 3º mês 4º mês 5º mês
Tempo do Projeto
ADAPTATIVO
PREDITIVO
Requisitos
Requisitos
SATISFAÇÃO 
DO CLIENTE
24
Entregas ágeis
Entregas ágeis possibilitam:
 » Aumento do valor agregado no produto: entrega de valor ao cliente, continuamente, 
incrementalmente e com qualidade.
 » Diminuição do leadtime: tempos de entrega reduzidos e melhoria no time to market.
 » Cliente feliz: Agilidade na entrega, feedback constante e qualidade na entrega.
VALOR TEMPO CLIENTE FELIZ
25
Framework Scrum
 FRAMEWORK
SCRUM
26
Framework Scrum
Framework Scrum
Conteúdo
» Framework Scrum
» Pilares do Scrum
» Valores do Scrum
» Estrutura do Scrum
FRAMEWORK 
SCRUM
28
Framework Scrum
Framework Scrum
Foi criado por Ken Schwaber e Jeff Sutherland, no início da década de 90, em uma tentativa de 
criar software de forma rápida, confiável e eficiente. Até o momento de sua criação, os projetos de 
software eram desenvolvidos com base no método cascata.
Ao contrário do modelo tradicional, o Scrum muda radicalmente a ideia de metodologias 
prescritivas e hierarquizadas. Ele se assemelha a sistemas adaptativos, autocorretivos e 
revolucionários.
A essência do Scrum é um pequeno time de pessoas. O time individual é altamente flexível 
e adaptativo, nele as equipes trabalham como uma unidade extremamente integrada, com 
cada membro desempenhando um papel bem definido, eliminando controles desnecessários, 
inadequados ou burocráticos. A concentração do trabalho está na essência de realizar entregas em 
períodos curtos, de forma contínua e com qualidade.
O Scrum é:
» Leve
» Simples de entender
» Difícil de dominar
O Scrum é um framework, não é uma metodologia. Ele reúne as melhores práticas sobre o tema e 
orienta sua utilização. Ele explica o que precisa ser feito, porém não entra no detalhe sobre como 
fazer, é voltado para pessoas e processos e, como todo método ágil, trabalha com empirismo.
O Scrum é um framework dentro do qual pessoas podem tratar e resolver 
problemas complexos e adaptativos, onde os requisitos não são claros ou 
mudam com muita frequência, enquanto produtiva e criativamente entregam 
produtos com o mais alto valor possível.
O Scrum é:
» Leve
» Simples de entender
» Difícil de dominar
Criadores do Scrum: 
Ken Schwaber e Jeff Sutherland 
29
Framework Scrum
Framework Scrum
ele é ele não é
ele faz ele não faz
Um processo 
empírico
Um Framework
Guia de práticas, artefatos e 
papéis para desenvolvimento 
de produto 
Entrega Iterativas e 
Incrementais
Promove a Melhoria 
Contínua
Diminui o tempo de 
entrega
Reduz 
incertezas
Maximiza o valor 
entregue ao cliente
Incentiva o 
engajamento 
Estimula a 
comunicação
Antecipa os riscos
Uma Metodologia
Um processo preditivo 
e detalhado
Mutável
Gestão de pessoas
Explicação do “como” 
deve ser feito
30
Framework Scrum
Framework Scrum
A origem do nome vem de uma posição do jogo de rugby chamada Scrum.
O Scrum é um método de reinício de jogada, no qual os jogadores dos dois times se juntam com a 
cabeça abaixada e se empurram com o objetivo de ganhar a posse de bola.
Esta palavra é utilizada porque a jogada em si reflete um trabalho em equipe fenomenal: união do 
time, ritmo igual, comunicação transparente e confiança uns nos outros
Origem do nome Scrum
31
Framework Scrum
Framework Scrum
O Scrum é baseado em processos empíricos e nasceu para resolver problemas complexos e 
adaptativos, sendo assim, não é necessário que o projeto no qual se trabalha seja de tecnologia, 
basta estar aderente a esses dois pontos.
Muitas empresas hoje utilizam o Scrum como forma de trabalho e, muitas delas são de setores 
distintos.
Quem usa o Scrum
32
Framework Scrum
PILARES DO 
SCRUM
34
Framework Scrum
Pilares do Scrum
Os pilares são os princípios fundamentais sobre os quais o Scrum foi construído, são eles que fazem 
a diferença na implementação e na manutenção do framework e criam o ambiente propício para 
projetos realmente ágeis.
Sabe-se que o Scrum trabalha com fatos, com base na experiência e nas evidências (empirismo), 
para isso três pilares apoiam a implementação de controle de processo: transparência, inspeção e 
adaptação.
Três pilares apoiam a implementação de 
controle de processo empírico: transparência, 
inspeção e adaptação.
Aspectos significativos 
do processo devem 
estar visíveis 
aos responsáveis 
pelos resultados
Os artefatos Scrum e o 
progresso em direção ao 
objetivo da Sprint devem ser 
inspecionados para detectar 
variações indesejadas
Sempre que um evento 
não desejado ocorra, 
deve-se adaptar o que 
seja necessário para 
que não volte a ocorrer
SCRUM
TRANSPARÊNCIA INSPEÇÃO ADAPTAÇÃO
35
Framework Scrum
Pilares do Scrum
Transparência
Apresentar os fatos como estão - Todos confiam uns nos outros e têm coragem de assumir todas as 
responsabilidades, seja com resultados bons, seja com resultados negativos. Não há agenda oculta, 
todos se esforçam e colaboram coletivamente para atingir o objetivo em comum.
Aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados.
Todo trabalho deve estar claramente definido e conhecido por todos os envolvidos no projeto.
A transparência se dá através da comunicação (verbal ou escrita) e deve ocorrer ao longo de todo o 
projeto.
Inspeção
Não é uma inspeção realizada por um inspetor ou por um auditor, mas sim uma inspeção feita por 
todos do Time Scrum.
A inspeção pode ser feita para o produto, os processos, os aspectos de pessoas, as práticas e as 
melhorias contínuas.
Todo trabalho deve ser inspecionado com a frequência necessária para garantir a qualidade na 
primeira tentativa.
Os artefatos Scrum e o progresso em direção ao objetivo da Sprint devem ser inspecionados para 
detectar variações indesejadas.
Adaptação
Melhoria contínua, a capacidade de adaptação com base nos resultados da inspeção.
Capacidade de adaptar o projeto à necessidade do negócio.
Sempre que um evento não desejado ocorrer, deve-se adaptar o que for necessário para que não 
volte a ocorrer.
36
Framework Scrum
VALORES 
DO SCRUM
38
Framework Scrum
Valores do Scrum
Segundo Ken Schwaber e Jeff Sutherland, criadores do Scrum, são esses cinco valores que darão 
vida aos pilares do Scrum: Transparência, Inspeção e Adaptação.
Para o sucesso do Scrum, os membros do Time Scrum precisam estar familiarizados com esses 
itens e utilizá-los em seu dia a dia para realizar entregas com qualidade surpreendente para seus 
clientes e ainda garantir um ambiente espetacular para trabalhar.
» Comprometimento: comprometer-se com o time, com a meta da Sprint e com os resultados.
» Coragem: ser transparente. Aceitar que é preciso mudar e que sua opinião nem sempre será a
melhor ou a escolhida pelo grupo.
» Foco: ter foco no trabalho que está sendo executado a fim de atingir a meta da Sprint.
» Abertura: poder propor melhorias, não ter medo de errar, assumir as falhas e pedir ajuda
quando necessário.
» Respeito: trazer unidade ao time, ajudar as pessoas a aprender, não julgar aqueles que sabem
menos, garantir a boa convivência e respeitar as dificuldades de cada um.
Os valores do Scrum são amplos que excedem a “barreira” da execução das tarefas do time. Porém, 
são valores que darão vida ao trabalho em equipe e, como já comentado, ao Scrum.
Comprometimento
Coragem
Foco
Abertura
Respeito
ESTRUTURA 
DO SCRUM
40
Framework Scrum
Estrutura do Scrum
Pode-se dividir o Framework Scrum em três partes: papéis do Time Scrum, cerimônias e artefatos.
» Papéis do Time Scrum:
• Product Owner Scrum Master
• Time de Desenvolvimento
» Cerimônias (Reuniões): Sprint
• Planejamento da Sprint Reunião diária
• Revisão da Sprint Retrospectiva da Sprint
» Artefatos
» Backlog doProduto
» Backlog daSprint Incremento
Cada parte conta com Scrum arcabouço de valores, práticas e princípios que serão detalhados 
adiante.
SCRUM
3 PAPÉIS 5 CERIMÔNIAS 3 ARTEFATOS
Sprint 
1 - 4 semanas
Product 
Owner
Scrum 
Master
Time de 
Desenvolvimento
Planejamento 
da Sprint
Reunião 
Diária
Revisão 
da Sprint
Retrospectiva 
da Sprint
Product 
Backlog
Backlog da 
Sprint
Incremento
41
Papéis do Scrum
PAPÉIS DO SCRUM
42
Papéis do Scrum
Papéis do Scrum
Conteúdo
» Time Scrum
» Product Owner
» Scrum Master
» Time de Desenvolvimento
» Tamanho do Time Scrum
» Papéis e Responsabilidade
PAPÉIS DO 
SCRUM
44
Papéis do Scrum
Papéis no Scrum
Nesta seção, dentro do Framework Scrum, o foco do aprendizado será direcionado para os “Papéis” 
do Scrum: Product Owner, Scrum Master e Time de Desenvolvimento.
SCRUM
3 PAPÉIS 5 CERIMÔNIAS5 CERIMÔNIAS 3 ARTEFATOS
Sprint 
1 - 4 semanas
Product 
Owner
Scrum 
Master
Time de 
Desenvolvimento
Planejamento 
da Sprint
Reunião 
Diária
Revisão 
da Sprint
Retrospectiva 
da Sprint
Product 
Backlog
Backlog da 
Sprint
Incremento
TIME SCRUM
46
Papéis do Scrum
Time Scrum
O Time Scrum é composto pelo Product Owner, pelo Time de Desenvolvimento e pelo Scrum 
Master.
Cada papel tem uma importância fundamental no Framework Scrum, garantindo a flexibilidade, a 
criatividade e a produtividade.
O Time Scrum é composto por indivíduos que estão comprometidos em realizar o trabalho 
proposto.
De forma não exaustiva, pode-se dizer que:
» O Product Owner é responsável por gerenciar o Product Backlog (lista ordenada de todos os
itens necessários para a entrega do projeto) e maximizar o valor do produto, resultado do
trabalho do Time de Desenvolvimento.
» O Scrum Master atua como um técnico, garantindo o uso correto do Scrum: a teoria, as
práticas, as regras e os valores, além de remover impedimentos que estejam atrapalhando a
produtividade do Time Scrum.
» O Time de Desenvolvimento tem como principal objetivo realizar o trabalho de entregar um
incremento potencialmente liberável do produto “pronto” ao final de cada Sprint.
O objetivo do Time Scrum é entregar produtos de forma iterativa e incremental, maximizando as 
oportunidades para feedback.
É importante destacar que no Framework Scrum, stakeholders, clientes, gerentes e diretoria não 
fazem parte do Time Scrum, portanto, não existem outros papéis além destes citados.
Product Owner Scrum Master Time de 
Desenvolvimento
47
Papéis do Scrum
Time Scrum
O Time Scrum possui duas características muito importantes que garantem o pleno funcionamento 
do Framework: ser auto-organizado e multifuncional.
• Planejam, executam e controlam
seu próprio trabalho
• São pró ativos
• Realizam decisões em conjunto
• Entemdem que a
responsabilidade é de todos
• Não julgam falhas, acham
soluções
Auto-organizado
• Possuem as habilidades
necessárias para executar o fluxo
de trabalho de ponta a ponta
• Assumem plenamente a
propriedade do produto
• São organizados em equipes
multidisciplinares e não
especialistas
Multifuncional
Pode-se dizer que são:
» Auto-organizados:
• Planejam, executam e controlam seu próprio trabalho: possuem completa autonomia e
poder de decisão em relação ao que precisa ser feito para atingir o objetivo da Sprint e
entregar um incremento pronto e potencialmente liberável. Escolhem qual a melhor forma
para completar seu trabalho, em vez de serem dirigidos por outros de fora do time. São
disciplinados e organizados, não necessitam que alguém gerencie a execução de suas
atividades, fazem isso de forma ordenada, compassada, transparente e organizada.
• São pró-ativos: Antecipam-se e se responsabilizam pelas próprias escolhas e ações frente às
situações impostas pelo meio.
• Realizam decisões em conjunto: trabalham como um time único para alcançar um objetivo
único. Todas as decisões devem ser tomadas em conjunto, de forma transparente.
• Entendem que a responsabilidade é de todos: a responsabilidade pelo sucesso ou pelo
fracasso de qualquer ação, atividade ou entrega é do time. Nunca se responsabilizam
individualmente, tampouco um único indivíduo é agraciado pelo sucesso.
48
Papéis do Scrum
Time Scrum
» Multifuncional:
• Possuem as habilidades necessárias para executar o fluxo de trabalho de ponta a ponta: o time
possui todas as habilidades necessárias para executar suas atividades sem depender de outros que
não fazem parte da equipe.
• Não dependem de recursos externos: são autossuficientes e não dependem de pessoas de fora do
time para finalizar os itens do Product Backlog.
• São organizados em equipes multidisciplinares e não especialistas: não existem silos no
Framework Scrum, ou seja, as equipes não estão estruturadas em especialidades. Um
Time Scrum é composto por pessoas com diversas habilidades, que juntas, são capazes de
realizar a entrega do incremento pronto e potencialmente liberável.
PRODUCT 
OWNER
50
Papéis do Scrum
Product Owner
O Product Owner é um membro do Time Scrum e sua principal reponsabilidade é maximizar o valor 
do produto, resultado do trabalho do Time de Desenvolvimento.
» • Gerenciar e priorizar o Backlog do produto: ele é a única pessoa responsável por gerenciar o
Product Backlog. Por este motivo, deve garantir que todos os integrantes do Time de Scrum
tenham conhecimento dos requisitos e das prioridades do produto.
» • Definir e comunicar a visão do produto: por ser a única pessoa responsável por gerenciar
o Product Backlog, deve garantir que todos os integrantes do Time de Scrum tenham
conhecimento dos requisitos e prioridades do produto.
» • Decidir sobre o escopo do trabalho e o que será feito pelo Time de Desenvolvimento: como
tem a visão do produto e das necessidades do cliente e é responsável por definir o Product
Backlog, deve ter autoridade para isso, sendo sua decisão considerada como final. Ninguém
pode dizer ao Time de Desenvolvimento que faça outra coisa que não seja o que foi definido
pelo Product Owner.
» • Garantir clareza e transparência do Backlog do Produto a todos os envolvidos no projeto:
comunicação é a base do relacionamento e do trabalho do Product Onwer. Ele deve trabalhar
com o pilar de Transparência diariamente, tanto com o Time Scrum, como com os envolvidos
no projeto e os clientes.
» • Alinhar com stakeholders, clientes, e as partes interessadas sobre as necessidades do
produto: o Product Owner é a interface entre o Time de Scrum e os stakeholders, clientes e
partes interessadas. Para que o Time Scrum trabalhe de forma produtiva, ele deve alinhar
constantemente o propósito e a direção do produto com a área de negócios. Só assim, poderá
confeccionar um Product Backlog aderente com as necessidades da organização.
» • Estar disponível para tirar dúvidas do Time de Desenvolvimento sobre o produto: o
Product Owner precisa estar disponível para o Time Scrum sanar dúvidas e realizar
perguntas pertinentes durante toda a Sprint e, consecutivamente, o projeto. Comunicação e
transparência fazem parte do papel do Product Owner.
» • Realizar a macrogerência do projeto de desenvolvimento: o gerenciamento do escopo,
tempo, custo, risco e qualidade são responsabilidades do Product Owner. É ele quem deve
reportar o andamento do projeto e as entregas aos stakeholders.
» • Planejar e realizar liberações do incremento do produto – é ele quem tem autoridade para
tal: o Time de Desenvolvimento tem a responsabilidade de entregar um incremento pronto
e potencialmente liberável ao final de cada Sprint, porém, é o PO que tem a autoridade de
liberá-lo ou não para a produção.
51
Papéis do Scrum
Product Owner
 » • Fornecer constantes feedbacks ao Time de Desenvolvimento sobre o produto: Feedback 
constante faz parte do Framework Scrum. Durante a reunião de revisão ou quando julgar 
necessário, o PO deve dar uma devolutiva do trabalho do Time Scrum em busca de melhoria 
contínua.
 » O Product Owner deve possuir um bom conhecimento do framework Scrum, além de 
habilidades de comunicação e poder de decisão.» Em um Time de Scrum, há apenas um Product Owner, que toma as decisões referentes 
ao produto. Isso acontece para que não haja divergência na definição do produto, o que 
prejudicaria o bom andamento do projeto.
 » O Product Owner pode fazer o descrito ou delegar para o Time de Desenvolvimento fazê-lo. No 
entanto, continua sendo o responsável pelos trabalhos.
 » Ele é uma pessoa e não um comitê, podendo 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çá-la ao Product Owner.
 » Um Product Owner pode ser alguém do Time de Desenvolvimento, embora isto não seja 
recomendado. Ele também pode trabalhar para mais de um Time Scrum, não existe uma regra 
em relação a isso.
Product Owner
Definir e comunicar a 
visão do produto
Decidir sobre o escopo 
do trabalho e ‘o que’ 
será feito pelo Time de 
Desenvolvimento
Gerenciar e priorizar o 
Product Backlog
Garantir clareza e 
transparência do Product 
Backlog a todos os 
envolvidos no projeto
Alinhar com stakeholders, 
clientes, e as partes 
interessadas sobre as 
necessidades do produto
Maximizar o valor do produto 
resultado do trabalho do Time 
de Desenvolvimento
Fornecer constantes feedbacks 
ao Time de Desenvolvimento 
sobre produto
Planejar e realizar liberações do 
incremento do produto – É ele 
quem tem autoridade para tal
Realizar a macro gerência do 
projeto de desenvolvimento
Estar disponível para retirar 
dúvidas do Time de 
Desenvolvimento 
sobre o produto
52
Papéis do Scrum
SCRUM 
MASTER
54
Papéis do Scrum
Scrum Master
O Scrum Master é um membro do Time Scrum, e sua principal responsabilidade é promover e 
suportar o Scrum, ajudando todos a entenderem a teoria, as práticas, as regras e os valores do 
Scrum.
» • Ser servo-líder, dispondo-se a ajudar as equipes, prestando atenção às suas necessidades
e problemas. Ele ajuda aqueles que estão fora do Time Scrum a entender quais 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. Ele lidera a equipe, não atua de
forma alguma como chefe, ele está lá para auxiliar, guiar, orientar e contribuir com todos para
alcançarem o objetivo da Sprint.
» • Garantir que objetivos, escopo e domínio do produto sejam entendidos o melhor possível
por todos do Time Scrum: ele preza a transparência entre todos do time, eliminando qualquer
ruído na comunicação,faz o meio de campo entre PO e Time de Desenvolvimento, auxiliando
o PO a entender os termos e os aspectos técnicos do produto e o Time de Desenvolvimento a
entender os termos e os aspectos de negócio do produto.
» • Remover impedimentos, permitindo que o Time Scrum trabalhe de forma mais produtiva: ele
remove todos os impedimentos que estejam atrapalhando o Time Scrum de alcançar a meta
da Sprint.
» • Evitar interferências externas ao Time Scrum: o Scrum Master atua como uma barreira ao
Time Scrum, que deve ser blindado de qualquer interferência externa, para que não atrapalhe
a execução de suas atividades.
» • Agir como um mentor para o Product Owner, ensinando-o a criar, a manter e a priorizar
o Product Backlog. Ele ensina e auxilia o PO a organizar o Product Backlog de acordo com
as melhores práticas, metodologias e regras. Importante destacar que ele não executa a
atividade de criar, manter e priorizar o Product Backlog, ele ensina. Ele não pesca o peixe, ele
dá a vara, a isca e ensina o método da pescaria.
» • Servir como mediador na comunicação entre as diferentes partes: o Scrum Master gerencia
conflitos.
» • Celebrar o sucesso do time: ele deve incentivar o Time Scrum a celebrar todas as pequenas e
as grandes conquistas. A felicidade do Time Scrum é fundamental para a execução do projeto
e para a melhoria contínua dos processos.
55
Papéis do Scrum
Scrum Master
 » • Gerir processos e não pessoas: o Scrum Master não é chefe de ninguém do Time Scrum, 
tampouco atua como tal. Ele realiza o gerenciamento dos processos para garantir que o 
Framework Scrum seja implementado e sustentado em sua totalidade.
 » • Trabalhar para a Organização: treina e implementa o Scrum na organização. Ajuda os 
funcionários e as partes interessadas a compreender e a tornar aplicável o Scrum e o 
desenvolvimento de produtos empíricos e causa mudanças que aumentam a produtividade do 
Time Scrum.
 » Um Scrum Master pode ser alguém do Time de Desenvolvimento, embora isso não seja 
recomendado. Ele também pode trabalhar para mais de um Time Scrum, não existe uma regra 
em relação a isso.
Ser servo líder, se dispondo a 
ajudar as equipes, prestando 
atenção às suas necessidades e 
problemas
Garantir que objetivos, escopo 
e domínio do produto sejam 
entendidos o melhor possível 
por todos do Time Scrum 
Remover impedimentos, 
permitindo que o Time Scrum 
trabalhe de forma mais 
produtiva
Evitar interferências externas 
ao Time Scrum
Agir como um mentor para o 
Product Owner, ensinando-o 
a criar, manter e priorizar o 
Product Backlog
Trabalhar para a Organização
Gerir processos e não pessoas
Celebrar o sucesso do time
Mediar conflitos
Servir como mediador 
na comunicação entre as 
diferentes partes
Scrum Master
Garantir o uso correto do 
Scrum: teoria, as práticas, as 
regras e os valores
56
Papéis do Scrum
TIME DE 
DESENVOLVIMENTO
58
Papéis do Scrum
Time de 
Desenvolvimento
O Time de Desenvolvimento consiste em profissionais que são membros do Time Scrum e sua 
principal responsabilidade é realizar o trabalho de entregar um incremento potencialmente 
liberável do produto “pronto” ao final de cada Sprint.
» • Realizar o trabalho de entregar um incremento potencialmente liberável do produto “Pronto”
ao final de cada Sprint: É de responsabilidade do Time Scrum executar suas tarefas ao longo
do Sprint para entregar um incremento pronto, potencialmente liberável e com qualidade ao
final de cada Sprint.
» • Organizar e gerenciar seu próprio trabalho: o Time de Desenvolvimento é auto-organizado.
Possui completa autonomia e poder de decisão em relação ao que precisa ser feito para atingir
o objetivo do Sprint e entregar um incremento pronto e potencialmente liberável. Escolhe
qual a melhor forma para completar seu trabalho, em vez de ser dirigido por outros de fora
do time. Não necessita que alguém gerencie a execução de suas atividades, faze isso de forma
ordenada, compassada, transparente e organizada.
» • Ser multidisciplinar: os membros do Time são organizados em equipes multidisciplinares e
não especialistas. Possuem todas as habilidades para realizar suas atividades para atingir a
meta da Sprint e entregar um incremento pronto e potencialmente liberável.
» • Definir aquilo que é necessário ser feito e como, para atingir a meta da Sprint. Trabalhar para
transformar os requisitos em um incremento: junto ao PO, puxam os itens do Product Backlog
para o Sprint Backlog, de acordo com sua capacidade de trabalho, transformam os itens do
Product Backlog em tarefas, criando o Sprint Backlog, do qual trabalham ao longo do Sprint
para transformar em um incremento pronto e potencialmente liberável.
» • Gerenciar Sprint Backlog: somente o Time de Desenvolvimento pode criar, gerenciar e
executar o Sprint Backlog.
59
Papéis do Scrum
Time de 
Desenvolvimento
» • Ser responsável, como um time, pelas falhas e pelas vitórias: entendem que o trabalho a ser
executado para atingir a meta do sprint é de todos, nenhum item do Product Backlog ou tarefa
do Sprint Backlog é de responsabilidade de uma pessoa e, sim, de todos. Portanto, nunca se
responsabilizam individualmente, tampouco um único indivíduo é agraciado pelo sucesso.
» • Ser multifuncional: não dependem de nenhum outro recurso de fora do time para executar o
fluxo de trabalho de ponta a ponta.
» • Estar comprometido com os objetivos do projeto: trabalhar para atingir a meta do sprint e
realizar entregas de qualidade de maneira iterativa e incremental.
O Time de Desenvolvimentodeve trabalhar apenas para um Scrum Master e um Product Owner.
Time de 
Desenvolvimento
Organizar e gerenciar seu 
próprio trabalho
Ser multidisciplinar
Trabalhar para transformar os 
requisitos em um incremento
Definir aquilo que é necessário 
ser feito, ‘como’, para atingir a 
meta da Sprint
Realizar o trabalho de entregar 
um incremento potencialmente 
liberável do produto “Pronto” 
ao final de cada Sprint
Estar comprometido com os 
objetivos do projeto
Ser multifuncional
Ser responsável, como um 
time, pelas falhas e vitórias
Gerenciar o Sprint Backlog
TAMANHO DO 
TIME SCRUM
61
Papéis do Scrum
Tamanho do Time 
Scrum
O tamanho ideal do Time de Desenvolvimento é pequeno o suficiente para se manter ágil e grande 
o suficiente para completar uma parcela significativa do trabalho dentro do Sprint (Scrum Guide
2017).
Para calcular o tamanho do Time Scrum, toma-se como base o Time de Desenvolvimento.
» O número de integrantes no Time de Desenvolvimento deve estar entre 3 e 9. Ou seja, 6+3
ou 6-3. Sem contar o Scrum Master e o Product Owner (a menos que eles também executem
trabalho de itens do Sprint Backlog).
Mais de nove integrantes no Time de Desenvolvimento diminui a interação, atrapalhando o 
diálogo Manter o time dentro das proporções ideais de tamanho garante que a comunicação 
flua da maneira correta. Há um limite máximo de informações que o cérebro pode gravar em 
um determinado momento, grandes grupos criam muitos canais de comunicação, criando uma 
situação de complexidade para um processo empírico gerenciar.
Times de Desenvolvimento menores podem encontrar restrições de habilidades durante a Sprint, 
gerando um Time incapaz de entregar um incremento potencialmente liberá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
Número de integrantes no 
Time de Desenvolvimento 
(Não inclui Product Owner e Scrum Master)
3 9
PAPÉIS E 
RESPONSABILIDADES
63
Papéis do Scrum
Papéis e 
Responsabilidades
O Framework Scrum é baseado em três papéis: Scrum Master, Time de Desenvolvimento e Product 
Owner. Portanto, a figura, de extrema importância para algumas metodologias de gerenciamento 
de projeto, o gerente de Projetos, não existe.
Pode-se dizer que as atribuições deste cargo foram pulverizadas nos três papéis do Time Scrum. 
As responsabilidades de escopo, tempo, custo, comunicação, risco e qualidade, antes definidas, 
gerenciadas e monitoradas pelo gerente de Projetos, passaram a fazer parte das atribuições do PO, 
do Scrum Master e do Time de Desenvolvimento.
» Product Ower: realizar a macrogerência do projeto de desenvolvimento, reportando o
andamento do projeto e as entregas aos stakeholders. Garante o gerenciamento do Product
Backlog e entrega do incremento (Escopo), reporta o progresso do Time de Desenvolvimento
ao longo dos Sprints (Tempo), monitora o custo do projeto (Custo), garante a fluidez e a
transparência na comunicação – alinhamento das necessidades, requisitos e evoluções do
produto (Comunicação), monitora os impedimentos e as dependências (Risco) e garante um
incremento pronto e liberável ao final de cada sprint (Qualidade).
» Scrum Master: Promove a fluidez e a transparência da comunicação, garantindo que
objetivos, escopo e domínio do produto sejam entendidos o melhor possível por todos do
Time Scrum(Comunicação), auxilia na remoção dos impedimentos (Riscos) e busca melhoria
contínua dos processos (Qualidade).
» Time Scrum: responsável pela execução os itens a atividades Sprint Backlog (escopo), por
entregar o incremento pronto e liberável ao final do Sprint (Tempo), pela fluidez e pela
transparência da comunicação (Comunicação), pelos impedimentos e dependências do
projeto (Riscos) e pela excelência na qualidade do incremento entregue (Qualidade).
E quem é o Gerente de Projeto? 
Não existe este papel no Scrum
Responsabilidade Product Owner Scrum Master Time de Desenvolvimento
Escopo ✓ × ✓
Tempo ✓ × ✓
Custo ✓ × ×
Comunicação ✓ ✓ ✓
Risco ✓ ✓ ✓
Qualidade ✓ ✓ ✓
• Ninguém desempenha a função de chefe no time
• Um membro do Time de Desenvolvimento pode realizar a função de Product Owner ou Scrum Master
• Product Owner e Scrum Master podem desempenhar suas funções em mais de um time
65
Artefatos do Scrum
 ARTEFATOS 
DO SCRUM
66
Artefatos do Scrum
Artefatos do 
Scrum
Conteúdo
» Product Backlog
» Sprint Backlog
» Incremento
• Definição de Pronto
ARTEFATOS 
DO SCRUM
68
Artefatos do Scrum
Artefatos do 
Scrum
Nesta seção, dentro do Framework Scrum, o foco do aprendizado será direcionado para os 
Artefatos do Scrum: Product Backlog, Sprint Backlog e Incremento.
3 ARTEFATOS
Incremento
Backlog da 
Sprint
Product 
Backlog
SCRUM
3 PAPÉIS 5 CERIMÔNIAS5 CERIMÔNIAS
Sprint 
1 - 4 semanas
Product 
Owner
Scrum 
Master
Time de 
Desenvolvimento
Planejamento 
da Sprint
Reunião 
Diária
Revisão 
da Sprint
Retrospectiva 
da Sprint
PRODUCT 
BACKLOG
70
Artefatos do Scrum
Product Backlog
O Product Backlog é uma lista ordenada de tudo o que é conhecido ser necessário no produto, seu 
responsável é o Product Owner, que gerencia o conteúdo e a prioridade dos itens, sendo a única 
origem dos requisitos para qualquer mudança a ser feita no produto.
O Product Backlog deve ser:
» Rico em necessidades do produto: no Product Backlog encontram-se características, funções,
requisitos, melhorias e correções que formam as mudanças que devem ser feitas no produto
nas futuras versões.
» Evolutivo: o Product Backlog nunca está completo. Os primeiros desenvolvimentos
estabelecem os requisitos inicialmente conhecidos e mais bem entendidos. O Backlog do
Produto evolui tanto quanto o produto e o ambiente no qual ele será utilizado evoluem (Scrum
Guide 2017).
» Dinâmico: mudando constantemente para identificar de que o produto necessita para ser mais
apropriado, competitivo e útil. Se um produto existe, seu Backlog do Produto também existe
(Scrum Guide 2017).
» Priorizado: os itens de maior valor para o negócio e que representam maior ganho do produto
devem ficar no topo.
» Detalhado: todos os itens do Product Backlog devem conter descrição, quanto mais no topo,
mais bem detalhados.
» Visível e transparente: todos do Time Scrum e os envolvidos no projeto devem ter acesso às
informações do Product Backlog.
Um Time de Desenvolvimento trabalha com um único Product Backlog.
Caso existam diversos Times Scrum trabalhando em um único produto, o Product Backlog também 
deve ser único e atender a todos os times.
O Product Owner é DONO do Product Backlog
Product Owner
» O Product Backlog é 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
Product Backlog
71
Artefatos do Scrum
Product Backlog
O Product Backlog 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.
Requisitos
Bugs
Melhorias
Melhorias
72
Artefatos do Scrum
Product Backlog
O Product Backlog 
nunca está completo. 
Entrada de novos 
Itens
Saída de Itens
73
Artefatos do Scrum
Product Backlog
Os itens do Product Backlog de ordem mais alta (topo da lista) devem ser mais claros e mais 
detalhados que os itens de ordem mais baixa
Os itens mais altos devem ser mais claros e mais detalhados que os itens de ordem mais baixa, 
sendo que quanto menor a ordem na lista, menos detalhes.
Prioridade Refinado
Refinado
74
Artefatos do Scrum
Product Backlog
A estrutura do Product Backlog deve possuir:
Descrição: descrição detalhada e clara o suficiente para que o Time de Desenvolvimento entenda o 
que deve ser executado e entregue.
Prioridade: prioridade de execução e liberação na perspectiva do Product Owner.
Valor: valor de retorno para o negócio em relação aos lançamentos do produto.
Estimativa: estimativa usando Planning Poker (Story Point)- na visão do Time de Desenvolvimento 
o tamanho do item a ser executado.
Descrição Prioridade Valor Estimativa (Story Point)
Item 1 100 1 (alto) 3
Item 2 150 2 (médio) 5
Item 3 200 2 (médio) 8
Estrutura do Backlog
75
Artefatos do Scrum
Product Backlog
A principal característica do Product Backlog é a evolução e, se modificar ao longo do tempo, é 
perfeitamente normal.
A figura representa o Ciclo de Vida do Product Backlog, entendendo passo a passo:
 » 1) A necessidade de inclusão ou exclusão de itens pode ser oriunda de uma necessidade 
externa, do Product Owner ou do próprio Time de Desenvolvimento (que identificou itens a 
serem realizados no Grooming, por exemplo).
 » 2) Os itens mais prioritários do Product Backlog são executados pelo Time de Desenvolvimento 
que, ao final da Sprint, entrega um incremento pronto e potencialmente liberável.
 » 3) Clientes, Product Owner e Stakeholders fornecem Feedback, um passo extremamente 
importante para a evolução do conteúdo do Product Backlog.
 » 4 e 5) É realizada a melhoria contínua do produto, ou seja, os feedbacks são absorvidos e se 
tornam novos itens no Product Backlog.
 » 6) Product Owner atualiza o Product Backlog com os novos itens, oriundos do processo.
Product Backlog é 
evolutivo
Clientes, Product 
Owner e Stakeholders 
fornecem Feedback
O Time Scrum deve ter somente 
1 Product Backlog!
Time Scrum avalia 
feedback
Time Scrum desenvolve 
os itens mais prioritários
É realizada 
a entrega do 
incremento
Melhoria contínua 
do produto
Product Owner 
atualiza o Product 
Backlog
Product Owner 
prioriza o Product 
Backlog
Necessidade externa
76
Artefatos do Scrum
SPRINT 
BACKLOG
78
Artefatos do Scrum
Sprint Backlog
Pr
io
ri
da
de
Product Backlog
Pr
io
ri
da
de
Product Owner
O Sprint Backlog é um artefato vivo 
que nasce durante o Planejamento 
da Sprint
Sprint Backlog
Itens priorizados 
e selecionados do 
Product Backlog 
(O QUE)
Tarefas necessárias 
para transformar os 
itens selecionados do 
Product Backlog em um 
“incremento pronto” 
(COMO)
Time de 
Desenvolvimento
79
Artefatos do Scrum
Sprint Backlog
Aqui está representada a criação do Sprint Backlog:
1. A partir da priorização dos itens do Product Backlog, o Time de Desenvolvimento, com
base na sua capacidade produtiva, seleciona os itens que poderá executar na Sprint (O QUÊ).
2. De posse dos itens, o Time de Desenvolvimento escreve as atividades necessárias para
completar um determinado item (COMO).
3. Cada item priorizado e ‘puxado’ do Product Backlog terá suas respectivas atividades.
4. As atividades surgem com o tempo, é normal iniciar uma Sprint com poucas atividades,
pois não se tem conhecimento de tudo o que será necessário realizar para finalizar
determinado item.
5. Para cada item, estima-se a quantidade de horas que será utilizada. Para atividades com
mais de 8 horas de duração, recomenda-se a quebra.
6. A visão inicial da Sprint Backlog é consolidada.
Pr
io
ri
da
de
Sprint Backlog (Plano de Trabalho)
Itens priorizados 
e selecionados do 
Product Backlog 
(O QUE)
Tarefas necessárias para 
transformar os itens selecionados 
do Product Backlog em um 
“incremento pronto” 
(COMO)
Time de 
Desenvolvimento
O Sprint Backlog 
cresce a medida que 
a Sprint se inicia
Novas atividades 
surgem e são 
adicionadas ao 
Sprint Backlog 
ITENS
ATIVIDADES
80
Artefatos do Scrum
Sprint Backlog
A estrutura do Product Backlog deve possuir:
» Descrição (item): descrição detalhada e clara o suficiente para que o Time de Desenvolvimento
entenda o que deve ser executado e entregue.
» Prioridade (item): prioridade de execução e liberação na perspectiva do Product Owner.
» Valor (item): valor de retorno para o negócio em relação aos lançamentos do produto.
» Estimativa (item): estimativa usando Planning Poker (Story Point) - na visão do Time de
Desenvolvimento, o tamanho do item a ser executado.
» Descrição (atividade): descrição da atividade a ser realizada.
» Horas (atividade): estimativa em horas da atividade a ser executada.
Descrição Prioridade Valor Estimativa
Item 1 100 1 (alto) 3
Item 2 150 2 (médio) 5
Item 3 200 2 (médio) 8
Estrutura do Sprint Backlog
Descrição Horas
Item 1 4
Item 2 6
Item 3 8
INCREMENTO
82
Artefatos do Scrum
Incremento
A cada Sprint, o objetivo do time deve ser gerar um incremento pronto e potencialmente e liberável. 
O incremento é a soma de todos os itens do Backlog do Produto finalizado durante a Sprint e o valor 
dos incrementos de todas as Sprints anteriores.
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 independentemente do Product Owner decidir por liberá-lo 
ou não (Scrum Guide, 2017).
Existem certa responsabilidades sobre o Incremento:
» Time de Desenvolvimento responsável por:
• Executar as tarefas necessárias para transformar os itens selecionados do Product Backlog em um
“incremento pronto”.
• Criar, junto com o Product Owner, a “definição de pronto”.
» Product Owner responsável por:
• Aceitar o incremento ao final da Sprint.
• Liberá-lo ou não para a produção
Levantamento de 
Requisitos
Planejamento
Desenvolvimento
Testes
Entrega
Sprint n
O incremento é a soma de 
todos os itens do Product 
Backlog completados durante 
a Sprint e o valor dos 
incrementos de todas as 
Sprints anteriores
INCREMENTO PRONTO 
Ao final da Sprint um novo 
incremento deve estar “Pronto” 
para ser liberado
Product Owner
Time de 
Desenvolvimento
RESPONSÁVEIS
83
Artefatos do Scrum
Incremento
INCREMENTO PRONTO
PRONTO significa que o 
incremento pode ser posto em 
produção imediatamente. Se 
não for possível coloca-lo em 
produção ele NÃO ESTÁ PRONTO
PRONTO
Requisitos finalizados, 
sem trabalho 
remanescente
Em condições de ser 
liberado para produção 
(Potencialmente liberável)
Excelente 
qualidade
84
Artefatos do Scrum
Definição de 
Pronto
A “Definição de Pronto” é um acordo formal entre o Product Owner e o Time de Desenvolvimento 
sobre o que é necessário para se considerar que um trabalho realizado na Sprint está “pronto”.
É checklist descritivo com todas as atividades que o Time de Desenvolvimento precisa realizar para 
entregar um incremento pronto, potencialmente liberável e com qualidade.
O checklist precisa ser de fácil entendimento, transparente, acessível e claro – todos do time 
precisam entender o que “pronto” significa.
A Definição de Pronto serve para:
» O Product Owner poder acompanhar a evolução dos itens do Product Backlog ao longo da
Sprint.
» O Time de Desenvolvimento e o Product Owner entrarem em um acordo sobre o que está ou
não finalizado.
» Um guia para o Time de Desenvolvimento utilizar durante a execução das atividades.
Caso haja vários times trabalhando em um mesmo Product Backlog, a Definição de Pronto deve ter 
sido discutida em conjunto e ser a mesma para todos.
A Definição de Pronto pode ser uma convenção da Organização. Mas, caso a empresa não possua 
uma, o Time de Desenvolvimento pode criar um próprio.
DEFINIÇÃO 
DE PRONTO
Checklist descritivo com todas as atividades 
que o Time de Desenvolvimento precisa 
realizar para entregar um incremento pronto, 
potencialmente liberável e com qualidade
Acordo formal entre Product Owner 
e Time de Desenvolvimento
Transparência para todos os 
envolvidos no projeto
85
Organização do Product Backlog
 ORGANIZAÇÃO 
DO PRODUCT 
BACKLOG
86
Organização do Product Backlog
Organização do 
Product Backlog
Conteúdo
» Product Backlog DEEP
» Refinamento dos Itens do Product Backlog 
(Grooming)
» Planning Poker
» Velocidade do Time Scrum
PRODUCT 
BACKLOG DEEP
88
Organização do Product Backlog
Product Backlog 
DEEP
DEEP é um acrônimo para Detalhado, Estimado, Emergente e Priorizado e são as características 
que o Product Owner deve buscar sempre em seu Product Backlog. Um produtobem-sucedido é 
-teoricamente - aquele que possui um Backlog do Produto com itens DEEP, que estejam alinhados
com a visão/objetivo do produto.
» Detalhado: quer dizer que o Product Backlog deve ter detalhes suficientes para garantir
clareza que assegure a execução, porém não detalhado excessivamente a ponto de gerar
desperdício. A necessidade de detalhamento é proporcional à ascensão do Product Backlog,
ou seja, os itens que vão entrar na próxima Sprint devem estar mais bem detalhados,
enquanto que os itens que vão entrar daqui a várias Sprints podem estar com menor detalhe.
» Estimado: quer dizer que os itens que estão detalhados suficientemente para se ter um nível
adequado de entendimento, devem ter uma estimativa de esforço relacionado a ele. O Product
Backlog não é apenas uma ferramenta de trabalho, mas também de planejamento. Essa
estimativa pode auxilia a entender se o nível de detalhe está bom o suficiente, já que itens do
Product Backlg com uma estimativa muito alta devem quebrados em itens menores.
» Emergente: quer dizer que o Product Backlog não é estático e evolui conforme o Product
Owner vai aprendendo sobre o produto, e o mercado vai lhe dando feedback sobre seus
lançamentos. O constante refinamento do backlog permite que o produto reaja bem a
mudanças de estratégia e de escopo.
» Priorizado: quer dizer que a ordem em que os elementos estão dispostos no Product Backlog
importa. Os itens mais prioritários devem estar no topo, enquanto que os menos prioritários
devem estar abaixo.
O Product Backlog precisa ser D.E.E.P.
Detalhado Estimado Emergente Priorizado
Product Owner
REFINAMENTO 
DOS ITENS 
DO PRODUCT 
BACKLOG 
(GROOMING)
90
Organização do Product Backlog
Refinamento dos itens do 
Product Backlog (Grooming)
O Refinamento dos Itens do Product Backlog, ou Grooming, é uma maneira de preparar os itens 
de Produt Backlog para Sprints futuras, refinando-os durante a Sprint corrente. A própria palavra 
Grooming, em inglês, significa cuidar da aparência, manter limpo e arrumado.
O Product Owner é responsável pela realização do Grooming e todos os membros do Time Scrum 
podem participar.
A entrada para que esta reunião aconteça é um Product Backlog atualizado, com todas as 
necessidades de negócio incluídas e detalhado.
Durante uma reunião de Grooming, a equipe e o Product Owner discutem os principais itens do 
Backlog. Para o Product Onwer, é dada a chance de verbalizar as recentes mudanças de escopo e de 
estratégia no produto e para o Time de Desenvolvimento fazer perguntas que normalmente surgem 
durante o planejamento da Sprint, como:
» • O que deve acontecer se o cliente inserir dados errados aqui?
» • Todo cliente terá permissão para acessar essa página do site?
» • O que acontece se…?
Sendo assim, o Grooming é realizado com o objetivo de:
1. Descobrir novos itens, assim como alteração e remoção de itens antigos.
2. Avaliar a granularidade dos itens do Product Backlog e quebrá-los em itens menores, caso
necessário.
3. Priorizar itens do Product Backlog (trazendo os mais importantes para o topo).
4. Preparar e refinar os itens mais importantes para a próxima Reunião de Planejamento da
Sprint.
5. Estimar e corrigir estimativas dos itens do Product Backlog (em caso de novas
descobertas).
Espera-se utilizar somente 10% da capacidade do Time de Desenvolvimento para esta reunião.
91
Organização do Product Backlog
Refinamento dos itens do 
Product Backlog (Grooming)
Product Owner
O refinamento do Backlog do Produto é a ação de adicionar detalhes, estimativas e ordem aos itens 
no Backlog do Produto.
Backlog do Produto
Prioridade
Traz as necessidades 
do produto
Pr
io
ri
da
de
Time de Desenvolvimento
Clareza
Granularidade
Descrição dos itens
Entendimento da 
necessidade de Negócio
Estimativa em 
alto nível
92
Organização do Product Backlog
Refinamento dos itens do 
Product Backlog (Grooming)
Da perspectiva dos pilares do Scrum, o Grooming se encaixa em:
Inspeção: o Product Owner reavalia a prioridade e a necessidade dos itens do Product Backlog, 
deixando-o atualizado, detalhado e priorizado.
Adaptação: o Time de Desenvolvimento identifica a necessidade de inclusão de detalhes e 
estimativas. Também verifica a granularidade dos itens do Product Backlog e quebra em itens 
menores.
Product 
Owner
INSPEÇÃO
Rever prioridade e 
necessidade dos 
itens do 
Product Backlog
Time de 
Desenvolvimento 
e Product Owner
ADAPTAÇÃO
Adicionar detalhes, 
estimativas e verificar 
a granularidade 
dos itens do 
Product Backlog
PLANNING 
POKER
94
Organização do Product Backlog
Planning Poker
O Planning Poker é uma estratégia usada em projetos ágeis que busca uma estimativa via consenso 
da equipe.
A ferramenta foi definida por James Grenning, em 2002, mas foi com o livro Agile Estimating and 
Planning, de Mike Cohn, que ela se popularizou no mundo de projetos.
Resumidamente, em um jogo Planning Poker, cada membro da equipe de desenvolvimento recebe 
um conjunto de cartas com os valores de certa sequência, que irá determinar, ao final do jogo, uma 
estimativa para as fases do Product Backlog.
O Planning Poker é:
» Prático: auxilia na estimativa dos itens do Product Backlog.
» Relativo: não se compara com nenhuma grandeza específica.
» Realizado: somente pelo Time de Desenvolvimento. As melhores estimativas são feitas pelas
pessoas que realmente realizam o trabalho.
» Consensual: o Time Scrum precisa estar em consenso quanto às estimativas dos itens do
Product Backlog.
» Rápido e objetivo: não possui brechas para demoras e erros, além de ser de fácil aprendizado.
O Planning Poker é realizado quando:
» Groomming:
Entender se o nível de detalhe do item do Product Backlog está bom o suficiente, já que itens do 
Product Backlog com uma estimativa muito alta devem ser quebrados em itens menores.
Planejar o trabalho restante e verificar se o projeto será finalizado no prazo.
» Reunião de Planejamento:
Auxiliar o Time de Desenvolvimento a puxar a quantidade de itens suficientes para serem 
entregues, de acordo com sua capacidade produtiva.
Para a realização do Planning Poker, existe uma sequência de valores para um conjunto de cartas 
e essa sequência pode ser definida de diversas formas. A escala mais usada por Times Scrum é 
baseada na frequência de Fibonacci modificada: 1, 2, 3, 5, 8, 13, 20, 40 e
100. Cada número desta sequência corresponde a uma carta que é utilizada para a estimativa. A
estimativa dada é chamada de Story Point.
95
Organização do Product Backlog
Planning Poker
Cartas são baseadas na Sequência de Fibonacci
1 2 3 5 8 13 20 40 100 ?
96
Organização do Product Backlog
Planning Poker
Para estimar, segue-se a seguinte sequência:
» Balizar a estimativa
1. Selecionar o item do Product Backlog com o menor tamanho.
2. Estimar o item, utilizando o Planning Poker.
3. Utilizar o item estimado como balizador para pontuação dos demais, nenhum item terá
menor pontuação que este.
» Primeira rodada de estimativa
4. Primeira rodada de estimativa
5. Estimar privadamente (aqui as cartas ainda não são mostradas).
6. Revelar as cartas após a finalização das estimativas.
» Segunda rodada de estimativa e finalização
7. Discutir as estimativas divergentes – maiores e menores.
8. Entrar em consenso em relação à estimativa.
9. Reestimar caso necessário.
Balizar a estimativa
1 Selecionar o item do Product Backlog com 
menor tamanho
2 Estimar o item utilizando
o Planning Poker
3 Utilizar o item estimado 
como balizador para 
pontuação dos demais, 
nenhum item terá menor 
pontuação que este
4 Iniciar as leitura dos 
demais itens do Product 
Backlog
5 Estimar privadamente 6 Revelar as cartas após a
finalização das estimativas
primeira rodada de estimativa
7 Discutir as estimativas 
divergentes – maiores 
e menores
8 Entrar em consenso em
relação a estimativa
9 Reestimar caso 
necessário
segunda rodada de estimativa e finalização
VELOCIDADE DO 
TIME SCRUM
98
Organização do Product Backlog
Velocidadedo time 
scrum
Velocidade do Time Scrum é o trabalho que o time consegue produzir a cada Sprint, de acordo com 
a Definição de Pronto.
Ao final de cada Sprint, o Time Scrum entrega um determinado número de itens, que contêm uma 
estimativa, a soma das iniciativas é a velocidade do Time Scrum naquela Sprint em específico.
Os itens que não são entregues, não foram finalizados, retornam ao Product Backlog e sua 
estimativa não é contabilizada como entrega. Esses itens serão reavaliados no Grooming e uma 
nova estimativa será feita, levando em consideração o trabalho restante.
Utiliza-se largamente, como estimativa, o Planning Poker.
Sprint 
Backlog
8 pontos
2 pontos
5 pontos
5 pontos
13 pontos
Product 
Backlog
Incremento 
Pronto
8 pontos
5 pontos
5 pontos
13 pontos
Velocidade 
de 31 pontos
99
Organização do Product Backlog
Velocidade do 
time scrum
Obter a velocidade média do Time Scrum auxiliando no planejamento das Sprints e realizar 
projeções sobre o projeto, é simples. Basta realizar uma média simples:
1. Somar as estimativas entregues em todas as Sprints anteriores.
2. Dividir pela quantidade de Sprints.
3. Pronto, a velocidade média do Time Scrum está calculada.
Esta quantidade de pontos irá prevalecer para o planejamento dos itens para as Sprints futuras.
Velocidade do Time Scrum é a média das velocidades ao longo do tempo
Tempo
Sprint 1 
31 pontos
Sprint 2 
32 pontos
Sprint 3 
31 pontos
Sprint 4 
29 pontos
Sprint 5 
35 pontos
Sprint 6 
38 pontos
VELOCIDADE DO 
TIME SCRUM
31 + 32 + 31 + 29 + 35 + 38
6 32 PONTOS
Esta quantidade de pontos irá prevalecer para o Planejamento dos 
Itens para as Sprint futuras
101
Eventos do Scrum
 EVENTOS 
DO SCRUM
102
Eventos do Scrum
Conteúdo
1. A Sprint
2. Planejamento da Sprint
2.1. Cancelamento da Sprint
3. Reunião Diária
4. Revisão da Sprint
5. Retrospectiva da 
Sprint
103
Eventos do Scrum
Sprint 
1 - 4 
semanas
Planejamento da 
Sprint
Reunião Diária Revisão da Sprint Retrospectiva da 
Sprint
Backlog do 
Produto
Backlog da 
Sprint
Incremento
3 ARTEFATOS
SCRUM
3 PAPÉIS 5 CERIMÔNIAS5 CERIMÔNIAS
Product 
Owner
Scrum 
Master
Time de 
Desenvolvimento
Nesta seção, dentro do Framework Scrum, 
o foco do aprendizado será direcionado às
cerimônias do Scrum: Sprint, Planejamento
da Sprint, Reunião diária, Revisão da Sprint e
Retrospectiva da Sprint.
Os eventos são usados no Scrum para criar
uma regularidade e minimizar a necessidade de
reuniões não definidas. Todos os eventos são
time-boxed, ou seja, têm uma duração máxima.
Uma vez que a Sprint começa, sua duração é 
fixada e não pode ser reduzida ou aumentada, 
diferentemente dos demais eventos que podem 
terminar quando o propósito do evento é 
alcançado, garantindo que uma quantidade 
adequada de tempo seja utilizada não 
permitindo desperdícios no processo.
104
Eventos do Scrum
A SPRINT
106
Eventos do Scrum
A Sprint
TIME SCRUM
TIME BOX = 1 a 4 SEMANAS
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. 
Reunião 
Diária
Sprint 
1 - 4 semanas
Retrospectiva da Sprint 
(Lições aprendidas)
Incremento
Revisão da Sprint 
(Demonstração do produto)
Backlog do Produto 
Priorizado e Refinado
Planejamento da Sprint 
Sprint Backlog 
(Plano de Trabalho)
A Sprint pode ser considerada como o principal 
evento do Scrum, porque é dentro dela que todo 
o ciclo acontece.
Uma Sprint tem um time-boxe de um mês ou
menos, a quantidade de semanas depende da
maturidade do Time Scrum e do apetite de risco
do Produt Owner. A participação na Sprint é
obrigatória para o Time Scrum.
A Sprint inicia-se com a reunião de planejamento. 
Nela o Time Scrum, em posse de um Product 
Backlog refinado e priorizado, irá planejar as 
tarefas das semanas seguintes a fim de alcançar 
um objetivo, ou meta, que será estabelecido 
durante a reunião entre o Product Owner e o Time 
de Desenvolvimento. Este conjunto de tarefas, que 
são os itens do Product Backlog, mais as ativida des 
para executá-lo chama-se Sprint Backlog, que é a 
saída da reunião.
107
Eventos do Scrum
A Sprint
Durante os dias da Sprint, o Time de 
Desenvolvimento executa as atividades 
planejadas e se reúne diariamente para 
compartilhar as evoluções e os impedimentos 
relacionados ao alcance da meta da Sprint.
Ao final, após as semanas de trabalho, o Time 
de Desenvolvimento criou um incremento 
pronto e potencialmente liberável: a entrega da 
Sprint. Na reunião de demonstração, o Time de 
Desenvolvimento apresenta o que foi entregue 
e colhe feedbacks para a evolução do produto. 
Nesta reunião, o foco é o produto.
Após a demonstração, o Time Scrum se reúne 
para discutir os pontos positivos e de melhoria 
da Sprint, além de traçar um plano de ação. 
Aqui as discussões permeiam os processos, 
os relacionamentos e as ferramentas. É o time 
analisando a si mesmo.
É durante a Sprint que também acontece o 
Grooming, garantindo que o Product Backlog 
esteja sempre aderente às necessidades da 
organização.
Durante a Sprint:
• Não são feitas mudanças que possam
pôr em perigo o objetivo da Sprint.
• As metas de qualidade não diminuem.
• O escopo pode ser clarificado e
renegociado entre o Product Owner e o
Time de Desenvolvimento quanto mais for
aprendido.
Cada Sprint tem uma meta do que deve ser 
construído, um plano previsto e flexível que 
irá guiar a construção, o trabalho e o produto 
resultante do incremento.
Sprints têm durações rígidas ao longo de todo 
o esforço de desenvolvimento, ou seja, ela
não termina antes, tampouco depois do time-
box acordado, sendo que uma nova Sprint
inicia imediatamente após a conclusão da
Sprint anterior.
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.
No Scrum, não existe uma Sprint 0, que utiliza 
o tempo para refinar itens, definir arquitetura,
discutir o produto etc. Em todas as Sprints,
incluindo a primeira, é necessário o entregável
do incremento “Pronto” e potencialmente
liberável. Aliás este é o objetivo da Sprint.
A criação de uma Sprint envolve trabalho
constante de comunicação entre os times
de Desenvolvimento, o Scrum Master e o
Product Owner. Eles devem compartilhar suas
necessidades, sua capacidade de produção e
sua evolução no alcance das metas, a fim de
evitar a quebra de expectativas ao final de
cada etapa.
Interferências externas devem ser barradas
pelo Scrum Master e todo novo pedido realizado
para o Time de Desenvolvimento deve, antes de
tudo, ser comunicado ao Product Owner.
108
Eventos do Scrum
PLANEJAMENTO 
DA SPRINT
110
Eventos do Scrum
Planejamento 
da Sprint
Incremento 
do Produto 
Recente
Product Backlog 
(Priorizado e 
Refinado)
Capacidade do 
Time Scrum
ENTRADA
O QUE FAZER COMO FAZER
META DA SPRINT
Meta da 
Sprint
Sprint 
Backlog
SAÍDA
Planejamento da Sprint
O planejamento da sprint é um evento no 
Scrum que inicia o Sprint, cujo objetivo é 
definir o que pode ser entregue e como esse 
trabalho será alcançado, sendo realizado em 
colaboração de todo o Time Scrum.
A reunião tem time-box definido de oito 
horas para Sprints de um mês de duração 
e é proporcionalmente menor para Sprints 
menores. Se uma Sprint, por exemplo, durar 
duas semanas, a reunião de planejamento da 
Sprint terá duração de quatro horas.
Pré-planejamento
Product Backlog: deve estar preparado, ou seja, 
refinado e priorizado. Esta atividade é feita na 
Sprint anterior à vigente, pelo Product Owner.
Incremento do produto recente: todos os 
incrementos já entregues, liberados ou não, 
devem ser de conhecimento do Time Scrum. 
O objetivo da Sprint é entregar um novo 
incremento pronto e potencialmente liberável.
Capacidade do Time Scrum: deve-se levar para 
a reunião a quantidade média de pontos que 
o Time Scrum entrega por Sprint. Este ponto é
importante para medir a capacidade deexecução
dos itens e a produtividade do Time Scrum.
111
Eventos do Scrum
Planejamento 
da Sprint
META DA SPRINT
O Planejamento
A reunião de Planejamento da Sprint pode ser divida em duas partes e cada 
etapa busca responder a uma pergunta, que é crucial para o desenrolar da Sprint:
• Primeira parte - O que pode ser entregue como
resultado do incremento da próxima Sprint?
Nesta primeira parte da Reunião de Planejamento, com a facilitação do Scrum 
Master, o Product Owner e o Time de Desenvolvimento colaboram para definir 
o que será desenvolvido na Sprint. Eles escolhem, a partir do topo do Product
Backlog, quais itens farão parte do Sprint Backlog.
É de responsabilidade do Product Owner explicar as funcionalidades de maior
prioridade para o Time de Desenvolvimento, que deve fazer perguntas para
esclarecer possíveis dúvidas e auxiliar, posteriormente, na definição de quais
itens eles irão mover do Product Backlog para o Sprint Backlog.
Essa colaboração se encerra quando o Product Owner e o Time de
Desenvolvimento concordam em quais e quanto itens serão ‘puxados’ para
execução de acordo com a capacidade produtiva do time (velocidade medida
de entrega – story point)
112
Eventos do Scrum
Planejamento 
da Sprint
Os itens selecionados farão parte do Sprint Backlog 
e serão detalhados na parte dois da reunião.
Finalizada esta parte, o Time de 
Desenvolvimento e o Product Owner negociam e 
estabelecem a meta da Sprint.
A meta ou o objetivo da Sprint é uma descrição 
do que se pretende atingir na Sprint, fornecendo 
ao Time de Desenvolvimento a orientação do 
que deve ser entregue.
• Segunda parte - Como o traBalho 
necessário para entregar o 
incremento será realizado?
Na segunda parte da reunião, o Time de 
Desenvolvimento planeja como será feito o 
desenvolvimento dos itens escolhidos para o 
Sprint Backlog.
O Time de Desenvolvimento trabalha 
percorrendo item a item entre os escolhidos 
para quebrar cada um em um conjunto de 
atividades correspondentes.
As atividades devem ser pequenas, com duração 
de, no máximo, oito horas (um dia). Atividades 
maiores que um dia de trabalho são de difícil 
acompanhamento e devem ser evitadas, já 
que um membro do Time de Desenvolvimento 
poderia informar ao resto do time que ainda 
está trabalhando na mesma tarefa por vários 
dias seguidos.
O QUE FAZER COMO FAZER
META DA SPRINT
Estimativa usando 
Planning Poker
Estimativa usando 
horas
PARTE 1 = 4 HORAS PARTE 2 = 4 HORAS
• Product Owner explica os itens do Product Backlog
• Time de Desenvolvimento sana as dúvidas
• Time de Desenvolvimento estima os itens
• Time de Desenvolvimento puxa os itens
• Define-se em conjunto, Product Owner e Time de 
Desenvolvimento a Meta da Sprint
• Time de Desenvolvimento escreve as atividades 
que irá realizar por item puxado
• Tarefas são estimadas em horas 
• Time de Desenvolvimento estima os itens
• Time de Desenvolvimento se compromete com 
a Meta da Sprint
113
Eventos do Scrum
Planejamento 
da Sprint
Uma vez que todas as atividades foram escritas 
por itens do Product Backlog, adicionam-se as 
estimativas de tempo gasto, ou seja, estima-se 
em horas, quando cada membro do Time de 
Desenvolvimento irá consumir para entregar 
determinada tarefa.
Neste primeiro momento, o trabalho de 
definição e estimativa das tarefas não é 
exaustivo nem completo.
O Time de Desenvolvimento cria as atividades 
com base nas informações e conhecimentos que 
tem no momento, ou seja, para cada item do 
Product Backlog dificilmente haverá todas as 
atividades escritas.
À medida que o Time de Desenvolvimento 
avança na Sprint e entende melhor o trabalho 
que está realizando, novas atividades vão 
surgir, outras serão modificadas ou até mesmo 
excluídas. Isto faz parte do processo.
A participação do Product Owner não 
é obrigatória neste momento, porém, é 
importante que ele esteja disponível para retirar 
eventuais dúvidas do Time de Desenvolvimento.
Assim, ao final da reunião de Planejamento 
espera-se obter o Sprint Backlog (total 
responsabilidade do Time de Desenvolvimento) 
e a meta da Sprint (acordada entre PO e Time de 
Desenvolvimento).
O sucesso da Sprint será verificado adiante 
durante a reunião de revisão da Sprint.
Time Scrum
Melhorar as 
comunicações, deixar o 
trabalho futuro visível 
e acordar objetivo com 
todos os responsáveis 
pela execução do projeto
TRANSPARÊNCIA
O planejamento da Sprint promove o pilar da 
transparência no Time Scrum: melhorar as 
comunicações, deixar o trabalho futuro visível e 
acordar um objetivo com todos os responsáveis 
pela execução do projeto
114
Eventos do Scrum
CANCELAMENTO 
DA SPRINT
116
Eventos do Scrum
Uma Sprint pode ser cancelada antes do time-boxed terminar, se a meta 
tornou-se obsoleta.
Isto pode acontecer caso a organização mude sua direção ou se as 
condições do mercado ou das tecnologias mudarem.
A autoridade para cancelar a Sprint é somente do Product Owner, embora 
ele possa fazer isso sob influência das partes interessadas, do Time de 
Desenvolvimento ou do Scrum Master.
Cancelamentos são raros de acontecer, justamente pelo fato de a Sprint 
ter um tempo curto de duração.
Quando um cancelamento acontece, os itens finalizados, de acordo com 
a definição de “Pronto”, são normalmente aceitos pelo PO e aqueles 
incompletos retornam ao Backlog do Produto.
META DA SPRINT OBSOLETASomente o Product 
Owner tem 
autoridade para 
Cancelar a Sprint
Sprint 
Backlog
8 pontos
2 pontos
5 pontos
Product 
Backlog Incremento Pronto
8 pontos
5 pontos
 REUNIÃO 
DIÁRIA
118
Eventos do Scrum
Reunião Diária
TIME BOX = 15 MINUTOS
TIME DE DESENVOLVIMENTO SCRUM MASTER
TIME BOX = 15 MINUTOS
Acontece diariamente Mesmo local Mesmo horário
Minimiza reuniões adicionais Compartilhar problemas
119
Eventos do Scrum
Reunião Diária
A reunião diária do Scrum é um evento 
time-box de 15 minutos para o Time de 
Desenvolvimento. Nela é obrigatória a 
participação do Time de Desenvolvimento, 
porque é ele que conduz a reunião.
O Scrum Master tem a função de garantir 
que a reunião ocorra e que o Time de 
Desenvolvimento esteja se comunicando 
de maneira efetiva e compartilhando as 
informações necessárias para garantir o 
alcance da meta da Sprint.
A participação do Product Owner é opcional, 
sendo que tanto ele como os stakeholders 
podem participar da reunião, desde que não 
atrapalhem ou interfiram nas discussões.
A reunião diária, como comentado, possui 
time-box definido e acontece todos os 
dias no mesmo horário e local. Isso reduzi 
a complexidade e traz hábito, disciplina e 
cadência para o time.
A reunião diária visa a diminuir a quantidade 
de reuniões adicionais, já que garante a 
fluidez da comunicação entre quem está 
executando as atividades.
O objetivo da reunião diária é realizar o 
alinhamento entre os membros do time a fim de 
garantir a entrega da meta ao final da Sprint.
Durante a reunião são compartilhados os 
problemas encontrados, porém a solução para 
eles não é questionada. Isso é realizado após 
a reunião diária, somente com os envolvidos, 
para discussões detalhadas, para adaptarou 
replanejar o trabalho do restante da Sprint.
120
Eventos do Scrum
Reunião Diária
META DA SPRINT
» O que eu fiz desde a última reunião?
» O que vou fazer até a próxima reunião?
» Quais são os impedimentos que estão me atrapalhando a realizar meu trabalho?
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 utilizam perguntas, outros se basearão 
em discussões. A forma mais utilizada de guiar a reunião diária é 
respondendo às três perguntas a seguir:
» O que eu fiz desde a última reunião?
» O que vou fazer até a próxima reunião?
» Quais são os impedimentos que estão me atrapalhando na
realização do meu trabalho?
O foco de toda reunião 
diária é olhar a meta 
da Sprint e o progresso 
do time em relação ao 
seu cumprimento.
121
Eventos