Ebook SW Scrum 04f PDF

Scrum
Definitivo
As tcnicas e Estratgias
para voc vencer usando
o mtodo gil mais
famoso da Galxia
Denis Rodrigues Pedro

Denisson Vieira
Scrum Definitivo
Mindmaster Treinamentos
Apresentao
Antes de mais nada, permita-nos apresentar a MindMaster adequadamente.
Somos uma empresa de treinamento diferenciada, focada em formar profissionais com
conhecimentos prticos e prontos para o mercado de trabalho. Criada por executivos de larga
experincia no mercado de TI a MindMaster tem se destacado por oferecer os treinamentos
que melhor acompanham as tendncias do mercado. J formamos mais de 4.000 alunos no
Brasil e no exterior e ainda s o comeo.
Somos especializados em treinar nossos alunos para prtica real dos mtodos geis em seu diaa-dia de trabalho, assim como, ajud-los a obterem sua certificao profissional , consolidando
ainda mais suas carreiras.
Se voc est procurando um jeito de aprender Scrum e coloc-lo realmente em prtica, voc
deve continuar a ler este livro e seguir cada uma das dicas apresentadas aqui.
Garantimos que ao se empenhar na realizao de todas as prticas e na assimilao dos
ensinamentos aqui prescritos, voc poder se tornar um verdadeiro Mestre Jedi do Scrum.
Que a Fora esteja com Voc!
Denis Pedro
Denisson Vieira
Co-founder
Co-Founder
Todas as imagens, personagens e smbolos, so marcas registradas da LucasFilm Ltd.
Scrum Definitivo
Introduo
H muito tempo atrs em uma galxia muito, muito distante ...
em entregas geis, atendendo os objetivos de sua empresa, clientes e

sim, da sua equipe, de um modo mais civilizado.
O Mundo mudou e o jeito gil de entregar projetos de qualidade
a nova tendncia. inevitvel resistir, voc no pode subestimar os
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 msica tema de Star Wars,
no mesmo?
Como este Livro est organizado
Realmente este pico filme foi marcante para vrias geraes e us-lo
como tema para nosso Livro foi uma forma de apresentar o mtodo
gil de gerenciar projetos de uma forma ldica e tambm de fcil
compreenso.
Na sequncia dos captulos do Livro voc ir perceber que h algumas

marcaes importantes que te ajudaro a entender melhor os
fundamentos do Scrum, bem como lhe ajudar a praticar e a iniciar a
transio para o mtodo gil.
O Fato do Gerente de Projetos dos dias atuais ter que

praticamente possuir poderes especiais para liderar projetos
cada vez mais complexos, por certo exige que ele se
transforme em um verdadeiro Jedi.
Cansados de ver centenas, porque no dizer
milhares, de profissionais que ao procurar um
jeito de aprender o Scrum para aplicar em
seus projetos passam horas a fio
no Google, apenas fazendo
uma caa implacvel
a todo e qualquer
material disponvel para
download, sem um norte
ou linha de raciocnio lgico
que o ensine os verdadeiros
caminhos da Fora, a forma
elegante de estruturar projetos
importante que voc absorva cada um dos contedos aqui

relacionados, bem como, pratique cada um dos exerccios.
O Livro est dividido em 7 Captulos:
1)
Os Fundamentos do Scrum
2)
O Time Scrum
3)
Eventos do Scrum
4)
Artefatos do Scrum
5)
Testes de Conhecimento
6)
Certificaes Scrum
7) Resumo
Scrum Definitivo
Nos primeiros 4 captulos voc ir encontrar as seguintes sees:
A Teoria Sobre a Fora

Nesta seo sero descritos fundamentos bsicos que voc deve
aprender para assimilar de uma vez por todas o framework Scrum e
suas caractersticas principais.
Aqui sero descritos os processos, eventos, papis e responsabilidades
do mtodo gil.
Como Usar a Fora

Nesta seo ser apresentada qual a melhor forma de usar a fora na
medida certa e quais os benefcios reais de aplicabilidade de cada evento
do Scrum. Afinal, de nada adianta voc todo o conhecimento sobre a
Fora e no saber qual a melhor forma de aplica-la nos seus projetos.
Entrar em Ao
a seo onde voc colocar seus conhecimentos de Scrum na Prtica.
Aprendendo desde a iniciar a transio para o mtodo gil em sua
empresa at a transformar um projeto regular para o mtodo gil.
Voc ser desafiado a vencer desafios especficos sobre Scrum e ao
mesmo tempo verificar o seu progresso como profissional
Material para Baixar

Estaro a sua disposio uma srie de modelos de documento para
download. Embora muitos sigam a linha de que um bom Jedi faz o seu
prprio Lightsaber, entendemos que ajudar voc com material de apoio
apenas mais uma forma de ajud-lo a compreender como colocar o
Scrum na vida real. Voc no apenas poder baixar os arquivos, mas
tambm ser instrudo sobre como utiliz-los.
Scrum Definitivo
Captulo 1
Os Fundamentos do Scrum
Scrum Definitivo
Captulo 1: Os Fundamentos do Scrum

De acordo com o Scrum Guide, o Scrum um framework para
desenvolver e manter produtos complexos. Este livro apresenta a
definio do Scrum, seus respectivos papis, eventos, artefatos e as
regras. Uma abordagem bastante objetivo seguir, explicando de modo
claro os conceitos e oferecendo ainda oportunidades de prtica.

O que o Scrum?
Scrum um framework dentro do qual pessoas podem tratar e resolver
problemas complexos de modo adaptativo, enquanto procuram
entregar produtos com o mais alto valor possvel do mais produtivo e
criativo possvel, sempre visando a satisfao do cliente.
O Scrum um framework estrutural que est sendo usada para

gerenciar o desenvolvimento de produtos complexos desde o incio de
1990. Scrum no um processo ou uma tcnica para construir produtos;
em vez disso, um framework dentro do qual voc pode empregar
vrios processos ou tcnicas. O Scrum deixa claro a eficcia relativa
das prticas de gerenciamento e desenvolvimento de produtos, de
modo que voc possa melhor-las. A Melhoria contnua passa a ser seu
companheiro constante.
Framework Scrum
O framework Scrum consiste nas equipes do Scrum associadas a papis,
eventos, artefatos e regras. Cada componente dentro do framework
serve a um propsito especfico e essencial para o uso e sucesso do
Scrum.
Neste livro vamos mencionar algumas ferramentas e tcnicas do Scrum.
Existem diversas estratgias especficas para o uso do framework
Scrum e algumas so descritas em outros treinamentos especficos da
MindMaster.
O Scrum se diferencia de mtodos tradicionais por ter as seguintes

caractersticas:
um conjunto de processos Leve, que no demanda muito esforo
ou ferramentas pesadas para sua prtica
relativamente Simples de entender e praticar
Extremamente difcil de dominar, apesar de sua simplicidade,
o jeito de pensar gil fora o profissional a abrir mo de diversos
conceitos enraizados pelos mtodos tradicionais e o fora a pensar
em qualidade e entrega contnua. Esta transio no tem de ser
dolorosa e por meio da prtica possvel perceber rapidamente os
seus benefcios.
Scrum Definitivo
Teoria do Scrum

Os horrios e locais das reunies podem ser publicados em
quadro de informaes do projeto
O Scrum foi fundamentado nas teorias empricas de controle de

processo, ou empirismo.

Um Burndown Chart pode ser apresentado para indicar
o progresso e avano do sprint (T ficando curioso com tanta
informao nova?)
O empirismo afirma que o conhecimento vem da experincia e

de tomada de decises baseadas no que conhecido. O Scrum
emprega uma abordagem iterativa e incremental para aperfeioar a
previsibilidade e o controle de riscos.
Os 3 Pilares do Scrum
Trs pilares apiam a implementao de controle de processo emprico:
transparncia, inspeo e adaptao.

Um quadro com as datas
dos releases

E tantas outras formas de
transparncia que puderem ser
empregadas no dia-a-dia do seu
projeto que especialmente faam
a diferena para sua organizao.
Transparncia
Aspectos e informaes relevantes do seu projeto devem estar sempre
visveis e claros para todos os participantes do projeto. Os responsveis
pelos resultados do projeto tem a solene responsabilidade de manter
uma comunicao clara e promover constantemente a transparncia.
Esta transparncia deve ser promovida por um um padro comum
de apresentar as informaes 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, tambm como
conhecido como Kanban (ser detalhado mais a frente) para
apresentar a situao real do Product Backlog (Calma, voc j vai
aprender mais sobre isso :)

Os requisitos da definio de pronto ou definition of
done (Isso demais) deve ser compartilhada com toda equipe,
especialmente com aqueles que recebero o produto do projeto.
Scrum Definitivo
Inspeo
Adaptao
Os profissionais do time Scrum devem, frequentemente, inspecionar os

artefatos Scrum e o progresso do projeto a fim de detectar prontamente
indesejveis variaes. Esta inspeo,no deve no entanto, ser to
freqente que atrapalhe a prpria execuo das tarefas.
As inspees quando realizadas de forma diligente, sem exageros, por
profissionais especializados no trabalho de garantia de qualidade so
normalmente as que obtm melhores resultados.
A adaptao um dos pilares mais importantes do Scrum. Atravs deste

prisma de tomada de ao, o projeto passa a ter mais foco na qualidade de
entrega do produto do que normalmente ocorre em projetos tradicionais.
Um modo de se verificar a adaptao no mundo real quando situaes
imprevistas acontecem na rotina do projeto e as datas acordadas junto
aos nossos clientes ou mesmo os requisitos no mudam.
Por exemplo:
Por exemplo:

A atuao de Testers ou Analistas de Testes em seu projeto
por certo podem contribuir demais com a inspeo da qualidade
de seu projeto, dado o nvel de especializao deste profissional.

de suma importncia que voc mensure os nveis de
qualidade do seu projeto, por exemplo, documentando e
categorizando os bugs, que sero parte importante do dia-a-dia
dos sprints que se seguiro frente.

Uma outra forma de promover a inspeo no seu projeto.
Ao iniciar a codificao de um projeto tenha em mente o uso
de tcnicas como o Test Driven Development e bibliotecas que
o ajudem a rodar os testes unitrios e identificar a respectiva
cobertura de cdigo, isto , as classes de seu cdigo podem e
devem ser testados unitariamente e por meio de ferramentas
prticas (e.g.: Sonar para projetos Java ou Ant para projetos .Net)
possvel mensurar a inspeo atravs de testes unitrios.
Outro exemplo a aplicao
de integrao contnua para
evitar problemas no build
da sua aplicao, isto , na
estruturao do seu ambiente
de desenvolvimento.
Se um Analista de Testes determina que um ou mais aspectos do

produto que est sendo desenvolvido sofreu algum tipo de desvio para
fora dos limites aceitveis, e que o produto resultado ser inaceitvel, o
processo de desenvolvimento ou o prprio produto do projeto deve ser
prontamente ajustado. O ajuste deve ser realizado o mais breve possvel
para minimizar mais desvios. Aqui quando muitos alunos percebem
a diferena do Scrum, pois embora haja uma certa liberdade com o
compromisso da Auto-organizao das equipes, ao identificar quaisquer
desvios a equipe tem que se empenhar e adaptar-se s mudanas e
eventuais desafios.
Dicas Importantes:
O Scrum oferece quatro oportunidades formais para promover a
transparncia, inspeo e adaptao. Mais adiante no livro voc ter
mais detalhes, porm estes sos os eventos onde voc ir aplicar os
pilares do Scrum.
Reunio de planejamento da Sprint (O famoso Sprint Planning)
Reunio diria (Daily Scrum ou Standup Meetings)
Reunio de reviso da Sprint (Tambm conhecida como Sprint
Review)
Retrospectiva da Sprint
Scrum Definitivo
O Manifesto gil
O Manifesto gil o marco da criao de um jeito novo de se
desenvolver produtos. Uma nova forma focada exclusivamente em
resultados e alta qualidade.
O manifesto pode ser encontrado www.agilemanifesto.org em diversos
idiomas.
Manifesto para Desenvolvimento gil de Software
Os nove principios do manifesto gil

Abaixo seguem os principais itens que foram atualizados no Scrum
Guide 2013 pelo Scrum.org. Voc poder baixar o guia e os contedos
adicionais do Guia atravs do nosso site.
1 - Mudanas no Objetivo do Sprint
O texto que dizia que no so feitas mudanas que afetem o
objetivo da Sprint, foi mudado para o que diz que no so feitas
mudanas que possam por em perigo o objetivo da Sprint.
2 - Configurao Time Box Sprint Planning
Estamos descobrindo maneiras melhores de

desenvolver software, fazendo-o ns mesmos e
ajudando outros a fazerem o mesmo.
Atravs deste trabalho, passamos a valorizar:
Indivduos e interaes mais que processos e
ferramentas
Software em funcionamento mais que documentao
abrangente
Colaborao com o cliente mais que negociao de
contratos
Responder a mudanas mais que seguir um plano
Ou seja, mesmo havendo valor nos itens direita,
valorizamos mais os itens esquerda.
Na verso 2011 a configurao da time-box da reunio de

planejamento da Sprint era de 8 horas cravadas, j na verso 2013
o texto trs um no mximo 8 horas
3 - Transparncia dos Artefatos
H um reforo agora que os artefatos precisam ser transparentes
para que todos tenham o mesmo entendimento dos artefatos.
4 - Participantes Sprint Planning
As questes que precisam ser respondidas ao final do
planejamento da Sprint ganharam um novo item, o que deixa
explicito que o Time precisa definir o Objetivo da Sprint.
5 - Time boxes
Foi deixado claro que os timeboxes so tempos mximos. O nico
timebox que no pode ser encurtado o Sprint; os demais (daily,
review e retrospectiva) podem ser finalizados, caso o seu propsito
seja alcanado antecipadamente.
Scrum Definitivo
Alm disso, foi deixado claro que, no final do sprint, no Sprint

Review, o time colabora nos prximos itens que poderiam ser
priorizados para otimizar o valor sendo entregue
6 - Equipe de Desenvolvimento
A regra que dizia: A composio do Time de Desenvolvimento
permanece constante foi retirada.
7 - Formato Reunio de Sprint Planning
O formato da reunio de planejamento da Sprint na verso 2011
era de duas partes, onde na parte 1 era definido o que seria feito
na prxima Sprint, e na parte 2 o Time definia como seria feito.
Agora os autores mudaram para uma reunio s, com apenas
uma parte, mas dividida em dois tpicos onde o o que e o como
sero definidos.
8 - Participantes Sprint Planning
Os autores agora sugerem que os participantes desta cerimnia
incluem o Time Scrum e os Stakeholders chaves convidados
10
Nossa maior prioridade satisfazer o cliente atravs da entrega

antecipada e continua de software com valor.
Acomodar mudanas de requisitos mesmo que seja ao final do
desenvolvimento. Processos geis aproveitam as mudanas para
dar vantagem competitiva ao cliente.
Entregar software funcionando frequentemente, o mais rpido
possvel.
Pessoas de negcios e desenvolvimento devem trabalhar juntos
diariamente durante todo o projeto.
Criar projetos rodeado de indivduos motivados, d-lhes o
ambiente e suporte necessrios, e estabelea confiana para que
o trabalho seja feito.
Valores do SCRUM
Foco na Entrega
Transparncia
9 - Daily SCRUM: As 3 Perguntas Alteradas
Time-Box
Foi ainda reforada a importncia do

Daily Scrum como
atividade de planejamento, com foco em alcanar a meta da
iterao. As trs perguntas fundamentais do Daily Scrum foram
modificadas para:
Qualidade Total
O que fiz ontem que ajudou o time a atingir a meta

do sprint?
O que vou fazer hoje para ajudar o time a atingir a meta
do sprint?
Existe algum impedimento que no permita a mim ou ao
time atingir a meta do sprint?
Trabalho em Equipe
Comunicao Constante
Comprometimento
AutoGerenciamento
Trazer tona os problemas
Scrum Definitivo
11
O princpio da auto-organizao
A Mitologia gil
Este princpio um dos mais difceis para a transio ao mtodo gil,

pois demanda confiana na equipe e por outro lado, a responsabilidade
dos indivduos para com as entregas comprometidas.
Juntamente com o Scrum surgem diversas desconfianas, que na maioria

das vezes se transformaram em mitologia em relao ao mtodo gil,
isto , mais do que preconceitos, so mitos gerados por profissionais que
desconhecem o Scrum ou temem sua aplicao prtica:
A maioria dos profissionais que atuam em mtodos tradicionais

desconfiam do pleno funcionamento deste princpio, porm, se no
aplicado, no h Scrum, pois a equipe tem um papel fundamental na
conduo dos sprints e a sua atuao independente e responsvel o
fator de sucesso que o projeto precisa.
A equipe deve ser capaz de se organizar e dividir o trabalho.

No necessariamente o time todo deve ser Snior, porm a autoorganizao requer comprometimento e responsabilidade desde o
primeiro dia de projeto.
Como no esporte, os membros da equipe so interdependentes e o Scrum
Master far todo o possvel para manter a auto-organizao, fator chave
para o sucesso do projeto.
Times Scrum so auto-organizveis e multifuncionais. Equipes autoorganizveis 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 competncias necessrias para
completar o trabalho sem depender de outros que no fazem parte da
equipe. O modelo de equipe no Scrum projetado para aperfeioar 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 verso
potencialmente funcional do produto do trabalho esteja sempre disponvel.
Scrum Definitivo
12
Entrar em Ao
De que forma a inspeo pode contribuir de modo prtico com o seu

projeto?
At aqui voc aprendeu alguns conceitos importantes sobre o Scrum,

especialmente sobre como ele foi estruturado e os seus respectivos
pilares.
Qual o principal benefcios que voc enxergaria em seu projeto ao

promover o uso da adaptao?
Trazendo voc para o mundo real, utilize as questes abaixo, pensando

em seu prprio projeto e faa um exerccio prtico da aplicao
do Scrum. No deixe de ponderar a respeito destas questes, que
comearo a transformar seu ponto de vista para o mtodo gil.
Tendo aprendido at o momento os principais fundamentos do Scrum,
quais so os principais desafios que voc acha que encontrar para
a transio para o mtodo gil, seja nos projetos em sua empresa ou
mesmo para voc?
Modelos para Baixar

Clique abaixo e acesse os arquivos modelos especiais deste captulo.
Entre com o seu login e senha e tenha acesso aos modelos de arquivo
prontos para sua utilizao.
http://www.mindmaster.com.br/livro-scrum/
Quais seriam as formas prticas de voc promover transparncia no seu

projeto e quais so os seus receios?
Scrum Definitivo
13
Captulo 2
O Time Scrum
Scrum Definitivo
Captulo 2: O Time Scrum

Agora aprenderemos um pouco mais, especialmente a respeito de um
Time Scrum, seus papis, funcionamento e como faz-lo funcionar.
O Time Scrum composto pelo Product Owner, a Equipe de
Desenvolvimento (Tambm descrito por diversos autores como
DevTeam ou Scrum Team) e o Scrum Master .

O Product Owner
O Product Owner, ou dono do produto, o
principal responsvel pela entrega do projeto,
por maximizar o valor do produto, por garantir
o retorno sobre o investimento no projeto e
apoiar, em termos de escopo, o trabalho da
equipe de Desenvolvimento.
Diversas organizaes podem tratar isso de modos distintos, mas
algo que jamais muda em sua essncia a importncia do PO para as
tomadas de deciso no projeto, sendo que um Product Owner deve ter
o poder necessrio para conduzir o projeto de acordo com a viso e
interesses da companhia e patrocinadores do projeto.
O Product Owner a nica pessoa responsvel por gerenciar o Backlog
do Produto.
Por Exemplo:

Expressar claramente os itens do Backlog do Produto, isto ,
aquilo que se deseja que seja criado ou mantido;
14

Priorizar os itens do Backlog do Produto de acordo com a
viso do projeto, interesses da companhia e que com as metas e
timing ideais para o projeto;

Garantir que o Backlog do Produto seja plenamente
compreensvel e aceito por todos;

Garantir que a Equipe de Desenvolvimento entenda os itens
do Backlog do Produto no nvel necessrio;

Aceitar ou rejeitar o trabalho entregue pelo ScrumTeam;

responsvel por medir o retorno sobre o investimento do
projeto, entenda que o custo investido no projeto uma parte da
estratgia de rentabilizao obtida atravs do lanamento deste
projeto. Isso pode ser melhor compreendido por um produto
que ser comercializado, por um projeto que trar economias ou
que evitar desperdcios, produtos que podem trazer benefcios
intangveis ou de marketing e outras formas de benefcios que
garantam o investimento no projeto.

o senhor do Backlog, ningum o altera sem o seu
consentimento.

Atua como ponto focal entre a equipe do projeto e os
stakeholders (Os clientes) do projeto.
O Desafio comum do Product Owner nas Organizaes

O Product Owner uma pessoa e no um comit. Algumas empresas
podem tender a delegar esta responsabilidade para um comit,
porm, para que isso funcione adequadamente, necessrio que
um profissional seja o responsvel por assumir tal papel e assim
desempenhar os pilares do Scrum nesta funo.
Scrum Definitivo
Embora o Product Owner possa representar o desejo de um comit

de demandas no Backlog do Produto, de acordo com a definio do
Scrum aqueles que quiserem uma alterao nas prioridades dos itens
de Backlog devem convencer o Product Owner. Desta forma, esta uma
das funes de maior responsabilidade em um projeto Scrum.
Para que o Product Owner tenha sucesso, toda a organizao deve
respeitar as suas decises. As decises do Product Owner so visveis no
contedo e na priorizao do Backlog do Produto.
Ningum deve ter permisso para as prioridades da Equipe de
Desenvolvimento no projeto, e o Time de Desenvolvimento no tem
permisso para agir sobre o que outras pessoas disserem ou alterarem
o backlog por si mesmos.
O ScrumTeam
O ScrumTeam consiste de
profissionais que realizam o
trabalho de entregar uma verso
funcional que potencialmente
incrementa o produto Pronto
ao final de cada Sprint. Somente
integrantes da Equipe de
Desenvolvimento criam tais
componentes que incrementam o
release do produto ao longo dos
sprints. De uma maneira clara, ao
longo de cada sprint a equipe de
desenvolvimento ou ScrumTeam
responsvel por desenvolver partes do produtos que funcionam e
agregam valor ao projeto, oferecendo uma plena viso de progresso.
15
A sinergia resultante aperfeioa a eficincia e a eficcia da Equipe de

Desenvolvimento como um todo. As Equipes de Desenvolvimento tem as
seguintes caractersticas:
Eles so auto-organizadas. Ningum (nem mesmo o Scrum
Master) diz a Equipe de Desenvolvimento como transformar
o Backlog do Produto em incrementos de funcionalidades
potencialmente utilizveis;
Equipes de Desenvolvimento so multifuncionais, possuindo
todas as habilidades necessrias, enquanto equipe, para criar o
incremento do Produto.
O Scrum no reconhece ttulos para os integrantes da
Equipe de Desenvolvimento que no seja o Desenvolvedor,
independentemente do trabalho que est sendo realizado pela
pessoa; No h excees para esta regra.
Individualmente os integrantes da
Equipe de Desenvolvimento podem ter
habilidades
especializadas e rea de
especializao, mas a
responsabilidade pertence Equipe
de Desenvolvimento como um todo;
Equipes de Desenvolvimento
no contm sub-equipes dedicadas
a domnios especficos de conhecimento,
como teste ou anlise de negcios.
tais
As Equipes de Desenvolvimento so estruturadas e autorizadas pela

organizao para organizar e gerenciar seu prprio trabalho, o que
conhecido como Auto-Organizao.
Scrum Definitivo
16
Tamanho do ScrumTeam
O Scrum Master trabalhando para o Product Owner
A seguir vamos tratar de um dos temas polmicos do Scrum.

Muitas empresas tendem a desrespeitar anos de prtica e pesquisa
desvirtuando o que foi desenhado para este framework que agil.
O Scrum Master serve o Product Owner de vrias maneiras, incluindo:
O tamanho ideal da Equipe de Desenvolvimento pequeno o suficiente

para se manter gil e grande o suficiente para completar uma parcela
significativa do trabalho.
Menos de trs integrantes na Equipe de Desenvolvimento diminuem a
interao e resultam em um menor ganho de produtividade. Equipes de
desenvolvimento menores podem
encontrar restries de habilidades durante a Sprint, gerando uma
Equipe de Desenvolvimento incapaz de entregar um incremento
potencialmente utilizvel. Havendo mais de nove integrantes exigida
muita coordenao. Equipes de Desenvolvimento grandes geram muita
complexidade para um processo emprico gerenciar. Os papis de
Product Owner e de Scrum Master no so includos nesta contagem.
O Scrum Master
O Scrum Master responsvel por
garantir que o Scrum seja entendido e
aplicado. O Scrum Master faz isso para
garantir que o Time Scrum esteja em
harmonia com a teoria, prticas e
regras do Scrum. O Scrum Master
um lder servidor para o Time Scrum.
Ele ponto focal entre o ScrumTeam e o restante dos
stakeholders Um das suas principais contribuies a ajuda
na comunicao adequada com o ScrumTeam, evitando quaiser
vis de comunicao ou pedidos informais de alterao do product
backlog.
Encontrando tcnicas para o gerenciamento efetivo do Backlog

do Produto;
Tornando a viso do projeto bem clara e objetiva, ainda
esclarecendo dvidas a respeito dos itens do Backlog do Produto
para a Equipe de Desenvolvimento;
Ensinar o ScrumTeam a criar itens de Backlog do Produto de
forma clara, no padro de qualidade adequado e concisa;
Compreender a estratgia de planejamento do Produto no
ambiente emprico e tornar isso realidade junto ao ScrumTeam;
o guardio dos processos Scrum e age como apoio direto do
Product Owner.
Facilitar os eventos Scrum conforme exigidos ou necessrios.
O Scrum Master trabalhando para o Scrum Team

O Scrum Master serve o ScrumTeam de vrias maneiras, incluindo:
Treinar a Equipe em auto-gerenciamento e disciplina de
entrega;
Ensinar e liderar a Equipe de Desenvolvimento na criao de
produtos de alto valor; Isso pode incluir a aplicao de tcnicas de
qualidade, desenvolvimento e gerenciamento do tempo
Remover impedimentos para o progresso do ScrumTeam;
Facilitar os eventos Scrum exigidos ou necessrios (Reunies);
Scrum Definitivo
Treinar a Equipe de Desenvolvimento em ambientes

organizacionais nos quais o Scrum no totalmente adotado e
compreendido.
Transmitir a viso da estratgia de desenvolvimento do produto
e as respectivas expectativas do Product Owner
O Scrum Master trabalhando para a Organizao

O Scrum Master serve a Organizao de vrias maneiras, incluindo:
Responsvel pela transio para o modelo gil;
Liderando e treinando a organizao na adoo do Scrum;
Planejando implementaes Scrum dentro da organizao;
Ajudando funcionrios e partes interessadas a compreender e
tornar aplicvel o Scrum e o desenvolvimento de produto emprico;
Causando mudanas que aumentam a produtividade do Time
Scrum; e,
Trabalhando com outro Scrum Master para aumentar a eficcia
da aplicao do Scrum nas organizaes.
17
Entrar em Ao
Agora que voc assimilou os papis e responsabilidades do Scrum,
qual seria a maior dificuldade de se estabelecer um time Scrum em sua
equipe?
Imagine que voc o Scrum Master do seu time. Pelo o que aprendeu
at agora, qual seria sua principal contribuio para o sucesso do Scrum
Team?
Dado que voc j domina alguns fundamentos do Scrum, qual seria a
melhor estratgia para voc montar uma equipe gil?
Modelos para Baixar

Scrum Definitivo
18
Captulo 3
Eventos Scrum
Scrum Definitivo
19
Captulo 3: Eventos Scrum
Os Sprints tem duraes coerentes em todo o esforo de

desenvolvimento. Uma nova Sprint inicia imediatamente aps a
concluso da Sprint anterior.
O Scrum se utiliza de uma srie de eventos ou cerimnias a de se criar

um padro de comunicao e tambm colocar os seus pilares em ao,
minimizando assim a necessidade de reunies adicionais ou excessivas.
As Sprints so compostas por uma reunio de planejamento da

Sprint (Sprint Planning), reunies dirias (DailyScrums), o trabalho
de desenvolvimento, uma reviso da Sprint (Sprint Review) e a
restrospectiva da Sprint.
O Scrum usa eventos time-boxed, isto , todo evento tem uma durao
mxima. Isto garante que uma quantidade adequada de tempo seja
gasta no planejamento evitando desperdcio de tempo e garantindo
maior agilidade.
Alm da Sprint, que um evento base para as demais cerimnias,
cada evento no Scrum uma oportunidade de inspecionar e adaptar
alguma coisa. Estes eventos so especificamente projetados para
permitir uma transparncia e inspeo criteriosa. A no incluso de
qualquer um dos eventos resultar na reduo da transparncia e da
perda de oportunidade para inspecionar e adaptar. Se no aplicar tudo
o que o Scrum prescreve em seu framework, em termos de eventos, a
produtividade e agilidade estaro ameaadas.

Sprint
Durante a Sprint:
No so feitas mudanas que podem afetar o objetivo da Sprint;
A composio do ScrumTeam permanece constante;
As metas de qualidade no diminuem; e,
O escopo pode ser clarificado e renegociado entre o Product
Owner e a Equipe de Desenvolvimento quanto mais for aprendido.
Cada Sprint pode ser considerada um projeto com horizonte no
maior que um ms. Como os projetos, as Sprints so utilizadas para
realizar algo. Cada Sprint tem a definio muito clara do que deve ser
construdo, um plano projetado e flexvel que ir guiar a construo, o
trabalho e o resultado do produto.
Este o corao do Scrum. a Sprint, um time-box

de normalmente um ms ou menos, durante o qual
um produto potencialmente utilizvel criado.
De acordo com o Scrum Guide, as Sprints so limitadas a um ms corrido.

Quando o horizonte da Sprint muito longo, a definio do que ser
construdo pode mudar, a complexidade pode aumentar e o risco pode
crescer, isso a essncia da entrega contnua e com qualidade do Scrum.
Durante a Sprint fica claro que a parte do produto

ou incremento deve estar Pronto, significando
que seguiu os critrios mnimos de qualidade para
aquela entrega incremental e priorizada .
Sprints permitem previsibilidade que garante a inspeo e adaptao do

progresso em direo a meta pelo menos a cada ms corrido. Sprints
tambm limitam o risco ao custo de um ms corrido.
Scrum Definitivo
20
Cancelamento da Sprint
Reunio de Planejamento da Sprint
Uma Sprint pode ser cancelada antes do time-box da Sprint terminar.

Somente o Product Owner tem a autoridade para cancelar a Sprint,
embora ele (ou ela) possa fazer isso sob influncia das partes
interessadas, do ScrumTeam ou do Scrum Master.
O trabalho a ser realizado na Sprint planejado na reunio de

planejamento da Sprint (Sprint Planning). Este plano criado com o
trabalho colaborativo de todo o Scrum Team.
A Sprint poder ser cancelada se o objetivo da Sprint se tornar obsoleto.

Isto pode ocorrer se a organizao mudar sua direo ou se as condies
do mercado ou das tecnologias mudarem. Geralmente a Sprint deve
ser cancelada se ela no faz mais sentido s dadas circunstncias. No
entanto, devido a curta durao da Sprint, raramente cancelamentos
fazem sentido.
Quando a Sprint cancelada,
qualquer item de Backlog
do Produto completado
e Pronto revisado. Se
uma parte do trabalho
estiver potencialmente
utilizvel, tipicamente o
Product Owner o aceita.
Todos os itens de Backlog
do Produto incompletos so reestimados e colocados de volta no
Backlog do Produto. O trabalho feito se deprecia
rapidamente e deve ser frequentemente re-estimado.
O cancelamentos de Sprints consome recursos, j que todos tem que se
reagrupar em outra reunio de planejamento da Sprint para iniciar outra
Sprint. Cancelamentos de Sprints so frequentemente traumticos para
o ScrumTeam, e so muito incomuns.
A reunio de planejamento da Sprint uma time-box de oito horas para

uma Sprint de um ms de durao. Para Sprints menores, este evento
deve ser proporcionalmente menor. Por exemplo, uma Sprint de duas
semanas ter uma reunio de planejamento de Sprint de quatro horas.
A reunio de planejamento da Sprint consiste em duas partes, cada uma
sendo uma time-box de metade do tempo de durao da reunio de
planejamento da Sprint. As duas partes da reunio de planejamento da
Sprint respondem as seguintes questes, respectivamente:
O que ser entregue como resultado do incremento da prxima
Sprint?
Como o trabalho necessrio para entregar o incremento ser
realizado?
Parte Um: O que ser Pronto nesta Sprint?
Nesta parte, a Equipe de Desenvolvimento trabalha para definir as
funcionalidades que sero desenvolvidas durante a Sprint. O Product
Owner apresenta os itens de Backlog do Produto ordenados para
a Equipe de Desenvolvimento e todo o Time Scrum colabora com o
entendimento do trabalho da Sprint.
Os artefatos de entrada da reunio de planejamento da Sprint so: 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.
Scrum Definitivo
O nmero de itens selecionados do Backlog do Produto para a Sprint

o nico trabalho do ScrumTeam nesta reunio. Somente o ScrumTeam
pode avaliar o que pode ser completado ao longo da prxima Sprint.
Aps o ScrumTeam estimar os itens de Backlog do Produto que ir
entregar na
Sprint, o Time Scrum determina a meta da Sprint.
A meta da Sprint um objetivo que ser conhecido dentro da Sprint
atravs da implementao do Backlog do Produto, fornecendo a
informao do que ser o output ou produto que ser produzido aps a
concluso do sprint.
Parte Dois: Como o trabalho escolhido ser Pronto ?
21
O Product Owner pode estar presente durante a segunda parte da

reunio de planejamento da Sprint, para clarificar os itens do Backlog
do Produto selecionados e para ajudar nas decises conflituosas ou
eventuais dvidas.
Se o ScrumTeam determina que tem excesso ou falta de trabalho, os
itens do Backlog da Sprint podem ser renegociados com o Product
Owner. O Scrum Master tambm pode convidar outras pessoas para
participar desta reunio de forma a fornecer opinio tcnica ou de
domnios especficos.
No final da reunio de planejamento da Sprint, o Scrum Team deve ser
capaz de explicar ao Product Owner e ao Scrum Master como pretende
trabalhar como equipe auto- organizada para completar o objetivo da
Sprint e criar um incremento previsto.
Tendo selecionado o trabalho da Sprint, a Equipe de Desenvolvimento

decide como ir construir essas funcionalidades durante a Sprint e
transform-las em um incremento de produto Pronto. Os itens de
Backlog do Produto selecionados para a Sprint, junto com o plano de
entrega destes itens chamado de Backlog da Sprint.
Objetivo ou meta da Sprint
O ScrumTeam frequentemente inicia o desenho do sistema e do

trabalho necessrio para converter o Backlog do Produto em um
incremento utilizvel do produto. O trabalho pode ser de vrios
tamanhos ou esforos. Contudo, o trabalho suficiente planejado
durante a reunio de planejamento da Sprint pelo ScrumTeam prever
o que esta acredita que poder fazer durante a prxima Sprint. Com o
trabalho planejado pelo ScrumTeam para os primeiros dias da Sprint,
este decomposto em unidades de um dia de durao ou menos at
o final desta reunio. O ScrumTeam se auto-organiza para realizar
por todo o trabalho do Backlog da Sprint, tanto durante a reunio de
planejamento da Sprint quanto no que for necessrio durante a Sprint.
Conforme o ScrumTeam trabalha, ela mantm

o objetivo em mente, e no caminho de buscar
satisfazer o objetivo da Sprint, ela implementa
a funcionalidade e a tecnologia.
O objetivo da Sprint d a Equipe de Desenvolvimento

alguma flexibilidade em relao as funcionalidades a
serem implementadas dentro da Sprint.
Caso o produto entregue seja diferente

do esperado pelo Product Onwer, ento
os membros do ScrumTeam colaboram
para negociar o escopo do Backlog da Sprint
dentro da Sprint.
Scrum Definitivo
Reunio Diria ou Daily Scrum

A Reunio Diria do Scrum um evento time-boxed de 15 minutos, para
que o ScrumTeam possa sincronizar as atividades e criar um plano para
as prximas 24 horas.
Esta reunio facilitada pelo Scrum Master e feita para inspecionar o
trabalho desde a ltima Reunio Diria, e prever o trabalho que dever
ser feito antes da prxima Reunio Diria.
A Reunio Diria mantida no mesmo horrio e local todo dia para
reduzir a complexidade. Durante a reunio cada integrante da Equipe de
Desenvolvimento esclarece:
O que foi completado desde a ltima reunio?
O que ser feito at a prxima reunio?
Quais os impedimentos que esto no caminho?
O ScrumTeam usa a Reunio Diria para avaliar o progresso em direo

ao objetivo da Sprint e para avaliar se o progresso tende para completar o
trabalho do Backlog da Sprint. A Reunio Diria aumenta a probabilidade
da Equipe de Desenvolvimento atingir o objetivo da Sprint
O ScrumTeam pode se encontrar imediatamente aps a Reunio Diria,
para re-planejar o restante do trabalho da Sprint.
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
criar um incremento previsto desejado no restante da Sprint.
22
O Scrum Master assegura que o ScrumTeam tenha a reunio, mas

a Equipe de Desenvolvimento responsvel por conduzir a Reunio
Diria. O Scrum Master ensina a Equipe de Desenvolvimento a manter
a Reunio Diria dentro da time-box de 15 minutos. Esta parte uma
das mais importantes a fim de se manter a ordem e obter ganhos de
produtividade.
O Scrum Master refora a regra de que somente os integrantes do
ScrumTeam participem da Reunio Diria. A Reunio Diria no uma
reunio de status, voltada para as pessoas que transformam os itens do
Backlog do Produto em um incremento.
Reunies Dirias melhoram as comunicaes, eliminam outras reunies,
identificam e removem impedimentos para o desenvolvimento, destacam
e promovem rpidas tomadas de deciso, e melhoram o nvel de
conhecimento da Equipe de Desenvolvimento. Esta uma reunio chave
para inspeo e adaptao.
A Utilizao de um quadro Kanban na reunio tambm pode ser aplicvel.
Reviso da Sprint (Sprint Review)

A Reviso da Sprint executada no final da Sprint para inspecionar o
incremento e adaptar o Backlog do Produto se necessrio.
Durante a reunio de Reviso da Sprint o ScrumTeam e as partes
interessadas colaboram sobre o que foi feito na Sprint. Com base nisso
e em qualquer mudana no Backlog do Produto durante a Sprint, os
participantes colaboram nas prximas coisas que precisam ser prontas.
Esta uma reunio informal, e a apresentao do incremento destina-se
a motivar e obter comentrios e promover a colaborao.
Esta uma reunio time-boxed de 4 horas de durao para uma Sprint
de um ms. Proporcionalmente um tempo menor alocado para Sprints
menores. Por exemplo, uma Sprint de duas semanas tem Reunies de
Reviso de duas horas.
Scrum Definitivo
A Reunio de Reviso inclui os seguintes elementos:

O Product Owner identifica o que foi Pronto e o que no foi
Pronto;
A Equipe de Desenvolvimento discute o que foi bem durante a
Sprint, quais problemas ocorreram dentro da Sprint, e como estes
problemas foram resolvidos;
A Equipe de Desenvolvimento demonstra o trabalho que est
Pronto e responde as
questes sobre o incremento;
O Product Owner discute o Backlog do Produto tal como est.
Ele (ou ela) projeta as provveis datas de concluso baseado no
progresso at a data; e,
O grupo todo colabora sobre o que fazer a seguir, e assim que
a Reunio de Reviso da
Sprint fornece valiosas entradas para a Reunio de Planejamento
da prxima Sprint.
O resultado da Reunio de Reviso da Sprint um Backlog do Produto

revisado que define o provvel Backlog do Produto para a prxima
Sprint. O Backlog do Produto pode tambm ser ajustado completamente
para atender novas oportunidades.
23
Retrospectiva da Sprint
A Retrospectiva da Sprint uma oportunidade para o ScrumTeam
inspecionar a si prprio e criar um plano para melhorias a serem
aplicadas na prxima Sprint.
A Retrospectiva da Sprint ocorre depois da Reviso da Sprint e antes da
reunio de planejamento da prxima Sprint. Esta uma reunio timeboxed de trs horas para uma Sprint de um ms. Proporcionalmente um
tempo menor alocado para Sprints menores.
O propsito da Retrospectiva da Sprint :
Inspecionar como a ltima Sprint foi em relao as pessoas,
relaes, processos e ferramentas;
Identificar e ordenar os principais itens que foram bem e as
potenciais melhorias; e,
Criar um plano para implementar melhorias no modo que o Time
Scrum faz seu trabalho;
O Scrum Master encoraja o Time Scrum a melhorar, dentro do processo
do framework do Scrum, o processo de desenvolvimento e as prticas
para faz-lo mais efetivo e agradvel para a prxima Sprint. Durante
cada Retrospectiva da Sprint, o Time Scrum planeja formas de aumentar
a qualidade do produto, adaptando a definio de Pronto quando
apropriado.
Ao final da Retrospectiva da Sprint, o Time Scrum dever ter identificado
melhorias que sero implementadas na prxima Sprint. A implementao
destas melhorias na prxima Sprint a forma de adaptao inspeo
que o Time Scrum faz a si prprio. A Retrospectiva da Sprint fornece
um evento dedicado e focado na inspeo e adaptao, no entanto, as
melhorias podem ser adotadas a qualquer momento.
Em resumo o Sprint Review foca na reviso do produto e a Retrospectiva
na reviso do processo.
Scrum Definitivo
24
Como Usar a Fora
Agenda JEDI para a reunio de planejamento do sprint
Como planejar um sprint
Para ficar ainda mais claro, segue aqui um exemplo real de uma reunio
de planejamento de Sprint, deste modo, voc poder gerenciar o tempo
adequado para sua reunio.
O planejamento de sprint uma reunio muito importante, e talvez seja

um dos eventos mais importantes no Scrum.
O propsito da reunio de planejamento do sprint dar equipe
informao suficiente para rodarem o projeto por algumas semanas, e
para dar ao product owner confiana e dados suficientes para avaliar o
desempenho do Sprint.
De modo prtico temos o seguinte na agenda de reunio de Sprint
Planning:
Agenda da Reunio de Sprint Planning

Participantes:
Data, Hora e Local:
Listar o Objetivo do sprint.
Uma lista de membros da equipe (e seus nveis de comprometimento).
Um sprint backlog (= uma lista de estrias inclusas no sprint).
Uma data definida para a concluso do sprint.
Reunio de planejamento do sprint: 13:00 17:00 (10 minutos de

intervalo a cada hora)
13:00 13:30. O ScrumMaster d abertura reunio e informa a

respeito da Agenda.
O product owner informa e detalha o objetivo do sprint e tambm
repassa com o ScrumTema os itens do product backlog. O Product
Owner define o lugar, data e hora da demonstrao do produto a
ser desenvolvido naquele Sprint.
13:30 15:00. O ScrumTeam estima o tempo e quebra os itens
conforme necessrio. O product owner priorizar o backlog com
base no grau de importncia conforme necessrio. Os itens so
esclarecidos. A Definition of Done repassada para todos.
15:00 16:00. O Scrum Team escolhe as estrias a serem includas
no sprint. Calculam a velocidade para verificar se o planejamento
ficou realista.
16:00 17:00. O Scrum Master informar a data, hora e local para
o DailyScrum. Se houver tempo ainda possvel usar os ltimos
minutos para esclarecimentos de dvidas.
Data e local definidos para o Daily Scrum.
Esta agenda apenas um exemplo e no precisa ser executada risca.

O Scrum Master pode aumentar ou diminuir os tempos conforme necessrio.
Scrum Definitivo
25
Entrar em Ao
Modelos para Baixar
Se voc chegou at aqui porque j aprendeu a respeito dos eventos

do Scrum. Sendo assim, descreva abaixo como voc organizaria o seu
primeiro Sprint Planning?
Durante o Sprint Planning o que voc faria para garantir um bom

planejamento do sprint eliminando quaisquer vis de comunicao?
Qual o real objetivo do Sprint Planning?

Quem so os responsveis pela estimativa de cada item do backlog?
Qual a funo do Sprint Review?
Porque preciso realizar a Retrospectiva do Sprint ?
Scrum Definitivo
26
Captulo 4
Artefatos do Scrum
Scrum Definitivo
27
Captulo 4: Artefatos do Scrum
devem ser feitas no produto nas futuras verses. Os itens do Backlog do

Produto possuem os atributos da descrio, ordem e estimativa (Que
nica e exclusivamente provida pelo ScrumTeam).
O Backlog do Produto , geralmente, ordenado por valor, risco,
prioridade e necessidade.
Os artefatos do Scrum so excelentes

ferramentas de apoio para a prtica dos
pilares do Scrum, bem como, apoiar as
tomadas de decises do Scrum Master
e Product Owner e prover informaes
significativas para o ScrumTeam.
Os itens no topo da lista ordenada do Backlog do Produto determinam

as atividades de desenvolvimento mais imediatas. Quanto maior a
ordem (topo da lista) de um item, mais o item do Backlog do Produto
deve ser considerado, e mais consenso existe em relao a ele e ao seu
valor.

Backlog do Produto
Como um (Funo), Eu
gostaria de (Funcionalidade)
O Backlog do Produto uma lista
para que (Benefcio)
ordenada de tudo que deve ser necessrio
no produto, e uma origem nica dos
requisitos para qualquer mudana a ser feita no produto. O Product
Owner responsvel pelo Backlog do Produto, incluindo seu contedo,
disponibilidade e ordenao.
Uma definio terica a respeito do Product Backlog

A rigor, um Backlog do Produto nunca est completo. Os primeiros
desenvolvimentos apenas estabelecem os requisitos inicialmente
conhecidos e melhor entendidos. O Backlog do Produto evolui tanto
quanto o produto e o ambiente no qual ele ser utilizado evoluem.
O Backlog do Produto dinmico; mudando constantemente para
identificar o que o produto necessita para ser mais apropriado,
competitivo e til. O Backlog do Produto existir enquanto o produto
tambm existir.
O Backlog do Produto lista todas as caractersticas, funes, requisitos,
melhorias e correes (Todos os Bugs) que formam as mudanas que
Os itens do Backlog do Produto de ordem mais alta (topo da lista) devem

ser mais claros e mais detalhados que os itens de ordem mais baixa.
Estimativas mais precisas so feitas com base na maior clareza e maior
detalhe; Quanto menor a ordem na lista, menor so os detalhes. Os
itens do Backlog do Produto que iro ocupar o desenvolvimento na
prxima Sprint so mais refinados, tendo sido decompostos de modo
que todos os itens possam ser Prontos dentro do time-box da Sprint.
Os itens do Backlog do Produto que podem ser Prontos
pela Equipe de Desenvolvimento dentro da Sprint so
considerados como disponveis ou executveis
para seleo na Reunio de Planejamento da
Sprint.
Requisitos nunca param de mudar, ento o
Backlog do Produto um artefato vivo. Mudanas
nos requisitos de negcio, condies de mercado ou
tecnologia podem causar mudanas no Backlog do
Produto.
Mltiplos Times Scrum frequentemente trabalham
juntos no mesmo produto. O Backlog do Produto
usado para descrever o trabalho previsto para o
produto. Um atributo do Backlog do Produto para
o grupo de itens ento aplicado.
Scrum Definitivo
A constante preparao e o cuidado dado ao Backlog do Produto a

ao de adicionar detalhes, estimativas e ordem aos itens no Backlog
do Produto. Este um processo contnuo em que o Product Owner e o
ScrumTeam colaboram nos detalhes dos itens do Backlog do Produto.
Durante a preparao do Backlog do Produto, os itens so analisados e
revisados. Contudo, eles podem ser atualizados a qualquer momento
pelo Product Owner ou a critrio do Product Owner.
Preparar o Backlog do Produto uma atividade de tempo parcial,
durante a Sprint, entre o Product Owner e o ScrumTeam.
Geralmente o ScrumTeam tem o domnio do conhecimento para
realizar a preparao por si prprios. Como e quando a preparao
considerada pronta uma deciso do Time Scrum. Esta preparao
usualmente no consome mais de 10% da capacidade do ScrumTeam.
O ScrumTeam responsvel por todas as estimativas. O Product Owner
deve influenciar o Time, ajudando no entendimento e eventualmente em
esclarecimentos a respeito de Itens de Backlog.
Monitorao do Progresso a Caminho do Objetivo

Em projetos geis a necessidade
de constante inspeo e
monitorao de desempenho
essencial.
O Product Owner acompanha
o total do trabalho realizado
especialmente a cada Reunio
de Reviso da Sprint. O Product
Owner compara este valor com
o trabalho restante na Reunio
de Reviso da Sprint anterior,
para avaliar o progresso em
relao ao que se havia previsto.
28
Esta informao deve ser transparente para todas as partes

interessadas.
Vrias artefatos podem ser utilizados, porm os de maior eficcia so os
grficos burndown e burnup que demonstram claramente o status do
progresso do projeto.
Backlog da Sprint
O Backlog da Sprint um conjunto de itens do Backlog do Produto
selecionados para a Sprint, visando atingir o objetivo da Sprint. O
Backlog da Sprint a previso da Equipe de Desenvolvimento sobre qual
funcionalidade estar no prximo incremento e do trabalho necessrio
para entregar a funcionalidade.
O Backlog da Sprint define qual
trabalho o ScrumTeam realizar
para converter os itens do Backlog
do Produto em um incremento
Pronto do Produto ao final do
Sprint. O Backlog do Produto torna
visvel todo o trabalho que a Equipe
de Desenvolvimento identifica como
necessrio para atingir o objetivo da
Sprint.
O Backlog da Sprint um plano com
detalhes suficientes que as mudanas
em progresso sejam entendidas
durante a Reunio Diria. A Equipe de
Desenvolvimento modifica o Backlog
da Sprint ao longo de toda a Sprint, e o
Backlog da Sprint vai surgindo durante a Sprint. Este surgimento ocorre
quando o ScrumTeam trabalha segundo o plano e aprende mais sobre o
trabalho necessrio para alcanar o objetivo da Sprint.
Scrum Definitivo
Sempre que um novo trabalho necessrio, o ScrumTeam adiciona

este item ao Backlog da Sprint. Conforme o trabalho realizado ou
completado, a estimativa do trabalho restante atualizada. Quando
elementos do plano so considerados desnecessrios, eles so
removidos. Somente o ScrumTeam pode alterar o Backlog da Sprint
durante a Sprint, contudo eles no esto autorizados a retirar nenhum
item priorizado pelo Product Owner.
O Backlog da Sprint altamente visvel, uma imagem em tempo real do
trabalho que a Equipe de Desenvolvimento planeja completar durante a
Sprint, e pertence exclusivamente Equipe de Desenvolvimento.
Monitorando o Progresso da Sprint

O ScrumTeam monitora o total do trabalho restante pelo menos a
cada Reunio Diria. A Equipe de Desenvolvimento acompanha estes
resumos dirios e projeta a probabilidade de alcanar o objetivo da
Sprint juntamente com o Scrum Master.
O Scrum no considera o
tempo gasto trabalhando
nos itens do Backlog da
Sprint. O trabalho restante
e a data so as nicas
variveis que interessam,
sendo que a data do Sprint
um compromisso do
ScrumTeam que deve ser
perseguido sob toda e
qualquer circunstncia.
O Kanban: Uma Excelente forma de se monitorar o andamento

da Sprint
29
(post-it e outros) para indicar o andamento dos fluxos de produo

em empresas de fabricao em srie. Nesses cartes so colocadas
indicaes sobre uma determinada tarefa, por exemplo, para executar,
em andamento ou finalizado.
A utilizao de um sistema Kanban permite um controle detalhado de
produo com informaes sobre quando, quanto e o que produzir. O
mtodo Kanban foi inicialmente aplicado em empresas japonesas de
fabricao em srie e est estreitamente ligado ao conceito de just in
time. A empresa japonesa de automveis Toyota foi a responsvel pela
introduo desse mtodo devido a necessidade de manter um eficaz
funcionamento do sistema de produo em srie.
A Existncia de uma parede cheia de posts uma das

caractersticas mais marcantes dos projetos geis
O Quadro Scrum pode ser de grande valia para alm de controlar o fluxo
de trabalho dentro de um Sprint, tambm fornecer transparncia nas
reunies dirias e tambm eliminar quaisquer tipos de ansiedade em
relao ao andamento do projeto.
Voc poder baixar um modelo em powerpoint para pronta utilizao na
seo de Downloads.
Incremento
O incremento a soma de todos os itens do Backlog do Produto
completados ao final das Sprints. Ao final da Sprint um novo incremento
deve estar Pronto, o que significa que deve estar na condio utilizvel
e atender a definio de Pronto do Time Scrum. Este deve estar na
condio utilizvel independentemente do Product Owner decidir por
liber-lo realmente ou no para produo. Em resumo o produto
entregue a cada Sprint at se ter a verso final do produto.
Kanban um termo de origem japonesa e significa literalmente carto

ou sinalizao. um conceito relacionado com a utilizao de cartes
Scrum Definitivo
30
Definio de Pronto ou Definition of Done
Para ser mais especfico 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.
Embora, isso varie significativamente de um extremo ao outro para cada
ScrumTeam, os integrantes devem ter um entendimento compartilhado
do que significa o trabalho estar completo, assegurando a transparncia.
Esta a Definio de Pronto para o Time Scrum e usado para
assegurar quando o trabalho esta completado no incremento do
produto.
1. Cdigo concludo ( todos os to dos no cdigo devem

estar concludos)
2. Cdigo comentado, checked e rodando em linha
contra a verso mais atualizada
Em projetos Scrum um item que considerado Pronto deve estar

realmente pronto.
3. Revisado em Pares (ou produzido em programao

em partes) de acordo com os padres de requisitos e
desenvolvimentos acordados.
A definio de pronto ponto chave para garantir qualidade do produto

e um dos itens necessrios para garantir um processo de entrega
expectativa do Product Owner.
4.
Neste ponto onde se demonstra a necessidade de

auto-gerenciamento e maturidade por parte dos times
Scrum, uma vez que um item do Product Backlog
jamais ser considerado concludo se no estiver
realmente Pronto.
A equipe de Desenvolvimento entrega um
incremento de funcionalidade do produto
a cada Sprint. Este incremento utilizvel,
assim o Product Owner pode escolher por
liber-lo imediatamente. Cada incremento
adicionado a todos os incrementos
anteriores e completamente testado,
garantindo que todos os incrementos
funcionam juntos.
Com um ScrumTeam maduro,
esperado que a sua definio de
Pronto seja expandida para incluir
critrios mais rigorosos de alta
qualidade.
Builds sem nenhum erro
5. Cobertura de Testes superior a 90% no cdigo com

testes escritos e passando.
6. Cdigo publicado em um ambiente de testes e com
resultados de testes com 90% de sucesso ou superior.
7. Testes de Aceitao concludos com sucesso e aceitos
de acordo com os requisites do produto.
8. Qualquer Quebra de Build, Mudanas de Configurao
ou na Documentao devem ser claramente comunicadas.
9. Documentao relevante ou Diagramas produzidos
devem estar atualizados.
10. Horas restantes registradas para a tarefa devem estar
zeradas e a tarefa fechada.
Scrum Definitivo
Como Usar a Fora

Como gerar um Product Backlog como um Jedi
O product backlog o ponto nevrlgico do Scrum. uma lista de
requisitos, estrias ou desejos. O melhor jeito de fazer um product
Backlog ter sempre em mente a viso do cliente em relao ao
produto.
O Product Backlog uma lista de items, que tambm so conhecidos
como estrias.
Geralmente estas estrias incluem os seguintes campos:

ID Uma identificao nica, um nmero sequencia ou cdigo. Cada
estria deve ser nica e facilmente identificvel.
31
demonstrvel e testada? Se a resposta for com 3 pessoas trancados em

uma sala, sem interrupes, levar aproximadamente 4 dias ento a
estimativa inicial de 12 pontos por estria.
O importante no ter estimativas absolutamente precisas (por exemplo,
dizer que uma estria com 2 pontos dever gastar 2 dias), mas sim
cumprir o que foi combinado, afinal o Cavaleiro Jedi deve sempre cumprir
com sua palavra.
Notas Voc pode informar quaisquer outras informaes,
esclarecimentos, referncias a outras fontes de informao que possam
contribuir com algo, contanto que sejam breves.
Exemplo de um Product Backlog Seguem abaixo apenas alguns
exemplos para demonstrar na prtica os itens descritos at aqui.
PRODUCT BACKLOG (exemplo)
Nome Um nome ou descrio curta para a estria. Por exemplo, Ver

o histrico 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 estrias. Normalmente recomendamos o
uso de de 2 at 10 palavras.
Grau de Importncia Isso opcional, porm pode dar um certo peso
para a estria. Recomendo utilizar um escala clara, uma pontuao
numrica ou escala de menos importante at muito importante. Toda o
grau de importncia deve ser definido pelo product owner.
Estimativa inicial As estimativas iniciais so providas pelo ScrumTeam,
que proveem quanto tempo necessrio para implementar aquela
estria, se comparada a outras estrias. A unidade pontos por
estria e geralmente corresponde mais ou menos a relao homem/
dias ideal. Esta mtrica inicial realizada de modo subjetivo mesmo,
perguntando para o time que em uma situao ideal, sem distrbios,
qual seria a o nmero ideal de pessoas para atuar e concluir esta estria
e quanto tempo. Questiona-se ainda, baseado no escopo desta estria,
aps quantos dias vocs apresentaro uma implementao pronta,
Scrum Definitivo
32
O Acesso ao Product Backlog
Voc pode utilizar vrias ferramentas, ou ainda usar uma planilha excel
compartilhada na rede e at uma planilha no Google Docs por exemplo.
O Importante que o aceso seja compartilhado com todo o ScrumTeam
e priorizado devidamente pelo ProductOwner.

PARA QUE (Justifique o porque do item especfico
no produto).
Entrar em Ao
Construindo seu Product Backlog
Voc pode usar os modelos product backlog que esto na rea de
downloads ou mesmo escrever o seu Product Backlog mo. Se preferir
fazer mo apenas para iniciar, voc vai precisar de um monte de
cartes de anotao e algumas canetas.
De qualquer modo, seria muito bom ter algumas pessoas que puderem
te ajudar neste exerccio. A Idia voc poder contar com pessoas para
te ajudar a escrever o escopo do produto, especialmente o cliente do seu
projeto pode ajudar bastante.
As regras do exerccio so simples, voc DEVE escolher o seu projeto,
pode utilizar o projeto do exerccio anterior ou mesmo utilizar outro
projeto, fica a seu critrio, porm recomendo seguir os seguintes passos:
Uma estria por carto ou uma idia em cada linha da planilha Um
item para cada idia que deve constar no product backlog
O formato para as suas estrias devem ser escritas da seguinte forma:

Insira um Ttulo (Este ttulo pode ser repetido para cada
estria, de modo que voc pode agrup-lo depois)

COMO UM (descrever o papel do usurio),
EU GOSTARIA DE (ter algo especfico no produto do projeto),
Segue aqui um exemplo de estria

para voc se basear:
Como um < Cliente da companhia
rea > eu gostaria de < Fazer check
in no site da empresa > para que <
fique menos tempo na fila>
isso a, simples assim. As
estrias podem ser to complexas
ou simples como voc preferir.
Elas podem estar relacionadas ou
no , detalhadas ou simples. Voc
escolhe a melhor forma de fazer.
Experimente-o com um projeto
que voc est prestes a comear.
Experimente-o com um projeto pessoal
que voc est adiando porque est com
medo de planejar a entregar. O Ideal seria
fazer algo que poderemos usar ao longo do curso.
Voc vai notar de imediato que o escopo do projeto torna-se mais claro,
que ao invs de se focar em tarefas e encadeamentos de atividades, o
foco total no usurio, no que voc precisa fazer e naquilo que trar
maior benefcio.
Quando voc terminar de escrever tudo , leia cada estria em voz alta
para todos e tente eliminar todas as estrias duplicadas. As discusses
com sua turma sero muito legais. Se for fazer o exerccio sozinho, tente
vislumbrar o que voc estar entregando ao final do projeto.
Scrum Definitivo
33
Dinmica de Grupo: Uma boa opo para

implantao do Scrum em sua equipe de projeto.
Qual o ponto mais importante na utilizao de

product Backlog
Assista o vdeo o abaixo e desenvolva esta dinmica com o time Scrum

de seu projeto e aprendam juntos de maneira bastante divertida.
O que voc acha que pode utilizar para monitorar o progresso do projeto
adequadamente
Pensando em seu projeto, apresente uma definio de pronto que esteja
de acordo com as expectativas do seu Product Owner.
Preencha o Product Backlog e visualize o produto potencialmente
entregvel ao final da Sprint
Modelos para Baixar

Scrum Definitivo
34
Captulo 5
Teste seu Conhecimento
Scrum Definitivo
Captulo 5: Teste seu Conhecimento

Neste captulo sero apresentadas 30 questes para voc testar o seu
conhecimento gil com as respostas comentadas ao final do captulo.
Q1. Imagine uma empresa de desenvolvimento de software que deseja
adotar o mtodo gil. Ser necessrio discutir o mtodo Scrum com os
clientes e receber sua aprovao antes de antes de usar nos projetos?
A.
Sim, pois isso muda a forma de entregar os projetos.
B.
Sim, pois isso aumenta o retorno sobre o investimento.
C.
No, pois uma forma interna de gerenciar o projeto.
D. No, pois o uso do Scrum sempre uma forma aceitvel de

trabalho.
Q2. Uma empresa de desenvolvimento de software est pensando em
colocar o Diretor de Marketing como Product Owner de um projeto.
Porm ele novo na empresa e no tem conhecimento tcnico. Deve ser
escolhida outra pessoa para a funo?
A. Sim, pois precisamos de um especialista que possa participar
ativamente com a equipe tcnica no trabalho e seja capaz de se
comunicar com o cliente.
B. Sim, pois precisamos de um especialista que possa participar
ativamente com a equipe tcnica no trabalho e que possa fazer
parte do time de desenvolvimento.
35
Q3. Ns estamos na dvida entre escolher a Maria ou o Antnio como

Scrum Master para o nosso projeto. Maria conhece bastante sobre
Scrum, mas ela muito nova e no possui muita experincia no mercado
de trabalho. Antnio no conhece Scrum, mas tem vrios anos de
experincia como Gerente de Projetos. Qual a melhor escolha?
A. Maria, pois ela conhece Scrum
e no precisa gerenciar o projeto.
B. Maria, pois ela conhece Scrum
e ir aprender gerenciamento de
projeto em breve.
C. Antnio, pois ele conhece
gerenciamento de projetos e no
precisa saber Scrum.
D. Antnio, pois ele conhece gerenciamento de projetos e ir
aprender Scrum em breve.
Q4. Considerando que temos um nmero limitado de recursos, ao
relacionar a equipe que atuar no projeto Scrum, qual a melhor escolha
entra as seguintes opes: 1) alocar 8 profissionais part-time (algumas
horas por dia) que tambm atuem em outros projetos da empresa. 2).
Rearranjar a estrutura da empresa para alocar 4 profissionais full-time
(tempo integral) e contratar uma nova pessoa para o time.
A.
Primeira, pois o custo menor.
B.
Primeira, pois cria um ambiente mais colaborativo.
C. No, pois ele no precisa ser um especialista j que vai ter outros
especialistas na equipe.
C. Segunda, pois aumenta o nmero de profissionais da

empresa.
D. No, pois ele no precisa ser um especialista desde que

conhea do negcio.
D.
Segunda, pois cria um time mais focado.
Scrum Definitivo
Q5. Em nosso projeto de desenvolvimento de software, ningum no

time sabe como testar profissionalmente, e ns precisamos disso como
requisito para o sucesso do projeto. O que devemos fazer?
A. Adicionamos mais um membro ao time, com especializao
ou plena explerincia em testes de software.
36
Q7. Estamos em um Sprint de requisitos e uma semana j passaou e

menos da metade do product backlog foi concluda. O Product Owner
acredita que o melhor a se fazer comear logo o primeiro Sprint
(Desenvolvimento) com a informao que temos mo, ao invs de ficar
esperando concluir para que todos os requisitos j estejam coletados.
Como Jedi Scrum Master voc deve orientar o time. O que eles devem
fazer?
B. Solicitamos ao time de testes, que no faz parte do

ScrumTeam, que cuide disso.
A.
C.
B. No, ns devemos esperar para completer todo o Product

Backlog antes de dar incio aos Sprints
Terceirizamos os testes com uma outra empresa
D. Est muito cedo para pensar emu ma tarefa que vai ser feita
s final do projeto
Q6. Quem deve estimar o volume de trabalho de cada item do backlog?

A. O Product Owner, porque ele tem total responsabilidade pelo
Product Backlog e conhece os itens mais que todo mundo
B. O Scrum Master, porque
dele a responsabilidade de planejar
tudo
C. O Scrum Team, porque eles
que devero realizar o trabalho
e eles conhecem a melhor forma
de entregar cada um dos itens de
acordo com o que foi requirido.
D. Todos os paps acima so
responsveis por estimar o trabalho
de um modo democrtico.
Sim, um bom momento para iniciar o primeiro Sprint
Q8. Na questo anterior, quem deve ajudar o Scrum Master a tomar a

deciso correta?
A.
Product Owner
B.
Scrum Master
C.
Scrum Team
D. No h um papel especfico para isso, todos devem

compartilhar a deciso.
Q9. Estamos prestes a iniciar o primeiro Sprint. Qual deve ser o primeiro
passo?
A.
Finalizar as estimativas dos itens do Product Backlog
B.
Sprint Initiation
C.
Sprint Startup
D.
Sprint Planning
E.
Daily Scrum
Scrum Definitivo
Q10. Estamos prestes a formar o Sprint Backlog. O ScrumTeam prefere

escolher 100 storypoints para o primeiro Sprint, mas o Product Owner
acredita que eles devem selecioanr pelo menos 150 pontos. Como Jedi
Scrum Master comandante da unidade o que voc recomenda eles a
fazer?
A.
B.
C.
D.
Todos devem discutir e chegar a um consenso

Tem que fazer os 100 storypoints
Tem que fazer os 150 storypoints
O Scrum Master deve decidir
Q11. Vamos decidir a durao dos Sprints. Algumas pessoas preferem

duas semanas e outros acreditam que o ideal seriam 3 semanas. Todos
esperam uma deciso do Jedi Scrum Master. O que o certo a fazer?
A. Comear com os dois
e mudar posteriormente se
necessrio.
B. Comear o primeiro Sprint
e ento ver quanto tempo sera
necesrio
37
Q12. O Product detectou algumas expectativas novas junto ao cliente.

Quando ser uma boa hora para inserir isso no Product Backlog?
A.
Assim que for detectado
B.
Depois do Sprint
C.
Antes do prximo Sprint
D.
No prximo Sprint Planning
Q13. Alguns membros do Scrum Team no esto seguros a respeito

do entendimento de alguns itens do Sprint Backlog items. O que o Jedi
Scrum Master deve recomendar?
A.
Eles devem tentar entender por si mesmos
B. Eles devem entrar em contato com o cliente e pedir maiores

informaes
C. Eles devem pedir ao Scrum Master que lhes d maiores
informaes
D.
Eles devem perguntar ao Product Owner
C. O Scrum Master tem a

palavra final neste assunto
D. O Product Owner tem a
palavra final neste assunto
Scrum Definitivo
Q14. O ScrumTeam percebe que o volume de trabalho para um dos

itens do Sprint Backlog est estimado incorretamente, e o volume
atual de trabalho totaliza 130 horas ao invs das 100 horas projetadas
inicialmente. Eles alertar a seu Scrum Master e pedem por ajuda. Como
um Jedi Scrum Master o que voc vai orient-los a fazer?
A. Eles devem devolver alguns itens ao Product Backlog a fim de
manter o Sprint Backlog com o volume projetado de 100 horas.
B. Eles devem pedir mais tempo ao Scrum Master para concluir
este Sprint
C.
D.
Eles devem pedir ao Product Owner para decidir sobre isso

Eles no devem fazer nada agora
Q15. O ScrumTeam percebe que se focarem nos ultimo 3 itens que esto
quase finalizados e estenderem o Sprint por apenas 2 dias, eles estaro
aptos a completar ambos. O que o Jedi Scrum Master recomenda a ser
feito?
A.
B.
Expandir a durao do Sprint e comepletar os 3 itens

Expandir a durao do Sprint, se o cliente aceitar
C. Expandir a durao do Sprint, se ambos, Scrum Master e

Product Owner, aceitarem.
D.
No expandir a durao do Sprint
38
Q16. Todos esto desapontados com o pequeno nmero de itens

completados do primeiro Sprint. The CEO Imperador solicita ao Scrum
Master uma explicao, especialmente sobre quem o responsvel
por isto. O que o nosso heri, o Jedi Scrum Master, deve responder a
respeito de quem o responsvel?
A.
Os 3 papis so responsveis.
B.
O ScrumTeam responsvel
C. Dois membros do ScrumTeam que estavam doentes durante

o Sprint so os responsveis.
D.
O Product Owner detm a responsabilidade maior
Q17. Chegou o momento do Sprint Review. O ScrumTeam acredita que

eles devem apresentar apenas o nico item concludo, mas o Product
Owner entende que eles devem tambm demonstrar os 3 itens que
esto quase concludos. Qum est certo?
A.
O ScrumTeam est certo
B. O Product Owner est certo,

uma vez que produtos que esto
quse concludos podem ser
apresentados.
C. O Product Owner est certo,
sendo assim, o Scrum Team
dever mencionar durante o Sprint
Review que estes 3 itens no esto
completos ainda, mas estaro no
futuro.
Scrum Definitivo
Q18. O novo representante do cliente (aquele que serve de interface

com o Product Owner) solicita ao Chefe do seu Departamento uma
reunio urgente com o Gerente do Projeto (O seu projeto). Quem o
Gerente do Projeto?
A.
Product Owner
B.
Scrum Master
C. ScrumTeam
D. Nenhum
Q19. De acordo com a questo
anterior, quem deve participar da
reunio com o representante do
cliente?
A.
Product Owner
B.
Scrum Master
C. ScrumTeam
39
Q20. O novo representante do cliente pede ao Chefe do seu

Departamente que introduza seu prprio Analista de Testes e agende
uma reunio com eles para discutir alguns tpicos importantes. O que
deve ser feito? Quem deve comparecer a esta reunio?
A. Apresentar formalmente a pessoa do ScrumTeam que
especialista em Testes e envi-lo a reunio.
B. Apresentar formalmente a pessoa do ScrumTeam que
especialista em Testes e enviar todo o ScrumTeam reunio para
trabalhar como uma equipe.
C. No apresentar ningum como responsvel por Testes e
enviar todo o ScrumTeam para a reunio.
D. No apresentar ningum como responsvel por Testes e
enviar o Product Owner para a reunio.
Q21. O ScrumTeam pede um dia folga depois de concluir o primeiro
Sprint (Para educao, pesquisa, interagir com outros times...), mas
a companhia no aceita. Quem deve discutir isso com a direo da
empresa e pegar sua aprovaol?
A.
Product Owner
D. Product Owner e o
Scrum Master
B.
Scrum Master
E. Todos
C. ScrumTeam
D. Todos
Scrum Definitivo
Q22. Itens incompletos do Sprint anterior (7 itens de 8) esto retornando

para o Product Backlog. O ScrumTeam entende que estes itens devem
ser selecionados para o prximo Sprint, sendo assim, eles podem se
manter focados e conclu-los rapidamente. Entretanto, o Product Owner
acredita que alguns itens so mais importantes agora. O que devemos
fazer agora?
A. Selecionar os itens pendentes assim o ScrumTeam pode
otimizar a velocidade de entrega.
B. Selecionar os itens pendentes porque no podemos comear
nada bovo anters de concluir todas as tarefas
C. Selecionar os novos itens porque o Product Owner assim
deseja
D. Selecionar novos itens porque uma boa idia iniciar um
novo Sprint com itens novos.
Q23. O ScrumTeam decidiu cancelar as Daily Scrums at o resto do
Sprint, para economizer tempo e entregar as coisas mais rapidamente.
Como Jedi Scrum Master, qual sua opinio?
A. Aceitvel, porque a entrega de produtos nossa prioridade
principal
B. Incorreto, mas aceitvel, uma vez que eles chegaram a
esta deciso e assumem a responsabilidade por suas prprias
entregas.
C.
Inaceitvel, porque Daily Scrum so requeridas no Scrum
D.
Inaceitvel, porque 15 minutos por dia no impacta em nada
40
Q24. O Scrum Master percebe que o Product Owner est indo a todas
as Daily Scrums e questiona o ScrumTeam sobre suas tarefas e d
direcionamentos especficos diariamente. Como comandante Jedi, o que
o Scrum Master deve achar disso?
A. Est errado, o Product Owner no
deve participar do Daily Scrum
B. Est errado, o Product Owner no
deve falar no Daily Scrum
C. Est OK, o Product Owner pode
fazer isso
D. Est OK, recomendado ao
Product Owner dar direcionamento
Q25. O Product Owner percebe que o cliente solicitou mudanas
significativas nos itens do Sprint Backlog que est em andamento. Estas
mudanas alteram completamente os itens. O que o Product Owner
deve fazer?
A. Pedir ao ScrumTeam para parar todo o trabalho nestes itens
e focar nos demais itens do Sprint Backlog
B.
Alterar estes 5 itens no Sprint Backlog to logo seja possvel
C.
Cancelar o Sprint
D. Fazer nada, permitir que o Sprint seja concludo

normalmente.
Scrum Definitivo
Q26. Ns no conseguimos concluir a maior dos itens do Sprint Backlog

nos ltimos dois Sprints. O que devemos fazer?
41
Q28. Qual foi nossa estimative inicial para o nmero de Sprints

requeridos para este projeto?
A.
Reduzir a capacidade dos Sprints
A. Um
B.
Aumentar a durao dos futuros Sprints
B. Seis
C. Ambos acima, uma vez que estamos ainda decidindo qual o

tempo correto para um Sprint.
C. Nove
D.
D. Dezesseis
Nenhuma das anteriores
E.
No determinado pelo Grfico
Analise o Burndown Chart abaixo e responda:

Q29. Quantos Sprints provavelmente sero necessaries para completer
o projeto?
Q27. Quantos Sprints foram feitos at agora?
A.
Provavelmente 9 sprints
B.
C.
D.
E.
A. Um
B. Seis
C. Nove
D. Dezesseis
E.
No determinado pelo Grfico

Scrum Definitivo
Q30. Ainda com base no Burndown Chart. O cliente deseja adicionar

novas funcionalidades com cerca de 400 storypoints para o projeto e
espera que o ScrumTeam lhe fornea uma estimative adicional. Qual a
sua idia? (Dica: Use a resposta da Q29)
A.
B.
C.
D.
42
As Respostas do Assessment
Para ter acesso s respostas clique no link ou digite
entrando com seu login e senha.
Scrum Definitivo
43
Captulo 6
As Certificaes geis
Scrum Definitivo
Captulo 6: As Certificaes geis

As certificaes basicamente servem para atestar o seu conhecimento
sobre determinado assunto., ou seja, um diploma que vai atestar que
voc sabe usar a fora.
Os profissionais com certificaes nas reas em que so especialistas
so mais satisfeitos em suas posies e mais confiantes quanto a suas
habilidades para fazer seus trabalhos do que seus pares. Alm de
possurem uma grande vantagem competitiva no mercado de trabalho.
As principais certificaes no mundo gil so regidas basicamente pelos
3 rgos a seguir:
44
Scrum Alliance
A Scrum Alliance uma entidade sem fins lucrativos com o objetivo de
promover a adoo efetiva do Scrum ao redor do mundo.
A comunidade de membros da Scrum Alliance j ultrapassa o nmero de

300 mil pessoas ao redor do globo.
As certificaes que so oferecidas pela Scrum Alliance so as seguintes:
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
Scrum Developer)
PMI: ACP (Agile Certified Practitioner)
Cada qual tem suas particularidades como veremos a seguir.
Fonte: scrumalliance.org
A certificao da Scrum Alliance que mais difundida a CSM (Certified

Scrum Master). Os requisitos para a certificao so:

Participar de 2 dias de treinamento em metologias geis

Fazer uma prova on-line de 35 perguntas, onde exigido o
mnimo de 70% de aproveitamento.
Prs
A dificuldade da prova de certificao menor se comparado
com a prova da Scrum.Org. So menos questes e um ndice de
aproveitamento mnimo menor, facilitando a vida do candidato.
Scrum Definitivo
45
Contras
Como pr-requisito que o candidato tenha participado de treinamento
presencial de 2 dias em uma instituio afiliada Scrum Alliance, o custo
deste certificao o mais alto de todas e vai variar de acordo com a
instituio de treinamento escolhida.
Sendo este treinamento presencial de somente 2 dias, normalmente as
instituies apresentam somente o bsico do Scrum, sem aprofundar
em casos prticos.
Professional Scrum Product Owner: Atesta os

conhecimentos fundamentais para o profissional que deseja
assumir o papel de Product Owner.
Dentre as certificaes da Scrum. Org, a mais difundida a PSM.
Os requisitos para obter esta certificao so:

Fazer uma prova online de 80 questes em um tempo
de 60 min.
Scrum.Org
A Scrum.Org tambm uma entidade sem fins lucrativos, mais voltado
para a disseminao do uso do Scrum no Desenvolvimento de Software.
O ndice de aproveitamento mnimo de 85%
Prs
A Scrum.Org no exige que voc tenha feito um curso em instituies
credenciadas como a Scrum Alliance. Desta forma as instituies que
ministram estes cursos preparatrios no precisam pagar nenhuma
taxa de credenciamento como acontece com as instituies afiliadas
Scrum Alliance, fazendo com que o custo do curso seja muito inferior
nos treinamento preparatrio para PSM (Scrum.Org) do que para CSM
(Scrum Alliance).
A misso da Scrum.Org melhorar a prtica do desenvolvimento de

software por meio do Scrum.
Caso o candidato sinta-se confortvel com seu conhecimento sobre

Scrum, este pode se submeter ao teste sem ter feito curso algum,
bastando apenas pagar a taxa da prova de US$ 100,00.
As certificaes oferecidas pela Scrum.Org so as seguintes:
Contras
Professional Scrum Master: Atesta os conhecimentos

fundamentais para o profissional que deseja assumir o papel
de Scrum Master.
Prova onde so atestados conhecimentos tericos sobre o Scrum, mas

que no representam que o candidato saiba aplicar na prtica.
Professional Scrum Developer: Atesta os conhecimentos

do desenvolvedor de software que est inserido no contexto
de um projeto Scrum.
Scrum Definitivo
PMI
46
Os requisitos para se obter a certificao so:

Comprovar pelo 2.000 horas de experincia em projetos
obtidas nos ltimos 5 anos mais 1.500 horas trabalhadas em
projeto geis nos ltimos 3 anos.
O Project Management Institute (PMI) uma instituio internacional

sem fins lucrativos que associa profissionais de gesto de projetos.
considerada uma das maiores associao do gnero no mundo, e possui
mais 500.000 profissionais certificados em cerca de 170 pases.

21 horas de contato com capacitao formal em
treinamentos geis

Prova presencial, em local aprovado pelo PMI, com 120
questes e 3 horas de durao.

necessrio um aproveitamento mnimo entre 70% e 80%
para passar.
Prs
O PMI famoso pela publicao do PMBOK (Project Management Body
of Knowledge), que considerado o guia principal das melhores prticas
de gerenciamento de projetos tradicionais. Pautado no PMBOK, a
certificao mais famosa do PMI o PMP.
Alm do PMP, recentemente o PMI tem avanado com sua nova
certificao gil, a PMI-ACP.
A certificao leva a chancela da maior e mais reconhecida instituio de

gerenciamento de projetos do mundo, que o PMI.
Aborda diversas tcnicas de metodologia gil que vo alm do Scrum.
Contras
Exige uma experincia anterior de 4.500 horas em projetos, o que pode
impossibilitar a certificao para profissionais iniciantes.
PMI-ACP , atualmente, a menos difundida no mundo gil, talvez por ser

a mais recente, porm vem ganhando fora a cada dia.
Por abordar diversas tcnicas alm do Scrum, o nvel de conhecimento

exigido maior dos as demais certificaes. Porm a prova no to
rigorosa quanto Scrum.Org.
O custo desta certificao tambm um pouco alto, pois a prova deve
ser feita presencialmente em um local credenciado pelo PMI.
Scrum Definitivo
47
Captulo 7
Resumo
Scrum Definitivo
48
Captulo 7: Resumo
Entregar software de qualidade de um modo gil, criativo e que atenda as expectativas do cliente no algo para qualquer um, isso trabalho para um
verdadeiro Jedi.
Neste livro abordamos conceitos, prticas e highlights importantes sobre o mtodo gil na prtica.
Voc deve ter percebido que muitas das coisas aqui ensinadas so 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 tambm ao final como aprender tudo isso de modo prtico e divertido atravs de um treinamento online totalmente inovador.
Esperamos que tenha gostado do livro e acima de tudo....
Que a Fora Esteja com Voc!
Scrum Definitivo
49
1-Product Backlog
2-Release Backlog
O Product Backlog contm uma lista de desejos com todas as User

Stories que tornaro o produto especial
A Meta principal de cada iterao entregar uma parte importante do

Product Backlog, conhecida como Release Backlog.
Depois de identificar quais User Stories iro em cada Release, estas User
Stories se tornam parte do Release Backlog
Como um (Funo), Eu gostaria

de (Funcionalidade) para que
(Benefcio)
Em Scrum funcionalidades so conhecidas como User Stories e so

escritas sob a perspectiva do usurio final. O Product Owner representa
os usurios clientes e decides quais User Stories ou itens devem ser
priorizados no Product Backlog
Depois as User Stories so estimadas pelo ScrumTeam que fornecem a

quantidade de tempo em horas para o desenvolvimento de cada item.
Scrum Definitivo
50
4-Burndown Charts
A cada Sprint (Um Marco do Projeto de curta durao) uma parte do

Release Backlog desenvolvida e uma parte potencialmente entregvel,
passvel de demonstrao, concluda.
O Progressso do Projeto monitorado utilizando o Burndown Chart,

uma das melhores ferramentas para prover visibilidade e garantir o
progresso do projeto de modo transparente. O Burndown chart prov
uma viso dia-a-dia da medida de progresso e do que ainda est por se
fazer em um referido Sprint.
Ve
loc
ida
de
A linha vermelha ou Velocidade a mdia da

produtividade de cada dia.
Trabalho Restante
Ao final de cada Sprint voc

dever ter um produto
plenamente testado com
todas as funcionalidade do
Sprint 100% concludas
Linha Tendncia
Geral
Data Estimada de
Trmino
Sprints geralmente tem

uma durao de 2 a 4
semanas, entretanto,
podem chegar at 30 dias.
Trabalho Restante
3-Sprint Backlog
Trabalho restante / Produtividade =

Dias para Concluso
M
dia
de
Pro
du
tiv
ida
de
=2
5h
/Di
a
Saber qual o ponto do projeto e sua tendncia de progresso pode ser

determinante para eventuais ajustes necessrios para tornar o projeto
em dia novamente.
Scrum Definitivo
51
5-Daily Standups
6-Sprint Retrospectives
As rpidas reunies de Daily Standup Meetings (Tambm conhecidas

como Daily Scrums) garantem que tudo est sob controle e que todos
tem todas as ferramentas que necessitam. uma ferramenta de
informao essencial para prover um fluxo de informao importante
entre os membros do projeto.
Depois de cada Sprint uma reunio de Retrospectiva visa ajustar e

aprimorar os processos.
Os membros do ScrumTeam listam o trabalho que eles completaram

desde a ltima reunio, qualquer impedimento em seu caminho e o que
eles faro at a prxima reunio.
Isto o que Fiz
desde nossa ltima
reunio.
Estes so os
obstculos que
encontrei.
Isto o que estou

planejando fazer
hoje.
Este um momento para cada membro do time refletir sobre o que foi
certo e quais so as oportunidades de melhorias.
O que funcionou?
O que no
funcionou?
O que podemos
melhorar para o
prximo Sprint?
Acima de tudo, o Scrum um mtodo de desenvolvimento gil flexvel

que oferece melhoria contnua e ajustes para todo o time.
Scrum Definitivo
Bibliografia Sugerida
52
Sites interessantes sobre Scrum

www.mindmaster.com.br
www.scrumalliance.org
www.scrum.org
www.mountaingoatsoftware.com
www.agilesoftwaredevelopment.com
www.noop.nl
Scrum Definitivo
Glossrio do Scrum
Scrum Master
O ScrumMaster o responsvel por garantir que o Scrum Team se
orienta pelos valores e prticas do Scrum. O ScrumMaster protege o
time certificando-se de que os membros no se comprometam com
compromissos alm dos que eles conseguem cumprir dentro de um
sprint.
Product Owner
O Product Owner (dono do produto) representa os interesses de
todos os envolvidos (stakeholders), define as funcionalidades do
produto e prioriza os itens de Product Backlog.
Scrum Team ou Time de Desenvolvimento

O Scrum Team constri o produto que o cliente ir utilizar
Product Backlog
Lista de desejos que incrementar o produto a ser desenvolvido
Sprint
Representa um ciclo de
desenvolvimento do
produto com timebox prdeterminado
TimeBox
Uma escala de tempo
que restringe o Sprint.
Tempo dedicado para o
cumprimento do Sprint.
53
Sprint Backlog
Lista de histrias a serem desenvolvidas em uma sprint
Sprint Planning
A reunio Sprint Planning onde o Scrum Team e o Product Owner
determinam quais funcionalidades e atividades sero realizadas
no prximo Sprint.
Daily Meetings ou StandUp meetings

uma reunio diria e rpida com todos os membros do Scrum
Team e o Scrum Master
Sprint Review
Todo Sprint se encerra com a Reunio Sprint Review, onde o Scrum
Team demonstra o incremento de produto potencialmente utilizvel.
Retrospectiva
o mecanismo principal para a visibilidade que o Scrum
proporciona a reas que potencialmente necessitam de
melhorias, transformando-as em resultados.
Release
Plano de alto nvel sobre o desenvolvimento
Release Planning
Planejamento do projeto em relao a Sprints, processos,
reunies e etc.
Burndown Chart
O Sprint Burndown Chart uma representao grfica do trabalho
restante no Sprint
Scrum Definitivo
54
Como posso aprender isso tudo na Prtica

Acesse o site abaixo e descubra uma maneira 100% prtica 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
Scrum Definitivo
55
Que a Fora Esteja com Voc!

www.mindmaster.com.br
contato@mindmaster.com.br
Capa e Diagramao por:
Yuri Santos
yupastudio.com

Ebook SW Scrum 04f PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Ebook SW Scrum 04f PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Scrum

Denis Rodrigues Pedro

Todas as imagens, personagens e smbolos, so marcas registradas da LucasFilm Ltd.

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

Porque decidimos escrever este Livro

Como este Livro est organizado

Na sequncia dos captulos do Livro voc ir perceber que h algumas

O Fato do Gerente de Projetos dos dias atuais ter que

importante que voc absorva cada um dos contedos aqui

Nos primeiros 4 captulos voc ir encontrar as seguintes sees:

A Teoria Sobre a Fora

Como Usar a Fora

Material para Baixar

Todas as imagens, personagens e smbolos, so marcas registradas da LucasFilm Ltd.

Todas as imagens, personagens e smbolos, so marcas registradas da LucasFilm Ltd.

Captulo 1: Os Fundamentos do Scrum

A Teoria Sobre a Fora

O Scrum um framework estrutural que est sendo usada para

O Scrum se diferencia de mtodos tradicionais por ter as seguintes

Todas as imagens, personagens e smbolos, so marcas registradas da LucasFilm Ltd.

O Scrum foi fundamentado nas teorias empricas de controle de

O empirismo afirma que o conhecimento vem da experincia e

Os profissionais do time Scrum devem, frequentemente, inspecionar os

A adaptao um dos pilares mais importantes do Scrum. Atravs deste

Se um Analista de Testes determina que um ou mais aspectos do

Manifesto para Desenvolvimento gil de Software

Os nove principios do manifesto gil

Estamos descobrindo maneiras melhores de

Na verso 2011 a configurao da time-box da reunio de

Todas as imagens, personagens e smbolos, so marcas registradas da LucasFilm Ltd.

Alm disso, foi deixado claro que, no final do sprint, no Sprint

Nossa maior prioridade satisfazer o cliente atravs da entrega

9 - Daily SCRUM: As 3 Perguntas Alteradas

Foi ainda reforada a importncia do

O que fiz ontem que ajudou o time a atingir a meta

Este princpio um dos mais difceis para a transio ao mtodo gil,

Juntamente com o Scrum surgem diversas desconfianas, que na maioria

A maioria dos profissionais que atuam em mtodos tradicionais

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

De que forma a inspeo pode contribuir de modo prtico com o seu

At aqui voc aprendeu alguns conceitos importantes sobre o Scrum,

Qual o principal benefcios que voc enxergaria em seu projeto ao

Trazendo voc para o mundo real, utilize as questes abaixo, pensando

Modelos para Baixar

Quais seriam as formas prticas de voc promover transparncia no seu

Todas as imagens, personagens e smbolos, so marcas registradas da LucasFilm Ltd.

Todas as imagens, personagens e smbolos, so marcas registradas da LucasFilm Ltd.

Captulo 2: O Time Scrum

A Teoria Sobre a Fora

Aceitar ou rejeitar o trabalho entregue pelo ScrumTeam;

O Desafio comum do Product Owner nas Organizaes

Embora o Product Owner possa representar o desejo de um comit

A sinergia resultante aperfeioa a eficincia e a eficcia da Equipe de

As Equipes de Desenvolvimento so estruturadas e autorizadas pela

O Scrum Master trabalhando para o Product Owner

A seguir vamos tratar de um dos temas polmicos do Scrum.

O Scrum Master serve o Product Owner de vrias maneiras, incluindo:

O tamanho ideal da Equipe de Desenvolvimento pequeno o suficiente

Encontrando tcnicas para o gerenciamento efetivo do Backlog

O Scrum Master trabalhando para o Scrum Team

Treinar a Equipe de Desenvolvimento em ambientes

O Scrum Master trabalhando para a Organizao

Modelos para Baixar