Scrum Definitivo PDF

Scrum
Definitivo
As técnicas e Estratégias
para você vencer usando
o método ágil mais
famoso da Galáxia
Denis Rodrigues Pedro

Denisson Vieira
Scrum Definitivo 2 Mindmaster Treinamentos
Apresentação
Antes de mais nada, permita-nos apresentar a MindMaster adequadamente.
Somos uma empresa de treinamento diferenciada, focada em formar profissionais com

conhecimentos práticos e prontos para o mercado de trabalho. Criada por executivos de larga
experiência no mercado de TI a MindMaster tem se destacado por oferecer os treinamentos
que melhor acompanham as tendências do mercado. Já formamos mais de 4.000 alunos no
Brasil e no exterior e ainda é só o começo.
Somos especializados em treinar nossos alunos para prática real dos métodos ágeis em seu dia-
a-dia de trabalho, assim como, ajudá-los a obterem sua certificação profissional , consolidando
ainda mais suas carreiras.
Se você está procurando um jeito de aprender Scrum e colocá-lo realmente em prática, você
deve continuar a ler este livro e seguir cada uma das dicas apresentadas aqui.
Garantimos que ao se empenhar na realização de todas as práticas e na assimilação dos

ensinamentos aqui prescritos, você poderá se tornar um verdadeiro Mestre Jedi do Scrum.
Que a Força esteja com Você!
Denis Pedro Denisson Vieira

Co-founder Co-Founder
Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

em entregas ágeis, atendendo os objetivos de sua empresa, clientes e

sim, da sua equipe, de um modo mais civilizado.
Introdução
O Mundo mudou e o jeito ágil de entregar projetos de qualidade é
a nova tendência. É inevitável resistir, você não pode subestimar os
Há muito tempo atrás em uma galáxia muito, muito distante ... poderes do Scrum... :)
Porque decidimos escrever este Livro Continue aqui com a gente e aproveite cada parte deste livro. Ele é
seu e vai te ajudar no caminho da agilidade.
A esta altura você já deve até estar ouvindo a música tema de Star Wars, Como este Livro está organizado
não é mesmo?
Realmente este épico filme foi marcante para várias gerações e usá-lo Na sequência dos capítulos do Livro você irá perceber que há algumas
como tema para nosso Livro foi uma forma de apresentar o método marcações importantes que te ajudarão a entender melhor os
ágil de gerenciar projetos de uma forma lúdica e também de fácil fundamentos do Scrum, bem como lhe ajudar a praticar e a iniciar a
compreensão. transição para o método ágil.
O Fato do Gerente de Projetos dos dias atuais ter que É importante que você absorva cada um dos conteúdos aqui
praticamente possuir poderes especiais para liderar projetos relacionados, bem como, pratique cada um dos exercícios.
cada vez mais complexos, por certo exige que ele se
transforme em um verdadeiro Jedi. O Livro está dividido em 7 Capítulos:
Cansados de ver centenas, porque não dizer 1) Os Fundamentos do Scrum

milhares, de profissionais que ao procurar um
jeito de aprender o Scrum para aplicar em 2) O Time Scrum
seus projetos passam horas a fio
no Google, apenas fazendo 3) Eventos do Scrum
uma caça implacável
a todo e qualquer 4) Artefatos do Scrum
material disponível para
download, sem um norte 5) Testes de Conhecimento
ou linha de raciocínio lógico
que o ensine os verdadeiros 6) Certificações Scrum
caminhos da Força, a forma
elegante de estruturar projetos 7) Resumo

Nos primeiros 4 capítulos você irá encontrar as seguintes seções: Entrar em Ação
A Teoria Sobre a Força É a seção onde você colocará seus conhecimentos de Scrum na Prática.
Aprendendo desde a iniciar a transição para o método ágil em sua
Nesta seção serão descritos fundamentos básicos que você deve empresa até a transformar um projeto regular para o método ágil.
aprender para assimilar de uma vez por todas o framework Scrum e
suas características principais. Você será desafiado a vencer desafios específicos sobre Scrum e ao
mesmo tempo verificar o seu progresso como profissional
Aqui serão descritos os processos, eventos, papéis e responsabilidades
do método ágil. Material para Baixar
Como Usar a Força Estarão a sua disposição uma série de modelos de documento para
download. Embora muitos sigam a linha de que um bom Jedi faz o seu
Nesta seção será apresentada qual a melhor forma de usar a força na próprio Lightsaber, entendemos que ajudar você com material de apoio
medida certa e quais os benefícios reais de aplicabilidade de cada evento é apenas mais uma forma de ajudá-lo a compreender como colocar o
do Scrum. Afinal, de nada adianta você todo o conhecimento sobre a Scrum na vida real. Você não apenas poderá baixar os arquivos, mas
Força e não saber qual a melhor forma de aplica-la nos seus projetos. também será instruído sobre como utilizá-los.

Capítulo 1
Os Fundamentos do Scrum

O Scrum é um framework estrutural que está sendo usada para

gerenciar o desenvolvimento de produtos complexos desde o início de
Capítulo 1: Os Fundamentos do Scrum 1990. Scrum não é um processo ou uma técnica para construir produtos;
em vez disso, é um framework dentro do qual você pode empregar
vários processos ou técnicas. O Scrum deixa claro a eficácia relativa
De acordo com o Scrum Guide, o Scrum é um framework para das práticas de gerenciamento e desenvolvimento de produtos, de
desenvolver e manter produtos complexos. Este livro apresenta a modo que você possa melhorá-las. A Melhoria contínua passa a ser seu
definição do Scrum, seus respectivos papéis, eventos, artefatos e as companheiro constante.
regras. Uma abordagem bastante objetivo seguirá, explicando de modo
claro os conceitos e oferecendo ainda oportunidades de prática. Framework Scrum
A Teoria Sobre a Força O framework Scrum consiste nas equipes do Scrum associadas a papéis,
eventos, artefatos e regras. Cada componente dentro do framework
serve a um propósito específico e é essencial para o uso e sucesso do
O que é o Scrum? Scrum.
Scrum é um framework dentro do qual pessoas podem tratar e resolver

Neste livro vamos mencionar algumas ferramentas e técnicas do Scrum.
problemas complexos de modo adaptativo, enquanto procuram
Existem diversas estratégias específicas para o uso do framework
entregar produtos com o mais alto valor possível do mais produtivo e
Scrum e algumas são descritas em outros treinamentos específicos da
criativo possível, sempre visando a satisfação do cliente.
MindMaster.
O Scrum se diferencia de métodos tradicionais por ter as seguintes

características:
• É um conjunto de processos Leve, que não demanda muito esforço

ou ferramentas pesadas para sua prática
• É relativamente Simples de entender e praticar
• É Extremamente difícil de dominar, apesar de sua simplicidade,

o jeito de pensar ágil força o profissional a abrir mão de diversos
conceitos enraizados pelos métodos tradicionais e o força a pensar
em qualidade e entrega contínua. Esta transição não tem de ser
dolorosa e por meio da prática é possível perceber rapidamente os
seus benefícios.

Teoria do Scrum • Os horários e locais das reuniões podem ser publicados em

quadro de informações do projeto
O Scrum foi fundamentado nas teorias empíricas de controle de • Um Burndown Chart pode ser apresentado para indicar
processo, ou empirismo. o progresso e avanço do sprint (Tá ficando curioso com tanta
informação nova?)
O empirismo afirma que o conhecimento vem da experiência e
de tomada de decisões baseadas no que é conhecido. O Scrum • Um quadro com as datas
emprega uma abordagem iterativa e incremental para aperfeiçoar a dos releases
previsibilidade e o controle de riscos. • E tantas outras formas de
transparência que puderem ser
Os 3 Pilares do Scrum empregadas no dia-a-dia do seu
projeto que especialmente façam
Três pilares apóiam a implementação de controle de processo empírico: a diferença para sua organização.
transparência, inspeção e adaptação.
Transparência
Aspectos e informações relevantes do seu projeto devem estar sempre

visíveis e claros para todos os participantes do projeto. Os responsáveis
pelos resultados do projeto tem a solene responsabilidade de manter
uma comunicação clara e promover constantemente a transparência.
Esta transparência deve ser promovida por um um padrão comum

de apresentar as informações do projeto, de modo que qualquer
observador possa ter o mesmo entendimento dos membros do time.
Por exemplo:
• Pode-se utilizar um quadro de tarefas, também como

conhecido como Kanban (será detalhado mais a frente) para
apresentar a situação real do Product Backlog (Calma, você já vai
aprender mais sobre isso :)
• Os requisitos da definição de pronto ou definition of

done (Isso é demais) deve ser compartilhada com toda equipe,
especialmente com aqueles que receberão o produto do projeto.

Inspeção Adaptação
Os profissionais do time Scrum devem, frequentemente, inspecionar os
A adaptação é um dos pilares mais importantes do Scrum. Através deste
artefatos Scrum e o progresso do projeto a fim de detectar prontamente
prisma de tomada de ação, o projeto passa a ter mais foco na qualidade de
indesejáveis variações. Esta inspeção,não deve no entanto, ser tão
entrega do produto do que normalmente ocorre em projetos tradicionais.
freqüente que atrapalhe a própria execução das tarefas.
Um modo de se verificar a adaptação no mundo real é quando situações

As inspeções quando realizadas de forma diligente, sem exageros, por
imprevistas acontecem na rotina do projeto e as datas acordadas junto
profissionais especializados no trabalho de garantia de qualidade são
aos nossos clientes ou mesmo os requisitos não mudam.
normalmente as que obtém melhores resultados.
Por exemplo:
Por exemplo:
• A atuação de Testers ou Analistas de Testes em seu projeto Se um Analista de Testes determina que um ou mais aspectos do
por certo podem contribuir demais com a inspeção da qualidade produto que está sendo desenvolvido sofreu algum tipo de desvio para
de seu projeto, dado o nível de especialização deste profissional. fora dos limites aceitáveis, e que o produto resultado será inaceitável, o
processo de desenvolvimento ou o próprio produto do projeto deve ser
• É de suma importância que você mensure os níveis de prontamente ajustado. O ajuste deve ser realizado o mais breve possível
qualidade do seu projeto, por exemplo, documentando e para minimizar mais desvios. Aqui é quando muitos alunos percebem
categorizando os bugs, que serão parte importante do dia-a-dia a diferença do Scrum, pois embora haja uma certa liberdade com o
dos sprints que se seguirão à frente. compromisso da Auto-organização das equipes, ao identificar quaisquer
desvios a equipe tem que se empenhar e adaptar-se às mudanças e
• Uma outra forma de promover a inspeção no seu projeto. eventuais desafios.
Ao iniciar a codificação de um projeto tenha em mente o uso
de técnicas como o Test Driven Development e bibliotecas que Dicas Importantes:
o ajudem a rodar os testes unitários e identificar a respectiva
cobertura de código, isto é, as classes de seu código podem e
O Scrum oferece quatro oportunidades formais para promover a
devem ser testados unitariamente e por meio de ferramentas
práticas (e.g.: Sonar para projetos Java ou Ant para projetos .Net) é transparência, inspeção e adaptação. Mais adiante no livro você terá
possível mensurar a inspeção através de testes unitários. mais detalhes, porém estes sãos os eventos onde você irá aplicar os
pilares do Scrum.
• Outro exemplo é a aplicação
de integração contínua para • Reunião de planejamento da Sprint (O famoso Sprint Planning)
evitar problemas no build • Reunião diária (Daily Scrum ou Standup Meetings)
da sua aplicação, isto é, na
estruturação do seu ambiente • Reunião de revisão da Sprint (Também conhecida como Sprint
de desenvolvimento. Review)
• Retrospectiva da Sprint
O Manifesto Ágil Os nove principios do manifesto ágil
Abaixo seguem os principais itens que foram atualizados no Scrum

O Manifesto Ágil é o marco da criação de um jeito novo de se
Guide 2013 pelo Scrum.org. Você poderá baixar o guia e os conteúdos
desenvolver produtos. Uma nova forma focada exclusivamente em
adicionais do Guia através do nosso site.
resultados e alta qualidade.
O manifesto pode ser encontrado www.agilemanifesto.org em diversos 1 - Mudanças no Objetivo do Sprint

idiomas. O texto que dizia que não são feitas mudanças que afetem o
objetivo da Sprint, foi mudado para o que diz que não são feitas
Manifesto para Desenvolvimento Ágil de Software mudanças que possam por em perigo o objetivo da Sprint.
2 - Configuração Time Box Sprint Planning
Estamos descobrindo maneiras melhores de Na versão 2011 a configuração da time-box da reunião de

desenvolver software, fazendo-o nós mesmos e planejamento da Sprint era de 8 horas cravadas, já na versão 2013
ajudando outros a fazerem o mesmo. o texto trás um “no máximo 8 horas”
Através deste trabalho, passamos a valorizar:

3 - Transparência dos Artefatos
Indivíduos e interações mais que processos e
Há um reforço agora que os artefatos precisam ser transparentes
ferramentas
para que todos tenham o mesmo entendimento dos artefatos.
Software em funcionamento mais que documentação
abrangente 4 - Participantes Sprint Planning
Colaboração com o cliente mais que negociação de As questões que precisam ser respondidas ao final do
contratos planejamento da Sprint ganharam um novo item, o que deixa
explicito que o Time precisa definir o Objetivo da Sprint.
Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita, 5 - Time boxes

valorizamos mais os itens à esquerda.
Foi deixado claro que os timeboxes são tempos máximos. O único
timebox que não pode ser encurtado é o Sprint; os demais (daily,
review e retrospectiva) podem ser finalizados, caso o seu propósito
seja alcançado antecipadamente.

Além disso, foi deixado claro que, no final do sprint, no Sprint Nossa maior prioridade é satisfazer o cliente através da entrega
Review, o time colabora nos próximos itens que poderiam ser antecipada e continua de software com valor.
priorizados para otimizar o valor sendo entregue
Acomodar mudanças de requisitos mesmo que seja ao final do
desenvolvimento. Processos ágeis aproveitam as mudanças para
6 - Equipe de Desenvolvimento
dar vantagem competitiva ao cliente.
A regra que dizia: “A composição do Time de Desenvolvimento
permanece constante” foi retirada. Entregar software funcionando frequentemente, o mais rápido
possível.
7 - Formato Reunião de Sprint Planning Pessoas de negócios e desenvolvimento devem trabalhar juntos
O formato da reunião de planejamento da Sprint na versão 2011 diariamente durante todo o projeto.
era de duas partes, onde na parte 1 era definido “o que” seria feito
Criar projetos rodeado de indivíduos motivados, dê-lhes o
na próxima Sprint, e na parte 2 o Time definia “como” seria feito.
ambiente e suporte necessários, e estabeleça confiança para que
Agora os autores mudaram para uma reunião só, com apenas
o trabalho seja feito.
uma parte, mas dividida em dois tópicos onde o “o que” e o “como”
serão definidos.
Valores do SCRUM
8 - Participantes Sprint Planning
• Foco na Entrega
Os autores agora sugerem que os participantes desta cerimônia
incluem o Time Scrum e os Stakeholders chaves convidados • Transparência
9 - Daily SCRUM: As 3 Perguntas Alteradas • Time-Box
Foi ainda reforçada a importância do Daily Scrum como • Qualidade Total

atividade de planejamento, com foco em alcançar a meta da
iteração. As três perguntas fundamentais do Daily Scrum foram
• Trabalho em Equipe
modificadas para:
• Comunicação Constante
O que fiz ontem que ajudou o time a atingir a meta
do sprint?
• Comprometimento
O que vou fazer hoje para ajudar o time a atingir a meta
do sprint?
• AutoGerenciamento
Existe algum impedimento que não permita a mim ou ao
time atingir a meta do sprint? • Trazer à tona os problemas

O princípio da auto-organização A Mitologia Ágil

Este princípio é um dos mais difíceis para a transição ao método ágil, Juntamente com o Scrum surgem diversas desconfianças, que na maioria
pois demanda confiança na equipe e por outro lado, a responsabilidade das vezes se transformaram em mitologia em relação ao método ágil,
dos indivíduos para com as entregas comprometidas. isto é, mais do que preconceitos, são mitos gerados por profissionais que
desconhecem o Scrum ou temem sua aplicação prática:
A maioria dos profissionais que atuam em métodos tradicionais
desconfiam do pleno funcionamento deste princípio, porém, se não
aplicado, não há Scrum, pois a equipe tem um papel fundamental na
condução dos sprints e a sua atuação independente e responsável é o
fator de sucesso que o projeto precisa.
A equipe deve ser capaz de se organizar e dividir o trabalho.
Não necessariamente o time todo deve ser Sênior, porém a auto-

organização requer comprometimento e responsabilidade desde o
primeiro dia de projeto.
Como no esporte, os membros da equipe são interdependentes e o Scrum

Master fará todo o possível para manter a auto-organização, fator chave
para o sucesso do projeto.
Times Scrum são auto-organizáveis e multifuncionais. Equipes auto-

organizáveis escolhem qual a melhor forma para completarem seu
trabalho, em vez de serem dirigidos por outros de fora da equipe. Equipes
multifuncionais possuem todas as competências necessárias para
completar o trabalho sem depender de outros que não fazem parte da
equipe. O modelo de equipe no Scrum é projetado para aperfeiçoar a
flexibilidade, criatividade e produtividade.
Times Scrum entregam produtos de forma iterativa e incremental,

maximizando as entregas feitas em cada sprint.
Entregas incrementais de produto “Pronto” garantem que uma versão

potencialmente funcional do produto do trabalho esteja sempre disponível.

Entrar em Ação De que forma a inspeção pode contribuir de modo prático com o seu
projeto?
Até aqui você aprendeu alguns conceitos importantes sobre o Scrum, Qual o principal benefícios que você enxergaria em seu projeto ao
especialmente sobre como ele foi estruturado e os seus respectivos promover o uso da adaptação?
pilares.
Trazendo você para o mundo real, utilize as questões abaixo, pensando

Modelos para Baixar
em seu próprio projeto e faça um exercício prático da aplicação
do Scrum. Não deixe de ponderar a respeito destas questões, que Clique abaixo e acesse os arquivos modelos especiais deste capítulo.
começarão a transformar seu ponto de vista para o método ágil.
Entre com o seu login e senha e tenha acesso aos modelos de arquivo
Tendo aprendido até o momento os principais fundamentos do Scrum, prontos para sua utilização.
quais são os principais desafios que você acha que encontrará para
a transição para o método ágil, seja nos projetos em sua empresa ou http://www.mindmaster.com.br/livro-scrum/
mesmo para você?
Quais seriam as formas práticas de você promover transparência no seu

projeto e quais são os seus receios?

Capítulo 2
O Time Scrum

• Priorizar os itens do Backlog do Produto de acordo com a
Capítulo 2: O Time Scrum visão do projeto, interesses da companhia e que com as metas e
timing ideais para o projeto;
Agora aprenderemos um pouco mais, especialmente a respeito de um

• Garantir que o Backlog do Produto seja plenamente
Time Scrum, seus papéis, funcionamento e como fazê-lo funcionar.
compreensível e aceito por todos;
O Time Scrum é composto pelo Product Owner, a Equipe de

• Garantir que a Equipe de Desenvolvimento entenda os itens
Desenvolvimento (Também descrito por diversos autores como
do Backlog do Produto no nível necessário;
DevTeam ou Scrum Team) e o Scrum Master .
• Aceitar ou rejeitar o trabalho entregue pelo ScrumTeam;

A Teoria Sobre a Força
• É responsável por medir o retorno sobre o investimento do
O Product Owner projeto, entenda que o custo investido no projeto é uma parte da
estratégia de rentabilização obtida através do lançamento deste
O Product Owner, ou dono do produto, é o projeto. Isso pode ser melhor compreendido por um produto
principal responsável pela entrega do projeto, que será comercializado, por um projeto que trará economias ou
por maximizar o valor do produto, por garantir que evitará desperdícios, produtos que podem trazer benefícios
o retorno sobre o investimento no projeto e intangíveis ou de marketing e outras formas de benefícios que
apoiar, em termos de escopo, o trabalho da garantam o investimento no projeto.
equipe de Desenvolvimento.
• É o senhor do Backlog, ninguém o altera sem o seu
Diversas organizações podem tratar isso de modos distintos, mas consentimento.
algo que jamais muda em sua essência é a importância do PO para as
tomadas de decisão no projeto, sendo que um Product Owner deve ter • Atua como ponto focal entre a equipe do projeto e os
o poder necessário para conduzir o projeto de acordo com a visão e stakeholders (Os clientes) do projeto.
interesses da companhia e patrocinadores do projeto.
O Desafio comum do Product Owner nas Organizações
O Product Owner é a única pessoa responsável por gerenciar o Backlog
do Produto.
O Product Owner é uma pessoa e não um comitê. Algumas empresas
podem tender a delegar esta responsabilidade para um comitê,
Por Exemplo:
porém, para que isso funcione adequadamente, é necessário que
um profissional seja o responsável por assumir tal papel e assim
• Expressar claramente os itens do Backlog do Produto, isto é,
desempenhar os pilares do Scrum nesta função.
aquilo que se deseja que seja criado ou mantido;

Embora o Product Owner possa representar o desejo de um comitê A sinergia resultante aperfeiçoa a eficiência e a eficácia da Equipe de
de demandas no Backlog do Produto, de acordo com a definição do Desenvolvimento como um todo. As Equipes de Desenvolvimento tem as
Scrum aqueles que quiserem uma alteração nas prioridades dos itens seguintes características:
de Backlog devem convencer o Product Owner. Desta forma, esta é uma
das funções de maior responsabilidade em um projeto Scrum. • Eles são auto-organizadas. Ninguém (nem mesmo o Scrum
Master) diz a Equipe de Desenvolvimento como transformar
Para que o Product Owner tenha sucesso, toda a organização deve o Backlog do Produto em incrementos de funcionalidades
respeitar as suas decisões. As decisões do Product Owner são visíveis no potencialmente utilizáveis;
conteúdo e na priorização do Backlog do Produto.
• Equipes de Desenvolvimento são multifuncionais, possuindo
Ninguém deve ter permissão para as prioridades da Equipe de todas as habilidades necessárias, enquanto equipe, para criar o
Desenvolvimento no projeto, e o Time de Desenvolvimento não tem incremento do Produto.
permissão para agir sobre o que outras pessoas disserem ou alterarem
o backlog por si mesmos. • O Scrum não reconhece títulos para os integrantes da
Equipe de Desenvolvimento que não seja o Desenvolvedor,
O ScrumTeam independentemente do trabalho que está sendo realizado pela
pessoa; Não há exceções para esta regra.
O ScrumTeam consiste de
profissionais que realizam o • Individualmente os integrantes da
trabalho de entregar uma versão Equipe de Desenvolvimento podem ter
funcional que potencialmente habilidades
incrementa o produto “Pronto”
ao final de cada Sprint. Somente especializadas e área de
integrantes da Equipe de especialização, mas a
Desenvolvimento criam tais responsabilidade pertence à Equipe
componentes que incrementam o de Desenvolvimento como um todo;
release do produto ao longo dos
sprints. De uma maneira clara, ao • Equipes de Desenvolvimento
longo de cada sprint a equipe de não contém sub-equipes dedicadas
desenvolvimento ou ScrumTeam a domínios específicos de conhecimento, tais
é responsável por desenvolver partes do produtos que funcionam e como teste ou análise de negócios.
agregam valor ao projeto, oferecendo uma plena visão de progresso.
As Equipes de Desenvolvimento são estruturadas e autorizadas pela

organização para organizar e gerenciar seu próprio trabalho, o que é
conhecido como Auto-Organização.

Tamanho do ScrumTeam O Scrum Master trabalhando para o Product Owner
A seguir vamos tratar de um dos temas polêmicos do Scrum. O Scrum Master serve o Product Owner de várias maneiras, incluindo:
Muitas empresas tendem a desrespeitar anos de prática e pesquisa
desvirtuando o que foi desenhado para este framework que é agil. • Encontrando técnicas para o gerenciamento efetivo do Backlog
do Produto;
O tamanho ideal da Equipe de Desenvolvimento é pequeno o suficiente
para se manter ágil e grande o suficiente para completar uma parcela • Tornando a visão do projeto bem clara e objetiva, ainda
significativa do trabalho. esclarecendo dúvidas a respeito dos itens do Backlog do Produto
para a Equipe de Desenvolvimento;
Menos de três integrantes na Equipe de Desenvolvimento diminuem a
interação e resultam em um menor ganho de produtividade. Equipes de • Ensinar o ScrumTeam a criar itens de Backlog do Produto de
desenvolvimento menores podem forma clara, no padrão de qualidade adequado e concisa;
encontrar restrições de habilidades durante a Sprint, gerando uma • Compreender a estratégia de planejamento do Produto no
Equipe de Desenvolvimento incapaz de entregar um incremento ambiente empírico e tornar isso realidade junto ao ScrumTeam;
potencialmente utilizável. Havendo mais de nove integrantes é exigida
muita coordenação. Equipes de Desenvolvimento grandes geram muita • É o guardião dos processos Scrum e age como apoio direto do
complexidade para um processo empírico gerenciar. Os papéis de Product Owner.
Product Owner e de Scrum Master não são incluídos nesta contagem.
• Facilitar os eventos Scrum conforme exigidos ou necessários.
O Scrum Master
O Scrum Master trabalhando para o Scrum Team
O Scrum Master é responsável por
garantir que o Scrum seja entendido e O Scrum Master serve o ScrumTeam de várias maneiras, incluindo:
aplicado. O Scrum Master faz isso para
garantir que o Time Scrum esteja em • Treinar a Equipe em auto-gerenciamento e disciplina de
harmonia com a teoria, práticas e entrega;
regras do Scrum. O Scrum Master é
um líder servidor para o Time Scrum. • Ensinar e liderar a Equipe de Desenvolvimento na criação de
produtos de alto valor; Isso pode incluir a aplicação de técnicas de
Ele é ponto focal entre o ScrumTeam e o restante dos qualidade, desenvolvimento e gerenciamento do tempo
stakeholders Um das suas principais contribuições é a ajuda
na comunicação adequada com o ScrumTeam, evitando quaiser • Remover impedimentos para o progresso do ScrumTeam;
viés de comunicação ou pedidos informais de alteração do product
backlog. • Facilitar os eventos Scrum exigidos ou necessários (Reuniões);

• Treinar a Equipe de Desenvolvimento em ambientes Entrar em Ação

organizacionais nos quais o Scrum não é totalmente adotado e
compreendido.
Agora que você assimilou os papéis e responsabilidades do Scrum,
• Transmitir a visão da estratégia de desenvolvimento do produto qual seria a maior dificuldade de se estabelecer um time Scrum em sua
e as respectivas expectativas do Product Owner equipe?
O Scrum Master trabalhando para a Organização Imagine que você é o Scrum Master do seu time. Pelo o que aprendeu
até agora, qual seria sua principal contribuição para o sucesso do Scrum
O Scrum Master serve a Organização de várias maneiras, incluindo: Team?
• Responsável pela transição para o modelo ágil; Dado que você já domina alguns fundamentos do Scrum, qual seria a
melhor estratégia para você montar uma equipe ágil?
• Liderando e treinando a organização na adoção do Scrum;
Modelos para Baixar
• Planejando implementações Scrum dentro da organização;
• Ajudando funcionários e partes interessadas a compreender e Clique abaixo e acesse os arquivos modelos especiais deste capítulo.
tornar aplicável o Scrum e o desenvolvimento de produto empírico;
• Causando mudanças que aumentam a produtividade do Time prontos para sua utilização.
Scrum; e,
http://www.mindmaster.com.br/livro-scrum/
• Trabalhando com outro Scrum Master para aumentar a eficácia
da aplicação do Scrum nas organizações.

Capítulo 3
Eventos Scrum

Os Sprints tem durações coerentes em todo o esforço de
Capítulo 3: Eventos Scrum desenvolvimento. Uma nova Sprint inicia imediatamente após a
conclusão da Sprint anterior.
As Sprints são compostas por uma reunião de planejamento da

O Scrum se utiliza de uma série de eventos ou cerimônias a de se criar
Sprint (Sprint Planning), reuniões diárias (DailyScrums), o trabalho
um padrão de comunicação e também colocar os seus pilares em ação,
de desenvolvimento, uma revisão da Sprint (Sprint Review) e a
minimizando assim a necessidade de reuniões adicionais ou excessivas.
restrospectiva da Sprint.
O Scrum usa eventos time-boxed, isto é, todo evento tem uma duração
Durante a Sprint:
máxima. Isto garante que uma quantidade adequada de tempo seja
gasta no planejamento evitando desperdício de tempo e garantindo
maior agilidade. • Não são feitas mudanças que podem afetar o objetivo da Sprint;
Além da Sprint, que é um evento base para as demais cerimônias, • A composição do ScrumTeam permanece constante;
cada evento no Scrum é uma oportunidade de inspecionar e adaptar
alguma coisa. Estes eventos são especificamente projetados para • As metas de qualidade não diminuem; e,
permitir uma transparência e inspeção criteriosa. A não inclusão de
qualquer um dos eventos resultará na redução da transparência e da • O escopo pode ser clarificado e renegociado entre o Product
perda de oportunidade para inspecionar e adaptar. Se não aplicar tudo Owner e a Equipe de Desenvolvimento quanto mais for aprendido.
o que o Scrum prescreve em seu framework, em termos de eventos, a
produtividade e agilidade estarão ameaçadas.
Cada Sprint pode ser considerada um projeto com horizonte não
maior que um mês. Como os projetos, as Sprints são utilizadas para
A Teoria Sobre a Força realizar algo. Cada Sprint tem a definição muito clara do que é deve ser
construído, um plano projetado e flexível que irá guiar a construção, o
trabalho e o resultado do produto.
Sprint
De acordo com o Scrum Guide, as Sprints são limitadas a um mês corrido.
Este é o coração do Scrum. É a Sprint, um time-box
Quando o horizonte da Sprint é muito longo, a definição do que será
de normalmente um mês ou menos, durante o qual
construído pode mudar, a complexidade pode aumentar e o risco pode
um produto potencialmente utilizável é criado.
crescer, isso é a essência da entrega contínua e com qualidade do Scrum.
Durante a Sprint fica claro que a parte do produto

Sprints permitem previsibilidade que garante a inspeção e adaptação do
ou incremento deve estar “Pronto”, significando
progresso em direção a meta pelo menos a cada mês corrido. Sprints
que seguiu os critérios mínimos de qualidade para
também limitam o risco ao custo de um mês corrido.
aquela entrega incremental e priorizada .

Cancelamento da Sprint Reunião de Planejamento da Sprint
Uma Sprint pode ser cancelada antes do time-box da Sprint terminar. O trabalho a ser realizado na Sprint é planejado na reunião de
Somente o Product Owner tem a autoridade para cancelar a Sprint, planejamento da Sprint (Sprint Planning). Este plano é criado com o
embora ele (ou ela) possa fazer isso sob influência das partes trabalho colaborativo de todo o Scrum Team.
interessadas, do ScrumTeam ou do Scrum Master.
A reunião de planejamento da Sprint é uma time-box de oito horas para
A Sprint poderá ser cancelada se o objetivo da Sprint se tornar obsoleto. uma Sprint de um mês de duração. Para Sprints menores, este evento
Isto pode ocorrer se a organização mudar sua direção ou se as condições deve ser proporcionalmente menor. Por exemplo, uma Sprint de duas
do mercado ou das tecnologias mudarem. Geralmente a Sprint deve semanas terá uma reunião de planejamento de Sprint de quatro horas.
ser cancelada se ela não faz mais sentido às dadas circunstâncias. No
entanto, devido a curta duração da Sprint, raramente cancelamentos A reunião de planejamento da Sprint consiste em duas partes, cada uma
fazem sentido. sendo uma time-box de metade do tempo de duração da reunião de
planejamento da Sprint. As duas partes da reunião de planejamento da
Quando a Sprint é cancelada, Sprint respondem as seguintes questões, respectivamente:
qualquer item de Backlog
do Produto completado
• O que será entregue como resultado do incremento da próxima
e “Pronto” é revisado. Se
Sprint?
uma parte do trabalho
estiver potencialmente
• Como o trabalho necessário para entregar o incremento será
utilizável, tipicamente o
realizado?
Product Owner o aceita.
Todos os itens de Backlog
do Produto incompletos são re- Parte Um: O que será Pronto nesta Sprint?
estimados e colocados de volta no
Backlog do Produto. O trabalho feito se deprecia Nesta parte, a Equipe de Desenvolvimento trabalha para definir as
rapidamente e deve ser frequentemente re-estimado. funcionalidades que serão desenvolvidas durante a Sprint. O Product
Owner apresenta os itens de Backlog do Produto ordenados para
O cancelamentos de Sprints consome recursos, já que todos tem que se a Equipe de Desenvolvimento e todo o Time Scrum colabora com o
reagrupar em outra reunião de planejamento da Sprint para iniciar outra entendimento do trabalho da Sprint.
Sprint. Cancelamentos de Sprints são frequentemente traumáticos para
o ScrumTeam, e são muito incomuns. Os artefatos de entrada da reunião de planejamento da Sprint são: O
Backlog do Produto ou Product Backlog, o mais recente incremento do
produto, a capacidade projetada da Equipe de Desenvolvimento durante
a Sprint e o desempenho anterior da Equipe de Desenvolvimento ou o
respectivo índice de velocidade.

O número de itens selecionados do Backlog do Produto para a Sprint é O Product Owner pode estar presente durante a segunda parte da
o único trabalho do ScrumTeam nesta reunião. Somente o ScrumTeam reunião de planejamento da Sprint, para clarificar os itens do Backlog
pode avaliar o que pode ser completado ao longo da próxima Sprint. do Produto selecionados e para ajudar nas decisões conflituosas ou
eventuais dúvidas.
Após o ScrumTeam estimar os itens de Backlog do Produto que irá
entregar na Se o ScrumTeam determina que tem excesso ou falta de trabalho, os
itens do Backlog da Sprint podem ser renegociados com o Product
Sprint, o Time Scrum determina a meta da Sprint. Owner. O Scrum Master também pode convidar outras pessoas para
participar desta reunião de forma a fornecer opinião técnica ou de
A meta da Sprint é um objetivo que será conhecido dentro da Sprint domínios específicos.
através da implementação do Backlog do Produto, fornecendo a
informação do que será o output ou produto que será produzido após a No final da reunião de planejamento da Sprint, o Scrum Team deve ser
conclusão do sprint. capaz de explicar ao Product Owner e ao Scrum Master como pretende
trabalhar como equipe auto- organizada para completar o objetivo da
Sprint e criar um incremento previsto.
Parte Dois: Como o trabalho escolhido será Pronto ?
Tendo selecionado o trabalho da Sprint, a Equipe de Desenvolvimento Objetivo ou meta da Sprint

decide como irá construir essas funcionalidades durante a Sprint e
transformá-las em um incremento de produto “Pronto”. Os itens de O objetivo da Sprint dá a Equipe de Desenvolvimento
Backlog do Produto selecionados para a Sprint, junto com o plano de alguma flexibilidade em relação as funcionalidades a
entrega destes itens é chamado de Backlog da Sprint. serem implementadas dentro da Sprint.
O ScrumTeam frequentemente inicia o desenho do sistema e do Conforme o ScrumTeam trabalha, ela mantém
trabalho necessário para converter o Backlog do Produto em um o objetivo em mente, e no caminho de buscar
incremento utilizável do produto. O trabalho pode ser de vários satisfazer o objetivo da Sprint, ela implementa
tamanhos ou esforços. Contudo, o trabalho suficiente é planejado a funcionalidade e a tecnologia.
durante a reunião de planejamento da Sprint pelo ScrumTeam prever
o que esta acredita que poderá fazer durante a próxima Sprint. Com o
Caso o produto entregue seja diferente
trabalho planejado pelo ScrumTeam para os primeiros dias da Sprint,
do esperado pelo Product Onwer, então
este é decomposto em unidades de um dia de duração ou menos até
os membros do ScrumTeam colaboram
o final desta reunião. O ScrumTeam se auto-organiza para realizar
para negociar o escopo do Backlog da Sprint
por todo o trabalho do Backlog da Sprint, tanto durante a reunião de
dentro da Sprint.
planejamento da Sprint quanto no que for necessário durante a Sprint.

Reunião Diária ou Daily Scrum O Scrum Master assegura que o ScrumTeam tenha a reunião, mas
a Equipe de Desenvolvimento é responsável por conduzir a Reunião
A Reunião Diária do Scrum é um evento time-boxed de 15 minutos, para Diária. O Scrum Master ensina a Equipe de Desenvolvimento a manter
que o ScrumTeam possa sincronizar as atividades e criar um plano para a Reunião Diária dentro da time-box de 15 minutos. Esta parte é uma
as próximas 24 horas. das mais importantes a fim de se manter a ordem e obter ganhos de
produtividade.
Esta reunião é facilitada pelo Scrum Master e é feita para inspecionar o
trabalho desde a última Reunião Diária, e prever o trabalho que deverá O Scrum Master reforça a regra de que somente os integrantes do
ser feito antes da próxima Reunião Diária. ScrumTeam participem da Reunião Diária. A Reunião Diária não é uma
reunião de status, é voltada para as pessoas que transformam os itens do
A Reunião Diária é mantida no mesmo horário e local todo dia para Backlog do Produto em um incremento.
reduzir a complexidade. Durante a reunião cada integrante da Equipe de
Desenvolvimento esclarece: Reuniões Diárias melhoram as comunicações, eliminam outras reuniões,
identificam e removem impedimentos para o desenvolvimento, destacam
e promovem rápidas tomadas de decisão, e melhoram o nível de
• O que foi completado desde a última reunião? conhecimento da Equipe de Desenvolvimento. Esta é uma reunião chave
para inspeção e adaptação.
• O que será feito até a próxima reunião?
A Utilização de um quadro Kanban na reunião também pode ser aplicável.
• Quais os impedimentos que estão no caminho?
Revisão da Sprint (Sprint Review)
O ScrumTeam usa a Reunião Diária para avaliar o progresso em direção A Revisão da Sprint é executada no final da Sprint para inspecionar o
ao objetivo da Sprint e para avaliar se o progresso tende para completar o incremento e adaptar o Backlog do Produto se necessário.
trabalho do Backlog da Sprint. A Reunião Diária aumenta a probabilidade
da Equipe de Desenvolvimento atingir o objetivo da Sprint Durante a reunião de Revisão da Sprint o ScrumTeam e as partes
interessadas colaboram sobre o que foi feito na Sprint. Com base nisso
O ScrumTeam pode se encontrar imediatamente após a Reunião Diária, e em qualquer mudança no Backlog do Produto durante a Sprint, os
para re-planejar o restante do trabalho da Sprint. participantes colaboram nas próximas coisas que precisam ser prontas.
Esta é uma reunião informal, e a apresentação do incremento destina-se
a motivar e obter comentários e promover a colaboração.
Todos os dias, a Equipe de Desenvolvimento deve estar apta a esclarecer
para o Product Owner e para o Scrum Master como pretendem trabalhar
em conjunto, como um time auto-organizado, para completar o objetivo e Esta é uma reunião time-boxed de 4 horas de duração para uma Sprint
criar um incremento previsto desejado no restante da Sprint. de um mês. Proporcionalmente um tempo menor é alocado para Sprints
menores. Por exemplo, uma Sprint de duas semanas tem Reuniões de
Revisão de duas horas.

A Reunião de Revisão inclui os seguintes elementos: Retrospectiva da Sprint
A Retrospectiva da Sprint é uma oportunidade para o ScrumTeam

• O Product Owner identifica o que foi “Pronto” e o que não foi
inspecionar a si próprio e criar um plano para melhorias a serem
“Pronto”;
aplicadas na próxima Sprint.
• A Equipe de Desenvolvimento discute o que foi bem durante a

A Retrospectiva da Sprint ocorre depois da Revisão da Sprint e antes da
Sprint, quais problemas ocorreram dentro da Sprint, e como estes
reunião de planejamento da próxima Sprint. Esta é uma reunião time-
problemas foram resolvidos;
boxed de três horas para uma Sprint de um mês. Proporcionalmente um
tempo menor é alocado para Sprints menores.
• A Equipe de Desenvolvimento demonstra o trabalho que está
“Pronto” e responde as
O propósito da Retrospectiva da Sprint é:
questões sobre o incremento;
• Inspecionar como a última Sprint foi em relação as pessoas,
• O Product Owner discute o Backlog do Produto tal como está. relações, processos e ferramentas;
Ele (ou ela) projeta as prováveis datas de conclusão baseado no
progresso até a data; e, • Identificar e ordenar os principais itens que foram bem e as
potenciais melhorias; e,
• O grupo todo colabora sobre o que fazer a seguir, e é assim que • Criar um plano para implementar melhorias no modo que o Time
a Reunião de Revisão da Scrum faz seu trabalho;
Sprint fornece valiosas entradas para a Reunião de Planejamento O Scrum Master encoraja o Time Scrum a melhorar, dentro do processo
da próxima Sprint. do framework do Scrum, o processo de desenvolvimento e as práticas
para fazê-lo mais efetivo e agradável para a próxima Sprint. Durante
cada Retrospectiva da Sprint, o Time Scrum planeja formas de aumentar
a qualidade do produto, adaptando a definição de “Pronto” quando
apropriado.
Ao final da Retrospectiva da Sprint, o Time Scrum deverá ter identificado

melhorias que serão implementadas na próxima Sprint. A implementação
destas melhorias na próxima Sprint é a forma de adaptação à inspeção
que o Time Scrum faz a si próprio. A Retrospectiva da Sprint fornece
um evento dedicado e focado na inspeção e adaptação, no entanto, as
O resultado da Reunião de Revisão da Sprint é um Backlog do Produto melhorias podem ser adotadas a qualquer momento.
revisado que define o provável Backlog do Produto para a próxima
Sprint. O Backlog do Produto pode também ser ajustado completamente Em resumo o Sprint Review foca na revisão do produto e a Retrospectiva
para atender novas oportunidades. na revisão do processo.

Como Usar a Força Agenda JEDI para a reunião de planejamento do sprint
Para ficar ainda mais claro, segue aqui um exemplo real de uma reunião
Como planejar um sprint de planejamento de Sprint, deste modo, você poderá gerenciar o tempo
adequado para sua reunião.
O planejamento de sprint é uma reunião muito importante, e talvez seja
um dos eventos mais importantes no Scrum. Reunião de planejamento do sprint: 13:00 – 17:00 (10 minutos de
intervalo a cada hora)
O propósito da reunião de planejamento do sprint é dar à equipe
informação suficiente para rodarem o projeto por algumas semanas, e
para dar ao product owner confiança e dados suficientes para avaliar o • 13:00 – 13:30. O ScrumMaster dá abertura à reunião e informa a
desempenho do Sprint. respeito da Agenda.
De modo prático temos o seguinte na agenda de reunião de Sprint • O product owner informa e detalha o objetivo do sprint e também
Planning: repassa com o ScrumTema os itens do product backlog. O Product
Owner define o lugar, data e hora da demonstração do produto a
ser desenvolvido naquele Sprint.
Agenda da Reunião de Sprint Planning •13:30 – 15:00. O ScrumTeam estima o tempo e quebra os itens
conforme necessário. O product owner priorizar o backlog com
Participantes: base no grau de importância conforme necessário. Os itens são
esclarecidos. A Definition of Done é repassada para todos.
Data, Hora e Local:
Listar o Objetivo do sprint. • 15:00 – 16:00. O Scrum Team escolhe as estórias a serem incluídas
no sprint. Calculam a velocidade para verificar se o planejamento
Uma lista de membros da equipe (e seus níveis de comprometimento). ficou realista.
Um sprint backlog (= uma lista de estórias inclusas no sprint).

• 16:00 – 17:00. O Scrum Master informar a data, hora e local para
Uma data definida para a conclusão do sprint. o DailyScrum. Se houver tempo ainda é possível usar os últimos
minutos para esclarecimentos de dúvidas.
Data e local definidos para o Daily Scrum.
Esta agenda é apenas um exemplo e não precisa ser executada à risca.
O Scrum Master pode aumentar ou diminuir os tempos conforme necessário.

Entrar em Ação Modelos para Baixar
Se você chegou até aqui é porque já aprendeu a respeito dos eventos Clique abaixo e acesse os arquivos modelos especiais deste capítulo.
do Scrum. Sendo assim, descreva abaixo como você organizaria o seu
primeiro Sprint Planning? Entre com o seu login e senha e tenha acesso aos modelos de arquivo
prontos para sua utilização.
Durante o Sprint Planning o que você faria para garantir um bom
planejamento do sprint eliminando quaisquer viés de comunicação?
Qual o real objetivo do Sprint Planning?
Quem são os responsáveis pela estimativa de cada item do backlog?
Qual a função do Sprint Review?
Porque é preciso realizar a Retrospectiva do Sprint ?

Capítulo 4
Artefatos do Scrum

devem ser feitas no produto nas futuras versões. Os itens do Backlog do

Produto possuem os atributos da descrição, ordem e estimativa (Que é
Capítulo 4: Artefatos do Scrum única e exclusivamente provida pelo ScrumTeam).
O Backlog do Produto é, geralmente, ordenado por valor, risco,

Os artefatos do Scrum são excelentes prioridade e necessidade.
ferramentas de apoio para a prática dos
pilares do Scrum, bem como, apoiar as Os itens no topo da lista ordenada do Backlog do Produto determinam
tomadas de decisões do Scrum Master as atividades de desenvolvimento mais imediatas. Quanto maior a
e Product Owner e prover informações ordem (topo da lista) de um item, mais o item do Backlog do Produto
significativas para o ScrumTeam. deve ser considerado, e mais consenso existe em relação a ele e ao seu
valor.
A Teoria Sobre a Força
Os itens do Backlog do Produto de ordem mais alta (topo da lista) devem
ser mais claros e mais detalhados que os itens de ordem mais baixa.
Backlog do Produto Estimativas mais precisas são feitas com base na maior clareza e maior
Como um (Função), Eu detalhe; Quanto menor a ordem na lista, menor são os detalhes. Os
O Backlog do Produto é uma lista gostaria de (Funcionalidade)
para que (Benefício) itens do Backlog do Produto que irão ocupar o desenvolvimento na
ordenada de tudo que deve ser necessário próxima Sprint são mais refinados, tendo sido decompostos de modo
no produto, e é uma origem única dos que todos os itens possam ser “Prontos” dentro do time-box da Sprint.
requisitos para qualquer mudança a ser feita no produto. O Product Os itens do Backlog do Produto que podem ser “Prontos”
Owner é responsável pelo Backlog do Produto, incluindo seu conteúdo, pela Equipe de Desenvolvimento dentro da Sprint são
disponibilidade e ordenação. considerados como “disponíveis” ou “executáveis”
para seleção na Reunião de Planejamento da
Uma definição teórica a respeito do Product Backlog Sprint.
A rigor, um Backlog do Produto nunca está completo. Os primeiros Requisitos nunca param de mudar, então o
desenvolvimentos apenas estabelecem os requisitos inicialmente Backlog do Produto é um artefato vivo. Mudanças
conhecidos e melhor entendidos. O Backlog do Produto evolui tanto nos requisitos de negócio, condições de mercado ou
quanto o produto e o ambiente no qual ele será utilizado evoluem. tecnologia podem causar mudanças no Backlog do
O Backlog do Produto é dinâmico; mudando constantemente para Produto.
identificar o que o produto necessita para ser mais apropriado,
competitivo e útil. O Backlog do Produto existirá enquanto o produto Múltiplos Times Scrum frequentemente trabalham
também existir. juntos no mesmo produto. O Backlog do Produto
é usado para descrever o trabalho previsto para o
O Backlog do Produto lista todas as características, funções, requisitos, produto. Um atributo do Backlog do Produto para
melhorias e correções (Todos os Bugs) que formam as mudanças que o grupo de itens é então aplicado.
A constante preparação e o cuidado dado ao Backlog do Produto é a Esta informação deve ser transparente para todas as partes
ação de adicionar detalhes, estimativas e ordem aos itens no Backlog interessadas.
do Produto. Este é um processo contínuo em que o Product Owner e o
ScrumTeam colaboram nos detalhes dos itens do Backlog do Produto. Várias artefatos podem ser utilizados, porém os de maior eficácia são os
Durante a preparação do Backlog do Produto, os itens são analisados e gráficos burndown e burnup que demonstram claramente o status do
revisados. Contudo, eles podem ser atualizados a qualquer momento progresso do projeto.
pelo Product Owner ou a critério do Product Owner.
Backlog da Sprint
Preparar o Backlog do Produto é uma atividade de tempo parcial,
durante a Sprint, entre o Product Owner e o ScrumTeam. O Backlog da Sprint é um conjunto de itens do Backlog do Produto
selecionados para a Sprint, visando atingir o objetivo da Sprint. O
Geralmente o ScrumTeam tem o domínio do conhecimento para Backlog da Sprint é a previsão da Equipe de Desenvolvimento sobre qual
realizar a preparação por si próprios. Como e quando a preparação é funcionalidade estará no próximo incremento e do trabalho necessário
considerada pronta é uma decisão do Time Scrum. Esta preparação para entregar a funcionalidade.
usualmente não consome mais de 10% da capacidade do ScrumTeam.
O Backlog da Sprint define qual
O ScrumTeam é responsável por todas as estimativas. O Product Owner trabalho o ScrumTeam realizará
deve influenciar o Time, ajudando no entendimento e eventualmente em para converter os itens do Backlog
esclarecimentos a respeito de Itens de Backlog. do Produto em um incremento
“Pronto” do Produto ao final do
Monitoração do Progresso a Caminho do Objetivo Sprint. O Backlog do Produto torna
visível todo o trabalho que a Equipe
Em projetos ágeis a necessidade de Desenvolvimento identifica como
de constante inspeção e necessário para atingir o objetivo da
monitoração de desempenho é Sprint.
essencial.
O Backlog da Sprint é um plano com
O Product Owner acompanha detalhes suficientes que as mudanças
o total do trabalho realizado em progresso sejam entendidas
especialmente a cada Reunião durante a Reunião Diária. A Equipe de
de Revisão da Sprint. O Product Desenvolvimento modifica o Backlog
Owner compara este valor com da Sprint ao longo de toda a Sprint, e o
o trabalho restante na Reunião Backlog da Sprint vai surgindo durante a Sprint. Este surgimento ocorre
de Revisão da Sprint anterior, quando o ScrumTeam trabalha segundo o plano e aprende mais sobre o
para avaliar o progresso em trabalho necessário para alcançar o objetivo da Sprint.
relação ao que se havia previsto.

Sempre que um novo trabalho é necessário, o ScrumTeam adiciona (post-it e outros) para indicar o andamento dos fluxos de produção
este item ao Backlog da Sprint. Conforme o trabalho é realizado ou em empresas de fabricação em série. Nesses cartões são colocadas
completado, a estimativa do trabalho restante é atualizada. Quando indicações sobre uma determinada tarefa, por exemplo, “para executar”,
elementos do plano são considerados desnecessários, eles são “em andamento” ou “finalizado”.
removidos. Somente o ScrumTeam pode alterar o Backlog da Sprint
durante a Sprint, contudo eles não estão autorizados a retirar nenhum A utilização de um sistema Kanban permite um controle detalhado de
item priorizado pelo Product Owner. produção com informações sobre quando, quanto e o que produzir. O
método Kanban foi inicialmente aplicado em empresas japonesas de
O Backlog da Sprint é altamente visível, uma imagem em tempo real do fabricação em série e está estreitamente ligado ao conceito de “just in
trabalho que a Equipe de Desenvolvimento planeja completar durante a time”. A empresa japonesa de automóveis Toyota foi a responsável pela
Sprint, e pertence exclusivamente à Equipe de Desenvolvimento. introdução desse método devido a necessidade de manter um eficaz
funcionamento do sistema de produção em série.
Monitorando o Progresso da Sprint
A Existência de uma parede cheia de postís é uma das
O ScrumTeam monitora o total do trabalho restante pelo menos a características mais marcantes dos projetos ágeis
cada Reunião Diária. A Equipe de Desenvolvimento acompanha estes
resumos diários e projeta a probabilidade de alcançar o objetivo da O Quadro Scrum pode ser de grande valia para além de controlar o fluxo
Sprint juntamente com o Scrum Master. de trabalho dentro de um Sprint, também fornecer transparência nas
reuniões diárias e também eliminar quaisquer tipos de ansiedade em
O Scrum não considera o relação ao andamento do projeto.
tempo gasto trabalhando
nos itens do Backlog da Você poderá baixar um modelo em powerpoint para pronta utilização na
Sprint. O trabalho restante seção de Downloads.
e a data são as únicas
variáveis que interessam, Incremento
sendo que a data do Sprint
é um compromisso do O incremento é a soma de todos os itens do Backlog do Produto
ScrumTeam que deve ser completados ao final das Sprints. Ao final da Sprint um novo incremento
perseguido sob toda e deve estar “Pronto”, o que significa que deve estar na condição utilizável
qualquer circunstância. e atender a definição de “Pronto” do Time Scrum. Este deve estar na
condição utilizável independentemente do Product Owner decidir por
O Kanban: Uma Excelente forma de se monitorar o andamento liberá-lo realmente ou não para produção. Em resumo é o produto
da Sprint entregue a cada Sprint até se ter a versão final do produto.
Kanban é um termo de origem japonesa e significa literalmente “cartão”

ou “sinalização”. É um conceito relacionado com a utilização de cartões
Definição de “Pronto” ou Definition of Done Para ser mais específico segue um exemplo simples de uma Definition of
Done.
Quando o item do Backlog do Produto ou um incremento é descrito
como “Pronto”, todos devem entender o que o “Pronto” significa.
1. Código concluído ( todos os ‘to dos’ no código devem
Embora, isso varie significativamente de um extremo ao outro para cada estar concluídos)
ScrumTeam, os integrantes devem ter um entendimento compartilhado
do que significa o trabalho estar completo, assegurando a transparência.
Esta é a “Definição de Pronto” para o Time Scrum e é usado para 2. Código comentado, checked e rodando em linha
assegurar quando o trabalho esta completado no incremento do contra a versão mais atualizada
produto.
Em projetos Scrum um item que é considerado Pronto deve estar 3. Revisado em Pares (ou produzido em programação
realmente pronto. em partes) de acordo com os padrões de requisitos e
desenvolvimentos acordados.
A definição de pronto é ponto chave para garantir qualidade do produto
e um dos itens necessários para garantir um processo de entrega à 4. Builds sem nenhum erro
expectativa do Product Owner.
5. Cobertura de Testes superior a 90% no código com
Neste ponto é onde se demonstra a necessidade de
auto-gerenciamento e maturidade por parte dos times testes escritos e passando.
Scrum, uma vez que um item do Product Backlog
jamais será considerado concluído se não estiver 6. Código publicado em um ambiente de testes e com
realmente “Pronto”. resultados de testes com 90% de sucesso ou superior.
A equipe de Desenvolvimento entrega um

7. Testes de Aceitação concluídos com sucesso e aceitos
incremento de funcionalidade do produto
a cada Sprint. Este incremento é utilizável, de acordo com os requisites do produto.
assim o Product Owner pode escolher por
liberá-lo imediatamente. Cada incremento 8. Qualquer Quebra de Build, Mudanças de Configuração
é adicionado a todos os incrementos ou na Documentação devem ser claramente comunicadas.
anteriores e completamente testado,
garantindo que todos os incrementos
funcionam juntos. 9. Documentação relevante ou Diagramas produzidos
devem estar atualizados.
Com um ScrumTeam maduro, é
esperado que a sua definição de 10. Horas restantes registradas para a tarefa devem estar
“Pronto” seja expandida para incluir zeradas e a tarefa fechada.
critérios mais rigorosos de alta
qualidade.

Como Usar a Força demonstrável e testada? Se a resposta for “com 3 pessoas trancados em
uma sala, sem interrupções, levará aproximadamente 4 dias” então a
estimativa inicial é de 12 pontos por estória.
Como gerar um Product Backlog como um Jedi
O importante não é ter estimativas absolutamente precisas (por exemplo,
O product backlog é o ponto nevrálgico do Scrum. É uma lista de dizer que uma estória com 2 pontos deverá gastar 2 dias), mas sim
requisitos, estórias ou desejos. O melhor jeito de fazer um product cumprir o que foi combinado, afinal o Cavaleiro Jedi deve sempre cumprir
Backlog é ter sempre em mente a visão do cliente em relação ao com sua palavra.
produto.
Notas – Você pode informar quaisquer outras informações,
esclarecimentos, referências a outras fontes de informação que possam
O Product Backlog é uma lista de items, que também são conhecidos
contribuir com algo, contanto que sejam breves.
como estórias.
Exemplo de um Product Backlog – Seguem abaixo apenas alguns
Geralmente estas estórias incluem os seguintes campos:
exemplos para demonstrar na prática os itens descritos até aqui.
ID – Uma identificação única, um número sequencia ou código. Cada

estória deve ser única e facilmente identificável. PRODUCT BACKLOG (exemplo)
Nome – Um nome ou descrição curta para a estória. Por exemplo, “Ver

o histórico de acessos”. Claro o suficiente para que o ScrumTeam e o
Product owner entendam sobre o item mencionado e claro o bastante
para distingui-la das demais estórias. Normalmente recomendamos o
uso de de 2 até 10 palavras.
Grau de Importância – Isso é opcional, porém pode dar um certo peso

para a estória. Recomendo utilizar um escala clara, uma pontuação
numérica ou escala de menos importante até muito importante. Toda o
grau de importância deve ser definido pelo product owner.
Estimativa inicial – As estimativas iniciais são providas pelo ScrumTeam,

que proveem quanto tempo é necessário para implementar aquela
estória, se comparada a outras estórias. A unidade é pontos por
estória e geralmente corresponde mais ou menos a “relação homem/
dias” ideal. Esta “métrica inicial” é realizada de modo subjetivo mesmo,
perguntando para o time que em uma situação ideal, sem distúrbios,
qual seria a o número ideal de pessoas para atuar e concluir esta estória
e quanto tempo. Questiona-se ainda, baseado no escopo desta estória,
após quantos dias vocês apresentarão uma implementação pronta,
O Acesso ao Product Backlog • EU GOSTARIA DE (ter algo específico no produto do projeto),
Você pode utilizar várias ferramentas, ou ainda usar uma planilha excel • PARA QUE (Justifique o porque do item específico
compartilhada na rede e até uma planilha no Google Docs por exemplo. no produto).
O Importante é que o aceso seja compartilhado com todo o ScrumTeam
e priorizado devidamente pelo ProductOwner. Segue aqui um exemplo de estória
para você se basear:
Entrar em Ação Como um < Cliente da companhia

área > eu gostaria de < Fazer check
Construindo seu Product Backlog in no site da empresa > para que <
fique menos tempo na fila>
Você pode usar os modelos product backlog que estão na área de
downloads ou mesmo escrever o seu Product Backlog à mão. Se preferir É isso aí, simples assim. As
fazer à mão apenas para iniciar, você vai precisar de um monte de estórias podem ser tão complexas
cartões de anotação e algumas canetas. ou simples como você preferir.
Elas podem estar relacionadas ou
De qualquer modo, seria muito bom ter algumas pessoas que puderem não , detalhadas ou simples. Você
te ajudar neste exercício. A Idéia é você poder contar com pessoas para escolhe a melhor forma de fazer.
te ajudar a escrever o escopo do produto, especialmente o cliente do seu
projeto pode ajudar bastante. Experimente-o com um projeto
que você está prestes a começar.
As regras do exercício são simples, você DEVE escolher o seu projeto, Experimente-o com um projeto pessoal
pode utilizar o projeto do exercício anterior ou mesmo utilizar outro que você está adiando porque está com
projeto, fica a seu critério, porém recomendo seguir os seguintes passos: medo de planejar a entregar. O Ideal seria
fazer algo que poderemos usar ao longo do curso.
Uma estória por cartão ou uma idéia em cada linha da planilha – Um
item para cada idéia que deve constar no product backlog Você vai notar de imediato que o escopo do projeto torna-se mais claro,
que ao invés de se focar em tarefas e encadeamentos de atividades, o
O formato para as suas estórias devem ser escritas da seguinte forma: foco é total no usuário, no que você precisa fazer e naquilo que trará
maior benefício.
• Insira um Título (Este título pode ser repetido para cada

Quando você terminar de escrever tudo , leia cada estória em voz alta
estória, de modo que você pode agrupá-lo depois)
para todos e tente eliminar todas as estórias duplicadas. As discussões
com sua turma serão muito legais. Se for fazer o exercício sozinho, tente
• COMO UM (descrever o papel do usuário), vislumbrar o que você estará entregando ao final do projeto.
Dinâmica de Grupo: Uma boa opção para Qual o ponto mais importante na utilização de
implantação do Scrum em sua equipe de projeto. product Backlog
Assista o vídeo o abaixo e desenvolva esta dinâmica com o time Scrum O que você acha que pode utilizar para monitorar o progresso do projeto
de seu projeto e aprendam juntos de maneira bastante divertida. adequadamente
Pensando em seu projeto, apresente uma definição de pronto que esteja

de acordo com as expectativas do seu Product Owner.
Preencha o Product Backlog e visualize o produto potencialmente

entregável ao final da Sprint
Modelos para Baixar

Clique abaixo e acesse os arquivos modelos especiais deste capítulo.
prontos para sua utilização.

Capítulo 5
Teste seu Conhecimento

Q3. Nós estamos na dúvida entre escolher a Maria ou o Antônio como

Scrum Master para o nosso projeto. Maria conhece bastante sobre
Capítulo 5: Teste seu Conhecimento Scrum, mas ela é muito nova e não possui muita experiência no mercado
de trabalho. Antônio não conhece Scrum, mas tem vários anos de
experiência como Gerente de Projetos. Qual a melhor escolha?
Neste capítulo serão apresentadas 30 questões para você testar o seu
conhecimento ágil com as respostas comentadas ao final do capítulo. A. Maria, pois ela conhece Scrum
e não precisa gerenciar o projeto.
Q1. Imagine uma empresa de desenvolvimento de software que deseja
adotar o método ágil. Será necessário discutir o método Scrum com os B. Maria, pois ela conhece Scrum
clientes e receber sua aprovação antes de antes de usar nos projetos? e irá aprender gerenciamento de
projeto em breve.
A. Sim, pois isso muda a forma de entregar os projetos.
C. Antônio, pois ele conhece
B. Sim, pois isso aumenta o retorno sobre o investimento.
gerenciamento de projetos e não
C. Não, pois é uma forma interna de gerenciar o projeto. precisa saber Scrum.
D. Não, pois o uso do Scrum é sempre uma forma aceitável de D. Antônio, pois ele conhece gerenciamento de projetos e irá
trabalho. aprender Scrum em breve.
Q2. Uma empresa de desenvolvimento de software está pensando em Q4. Considerando que temos um número limitado de recursos, ao
colocar o Diretor de Marketing como Product Owner de um projeto. relacionar a equipe que atuará no projeto Scrum, qual a melhor escolha
Porém ele é novo na empresa e não tem conhecimento técnico. Deve ser entra as seguintes opções: 1) alocar 8 profissionais part-time (algumas
escolhida outra pessoa para a função?
horas por dia) que também atuem em outros projetos da empresa. 2).
Rearranjar a estrutura da empresa para alocar 4 profissionais full-time
A. Sim, pois precisamos de um especialista que possa participar
ativamente com a equipe técnica no trabalho e seja capaz de se (tempo integral) e contratar uma nova pessoa para o time.
comunicar com o cliente.
A. Primeira, pois o custo é menor.
B. Sim, pois precisamos de um especialista que possa participar
ativamente com a equipe técnica no trabalho e que possa fazer
parte do time de desenvolvimento. B. Primeira, pois cria um ambiente mais colaborativo.
C. Não, pois ele não precisa ser um especialista já que vai ter outros C. Segunda, pois aumenta o número de profissionais da
especialistas na equipe. empresa.
D. Não, pois ele não precisa ser um especialista desde que

conheça do negócio. D. Segunda, pois cria um time mais focado.

Q5. Em nosso projeto de desenvolvimento de software, ninguém no Q7. Estamos em um Sprint de requisitos e uma semana já passaou e
time sabe como testar profissionalmente, e nós precisamos disso como menos da metade do product backlog foi concluída. O Product Owner
requisito para o sucesso do projeto. O que devemos fazer? acredita que o melhor a se fazer é começar logo o primeiro Sprint
(Desenvolvimento) com a informação que temos à mão, ao invés de ficar
A. Adicionamos mais um membro ao time, com especialização esperando concluir para que todos os requisitos já estejam coletados.
ou plena expleriência em testes de software. Como Jedi Scrum Master você deve orientar o time. O que eles devem
fazer?
B. Solicitamos ao time de testes, que não faz parte do
A. Sim, é um bom momento para iniciar o primeiro Sprint
ScrumTeam, que cuide disso.
B. Não, nós devemos esperar para completer todo o Product

C. Terceirizamos os testes com uma outra empresa
Backlog antes de dar início aos Sprints
D. Está muito cedo para pensar emu ma tarefa que vai ser feita Q8. Na questão anterior, quem deve ajudar o Scrum Master a tomar a
só final do projeto decisão correta?
A. Product Owner
Q6. Quem deve estimar o volume de trabalho de cada item do backlog?
B. Scrum Master
A. O Product Owner, porque ele tem total responsabilidade pelo
Product Backlog e conhece os itens mais que todo mundo C. Scrum Team
B. O Scrum Master, porque é D. Não há um papel específico para isso, todos devem
dele a responsabilidade de planejar compartilhar a decisão.
tudo
Q9. Estamos prestes a iniciar o primeiro Sprint. Qual deve ser o primeiro
C. O Scrum Team, porque eles passo?
que deverão realizar o trabalho
e eles conhecem a melhor forma A. Finalizar as estimativas dos itens do Product Backlog
de entregar cada um dos itens de
acordo com o que foi requirido. B. Sprint Initiation
D. Todos os papés acima são C. Sprint Startup

responsáveis por estimar o trabalho
D. Sprint Planning
de um modo democrático.
E. Daily Scrum
Q10. Estamos prestes a formar o Sprint Backlog. O ScrumTeam prefere Q12. O Product detectou algumas expectativas novas junto ao cliente.
escolher 100 storypoints para o primeiro Sprint, mas o Product Owner Quando será uma boa hora para inserir isso no Product Backlog?
acredita que eles devem selecioanr pelo menos 150 pontos. Como Jedi
Scrum Master comandante da unidade o que você recomenda eles a A. Assim que for detectado
fazer?
B. Depois do Sprint
A. Todos devem discutir e chegar a um consenso
C. Antes do próximo Sprint
B. Tem que fazer os 100 storypoints
D. No próximo Sprint Planning
C. Tem que fazer os 150 storypoints
Q13. Alguns membros do Scrum Team não estão seguros a respeito
D. O Scrum Master deve decidir do entendimento de alguns itens do Sprint Backlog items. O que o Jedi
Scrum Master deve recomendar?
Q11. Vamos decidir a duração dos Sprints. Algumas pessoas preferem
duas semanas e outros acreditam que o ideal seriam 3 semanas. Todos A. Eles devem tentar entender por si mesmos
esperam uma decisão do Jedi Scrum Master. O que é o certo a fazer?
B. Eles devem entrar em contato com o cliente e pedir maiores
A. Começar com os dois informações
e mudar posteriormente se
necessário. C. Eles devem pedir ao Scrum Master que lhes dê maiores
informações
B. Começar o primeiro Sprint
e então ver quanto tempo sera D. Eles devem perguntar ao Product Owner
necesário
C. O Scrum Master tem a

palavra final neste assunto
D. O Product Owner tem a

palavra final neste assunto

Q14. O ScrumTeam percebe que o volume de trabalho para um dos Q16. Todos estão desapontados com o pequeno número de itens
itens do Sprint Backlog está estimado incorretamente, e o volume completados do primeiro Sprint. The CEO Imperador solicita ao Scrum
atual de trabalho totaliza 130 horas ao invés das 100 horas projetadas Master uma explicação, especialmente sobre quem é o responsável
inicialmente. Eles alertar a seu Scrum Master e pedem por ajuda. Como por isto. O que o nosso herói, o Jedi Scrum Master, deve responder a
um Jedi Scrum Master o que você vai orientá-los a fazer? respeito de quem é o responsável?
A. Eles devem devolver alguns itens ao Product Backlog a fim de A. Os 3 papéis são responsáveis.
manter o Sprint Backlog com o volume projetado de 100 horas.
B. O ScrumTeam é responsável
B. Eles devem pedir mais tempo ao Scrum Master para concluir
este Sprint C. Dois membros do ScrumTeam que estavam doentes durante
o Sprint são os responsáveis.
C. Eles devem pedir ao Product Owner para decidir sobre isso
D. O Product Owner detém a responsabilidade maior
D. Eles não devem fazer nada agora
Q17. Chegou o momento do Sprint Review. O ScrumTeam acredita que
Q15. O ScrumTeam percebe que se focarem nos ultimo 3 itens que estão eles devem apresentar apenas o único item concluído, mas o Product
quase finalizados e estenderem o Sprint por apenas 2 dias, eles estarão Owner entende que eles devem também demonstrar os 3 itens que
aptos a completar ambos. O que o Jedi Scrum Master recomenda a ser estão quase concluídos. Qum está certo?
feito?
A. O ScrumTeam está certo
A. Expandir a duração do Sprint e comepletar os 3 itens
B. O Product Owner está certo,
B. Expandir a duração do Sprint, se o cliente aceitar uma vez que produtos que estão
quse concluídos podem ser
C. Expandir a duração do Sprint, se ambos, Scrum Master e apresentados.
Product Owner, aceitarem.
C. O Product Owner está certo,
D. Não expandir a duração do Sprint sendo assim, o Scrum Team
deverá mencionar durante o Sprint
Review que estes 3 itens não estão
completos ainda, mas estarão no
futuro.

Q18. O novo representante do cliente (aquele que serve de interface Q20. O novo representante do cliente pede ao Chefe do seu
com o Product Owner) solicita ao Chefe do seu Departamento uma Departamente que introduza seu próprio Analista de Testes e agende
reunião urgente com o Gerente do Projeto (O seu projeto). Quem é o uma reunião com eles para discutir alguns tópicos importantes. O que
Gerente do Projeto? deve ser feito? Quem deve comparecer a esta reunião?
A. Product Owner A. Apresentar formalmente a pessoa do ScrumTeam que é

especialista em Testes e enviá-lo a reunião.
B. Scrum Master
B. Apresentar formalmente a pessoa do ScrumTeam que é
C. ScrumTeam especialista em Testes e enviar todo o ScrumTeam à reunião para
trabalhar como uma equipe.
D. Nenhum
C. Não apresentar ninguém como responsável por Testes e
Q19. De acordo com a questão enviar todo o ScrumTeam para a reunião.
anterior, quem deve participar da
reunião com o representante do D. Não apresentar ninguém como responsável por Testes e
cliente? enviar o Product Owner para a reunião.
A. Product Owner Q21. O ScrumTeam pede um dia folga depois de concluir o primeiro
Sprint (Para educação, pesquisa, interagir com outros times...), mas
B. Scrum Master a companhia não aceita. Quem deve discutir isso com a direção da
empresa e pegar sua aprovaçãol?
C. ScrumTeam
A. Product Owner
D. Product Owner e o
Scrum Master B. Scrum Master
E. Todos C. ScrumTeam
D. Todos

Q22. Itens incompletos do Sprint anterior (7 itens de 8) estão retornando Q24. O Scrum Master percebe que o Product Owner está indo a todas
para o Product Backlog. O ScrumTeam entende que estes itens devem as Daily Scrums e questiona o ScrumTeam sobre suas tarefas e dá
ser selecionados para o próximo Sprint, sendo assim, eles podem se direcionamentos específicos diariamente. Como comandante Jedi, o que
manter focados e concluí-los rapidamente. Entretanto, o Product Owner o Scrum Master deve achar disso?
acredita que alguns itens são mais importantes agora. O que devemos
fazer agora? A. Está errado, o Product Owner não
deve participar do Daily Scrum
A. Selecionar os itens pendentes assim o ScrumTeam pode
otimizar a velocidade de entrega. B. Está errado, o Product Owner não
deve falar no Daily Scrum
B. Selecionar os itens pendentes porque não podemos começar
nada bovo anters de concluir todas as tarefas C. Está OK, o Product Owner pode
fazer isso
C. Selecionar os novos itens porque o Product Owner assim
deseja D. Está OK, é recomendado ao
Product Owner dar direcionamento
D. Selecionar novos itens porque é uma boa idéia iniciar um
novo Sprint com itens novos. Q25. O Product Owner percebe que o cliente solicitou mudanças
significativas nos itens do Sprint Backlog que está em andamento. Estas
Q23. O ScrumTeam decidiu cancelar as Daily Scrums até o resto do mudanças alteram completamente os itens. O que o Product Owner
Sprint, para economizer tempo e entregar as coisas mais rapidamente. deve fazer?
Como Jedi Scrum Master, qual sua opinião?
A. Pedir ao ScrumTeam para parar todo o trabalho nestes itens
A. Aceitável, porque a entrega de produtos é nossa prioridade e focar nos demais itens do Sprint Backlog
principal
B. Alterar estes 5 itens no Sprint Backlog tão logo seja possível
B. Incorreto, mas aceitável, uma vez que eles chegaram a
esta decisão e assumem a responsabilidade por suas próprias C. Cancelar o Sprint
entregas.
D. Fazer nada, permitir que o Sprint seja concluído
C. Inaceitável, porque Daily Scrum são requeridas no Scrum normalmente.
D. Inaceitável, porque 15 minutos por dia não impacta em nada

Q26. Nós não conseguimos concluir a maior dos itens do Sprint Backlog Q28. Qual foi nossa estimative inicial para o número de Sprints
nos últimos dois Sprints. O que devemos fazer? requeridos para este projeto?
A. Reduzir a capacidade dos Sprints A. Um
B. Aumentar a duração dos futuros Sprints B. Seis
C. Ambos acima, uma vez que estamos ainda decidindo qual o

C. Nove
tempo correto para um Sprint.
D. Nenhuma das anteriores D. Dezesseis
E. Não é determinado pelo Gráfico
Analise o Burndown Chart abaixo e responda:

Q29. Quantos Sprints provavelmente serão necessaries para completer
o projeto?
A. Provavelmente 9 sprints
B. Provavelmente 10 sprints
C. Provavelmente 11 sprints
D. Provavelmente 14 sprints
Q27. Quantos Sprints foram feitos até agora?
E. Provavelmente 16 sprints
A. Um
B. Seis
C. Nove
D. Dezesseis
E. Não é determinado pelo Gráfico

Q30. Ainda com base no Burndown Chart. O cliente deseja adicionar As Respostas do Assessment
novas funcionalidades com cerca de 400 storypoints para o projeto e
espera que o ScrumTeam lhe forneça uma estimative adicional. Qual é a Para ter acesso às respostas clique no link ou digite
sua idéia? (Dica: Use a resposta da Q29)
entrando com seu login e senha.
A. Provavelmente 4 sprints
B. Provavelmente 5 sprints
C. Provavelmente 7 sprints
D. Provavelmente 9 sprints

Capítulo 6
As Certificações Ágeis

Scrum Alliance
Capítulo 6: As Certificações Ágeis
A Scrum Alliance é uma entidade sem fins lucrativos com o objetivo de
promover a adoção efetiva do Scrum ao redor do mundo.
As certificações basicamente servem para atestar o seu conhecimento
sobre determinado assunto., ou seja, é um diploma que vai atestar que
você sabe usar a força.
Os profissionais com certificações nas áreas em que são especialistas

são mais satisfeitos em suas posições e mais confiantes quanto a suas
habilidades para fazer seus trabalhos do que seus pares. Além de A comunidade de membros da Scrum Alliance já ultrapassa o número de
possuírem uma grande vantagem competitiva no mercado de trabalho. 300 mil pessoas ao redor do globo.
As principais certificações no mundo ágil são regidas basicamente pelos As certificações que são oferecidas pela Scrum Alliance são as seguintes:
3 órgãos a seguir:
Scrum Alliance: CSM (Certified Scrum Master ), CSPO

(Certified Scrum Product Owner) e CSD (Certified Scrum
Developer)
Scrum.Org: PSM (Professional Scrum Master), PSPO

(Professional Scrum Product Owner) e PSD (Professional
Fonte: scrumalliance.org
Scrum Developer)
A certificação da Scrum Alliance que é mais difundida é a CSM (Certified
PMI: ACP (Agile Certified Practitioner)
Scrum Master). Os requisitos para a certificação são:
Cada qual tem suas particularidades como veremos a seguir. • Participar de 2 dias de treinamento em metologias ágeis
• Fazer uma prova on-line de 35 perguntas, onde é exigido o

mínimo de 70% de aproveitamento.
Prós
A dificuldade da prova de certificação é menor se comparado

com a prova da Scrum.Org. São menos questões e um índice de
aproveitamento mínimo menor, facilitando a vida do candidato.
Contras Professional Scrum Product Owner: Atesta os

conhecimentos fundamentais para o profissional que deseja
Como é pré-requisito que o candidato tenha participado de treinamento assumir o papel de Product Owner.
presencial de 2 dias em uma instituição afiliada à Scrum Alliance, o custo
deste certificação é o mais alto de todas e vai variar de acordo com a Dentre as certificações da Scrum. Org, a mais difundida é a PSM.
instituição de treinamento escolhida.
Os requisitos para obter esta certificação são:
Sendo este treinamento presencial de somente 2 dias, normalmente as
instituições apresentam somente o básico do Scrum, sem aprofundar • Fazer uma prova online de 80 questões em um tempo
em casos práticos. de 60 min.
Scrum.Org • O índice de aproveitamento mínimo é de 85%
Prós
A Scrum.Org é também uma entidade sem fins lucrativos, mais voltado
para a disseminação do uso do Scrum no Desenvolvimento de Software. A Scrum.Org não exige que você tenha feito um curso em instituições
credenciadas como a Scrum Alliance. Desta forma as instituições que
ministram estes cursos preparatórios não precisam pagar nenhuma
taxa de credenciamento como acontece com as instituições afiliadas à
Scrum Alliance, fazendo com que o custo do curso seja muito inferior
nos treinamento preparatório para PSM (Scrum.Org) do que para CSM
(Scrum Alliance).
Caso o candidato sinta-se confortável com seu conhecimento sobre

A missão da Scrum.Org é melhorar a prática do desenvolvimento de Scrum, este pode se submeter ao teste sem ter feito curso algum,
software por meio do Scrum. bastando apenas pagar a taxa da prova de US$ 100,00.
As certificações oferecidas pela Scrum.Org são as seguintes: Contras
Professional Scrum Master: Atesta os conhecimentos Prova onde são atestados conhecimentos teóricos sobre o Scrum, mas
fundamentais para o profissional que deseja assumir o papel que não representam que o candidato saiba aplicar na prática.
de Scrum Master.
Professional Scrum Developer: Atesta os conhecimentos

do desenvolvedor de software que está inserido no contexto
de um projeto Scrum.
PMI Os requisitos para se obter a certificação são:
• Comprovar pelo 2.000 horas de experiência em projetos

O Project Management Institute (PMI) é uma instituição internacional obtidas nos últimos 5 anos mais 1.500 horas trabalhadas em
sem fins lucrativos que associa profissionais de gestão de projetos. É projeto ágeis nos últimos 3 anos.
considerada uma das maiores associação do gênero no mundo, e possui
mais 500.000 profissionais certificados em cerca de 170 países. • 21 horas de contato com capacitação formal em
treinamentos ágeis
• Prova presencial, em local aprovado pelo PMI, com 120

questões e 3 horas de duração.
• É necessário um aproveitamento mínimo entre 70% e 80%

para passar.
Prós
O PMI é famoso pela publicação do PMBOK (Project Management Body
A certificação leva a chancela da maior e mais reconhecida instituição de
of Knowledge), que é considerado o guia principal das melhores práticas
gerenciamento de projetos do mundo, que é o PMI.
de gerenciamento de projetos tradicionais. Pautado no PMBOK, a
certificação mais famosa do PMI é o PMP.
Aborda diversas técnicas de metodologia ágil que vão além do Scrum.
Além do PMP, recentemente o PMI tem avançado com sua nova
certificação ágil, a PMI-ACP. Contras
Exige uma experiência anterior de 4.500 horas em projetos, o que pode

impossibilitar a certificação para profissionais iniciantes.
Por abordar diversas técnicas além do Scrum, o nível de conhecimento

exigido é maior dos as demais certificações. Porém a prova não é tão
PMI-ACP é, atualmente, a menos difundida no mundo ágil, talvez por ser rigorosa quanto à Scrum.Org.
a mais recente, porém vem ganhando força a cada dia.
O custo desta certificação também é um pouco alto, pois a prova deve
ser feita presencialmente em um local credenciado pelo PMI.

Capítulo 7
Resumo

Capítulo 7: Resumo
Entregar software de qualidade de um modo ágil, criativo e que atenda as expectativas do cliente não é algo para qualquer um, isso é trabalho para um
verdadeiro Jedi.
Neste livro abordamos conceitos, práticas e highlights importantes sobre o método ágil na prática.
Você deve ter percebido que muitas das coisas aqui ensinadas são oportunidades únicas para você aplicar com seu time no trabalho e ver os resultados
por si mesmo.
A seguir vou listar uma sequencia de itens que resumem os principais conceitos do Scrum.
Se desejar, informo também ao final como aprender tudo isso de modo prático e divertido através de um treinamento online totalmente inovador.
Esperamos que tenha gostado do livro e acima de tudo....
Que a Força Esteja com Você!

1-Product Backlog 2-Release Backlog
O Product Backlog contém uma lista de desejos com todas as User A Meta principal de cada iteração é entregar uma parte importante do
Stories que tornarão o produto especial Product Backlog, conhecida como Release Backlog.
Depois de identificar quais User Stories irão em cada Release, estas User
Stories se tornam parte do Release Backlog
Como um (Função), Eu gostaria

de (Funcionalidade) para que
(Benefício)
Depois as User Stories são estimadas pelo ScrumTeam que fornecem a

Em Scrum funcionalidades são conhecidas como User Stories e são quantidade de tempo em horas para o desenvolvimento de cada item.
escritas sob a perspectiva do usuário final. O Product Owner representa
os usuários clientes e decides quais User Stories ou itens devem ser
priorizados no Product Backlog

3-Sprint Backlog 4-Burndown Charts
A cada Sprint (Um Marco do Projeto de curta duração) uma parte do O Progressso do Projeto é monitorado utilizando o Burndown Chart,
Release Backlog é desenvolvida e uma parte potencialmente entregável, uma das melhores ferramentas para prover visibilidade e garantir o
passível de demonstração, é concluída. progresso do projeto de modo transparente. O Burndown chart provê
uma visão dia-a-dia da medida de progresso e do que ainda está por se
fazer em um referido Sprint.
Linha Tendência
Trabalho Restante
Sprints geralmente tem Geral
Data Estimada de
uma duração de 2 a 4 Ve
Término
loc
semanas, entretanto, ida
de
podem chegar até 30 dias.
A linha vermelha ou Velocidade é a média da

Ao final de cada Sprint você produtividade de cada dia.
deverá ter um produto
plenamente testado com Trabalho restante / Produtividade =
todas as funcionalidade do Dias para Conclusão
Trabalho Restante
Sprint 100% concluídas Mé
dia
de
Pro
du
tiv
ida
de
=2
5h
/Di
a
Saber qual é o ponto do projeto e sua tendência de progresso pode ser

determinante para eventuais ajustes necessários para tornar o projeto
em dia novamente.
5-Daily Standups 6-Sprint Retrospectives
As rápidas reuniões de Daily Standup Meetings (Também conhecidas Depois de cada Sprint uma reunião de Retrospectiva visa ajustar e
como Daily Scrums) garantem que tudo está sob controle e que todos aprimorar os processos.
tem todas as ferramentas que necessitam. É uma ferramenta de
informação essencial para prover um fluxo de informação importante
entre os membros do projeto.
Este é um momento para cada membro do time refletir sobre o que foi
Os membros do ScrumTeam listam o trabalho que eles completaram certo e quais são as oportunidades de melhorias.
desde a última reunião, qualquer impedimento em seu caminho e o que
eles farão até a próxima reunião.
Isto é o que Fiz

O que funcionou?
desde nossa última Isto é o que estou
Estes são os
reunião. planejando fazer O que não
obstáculos que
hoje. funcionou?
encontrei.
O que podemos
melhorar para o
próximo Sprint?
Acima de tudo, o Scrum é um método de desenvolvimento ágil flexível

que oferece melhoria contínua e ajustes para todo o time.

Bibliografia Sugerida Sites interessantes sobre Scrum
www.mindmaster.com.br
www.scrumalliance.org
www.scrum.org
www.mountaingoatsoftware.com
www.agilesoftwaredevelopment.com
www.noop.nl

Glossário do Scrum Sprint Backlog
Scrum Master Lista de histórias a serem desenvolvidas em uma sprint
O ScrumMaster é o responsável por garantir que o Scrum Team se Sprint Planning

orienta pelos valores e práticas do Scrum. O ScrumMaster protege o
time certificando-se de que os membros não se comprometam com A reunião Sprint Planning é onde o Scrum Team e o Product Owner
compromissos além dos que eles conseguem cumprir dentro de um determinam quais funcionalidades e atividades serão realizadas
sprint. no próximo Sprint.
Product Owner Daily Meetings ou StandUp meetings
É uma reunião diária e rápida com todos os membros do Scrum

O Product Owner (dono do produto) representa os interesses de
Team e o Scrum Master
todos os envolvidos (stakeholders), define as funcionalidades do
produto e prioriza os itens de Product Backlog.
Sprint Review
Scrum Team ou Time de Desenvolvimento
Todo Sprint se encerra com a Reunião Sprint Review, onde o Scrum
Team demonstra o incremento de produto potencialmente utilizável.
O Scrum Team constrói o produto que o cliente irá utilizar
Retrospectiva
Product Backlog
É o mecanismo principal para a visibilidade que o Scrum
Lista de desejos que incrementar o produto a ser desenvolvido proporciona a áreas que potencialmente necessitam de
melhorias, transformando-as em resultados.
Sprint
Release
Representa um ciclo de
desenvolvimento do Plano de alto nível sobre o desenvolvimento
produto com timebox pré-
determinado Release Planning
TimeBox Planejamento do projeto em relação a Sprints, processos,

reuniões e etc.
Uma escala de tempo
que restringe o Sprint. Burndown Chart
Tempo dedicado para o
cumprimento do Sprint. O Sprint Burndown Chart é uma representação gráfica do trabalho
restante no Sprint

Como posso aprender isso tudo na Prática
Acesse o site abaixo e descubra uma maneira 100% prática de aprender

Scrum e implementar em seu projeto.
Surpreenda-se com o material e Agilize sua Carreira, Torne-se um

Gerente Agil
Acesse agora: http://www.mindmaster.com.br/curso-scrum-master

Que a Força Esteja com Você!

www.mindmaster.com.br
contato@mindmaster.com.br

Capa e Diagramação por:
Yuri Santos
yupastudio.com

Scrum Definitivo PDF

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Scrum Definitivo PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Scrum

Denis Rodrigues Pedro

Somos uma empresa de treinamento diferenciada, focada em formar profissionais com

Garantimos que ao se empenhar na realização de todas as práticas e na assimilação dos

Que a Força esteja com Você!

Denis Pedro Denisson Vieira

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

em entregas ágeis, atendendo os objetivos de sua empresa, clientes e

Cansados de ver centenas, porque não dizer 1) Os Fundamentos do Scrum

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

O Scrum é um framework estrutural que está sendo usada para

Scrum é um framework dentro do qual pessoas podem tratar e resolver

O Scrum se diferencia de métodos tradicionais por ter as seguintes

• É um conjunto de processos Leve, que não demanda muito esforço

• É relativamente Simples de entender e praticar

• É Extremamente difícil de dominar, apesar de sua simplicidade,

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Teoria do Scrum • Os horários e locais das reuniões podem ser publicados em

Aspectos e informações relevantes do seu projeto devem estar sempre

Esta transparência deve ser promovida por um um padrão comum

• Pode-se utilizar um quadro de tarefas, também como

• Os requisitos da definição de pronto ou definition of

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Um modo de se verificar a adaptação no mundo real é quando situações

O Manifesto Ágil Os nove principios do manifesto ágil

Abaixo seguem os principais itens que foram atualizados no Scrum

O manifesto pode ser encontrado www.agilemanifesto.org em diversos 1 - Mudanças no Objetivo do Sprint

2 - Configuração Time Box Sprint Planning

Estamos descobrindo maneiras melhores de Na versão 2011 a configuração da time-box da reunião de

Através deste trabalho, passamos a valorizar:

Ou seja, mesmo havendo valor nos itens à direita, 5 - Time boxes

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

9 - Daily SCRUM: As 3 Perguntas Alteradas • Time-Box

Foi ainda reforçada a importância do Daily Scrum como • Qualidade Total

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

O princípio da auto-organização A Mitologia Ágil

A equipe deve ser capaz de se organizar e dividir o trabalho.

Não necessariamente o time todo deve ser Sênior, porém a auto-

Como no esporte, os membros da equipe são interdependentes e o Scrum

Times Scrum são auto-organizáveis e multifuncionais. Equipes auto-

Times Scrum entregam produtos de forma iterativa e incremental,

Entregas incrementais de produto “Pronto” garantem que uma versão

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Trazendo você para o mundo real, utilize as questões abaixo, pensando

Quais seriam as formas práticas de você promover transparência no seu

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

• Priorizar os itens do Backlog do Produto de acordo com a

Agora aprenderemos um pouco mais, especialmente a respeito de um

O Time Scrum é composto pelo Product Owner, a Equipe de

• Aceitar ou rejeitar o trabalho entregue pelo ScrumTeam;

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

As Equipes de Desenvolvimento são estruturadas e autorizadas pela

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Tamanho do ScrumTeam O Scrum Master trabalhando para o Product Owner

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

• Treinar a Equipe de Desenvolvimento em ambientes Entrar em Ação

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Todas as imagens, personagens e símbolos, são marcas registradas da LucasFilm Ltd.

Os Sprints tem durações coerentes em todo o esforço de