Scrum Courseware

SCRUM
Gerenciamento de Projetos de Software

APRESENTAÇÕES
Nome
Empresa (breve descrição da empresa)
Quanto tempo na área de software?
Atua em outros áreas?
Foi (é) desenvolvedor?
Foi (é) gerente de projetos?
O que sabe sobre Agile? E sobre Scrum?
www.adaptworks.com.br
APRESENTAÇÕES
Sobre mim
Fabiano Milani, CSM, é consultor, instrutor e coach em liderança e
gerenciamento de projetos de software onde utiliza metodologias
e processos ágeis.
• Co-fundador e membro do time da AdaptWorks juntamente com Alexandre

Magno, primeiro e único Certified Scrum Trainer do Brasil e Edmilson Miyasaki,
a AdaptWorks é uma nova empresa brasileira, com escritórios em São Paulo -
Brasil e Londres - UK, que tem como propósito atuar na capacitação e condução
de seus clientes na adaptação cultural necessária para o alcance de melhores
resultados em seus projetos.
• Atua na área de software há 16 anos, participando de projetos de variadas
dimensões de lead time, escopo e investimento.
• Atua como co-trainer do Alexandre Magno nos treinamentos de CSM (
Certified ScrumMaster ) pelo Brasil;
• Atuou como desenvolvedor e coordenador de desenvolvimento de vários
segmentos de empresa;
• Atuou professor de matemática, física e linguagens de programação.
PRODUCT BACKLOG
Parte I – Conhecendo Scrum
Parte II – Como adotar Scrum em sua empresa
Parte III – Expandindo o uso de Scrum
SPRINT BACKLOG
Parte II – Como adotar Scrum em Parte III – Expandindo o uso de
sua empresa Scrum
• Por que precisamos de uma • Scrum Master, o líder da banda • Scrum e outras metodologias: UP,
metodologia? • Conhecendo a empresa XP, FDD;
• Introdução às abordagens ágeis; Kingsoftware; • Scrum e CMMI;
• O que é Scrum? • Formando um time ágil; • Scrum e PMBok;
• O ciclo de vida do Scrum; • Apresentando Scrum para o time; • Scrum e Corrente Crítica;
• Os papéis no Scrum; • Auxiliando o Product Owner na • Scrum e ferramentas;
• O conceito de Sprint: Entregando elaboração do Product Backlog;
freqüentemente software de valor • Auxiliando o time nas estimativas
para o cliente; do Product Backlog;
• Product Backlog: Descobrindo, • Facilitando o Sprint Planning
priorizando e estimando as Meeting #1;
necessidades do cliente; • Facilitando o Sprint Planning
• Sprint Planning Meeting: Meeting #2;
Planejamento na medida certa; • Iniciando o Sprint
• Scrum Daily Meeting: Descobrindo • Facilitando Scrum Daily Meeting;
pequenos problemas antes que • A engenharia de software no
estes se tornem grandes; Scrum;
• Sprint Review: Apresentando o • Auxiliando o time no planejamento
resultado; do Scrum Review;
• Sprint Retrospective: Avaliando • Facilitando a Scrum Retrospective;
pontos positivos e negativos e se
• Reiniciando o jogo;
preparando para reiniciar;
• Lições com o projeto Kingsoftware;
CONHECENDO SCRUM
ONDE ESTAMOS?
sua empresa Scrum
O QUE É PROJETO?
O ambiente de um projeto de software
O QUE É PROJETO?
O ambiente de um projeto de software
O QUE É PROJETO?
Características dos componentes
• Conhecimento e • Personalidade coletiva

habilidades • Risco X Segurança
• Motivação e • Etiqueta
comprometimento • O “jeito de ser” da
• Reconhecimento organização
• Crescimento
Pessoas Cultura
• Disciplina e • Produtividade
coordenação • Controle
• Gerenciamento • Eficiência
• Padronização • Automação
• Institucionalização
Processos Ferramentas
ATIVIDADE
Analisando os componentes de um contexto qualquer
Escolha um contexto qualquer e descreva resumidamente:
1. Que pessoas estão envolvidas?
2. Quais processos são observáveis?
3. Quais tecnologias são aplicadas?
4. Como a cultura influencia nesse (ou é influenciada por

esse) contexto?
O QUE É PROJETO?
Duas visões diferentes
Um projeto é um problema agendado

para solução!
Dr. Joseph M. Juran
Um projeto é uma coleção de valor

agendada para realização
David J. Anderson
O QUE É PROJETO?
Conceito
É um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo
• É temporário, isto é, possui uma data de início e uma data de término;
• Resulta em produto(s) que não exista(m) antes, ou existirá(ão) de forma diferente

(exclusividade);
• Possui restrições em custo, prazo, qualidade e/ou recursos;
• Exige uma coordenação para ser executado (isto é, possui um certo grau de complexidade);
• Conduzido por pessoas;
• Elaboração progressiva: desenvolver em etapas e continuar por incrementos
O QUE É UMA METODOLOGIA?
Em engenharia de software e no gerenciamento de projetos
Uma metodologia é um conjunto codificado de
práticas (algumas vezes acompanhadas por material
de treinamento, programas de educação formais,
planilhas, e ferramental de diagramação) que deve ser
repetível durante o processo de produção do
software.
Muitas metodologias experimentaram algo como uma

tentativa de definir algoritmos para os programadores
seguirem. Isto tem como efeito tornar o programas
mais impessoais e menos interessante. Isto diminui a
motivação e a satisfação como o trabalho para os
programadores. Programadores costumam resistir a
metodologias muito rígidas.
Fonte: Wikipedia
POR QUE PRECISAMOS DE UMA METODOLOGIA?
Qual o propósito de um processo de desenvolvimento de software?
Capacitar e reforçar a entrega repetível de software que funciona...
no prazo adequado e eficiente em relação ao seu custo...
fornecendo informação precisa e significativa a todos os papéis principais, dentro e fora de

um projeto...
com o mínimo de interrupção para os desenvolvedores
Coad, de Luca
JMCU
O Chaos Report
O Standish Group vem, há mais de uma década, realizando
estudos em volta dos resultados dos projetos de software ao
redor do mundo. O resultado destes estudos é um relatório
batizado de Chaos Report;
Em nenhum lugar o desafio para chegar ao máximo da

potencialidade é tão profundo quanto dentro das corporações
de software. O Chaos Report de 2004 considera que apenas 1
em cada 3 projetos de software é bem sucedido. O relatório
também mostra que aproximadamente 70% dos projetos de
software não conseguiram oferecer o que se pretendia
originalmente sem exceder o orçamento, ultrapassar o
cronograma previsto ou sacrificar a qualidade final;
A vasta maioria dos projetos de software falha por falta de

clareza – sobre funções pessoais, responsabilidades e requisitos
– e também por inabilidade para acompanhar o que ocorre em
cada um dos diferentes passos do ciclo de vida da aplicação. Esta
situação é potencializada pela dinâmica natural do mercado, e
pelos constantes pedidos de alteração.
Fonte: Borland Software Corporation
Se fabricássemos aviões...
O que precisamos saber?
• Precisamos saber como lidar com requisitos;
• Precisamos saber como melhorar a comunicação entre os

membros das equipes;
• Precisamos saber como estimar as atividades para a produção de

nosso produto;
• Precisamos saber como entregaremos os produtos para nossos

clientes;
• Precisamos saber como difundir o conhecimento em nossas

equipes;
• Precisamos saber o que e como documentamos;
• Precisamos saber qual o ciclo de vida da nossa produção;
• Precisamos saber como organizar nossa produção;
• Precisamos saber como conseguiremos qualidade;
Metodologias/Processos/Certificações disponíveis no mercado
Como escolher uma?
Para isso precisamos saber ONDE QUEREMOS CHEGAR!
“- Poderia me dizer, por favor, qual é o caminho para sair

daqui?
- Isso depende muito do lugar para onde você quer ir.
- Não me importa muito onde.
-Nesse caso, não importa por qual caminho você vá.“
Diálogo entre Alice e o Gato de Cheshire.

Alice no país das maravilhas, de Lewis Carroll
Como categorizar a complexidade de um projeto de software?
Uma dimensão relacionada a PESSOAS adiciona
mais um nível de complexidade no gráfico ao
lado;
Anarquia
O último projeto simples que existiu foi em
1969
Complexo
Simples Complicado
Tecnologia
Fonte: ADM, 2004
EXERCÍCIO
Por que precisamos de uma metodologia?
Cite quais são os principais problemas no processo de
desenvolvimento de software da sua empresa.
Cite o que você espera de uma metodologia para

desenvolvimento de software.
ONDE ESTAMOS?
sua empresa Scrum
INTRODUÇÃO ÀS ABORDAGENS ÁGEIS
O Manifesto Ágil
Em 2001, um grupo de profissionais veteranos na área de software decidiu se reunir em uma
estação de esqui, nos EUA, para discutir formas de melhorar o desempenho de seus projetos.
Embora cada envolvido tivesse suas próprias práticas e teorias sobre como fazer um projeto de
software ter sucesso, cada qual com as suas particularidades, todos concordavam que, em suas
experiências prévias, um pequeno conjunto de princípios sempre parecia ter sido respeitado
quando os projetos davam certo;
O grupo era composto de grandes nomes do mundo do software, tais como: Kent Beck, Jim
Highsmith, Alistair Cockburn, Martin Fowler, Ken Shwaber e Jeff Sutherland.
O que é agilidade?
• Um estado mental, não um conjunto de documentos, passos ou técnicas;
• É mais atitude do que um processo, mais ambiente que uma metodologia;
• Desenvolvimento iterativo;
• Entregar produto com valor para o negócio, mais rápido e continuamente;
• Garantir progresso real;
• Abraçar mudanças;
• Melhorar a comunicação entre negócios e TI;
• Qualidade desde o início.
O que é agilidade?
Agilidade é a habilidade para criar e

responder à mudança, para lucrar num
ambiente turbulento de negócios.
Agilidade é a habilidade para equilibrar

flexibilidade e estabilidade.
Jim Highsmith
O QUE NÃO É AGILIDADE?
Fonte: Reebok
O Manifesto Ágil
O manifesto diz:
“Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e
ajudando outros a fazê-lo. Através desse trabalho, passamos a valorizar:
Indivíduos e interação entre eles mais que processos e ferramentas

Produto em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.”
http://agilemanifesto.org
Decifrando o manifesto
Indivíduos e interação entre eles mais que processos e ferramentas
• Processos fornecem direcionamento e suporte, e ferramentas produtividade, mas sem as

pessoas certas, que possuam satisfatório conhecimento técnico e habilidades para formar
uma equipe altamente eficaz, todos os processos e ferramentas do mundo irão falhar;
• Bons processos devem mais auxiliar o time que ditar as ações que seus membros devem
tomar;
• Processos devem se adaptar ao time, e não o inverso;
• Processos e ferramentas são úteis, mas quando decisões tiverem que ser tomadas, estas
serão feitas de acordo com a capacidade e conhecimento de seu time.
Baseado em: Agile Project Management – Jim Highsmith
Produto em funcionamento mais que documentação abrangente
• Troque a entrega de documentação e artefatos por versões iterativas de um produto real

que será útil para o cliente;
• Documentos não funcionam. Produtos sim;
• No entanto, produtos funcionando não excluem a necessidade de documentação.

Documentos auxiliam a comunicação e colaboração, facilitam a transferência de
conhecimento e preservam informações históricas. Não estamos dizendo que
documentação não é importante, mas apenas que é menos importante que produto
funcionando;
• Documentação não deve substituir a interação.
Colaboração com o cliente mais que negociação de contratos
• Em projetos ágeis, clientes e gerentes de produto são os guias;
• A meta de um time em projetos ágeis é entregar valor para o cliente;
• Clientes definem o que é valor. Os stakeholders definem as restrições. Quando fazemos

confusão entre clientes e stakeholders nosso projeto está tomando o rumo errado.
• A fórmula para o sucesso é simples: Entregue hoje, adapte amanhã!
Responder a mudanças mais que seguir um plano
• Todos os projetos são conhecidos e desconhecidos, certos e incertos, e portanto todos eles
precisam ter um balanceamento entre planejamento e mudanças;
• Evite a “Síndrome de Nostradamus”. Adaptação ao invés de antecipação
• Projetos baseados na exploração são caracterizados por um processo com ênfase em

formar uma “ante-visão” e então explorá-la dentro de uma visão, e não de um plano
detalhado. Isso não significa que isto seja “a única verdade”, mas sim que é o melhor a ser
feito em muitos tipos de projeto;
• Rob Austin e Lee Diven citam em Artful Making que o lema “Planeje o trabalho, e trabalhe
o plano” os levou ao fracasso em um projeto de TI que envolveu mais de U$ 125 milhões.
Desenvolvimento iterativo
Uma iteração é um “pacote de tempo” que possui um custo
fixo e um conjunto de funcionalidades que pode variar;
As funcionalidades que farão parte de uma iteração são

priorizadas pelo cliente;
Iterações podem perder funcionalidades, mas nunca datas;
Surgiu uma necessidade urgente que precisa ser inserida

nesta iteração. Não tem problema, desde que alguma outra
funcionalidade com o mesmo “peso” seja removida; (XP)
Cliente entende que prioridades no “final da lista” podem

ficar de fora e/ou eles podem adicionar funcionalidades;
Flexibilidade está nas funcionalidades, não no prazo ou no

custo.
Produto
Release Release 1
2
Iteração
2 Iteração 1
Release Iteração Item 1 Item 2
3 3
Produto
Release Release
Release 1
2 3
Func. A Func. B Func. F Func. K

Func. E Func. C Func. J Func. L
Func. G Func. D Func. M
Func. H Lista Lista
Func. I funcionalidades funcionalidades
O ciclo de vida de projetos ágeis
Fonte: Agile Project Management – Jim Highsmith
Abordagens ágeis mais difundidas
Scrum
• É uma abordagem ágil para o gerenciamento de projetos. Fornece

práticas que ajudam gerentes a tornar mais dinâmico e gerenciável o
ambiente de desenvolvimento de software.
XP (eXtreme Programming)
• É uma abordagem ágil para a engenharia de projetos de software.

Como o próprio nome diz, é extremamente focada no
desenvolvimento, e tem como principal característica a programação
em par.
FDD (Feature Driven Development)
• É uma abordagem ágil para a engenharia de projetos de software.

Defende o desenvolvimento de um modelo abrangente no início do
projeto pelo qual as funcionalidades do sistema serão descobertas e
desenvolvidas.
Problemas com abordagens ágeis
Por não fornecerem dezenas de volumes de livros com processos a serem seguidos à risca, as
abordagens ágeis precisam ser aplicadas através do bom senso...o que muitas vezes não
acontece;
Essa mesma idéia de simplicidade faz com que várias equipes iniciem a implantação de um
processo ágil em sua empresa sem a menor preparação para isso;
Em empresas mais formais, processos e atividades envolvendo post-its, desenhos, jogos e

outros, podem ser mal interpretados, precisando então de um trabalho cultural bem
planejado;
The dark side of agile
Ouvi dizer que você Bem simples! Passamos

está usando a desenvolver em par e
abordagens ágeis na não documentamos mais
sua equipe. Como nada!
foi a implantação?
A mitologia ágil
Escuto freqüentemente contos sobre a falta da disciplina em Agile:
• Agile deixa minhas equipes de engenharia fazer o que quiserem
• A qualidade do produto cairá
Ou sobre a falta da visibilidade:

• Não tenho nenhuma visibilidade do que está acontecendo
• Não consigo prever o que eu começarei, ou quando”.
E sobre a falta de aplicabilidade:

• Agile é apenas para geeks
• Agile é apenas para equipes pequenas
E principalmente: “Agile é fácil!”
Fonte: Hubert Smiths, 2006 – Introduction to Agile Methods and Practices
Posicionamento de Agile no mercado
Pesquisa sobre adoção de Agile divulgada em dezembro de 2006 pela Trail Ridge Consulting
Equipes seguindo algum processo ágil Tempo (em anos) que algum processo
(em todo tamanho de organização) ágil vem sendo utilizado na organização
Principal processo ágil em uso Principal processo ágil em uso

(em todo tamanho de organização) (por tamanho de organização)
Yahoo! United Overseas Bank
“O Yahoo! usa Scrum há mais de 18 meses, e “Quando assumimos o projeto, ele possuía
possui uma média de 500 colaboradores mais de 3.500 use-cases, que haviam levado
usando Scrum nos Estados Unidos, Europa e dois anos de consultoria para serem
Índia. Scrum vem sendo usado com sucesso desenvolvidos. O projeto estava fadado ao
em projetos como o Yahoo! Podcasts e fracasso e considerado impossível. Após 15
outros” meses utilizando as práticas da FDD já
havíamos entregado 2.000 features com uma
equipe de 50 pessoas”
Pete Deemer Jeff De Luca foi Gerente de Projeto

Chief Product Officer, CSM neste famoso projeto do United
Yahoo! Bangalore - 25/07/2006 Overseas Bank, em Cingapura.
ONDE ESTAMOS?
sua empresa Scrum
O QUE É SCRUM?
Depende de onde você está
O QUE É SCRUM?
A origem do Scrum
Scrum foi criado no início da década de 1990 por Jeff Sutherland e Ken Schwaber,
nos Estados Unidos.
O QUE É SCRUM?
Algumas definições
• Scrum é um processo iterativo e incremental para o desenvolvimento de qualquer produto
e gerenciamento de qualquer trabalho.
• Scrum é um processo ágil para o gerenciamento e controle de projetos;
• Scrum é um wrapper para práticas de engenharia existentes;
• Scrum é uma abordagem para desenvolvimento de sistemas e produtos onde os requisitos

sofrem constantes mudanças;
• Scrum é um processo que controla o caos dos conflitos de interesses;
• Scrum é uma forma de otimizar a comunicação do time e favorecer a cooperação;
• Scrum é uma forma de otimizar a produtividade;
• Scrum é escalável para pequenos projetos e grandes corporações;
• Scrum é uma forma de todos se sentirem bem com seu trabalho, suas contribuições, e faz
com que todos dêem o melhor de si para o sucesso do projeto.
O QUE É SCRUM?
Scrum NÃO é uma bala de prata
O QUE É SCRUM?
A objetividade de Scrum
• Uma das grandes vantagens do Scrum é que ele é bastante objetivo, possui papéis bem
definidos, e é de fácil adaptação.
• O Scrum não é um processo previsível, ele não define o que fazer em todas as
circunstâncias. Logo, o Scrum não vai dizer exatamente o que fazer, não irá resolver todos
os seus problemas, mas com certeza os problemas serão mais facilmente identificados.
• Um dos aspectos positivos do Scrum é a sua adaptabilidade, portanto, o conhecimento das

suas práticas é extremamente importante, por permitir a aplicação das mesmas de forma
variada.
• Utilize Scrum no gerenciamento de seus processos. Utilize outra metodologia para a

engenharia de seu projeto.
O QUE É SCRUM?
Aspectos de Scrum
• Substitui o gerenciamento empírico e processos de controle, por feedback em loops de
inspeção e adaptação.
• Distribui funcionalidades em Sprints de 2, 3 ou 4 semanas.
• Escalável para projetos longos, largos e distribuídos (Scrum of Scrums, Type C Scrum,
• MetaScrum).
• Suporta CMMI Nível 3 e ISO9001.
• Extremamente simples, mas resistente!
O QUE É SCRUM?
Processo definido ou processo empírico?
“É típica a adoção da abordagem de modelagem
definida (teórica) quando os mecanismos subjacentes
pelos quais um processo funciona são razoavelmente
bem entendidos.
Quando o processo é muito complicado para a
abordagem teórica, a abordagem empírica é a opção
apropriada.”
Process Dynamics, Modeling, and Control – Ogunnaike and Ray, Oxford University Press, 1992
ATIVIDADE
Eu preciso de comando-controle?
O QUE É SCRUM?
Liderança-Colaboração sim! Comando-Controle NÃO!
Liderança -
Colaboração
Comando -
Controle
Comando – Controle é muito lento porque:
• Não permite processar informações rapidamente

• Não permite tomar decisões rapidamente
ATIVIDADE
A arte do possível
Explore a diferença entre planejar uma viagem se cada
sentença começa com:
“sim, mas”
“sim, e”
ONDE ESTAMOS?
sua empresa Scrum
O CICLO DE VIDA DE SCRUM
O CICLO DE VIDA DE SCRUM
O ciclo de vida do Scrum tem o seu progresso baseado em uma série de iterações bem
definidas, cada uma com duração de duas a quatro semanas, chamadas Sprints. Antes de cada
Sprint, realiza-se uma reunião de planejamento (Sprint Planning Meeting) em que o time
(equipe) de desenvolvedores tem contato com o cliente (Product Owner) para priorizar o
trabalho que precisa ser feito, selecionar e estimar as tarefas que o time pode realizar dentro
da Sprint. A próxima fase é a execução da Sprint.
Durante a execução da Sprint, o time controla o andamento do desenvolvimento realizando

Reuniões Diárias (Daily Meeting) de não mais que 15 minutos de duração, e observando o seu
progresso usando um gráfico chamado Sprint Burndown.
Ao final de cada Sprint, deve-se realizar uma Reunião de Revisão (Sprint Review), em que o
time demonstra o produto gerado na Sprint e valida se o objetivo foi atingido. Logo em
seguida, realiza-se a Reunião de Retrospectiva (Sprint Retrospective), uma reunião de lições
aprendidas, com o objetivo de melhorar o processo, time e/ou produto para a próxima Sprint.
ONDE ESTAMOS?
sua empresa Scrum
OS PAPÉIS EM SCRUM
Pigs e chickens são papéis no Scrum?
Não. Os termos pig (porco) e chicken (galinha) são utilizados em Scrum de forma
informal – e eficiente – para tornar transparente quais são os papéis e/ou pessoas
que estão realmente comprometidos com o projeto, e quais estão apenas
envolvidos.
Pig: Alguém que ocupa um dos três papéis do Scrum (Team member, Product
Owner, Scrum Master) e tem um total comprometimento com o projeto.
Chicken: Alguém que tem interesse no produto a ser gerado, mas não ocupa
nenhum papel formal do Scrum.
OS PAPÉIS EM SCRUM
O Product Owner (PO)
O Product Owner representa o cliente ou patrocinador do
projeto, e faz parte do time que entregará o produto.
Suas responsabilidades são:

• Definir a visão do produto (product vision);
• Gerenciar o retorno de investimento (ROI);
• Apresentar ao time os requisitos necessários para a
entrega do produto;
• Priorizar cada requisito de acordo com seu valor para o
negócio/cliente;
• Gerenciar a entrada de novos requisitos e suas
priorizações;
• Planejar entregas (releases);
• Atuar como facilitador quando mais de um cliente estiver
envolvido no projeto;
• Garantir que Especialistas de Domínio estejam disponíveis
para o time.
OS PAPÉIS EM SCRUM
O Scrum Master (SM)
O papel do Scrum Master, diferentemente dos gerentes de
projeto na maioria das práticas e metodologias, difere do
tradicional “comando e controle”. Em Scrum, um Scrum
Master trabalha com e, principalmente, para o time.

• Permitir que o time seja auto-gerenciável;
• Garantir que os caminhos para a comunicação do time
estejam abertos permanentemente;
• Garantir e auxiliar o time a seguir corretamente as
práticas do Scrum;
• Remover qualquer impedimento que o time encontre;
• Proteger o time de interferências externas para garantir
que sua produtividade não seja afetada;
• Facilitar as reuniões diárias.
OS PAPÉIS EM SCRUM
Os membros do time
Um membro do time é alguém que esteja comprometido a
fazer o trabalho necessário para atingir a meta de uma
sprint. Em Scrum não temos arquitetos, testers ou
programadores, temos sim, membros com perfis de
arquiteto, de tester ou de programador...mas que podem
atuar em papéis secundários para garantir o alcance da
meta.

• Definir a meta da sprint;
• Estar comprometido com o trabalho e com a alta
qualidade;
• Trabalhar seguindo a visão do produto e meta da
sprint;
• Colaborar com outros membros do time e ajudar a
torná-lo auto-gerenciado;
• Estimar os itens do backlog e garantir o esforço
necessário para que as estimativas sejam realistas;
• Participar das reuniões diárias;
• Manifestar impedimentos.
OS PAPÉIS EM SCRUM
Fluxo simples
Coloca itens Pegam itens

(priorizado) Time
Product Owner Colocam

Product Backlog
O que sobrar, devolvem
Sprint Backlog
Scrum Master
ONDE ESTAMOS?
sua empresa Scrum
O CONCEITO DE SPRINT
Características
A Sprint é um time-box de 2, 3 ou 4 semanas no qual o time do projeto irá produzir uma parte
do produto definida pelo cliente;
O conceito de Sprint nos remete à necessidade de estarmos frequentemente entregando algo

de valor para o cliente. Diferentemente dos modelos “tradicionais”, onde você desenvolve o
produto em um longo período de tempo e, apenas no final – com o produto “pronto” - o
entrega ao cliente, em Scrum você sempre entregará “parte” do produto em pequenos
intervalos de tempo, sendo que esta “parte” é a prioridade do cliente, ou seja, o que ele
realmente está precisando naquele momento;
Uma Sprint deve ser “empreendida” por um time multi-funcional com não mais que nove
membros;
Cada Sprint deve ter uma meta específica que represente o desejo do cliente para aquele time-
box específico;
Os membros do time da Sprint são os responsáveis por estimar os itens que compõem o desejo
do cliente e dar a palavra final do que será possível ser desenvolvido naquele time-box.
Composição
Uma Sprint é composta das seguintes etapas:
• Planejamento (Sprint Planning Meeting): A reunião de planejamento da Sprint é um time-

box composto de duas partes, sendo cada uma delas com duração de metade do tempo
disponível para a reunião. Na primeira parte, o time deverá definir a meta da Sprint e
selecionar os itens do Backlog que poderão ser desenvolvidos no tempo disponível. Na
segunda parte, o time deverá gerar o Sprint Backlog, que é formado pela decomposição em
tarefas dos itens selecionados na primeira parte da reunião, após isso deverão, caso
necessário, realizar o ajuste da meta da Sprint;
• Execução (The Sprint): É aqui que a produção da “parte” do produto selecionada é
realizada. O Scrum não prevê processos de engenharia, o comum aqui é utilizar práticas
com este foco para serem utilizadas na execução do Sprint;
Composição
• Revisão (Sprint Review): O resultado da Sprint deve ser apresentado para o cliente. Os
itens de Backlog deverão ser avaliados para verificar se estes foram satisfeitos ou não. Por
fim, deverá ser verificado se a meta da Sprint foi ou não atingida;
• Retrospectiva (Sprint Retrospective): Nesta reunião o time deverá analisar o que foi feito
de forma adequada durante o Sprint e o que ainda pode ser melhorado.
A idéia é aprender com a experiência para melhorar nas próximas Sprints.
The dark side of agile
Scrum não fala nada Hmmmm... Scrum não

sobre a engenharia do fala nada sobre o
produto. Isto significa almoço. Isto significa que
que ela não é almoçar não é
importante? importante?
Cancelamentos
Uma Sprint pode ser cancelada antes da sua
finalização nas seguintes situações:
• O time pode cancelar uma se sentirem que não

conseguirão atingir a sua meta;
• Gerentes podem cancelar uma Sprint caso

fatores externos influenciem diretamente no
valor da meta da Sprint;
• Caso uma Sprint seja cancelada deve se iniciar

imediatamente o planejamento da próxima
Sprint.
ONDE ESTAMOS?
sua empresa Scrum
PRODUCT BACKLOG
Entendendo
O primeiro passo em um projeto Scrum é de responsabilidade do Product Owner, que deve
articular a visão do produto;
O Product Backlog representa esta visão, ele deve ser apresentado no formato de uma lista
com itens priorizados e ordenados de acordo com o valor que representam para o cliente e
negócio;
O Product Backlog irá existir por todo o ciclo de vida do projeto (e não da sprint), e é
regularmente atualizado pelo Product Owner para refletir as mudanças e necessidades do
cliente, mudanças estratégicas ou tecnológicas, novas idéias, enfim...mudanças;
Um Product Backlog é composto de vários tipos de itens: funcionalidades, requisitos de

desenvolvimento, exploração técnica, estudo, documentação, bugs, etc.
Apenas um Product Backlog deve existir, e ele deve definir uma visão de tudo que precisa ser
feito;
As estimativas devem ser realizadas pelo time, mas deve ser de compreensão de todos que
elas são apenas estimativas, e podem ser bastante imprecisas, servindo apenas para atribuir
itens do Product Backlog às Sprints.
PRODUCT BACKLOG
A física do Product Backlog
Alta prioridade
Cada Sprint implementa os requisitos de prioridade mais alta
Cada novo requisito é

priorizado e inserido no
Product Backlog pelo
Product Owner a qualquer
momento
Requisitos podem ser repriorizados pelo

Product Owner a qualquer momento
Requisitos podem ser

removidos do
Product Backlog pelo
Product Owner a qualquer
momento
Baixa prioridade
Copyright Scott Ambler, 2004
PRODUCT BACKLOG
Exemplo
Prioridade Item Descrição Est

Urgente
1 Refactoring do banco de dados 32
2 Relatório de vendas por unidade e período 8
3 Suporte a cartão de crédito Visa no processo de vendas 13
4 Relatório gerencial com estatísticas de vendas 5
Alta
5 Alterações na tela de entrada do sistema 5
6 Estudar nova versão da framework de mapeamento objeto/relacional 5
7 Consulta parametrizada de vendas 3
8 Melhoria na criptografia de transferência de dados 8
9 Suporte a cartão de crédito Aura no processo de vendas 8
10 Criação de Help 13
11 Implementar internacionalização 8
12 Validação de tipo de licenciamento (concorrente/nomeada) 5
13 Exportação de venda no formato Excel 3
14 Relatório parametrizado de vendedores e contas 5
Média
16 Consumo de Web Services dos Correios para preenchimento de endereço através de CEP 13
17 Criação de biblioteca de temas para o usuário 13
PRODUCT BACKLOG
Perguntas e Respostas
P: O Product Owner pode fazer alterações no Product Backlog durante a execução de uma
Sprint?
R: Sim, e é encorajado a isso, lembrem-se que em Scrum mudanças são sempre bem vindas. No
entanto, atente para o fato de que durante uma Sprint o time não está mais olhando para o
Product Backlog, mas sim para o Sprint Backlog e este não deve ser alterado. Quando a Sprint
corrente for finalizada, aí sim o time vai novamente olhar para o Product Backlog, que deve
estar extremamente atualizado.
P: Em que formato e em qual nível de detalhamento os itens do Product Backlog devem ser
escritos?
R: Não é o Scrum que deve definir isso, mas sim você e seu time! Qual o nível de detalhamento
que vocês acham que deve ser ideal para este projeto? Em que formato fica de melhor
entendimento para o time? O Scrum não diz para você detalhar muito ou pouco, apenas o
encoraja a ter bom senso para definir isso em cada projeto e/ou time a ser trabalhado.
Pergunte ao seu time!
PRODUCT BACKLOG
Outro exemplo
Prioridade Item Descrição Est Notas

Urgente
1 Refactoring do banco de dados 32 Focar na estrutura de normalização

2 Relatório de vendas por unidade e período 8
3 Suporte a cartão de crédito Visa no processo de vendas 13 Seguir “Guia Visa para Aplicações”; Criar
diagrama de sequências
Alta

6 Estudar nova versão da framework de mapeamento objeto/relacional 5
7 Consulta parametrizada de vendas 3 Usar paginação de 10 em 10 para

resultado
8 Melhoria na criptografia de transferência de dados 8 Consultar depto. Infra. sobre problemas

com a atual
9 Suporte a cartão de crédito Aura no processo de vendas 8

10 Criação de Help 13 Consultar padrão em O:\Padroes\Ajuda
11 Implementar internacionalização 8
12 Validação de tipo de licenciamento (concorrente/nomeada) 5 Criar diagrama de sequência
13 Exportação de venda no formato Excel 3
14 Relatório parametrizado de vendedores e contas 5
Média
16 Consumo de Web Services dos Correios para preenchimento de 13

endereço através de CEP
17 Criação de biblioteca de temas para o usuário 13
ONDE ESTAMOS?
sua empresa Scrum
SPRINT PLANNING MEETING
Regras
A Sprint Planning Meeting ou Reunião de Planejamento, é dividida em duas partes, e entra em
cena no início de cada Sprint.
Além de todos os comprometidos (PO, SM e Time), alguns envolvidos podem ser convidados a
participar em determinados momentos da reunião, desde que agreguem valor à mesma e
tenham seu convite aprovado pelo Product Owner.
Pela prática, percebemos que a duração desta reunião segue a seguinte tabela:
Duração
Reunião de Planejamento
Sprint
#1 #2
4 semanas 4h 4h
3 semanas 3h 3h
2 semanas 2h 2h
Sprint Planning Meeting – parte I
Na primeira parte, o Product Owner e o time, sendo facilitados pelo Scrum Master, realizam
uma revisão no Product Backlog, discutindo sobre o propósito e metas de cada item e dando a
oportunidade para que o Product Owner exponha seus desejos. O time seleciona os itens que
acredita que possam ser desenvolvidos na próxima Sprint e define a meta.
O Product Backlog deve ter sido preparado pelo Product Owner antes da reunião de
planejamento. O Scrum Master deve auxiliá-lo nesta tarefa.
Prioridade Item Descrição Est

Meta do Sprint:
Urgente
1 Refactoring do banco de dados 32
2 Relatório de vendas por unidade e período 8 Refatorar banco de dados e

3 Suporte a cartão de crédito Visa no processo de vendas 13 implementar relatórios de
vendas necessários para as
Alta

tomadas de decisões nos
6 Estudar nova versão da framework de mapeamento 5 finais de trimestre.
objeto/relacional
7 Consulta parametrizada de vendas 3
• Velocidade é uma medida da produtividade do time;
• Representa a taxa de trabalho que o time conseguiu completar durante um Sprint;
• Serve de guia para o planejamento de Sprints.

Por exemplo, se na Sprint anterior um time foi
capaz de completar 55 pontos, esta quantidade de trabalho realizado passa a ser a
velocidade do time e contribuirá bastante para o planejamento da próxima Sprint;
• Serve de guia para o planejamento de Releases e progresso do projeto. Por exemplo, se na

Sprint – de 30 dias – o time foi capaz de completar 55 pontos, provavelmente precisará de
mais 3 Sprints para completar os 165 restante no Product Backlog;
• Velocidade pode ser calculada em horas, pontos ou da forma que o time ache apropriado;
Quando não tivermos executando ainda nenhuma Sprint, não teremos como saber a
velocidade do time. Desta forma não teremos nenhum guia para nos ajudar a definir quanto
podemos fazer em uma Sprint. O que fazer?
• Caso algum projeto utilizando Scrum tenha sido realizado antes deste, verifique qual foi a
velocidade da última Sprint. Caso o time seja o mesmo – ou tenha características
semelhantes – isto deverá funcionar.
• Execute uma “mini-sprint” para completar alguns itens do Product Backlog. Desta forma
você possuirá uma velocidade inicial.
Product Backlog
Selecionar
Sprint Backlog
Como? Não sei
nossa velocidade.
Sprint
Mini-Sprint Backlog
Backlog Executado com Velocidade Inicial:
13 pontos (ou X 34 pontos (ou X*3
horas) horas)
ATIVIDADE
Jogo da velocidade
Quantas bolas de tênis você e seu time

conseguem colocar no cesto em 2
minutos?
• Durante esta reunião o Product Owner pode ainda realizar
alterações nas prioridades do Product Backlog.
• Durante esta reunião devemos também discutir sobre
estimativas iniciais ou revisão/adaptação das estimativas dos
itens do Product Backlog;
• O esforço estimado para os itens selecionados deve ser
negociado entre o time e o Product Owner, sempre praticando
o bom senso e não sendo influenciados por alguma pressão
exercida por nenhuma das partes;
• Existem diversas técnicas de estimativas que podem ser
utilizadas em projetos Scrum. O Planning Poker é uma das
mais populares, onde, através de cartas com numeração
seguindo a tabela de Fibonacci, os membros do time
“sugerem” um tamanho (size) para os itens do Product
Backlog.
Estimativas, estimativas... como medir criatividade?
Richard Feynman, ganhador do prêmio Nobel de física
em 1965 foi obrigado a fazer um exame médico para o
exército.
Psiquiatra: Quanto você valoriza a vida?

Feynman: Sessenta e quatro
P: Por que você disse sessenta e quatro?
F: Como você espera que se meça o valor da vida?
P: Não! Eu quero dizer, por que você falou “sessenta e
quatro” e não “setenta e três”, por exemplo?
F: Se eu tivesse dito “setenta e três”, você faria a
mesma pergunta!
Planning... Poker?
• O Planning Poker vem sendo a melhor técnica utilizada por times em projetos que utilizam
processos ágeis;
• O Planning Poker combina opinião de especialistas, analogia, bom senso e uma forma
agradável para se gerar estimativas;
• Todos os membros de um time devem participar do Planning Poker, isto inclui:

programadores, testers, DBAs, analistas, designers e outros;
• Os números da sequência de Fibonacci é são um dos mais utilizados como valores válidos
para estimativas através do Planning Poker;
• O Planning Poker deve ser aplicado para qualquer novo Item do Product Backlog (Product
Backlog Item), ou mesmo para itens que precisem ser reestimados;
• Estimativas de itens do Product Backlog devem ser feitas em tamanho.
Como funciona o Planning Poker?
• Cada participante deve possuir o seu conjunto de cartas contendo os valores válidos, de
acordo com a escala adotada;
• Para cada Product Backlog Item a ser estimado, o facilitador (normalmente o Product
Owner ou Especialista de Negócio) deve realizar uma breve descrição;
• Após todas as dúvidas sobre o item serem respondidas, cada membro do time deve
escolher uma carta representando a sua estimativa. A carta selecionada não deve ser vista
pelos outros membros do time enquanto todos ainda não tenham selecionado a sua;
• Todos devem, no mesmo momento, mostrar sua carta de estimativa;
• Se as estimativas divergirem, os participantes que apresentaram carta com maior e menor

valor devem explicar o motivo que o levaram a escolhê-la.
• Isto não deve de forma alguma ser feita de forma agressiva, ou mesmo defensiva, mas
apenas como um troca de conhecimento entre visões diferentes sobre o esforço necessário
para a conclusão de um item.
Como funciona o Planning Poker?
• Após as devidas explicações, inicie um novo round repetindo o ciclo, até que haja um
consenso quanto ao tamanho do item;
• Normalmente, as estimativas entram em convergência já no segundo round, ou no máximo

no terceiro. Mas caso isso não aconteça, o ciclo deve ser continuado.
Baseado em: Estimating & Planning – Mike Cohn
ATIVIDADE
Estimando com Planning Poker
• O instrutor apresentará um conjunto de livros que
deverão ser lidos na próxima Sprint.
• Através do Planning Poker vamos estimar qual o

“tamanho” estimado para cada livro, de acordo com sua
quantidade de páginas, grau de dificuldade, língua, etc.
ATIVIDADE
ATIVIDADE
VÍDEO
Experiências com Planning Poker
Por que o Planning Poker funciona?
• Porque o Planning Poker apresenta múltiplas opiniões de especialistas quanto à estimativa
de um item, e como Scrum trabalha com times multi-funcionais, é sempre importante ter
um consenso quanto a este fator;
• Porque o Planning Poker estimula o dialogo durante os rounds, e cada membro do time
tem que explicar para todos os outros membros o porque estimou o item com aquele
tamanho. Todo este processo gera compartilhamento de conhecimento;
• Estudos mostram que estimas feitas em grupo vem sendo bem mais bem sucedidas que
estimativas individuais;
• Porque estimar com Planning Poker é divertido!
Baseado em: Estimating & Planning – Mike Cohn
Sprint Planning Meeting – parte II
• A segunda parte da reunião de planejamento deve ocorrer imediatamente após a
finalização da primeira;
• O Product Owner deve estar disponível para, caso necessário, detalhar algum item ou
remover dúvidas quanto ao objetivo do mesmo;
• O time deve elaborar a estratégia de desenvolvimento que será utilizada para que a meta
da Sprint seja atingida. Ao final desta reunião eles devem saber responder como
construirão as funcionalidades do produto durante o Sprint;
• Essas estratégias são geradas a partir do detalhamento dos itens do Product Backlog. As
tarefas geradas através desse detalhamento é chamada de Sprint Backlog;
• Os membros do time devem escolher suas tarefas e então estimá-las em horas;
• Tarefas devem ter de 4 a 16 horas de duração. Tarefas maiores deverão ser quebradas em
duas ou mais.
Características do Sprint Backlog
• Itens do Product Backlog devem ser decompostos em tarefas (Tasks);
• As tarefas devem ter estimativas de 4 a 16 horas, se maior que isso deve ser quebrada em
mais de uma tarefas;
• Qualquer membro do time pode adicionar, remover ou alterar tarefas do Sprint Backlog;
• As tarefas são escolhidas pelos membros do time, e não designadas a eles.
Sprint Backlog
Item Descrição Tempo
1 Refactoring do banco de dados
Mapear tabelas que serão refatoradas 6h
Definir estratégia de refatoração 2h
Montar/gerar script de refatoração 8h
Aplicar script de refatoração 2h
Avaliar eficiência da refatoração 6h
ATIVIDADE
Jogo do Planejamento
• O Product Owner deverá entregar a cada equipe um
Product Backlog priorizado representando os desejos de
seu cliente;
• Planejamento
• A equipe deve estimar os itens do Product
Backlog;
• A equipe deve selecionar os itens do Product
Backlog que poderão ser entregues no final do
próximo Sprint;
• Execução
• A equipe deve executar as atividades do Sprint
• Revisão
• O que deveria ter sido entregue? O que
realmente foi entregue?
• Retrospectiva
• O que está bom? O que pode ser melhorado?
• Próximo Sprint
ONDE ESTAMOS?
sua empresa Scrum
DAILY MEETING
Reunir todo dia? Impossível!
Uma vez que a Sprint tenha sido iniciada, emerge então uma
das principais práticas do Scrum: as reuniões diárias (Scrum
Daily Meetings)
Uma Scrum Daily Meeting é uma reunião diária, com duração

exata de 15 minutos, que devem sempre ser realizada no
mesmo local e horário e sempre com a participação do
Scrum Master (facilitador) e dos membros do time
Cada membro deve relatar ao time sobre os progressos e

obstáculos que vem encontrando em seu caminho. Em suma,
três perguntas devem ser respondidas por cada um deles:
1. O que fiz (quanto andei) desde a última reunião diária?
2. O que pretendo fazer (quanto andarei) até a próxima
reunião diária?
3. Estou encontrando impedimentos? Quais?
ATIVIDADE
Scrum from Hell
Você está preparado para

enfrentar as armadilhas
das reuniões diárias?
DAILY MEETING
O quadro de acompanhamento
Tarefas Tarefas Tarefas Tarefas

Item Horas
desejadas em andamento para inspeção finalizadas
Aplicar script de Montar script de Determinar tarefas Mapear tabelas

refatoração refatoração para o script para refatoração
Refactoring do
banco de dados
24
02 08 02 06
13 Avaliar eficiência
da refatoração
06 Estimativa em
horas
Estimativa em
tamanho
Relatório de vendas
por unidade e período
21
DAILY MEETING
O quadro de acompanhamento
DAILY MEETING
Sprint Backlog
Sprint Backlog Esforço Restante
Nov/06
Item Descrição Resp. Tempo
11 12 13 14 15 16
Total de esforço em homem/hora 138 101 87 62 48 37 14

1 Refactoring do banco de dados 24h 16 12 12 6 6 0
Mapear tabelas que serão
PR 6h 6 0 0 0 0 0
refatoradas
Definir estratégia de refatoração LF 2h 2 0 0 0 0 0
Montar/gerar script de refatoração AT 8h 8 8 4 4 0 0
Aplicar script de refatoração AT 2h 2 2 2 2 0 0
Avaliar eficiência da refatoração LF 6h 6 6 6 6 2 0
DAILY MEETING
Sprint Burndown
• Após a reunião diária, os membros do time atualizam o montante de tempo que falta para
completar cada tarefa do Sprint Backlog. Esta informação é gravada em um gráfico
denominado Sprint Burndown. Este gráfico mostra, dia após dia, a quantidade de horas que
faltam ser completadas para o atingimento da meta da Sprint;
• Através do Sprint Burndown a equipe consegue rapidamente identificar problemas no

ritmo do time e tomar as providências necessárias.
Burndown
500
450
400
350
300
250
200
150
100
50
0
10/03/06 16/03/06 22/03/06 28/03/06
ONDE ESTAMOS?
sua empresa Scrum
SPRINT REVIEW
E o resultado foi...
• Após a finalização de uma Sprint, é hora de realizar a
Sprint Review;
• Aqui deveremos avaliar:
• O que estou entregando?
• O que eu deveria estar entregando?
• Nesta atividade a equipe irá realizar uma apresentação
do produto que foi gerado (incrementado) durante a
Sprint, focando nas tarefas do Sprint Backlog;
• Participam da Sprint Review o Product Owner, o Scrum
Master, os membros do time, clientes, stakeholders,
executivos e qualquer pessoa que esteja interessada no
resultado da Sprint;
• Esta apresentação dura normalmente entre 30 minutos
e 1 hora e deve ser realização no formato de demo, ou
seja, PowerPoints são completamente dispensáveis;
• Qualquer participante da Sprint Review deve ser
encorajado a realizar perguntas e fornecer sugestões.
SPRINT REVIEW
Revisar, analisar e organizar
Product Backlog Protótipo do produto Condição de negócio e

tecnológica atual
Revisão, aprendizado e organização
ONDE ESTAMOS?
sua empresa Scrum
SPRINT RETROSPECTIVE
Aprendendo com os acertos, mas principalmente com os erros
• A Sprint Retrospective é uma das ferramentas mais importantes para que você obtenha
sucesso com Scrum;
• Esta é a oportunidade que o time tem para discutir sobre o que funcionou e o que não
funcionou durante a Sprint;
• Product Owner, Scrum Master e os membros do time devem participar da retrospectiva.

Uma boa estratégia é convidar alguém neutro para facilitar a sessão;
• A estrutura da Sprint Restrospective é bem simples. Divida um quadro branco ou poster em

duas áreas com os seguintes títulos: “O que funcionou bem?” e “O que pode ser
melhorado?”. Após isso, cada membro deve colocar post-its em cada uma das áreas
indicando os itens que, em sua opinião, merecem estar ali;
• Então, o time visualiza os itens citados, discute sobre e planeja ações a serem tomadas para
a próxima Sprint.
ATIVIDADE
Scrum 59 Game
1. Defina os papéis no time
2. O Product Owner deve priorizar o Product Backlog;
3. O time deve estimar os itens o Product Backlog;
4. Realize uma Sprint Planning Meeting
Tempo: 10 minutos
a. Selecione 5 itens do Product Backlog para
compor a Sprint;
b. Decomponha cada item em 2 ou 3 tarefas;
5. Conduza um dia de desenvolvimento
Tempo: 10 minutos
6. Conduza um Daily Meeting
Tempo: 5 minutos
7. Conduza um dia de desenvolvimento
Tempo: 10 minutos
8. Conduza uma Sprint Review;
Tempo: 5 minutos
9. Sprint Retrospective com o grupo;
Tempo: 19 minutos
SPA PARA CÃES
Produto: “Flyer” de divulgação
• Criar nome e logo da empresa;

• Criar estrutura gráfica do “flyer”;
• Definir os principais atrativos do SPA;
• Definir a estrutura do pacote “King Dog”;
• Definir localização do Spa;
• Montar um pacote para cães europeus de passagem
pelo Brasil;
• Informe como o cliente poderá conseguir mais
informações;
• Montar um pacote para “noivas”;
• Escrever testemunhos;
• Definir valores e formas de pagamento para os pacotes;
• Fornecer serviço de câmbio para os turistas;
• Definir o menu completo de uma semana no spa;
• Definir enxoval de estadia;
• Definir programa de fidelidade e benefícios;
• Montar um pacote focado para cães argentinos;
• Bio completa dos membros do staff.
ATIVIDADE
Get Scruuuuuum!
Associe os elementos da esquerda com os elementos da direita:
• Product Backlog • Tarefas (tasks)

• Sprint Review Meeting • Product Owner
• Scrum Master • Time multi-funcional
• Sprint Backlog • Processo iterativo
• Chicken • Scrum Retrospective
• As 3 perguntas • Auto-gerenciamento
• Sprint Planning Meeting • Membro do time
• Daily Meeting • Ken Schwaber
• Burndown Chart • The New New Product Game
• Planning Poker • Caso de sucesso com Scrum
• Sprint • Scrum flow
PARTE II – COMO ADOTAR SCRUM EM SUA EMPRESA
ONDE ESTAMOS?
sua empresa Scrum
SCRUM MASTER – O LÍDER DA BANDA!
Você está preparado para assumir este papel?
O dia-a-dia de um Scrum Master
• Remover as barreiras entre desenvolvimento e cliente;
• Ensinar o cliente como maximizar o ROI e atingir seus objetivos através do Scrum;
• Melhorar o dia-a-dia dos membros do time facilitando a criatividade e o fortalecimento;
• Melhorar a produtividade do time de qualquer forma possível;
• Melhorar as práticas de engenharia e ferramentas para auxiliarem o time no alcance das
metas;
• Combater a ilusão do comando-controle;
• Priorizar os impedimentos e combatê-los;
• Assegurar-se que todos os membros do time estão fazendo o que se comprometeram a
fazer;
• Determinar onde o Scrum está, comparado com onde poderia estar;
• Auxiliar o Product Owner com o Product Backlog;
• Garantir o uso do Scrum;
• Facilitar reuniões;
• Lembrar-se freqüentemente que um Scrum Master NÃO possui autoridade
Qualidades necessárias para um Scrum Master
Responsável
Na maioria das organizações, responsabilidade é atribuída juntamente com a autoridade

necessária para se executar um tarefa com sucesso. Scrum Masters não possuem autoridade e,
portanto, devem ser capazes de assumir a responsabilidade do projeto sem esta atribuição.
O papel de um ScrumMaster é similar ao de um maestro de uma orquestra. Ambos devem

fornecer a orientação e a liderança em real-time a um time talentoso que une-se para criar algo
que não conseguiriam sozinhos. O maestro Keith Lockhart do PNF de Boston disse de seu
papel, “as pessoas supõem que quando você se transforma em um maestro você quer estar na
frente de um time ostentando o seu poder. Eu não sou um junkie do poder, eu sou um junkie
da responsabilidade.”
Scrum Master é responsável, e não poderoso.
Baseado em: Leader of the band – Mike Cohn
Comunicativo
Se você é conhecido por todos da empresa, passa horas do dia dialogando com seus colegas
sobre os assuntos mais diversos possíveis e é reconhecido na empresa como uma pessoa
“popular”...não, não são estas as qualidades de comunicação que são necessárias em um
Scrum Master. Um Scrum Master deve ser comunicativo no sentido de “dar comunicação para
facilitar a comunicação”, ou seja, para manter o projeto no foco e a equipe em volta do Scrum,
o Scrum Master precisa garantir que a equipe esteja se comunicando de forma eficaz...para
isso ele precisará exercer qualidade na sua comunicação.
As pessoas somente conseguem se entender, se a comunicação for eficiente. Isto é, se as

pessoas conseguem transmitir suas idéias de tal forma que as outras entendam o seu
significado. Muitas vezes será necessário construir pontes entre uns e outros.
O Método de Sócrates é um grande aliado para facilitar uma comunicação rica;
Um bom Scrum Master deve saber interpretar as quatro dimensões de uma mensagem:
conteúdo objetivo, auto-revelação, relação e apelação.
Ouça de verdade, ou seja, preste atenção ao que está sendo dito por baixo das palavras.
Humilde
Um bom Scrum Master não está trabalhando pelo seu ego. Ele deverá frequentemente realizar
o Exame do Orgulho, avaliando sempre “O que ajudou a realizar”, e não “O que realizou”;
Mais do que atender às suas necessidades, um bom Scrum Master deve estar sempre disposto
a fazer o que for necessário para ajudar o time a alcançar seu objetivo;
Um Scrum Master humilde reconhece o valor em todos os membros do time e, desta forma, os
conduz a terem a mesma opinião.
Facilitador
Um bom Scrum Master trabalhará para assegurar uma cultura de colaboração dentro do time;
O Scrum Master deve ser capaz de, através de muita facilitação, fazer com que os membros do
time consigam expressar suas impressões e dores;
Ele deve criar uma atmosfera colaborativa através de facilitação, palavras e ações;
Combater atitudes impróprias dentro do grupo faz parte do trabalho para criar esta atmosfera;
Comprometido
Por mais que seja possível ser um Scrum Master partial time, o ideal é que esta pessoa tenha
todo o seu tempo disponível para servir ao time... acredite, há trabalho suficiente para isso;
Caso seja necessário um Scrum Master dividir papéis, evite multi-tarefa! Tente adotar uma
política na qual, por exemplo, pela manhã você seja Scrum Master e pela tarde seja Analista de
Sistemas, evitando sempre ser os dois ao mesmo tempo;
Um bom Scrum Master deve estar comprometido com eliminação de impedimentos.

Impediments Backlog sem progresso pode significar pouco compromisso do Scrum Master;
Scrum Master é um “pig”, portanto deve sentir o mesmo nível de compromisso que os
membros do time.
Influente
Para ser bem sucedido como Scrum Master você precisará – freqüentemente – influenciar
pessoas, dentro e fora da equipe;
Dentro do time, o Scrum Master precisará ser influente para poder aplicar as práticas do Scrum
da forma correta;
Externamente, o Scrum Master terá que ser influente junto ao Product Owner para que este se
sinta dentro do time e se esforce para entender as necessidades do cliente. Poderá ser
solicitado para “vender” Scrum para escalões mais altos e outros departamentos;
Para mudar hábitos e redirecionar a cultura de equipes e até de uma empresa inteira, um bom
Scrum Master deverá ter excelentes habilidades de persuasão.
Conhecedor
Para um time acreditar que um Scrum Master pode realmente serví-lo (e consequentemente
ajudá-lo a atingir um objeto) este deve ter conhecimentos e habilidades comprovadas e
admiradas pelo time;
Um Scrum Master que não tem seu conhecimento admirado pelo time cai rapidamente em
descredito, e morre;
Um bom Scrum Master deve ter conhecimento técnico, de mercado e ser especialista em
assuntos que sejam vitais para ajudar o time a ser bem sucedido;
Manual de um Líder Ágil
1. Cultive o prazer
• Por que tenho prazer exercendo este papel?
• Como demonstrarei esse prazer por meio da forma como sirvo e lidero as pessoas ao meu
redor?
Lembre-se: O Prazer é sua principal estratégia de retenção de pessoal.
2. Produza energia
O que produz energia: prazer, grandes idéias, princípios elevados, superação de metas,
trabalho interessante, desafios estimulantes e visão instigante do futuro.
• Qual efeito minha ação terá na energia das pessoas ao meu redor?
Manual de um Líder Ágil
3. Inspire audácia
Não permita que as crenças de outras pessoas se tornem as suas.
• Como vamos mudar o mundo do nosso cliente com este projeto?
4. Apresente prova
Você é um líder ágil de verdade? Então prove! Prove aos outros. Prove a si mesmo.
• O que fiz hoje que confirma meu compromisso com este time?
• O que farei amanhã para demonstrar o poder das minhas convicções?
ONDE ESTAMOS?
sua empresa Scrum
ESTUDO DE CASO
Kingsoftware
KINGSOFTWARE
Conhecendo a empresa
A KINGSOFTWARE é uma empresa especializada no desenvolvimento de sistemas para a área
agrícola. Ela possui um produto chamado Kingsoftware Agrotech que é líder de mercado na
Jamaica e em outros países da América Central.
Recentemente surgiu a necessidade do desenvolvimento de um novo produto, um software

voltado para a pecuária e batizado pela empresa como Kingsoftware Pequatec.
Eles possuem uma experiente equipe de desenvolvedores e analistas, e um gerente de produto

(Bob, produto AgroTech), foi ele quem liderou o traumático e improvisado desenvolvimento do
produto, e é quem cuida da evolução e manutenção do mesmo.
Além disso, a empresa possui uma gama de

clientes que – em sua maioria – está amplamente
satisfeita com o produto.
KINGSOFTWARE
O time
Mr. Cosmos, o diretor da Kingsoftware Bob, gerente do produto AgroTech
Ziggy, Taylor e Johnny, os chefes de desenvolvimento
KINGSOFTWARE
Conversa entre Mr. Cosmos e Taylor
Mr. Cosmos (diretor): Sabe Taylor, estamos com esse desafio pela frente. Tenho certeza que
caso consigamos produzir o PequaTech em 12 meses teremos um grande mercado para
trabalhar. Mas tenho um sentimento ruim, tenho a impressão de que não estamos prontos
para fazer isso.
Taylor (chefe de desenvolvimento): Mas como Mr.Cosmos? Nós temos um produto líder de
mercado na mão, uma equipe de desenvolvimento experiente, uma demanda para um novo
produto... o que podemos precisar mais? Tenho certeza que estamos prontos para um novo
projeto!
Mr. Cosmos: Taylor, os tempos mudaram. Você lembra como começamos o Agrotech? Viemos
fazendo tudo aos trancos e barrancos... tanto isso é fato que temos as dificuldades que temos
hoje para manter o produto e, principalmente, para evoluir o produto. Duvido que hoje nosso
clientes tolerem erros que cometemos no passado, eles facilmente pulam para o concorrente,
que não está mais cometendo os mesmo erros.
Taylor: Sim chefe, mas tudo funciona! Nosso clientes estão satisfeitos e não precisam de mais
do que oferecemos... eles só pedem novas implementações e correções relacionadas à
negócio, mas tecnologicamente, o que fornecemos está mais do que bom.
KINGSOFTWARE
Chega Clark, o salvador
Mr. Cosmos, após várias leituras e consultorias, chegou à conclusão de que o que eles
precisavam para o PequaTec era de um Gerente de Projetos. Um profissional com experiência
no mercado, que tivesse qualificações e que pudesse gerar um produto sólido, desenvolvido
com planejamento e, fortemente padronizado e documentado. Afinal, ele havia chegado à
conclusão de que seu desenvolvimento hoje estava uma “bagunça” e, nada melhor do que
“mão-de-ferro” para arrumar uma bagunça, certo?
Clark Tenn, MSC, é gerente de projetos há mais de 08 anos, já tendo participado

de projetos envolvendo mais de U$ 2.000.000, possuía mestrado pela I’m The
Best University, além de publicações em diversas revistas da América Central e
América do Norte.
O último projeto de Clark, que acabara há pouco mais de duas semanas, envolvia
a construção de uma fábrica de calçados em Porto Rico . Este é seu primeiro
projeto de software.
KINGSOFTWARE
Apresentando a metodologia
No primeiro dia de projeto, Clark reuniu sua equipe em um Kick-Off na Fábrica de Software e
explicou rapidamente sobre os processos que seriam utilizados daqui pra frente. Ele falou
sobre a metodologia de desenvolvimento que seria utilizada daqui pra frente, em cascata
(waterfall). Como justificativa pela escolha, ele mencionou sobre a divisão do processo em
fases bem definidas e, principalmente, pelo fato da waterfall ter sido utilizada com sucesso em
vários e vários projetos desde a revolução industrial, ou seja, era um mecanismo consagrado.
KINGSOFTWARE
KINGSOFTWARE
Primeira entrega
Clark: Com licença Mr. Cosmos, é que estou ansioso para lhe mostrar meus relatórios e nosso
resultado de seis meses árduo de trabalho no projeto PequaTech.
Mr. Cosmos: Pode entrar Clark, mais ansioso que você estou eu, afinal de contas os clientes
estão em cima querendo saber notícias do PequaTech, e lembre-se que nos restam apenas 6
meses para o final do projeto...a campanha de marketing está pronta, e a equipe comercial
está na rua. Estamos extremamente excitados...mas vamos lá, me anime mais, mostre-me o
que temos do PequaTech até agora...
Clark: Com prazer Mr. Cosmos, veja que maravilha...
KINGSOFTWARE
Software funcionando?
Clark: Do lado esquerdo temos todas as entrevistas
realizadas com os responsáveis pelo sistema, e veja
que maravilhoso: TODAS ASSINADAS E VALIDADAS POR
ELES! Do lado direito temos o desenho de todas as
telas do sistema, juntamente com relatórios semanais
que gerei... algo como o “diário do projeto”, e temos
mais Mr. Cosmos, criei diversos checklists para que
possamos acompanhar todo o trabalho daqui pra
frente. Além disso temos os 217 casos de uso
documentados e vários diagramas UML. Não é
maravilhoso??
Mr. Cosmos: Hmmm... não estava acostumado com

isso, mas se funciona para prédios e carros, como não
funcionar para software, não é verdade? Ok, Clark,
agora mostre-me o que temos do PequaTech pronto...
Clark: Como assim?? Temos tudo o que lhe mostrei...

os documentos, checklists... e agora sim estamos
prontos para entrar na fase de implementação.
Mr. Cosmos: Hmmm... estou começando a me

preocupar... mas vamos em frente.
KINGSOFTWARE
O que os chefes de desenvolvimento estão achando?
Durante o sétimo mês de projeto, Mr. Cosmos resolveu conversar com os chefes de
desenvolvimento para colher opiniões sobre o projeto PequaTech...
Mr. Cosmos, tenho que ser

sincero com o Sr.. Estou
Taylor
Mr. Cosmos, estamos no achando tudo muito
Johnny caminho certo, é burocrático... e na verdade,
maravilhoso trabalhar já tem algumas coisas que não
com todos os requisitos em concordo. Por exemplo,
mãos, tudo bem estamos limitados
documentado. Apenas fico tecnologicamente... pois
apreensivo com o prazo, ainda usamos a linguagem de
temo que precisaremos de programação I’llSurvive... que
mais tempo para finalizar o não atende mais as nossas
PequaTech. necessidades. Minha solução
foi criar uma biblioteca de
funções para agilizar o MEU
trabalho.
KINGSOFTWARE
O que os chefes de desenvolvimento estão achando?
Ziggy Olha chefia... tenho certeza que nada disso vai funcionar, e
confesso que minha equipe já está bem desmotivada... o
Mauricinho lá só sabe dar ordens e falar pra documentarmos tudo,
exatamente tudo. Meu pessoal não gosta de lidar com papel.
Outra coisa, está muito complicado para entendermos o que está
escrito nos requisitos... alguns são muito detalhados, outros
pouco, outros mais ou menos... e o pior de tudo é que o
desgraçado do usuário que forneceu os dados dos requisitos nunca
sabe explicar direito o que quer, acredite: MUITAS VEZES
DESCONFIO QUE NEM ELE SABE O QUE QUER!
KINGSOFTWARE
Visibilidade de Progresso
Enquanto isso, no desenvolvimento...
Ei Leonard, como está a

implementação da rotina de Cálculo de Corte que você iniciou ontem?
Johnny
Johny, com os requisitos em mãos está tudo como planejado. Estou

com 35% dela finalizada...
Leonard
(programador)
KINGSOFTWARE
No dia seguinte...
Bom dia Leonard, e a implementação da rotina de Cálculo de Corte?

Tudo tranqüilo?
Johnny
Ô... tô com todo o gás... 90% dela fechada...
Leonard
(programador)
KINGSOFTWARE
Três dias depois...
Alguma notícia de Cálculo de Corte, Leonard?
Johnny
Fechando chefe... 90%
Leonard
(programador)
KINGSOFTWARE
Quinze dias depois...
Leonard, e o Cálculo de Corte, ESTAMOS ATRASADOS!!!!
Johnny
Chefe, agora estamos mesmo em 90%... fechando no máximo hoje até

às 18hs...
Leonard
(programador)
KINGSOFTWARE
(In)Visibilidade de Progresso... e conflitos
UM MÊS DEPOIS...
Leonard...ESTOU SENDO PRESSIONADO!!!!!

C-A-D-Ê O CÁLCULO DE CORTEEEEE...
Johnny
AINDA ESTÁ EM 90%....E QUER SABER...TÔ FORA!!!!

NÃO AGUENTO MAIS ESSA PRESSÃO!!!!!!
Leonard
(programador)
KINGSOFTWARE
Plano de Riscos
Clark: Com licença Mr. Cosmos, posso entrar.
Mr. Cosmos: Sim Clark, vamos lá, estou ansioso para saber o motivo de você ter convocado
essa reunião... espero que tenhamos boas notícias. Como anda o projeto?
Clark: Mr. Cosmos, alguns problemas apareceram... mas nada não previsto no nosso Plano de
Riscos do Projeto... mas precisamos de algumas ações imediatas...
Mr. Cosmos: O que você chama de ações imediatas?
Clark: Estamos com problemas para entregar o produto no prazo... mas TENHO uma solução:
Diminuímos a fase de testes em 90% e contratamos mais mão-de-obra para essa reta final.
Precisaremos de mais 06 programadores em nossa equipe. Ah... ia esquecendo, precisaremos
ainda adquirir ferramentas... isso nos dará muita produtividade.
Mr. Cosmos: Clark, estou muito preocupado com tudo isso, a nossa equipe comercial já vendeu
mais de 1.000 cópias do PequaTech... não podemos falhar! Mas confio em você, faça o que for
necessário para o sucesso do projeto. Só isso?
KINGSOFTWARE
Integração com o cliente
Clark: Na verdade tenho um outro assunto, mas esse o Sr. vai gostar.
Mr. Cosmos: Então diga...
Clark: Bem... solicitei o cancelamento do contrato com um de nossos clientes que estavam
servindo de base de requisitos para o projeto PequaTech...
Mr. Cosmos: O Q-U-Ê????
Clark: É que eu estava tendo problemas com este cliente... eles estavam nos fornecendo
requisitos muito vagos, e isto estava afetando a nossa produtividade. Mas NÃO SE PREOCUPE,
tudo estava documentado e assinado pelo cliente, poderemos aplicar-lhes uma excelente
multa!!!
Mr. Cosmos: < entrando em desespero >
KINGSOFTWARE
Comprometimento, espírito de equipe...
Quer saber mano... tô com o

cronograma todo estourado, não
agüento mais esse cara me cobrando...
VOU FAZER UMA “GAMBIARRA” aqui
no código... ninguém vai saber mesmo!
Zabu
(programador)
KINGSOFTWARE
Mais ferramentas, mais “mão-de-obra”: a solução!
NOVOS PROFISSIONAIS NA EQUIPE, GRANDE REFORÇO E SUCESSO GARANTIDO!
Clark: Bom dia Srs., esses aqui são: Billy, Paul, Sabino, Amanda, Dennys e Samantha. Eles nos
ajudarão a fechar nosso projeto nesses últimos 2 meses... por favor, integrem eles ao projeto.
A Amanda e o Paulo conhecem pouco da linguagem I´llSurvive, preciso que vocês os ajudem
nisso.
Johny: Por onde começamos Clark? Tem muita coisa para repassar-lhes... e estamos com nossa
agenda lotada de tarefas para os próximos... bem... 3 meses na verdade.
Clark: Johny meu caro, às vezes você se esquece que nosso projeto teve uma documentação
de alto nível... passe a eles os nossos documentos que tenho certeza que será o suficiente para
iniciarem.
Ziggy: Ora Clark, me desculpe mas o sr. só pode estar brincando. Com tanta pressão, tarefas
atrasadas e prazo no nosso ouvido... já faz mais de 3 meses que não atualizamos a
documentação, ou seja, se eles aprenderem por ali, aprenderão errado!
Clark: Meu Deus, como VOCÊS deixaram isso acontecer??? Bem, esqueçamos a
documentação então... Ziggy você fica responsável por orientar-lhes...
KINGSOFTWARE
KINGSOFTWARE
Projeto Pequatec
KINGSOFTWARE
Avaliando o projeto PEQUATEC...
Na sua opinião, o que contribuiu para o
seu fracasso?
A KINGSOFTWARE PRECISA DE VOCÊ!
Get Scruuuuuuuuuuuuuumm !
Após o fracasso inicial do projeto PEQUATEC, a Kingsoftware está inclinada a utilizar Scrum em
seu próximo projeto...
A primeira missão da sua empresa é:
Convencer a Kingsoftware a
utilizar Scrum.
THE NEW NEW PEQUATEC PROJECT
Agora o seu time será responsável por conduzir o gerenciamento e desenvolvimento do “novo”
projeto do produto PEQUATEC
Os clientes estão pressionando a Kingsoftware... o faturamento da empresa caiu

bruscamente...
CONTO COM VOCÊS!
ONDE ESTAMOS?
sua empresa Scrum
FORMANDO UM TIME ÁGIL
Chame as pessoas certas
Características de times ágeis
• Times compactos que definem, constroem, testam, aceitam e entregam valor em um
timebox;
• Forte comunicação e integração com o dono do valor (Product Owner / Cliente);
• Preparado para responder à mudanças;
• Fornece visibilidade real na distribuição de valor;
• Usam permanentemente “NÓS” e não “EU”;
• São “aconselhados” por mentores/coaches experientes.
Em times ágeis, todos participam
• Product Owner / Cliente /
Especialista do Negócio;
• Gerente de Projeto / Scrum

Master / Agile Coach
• O time de desenvolvimento:
Desenvolvedores, Testers,
Redatores Técnicos,
Arquitetos, etc.)
• Outros membros do time
Práticas ágeis contribuem para a formação de um grande time
Quando um time ágil planeja?
• A cada Sprint;
• Todo dia;
Quem participa do planejamento?
• Todos
Como o planejamento é feito?
• Priorizando o valor do que precisa ser entregue em um timebox;
• Estimando o trabalho e recursos;
• Comprometendo-se a entregar valor.
Um time é ágil quando...
• O time toma suas próprias decisões e se mostra comprometido com estas;
• O Scrum Master / Agile Coach facilita e serve ao time;
• Decisões dirigidas ao consenso, transformando divergência em convergência;
• O time adota práticas que facilitam o aprendizado;
• O vocabulário ágil emerge;
• Todos estão sempre acessíveis ao time para fornecer feedback e remover impedimentos;
• Os membros do time se respeitam... de verdade.
ONDE ESTAMOS?
sua empresa Scrum
APRESENTANDO SCRUM PARA O TIME
Kickoff do projeto
• Convide alguém com experiência prática em Scrum para lhe auxiliar;
• Apresente o Manifesto Ágil, fale sobre porque surgiu Agile e suas vantagens;
• Ensine a teoria de Scrum, e abuse de atividades para mostrar a parte prática; use a
criatividade;
• Fale sobre o ciclo de vida do Scrum, seus artefatos e suas principais atividades;
• Faça um brainstorming sobre como Scrum poderia ser aplicado na empresa, e sobre os
problemas culturais que ameaçariam o seu uso;
• Realize o jogo Scrum 59!
APRESENTANDO SCRUM PARA O TIME
Kickoff do projeto
Mas o mais importante para se ter uma apresentação bem sucedida de Scrum para o seu time,
é conhecer bem a cultura da empresa. A forma com que Scrum é apresentado pode ser
extremamente bem sucedida para uma empresa e um fracasso para outras.
Pense na cultura!
ONDE ESTAMOS?
sua empresa Scrum
AUXILIANDO O PRODUCT OWNER
Um Product Owner tem que entender o que ele é
Devido à forma com que as necessidades do cliente são tratadas em metodologias tradicionais,
inicialmente, é normal o Product Owner se sentir “rebaixado” ao cargo de Analista de Sistemas
ou Documentador... você, como Scrum Master, deve mostrá-lo a verdade sobre isso, e deixar
bem claro que em Agile ele faz parte do time;
O Product Owner manda no Product Backlog!
Quase sempre o Product Owner se sente inseguro ao elaborar um Product Backlog: que
formato seguir? Quão granular devem ser meus Backlog Items?
A melhor estratégia aqui é, decidir juntamente com o time, em que formato o Product Backlog
deve ser apresentado. Sessões de brainstorming funcionam bem.
Um bom Product Owner tem que saber que cada Backlog Item serve como comunicação entre
ele e os desenvolvedores. Ele tem que estar comprometido em fornecer uma boa comunicação
através deste artefato;
Priorização é a chave! Um Product Backlog bem priorizado garante entregas de valor para o
cliente.
AUXILIANDO O PRODUCT OWNER
Algumas técnicas para elaboração de um product Backlog
Desenvolvimento de
Sessões de Facilitação Modelo Abrangente
(FDD)
Brainstorming User Stories

(XP)
Mapas Mentais TOC (Árvores)
ONDE ESTAMOS?
sua empresa Scrum
AUXILIANDO O TIME NAS ESTIMATIVAS
Preparando-se para a reunião de estimativas
• Os participantes da reunião são: Product Owner, Scrum Master e todos os membros do
time;
• Certifique-se que o Product Backlog esteja priorizado;
• Certifique-se que há disponível um conjunto de cartas para a prática do Planning Poker;
• Certifique-se que há tempo disponível – sem interrupções – para a realização da reunião.
AUXILIANDO O TIME NAS ESTIMATIVAS
A reunião
• Inicie a reunião apresentando a meta da mesma e
deixando bem claro a todos o que é uma estimativa
e o que é “estimar por tamanho” e não por tempo;
• O Product Owner deve apresentar qual área do

Product Backlog (normalmente os 20% iniciais)
contém os itens que ele deseja que sejam estimados;
• O Product Owner deve falar sobre cada item,

descrevendo-o e falando de forma abrangente sobre
as regras de negócio do mesmo;
• O time pratica o Planning Poker para estimar cada

item;
• A estimativa em tamanho de cada item é inserida no

Product Backlog;
• Finalize a reunião colhendo um rápido feedback de

todos os membros do time. O que você achou desta
reunião?
ONDE ESTAMOS?
sua empresa Scrum
FACILITANDO O SPRINT PLANNING MEETING PARTE I
Preparando-se para o Sprint Planning Meeting Parte I
• Os participantes da reunião são: Duração
Product Owner, Scrum Master e Reunião de Planejamento
todos os membros do time; Sprint
#1 #2
4 semanas 4h 4h
• Certifique-se que o Product Backlog esteja 3 semanas 3h 3h
priorizado; 2 semanas 2h 2h
• Certifique-se que os Backlog Items estejam estimados;
• Tenha em mãos um calendário com possíveis impedimentos em datas do Sprint (feriados,

ausência prevista de membros, etc...);
• Certifique-se que haja um ambiente físico apropriado para a reunião;
• Tenham em mão anotações com os resultados da Sprint Review e Retrospective referente

à Sprint anterior;
• Certifique-se que a agenda da próxima Sprint esteja pronta, composta de: data inicial e
final, anotações, impedimentos previstos, etc...
FACILITANDO O SPRINT PLANNING MEETING PARTE I
A reunião
O Product Owner deve falar ao time sobre a visão do produto;
O Product Owner e o time devem definir a meta da Sprint;
Durante esta reunião, é permitido que o Product Owner realize alterações de

inclusão,exclusão ou alteração no Product Backlog
O time deve realizar a estimativa dos itens do backlog que não estejam estimados;
O Product Owner e o time, em consenso, escolhem os itens que irão fazer parte do próximo
Sprint, estes itens selecionados são chamados de Selected Product Backlog.
ONDE ESTAMOS?
sua empresa Scrum
FACILITANDO O SPRINT PLANNING MEETING PARTE II
Preparando-se para o Sprint Planning Meeting Parte II
• Os participantes da reunião são: Scrum Master e todos os membros do time. Caso
necessário, pode ser que ajudem a facilitação, tais como: Post-its, canetas, marcadores,
quadro-solicitada a presença do Product Owner (ou Especialista de Negócios designado por
este) para esclarecer dúvidas sobre itens do Selected Product Backlog;
• Certifique-se que o Selected Product Backlog esteja acessível ao time;
• Reúna artefatos branco, flipchart, etc.
FACILITANDO O SPRINT PLANNING MEETING PARTE II
A reunião
• Os membros do time devem decompor cada item do Selected
Product Backlog em tarefas necessárias para entregá-lo, isto
inclui: codificação, testes, reuniões, estudos, documentação,
etc.);
• Se alguma tarefa tiver estimativa superior a 8 ou 16 horas

(depende de sua estratégia de gerenciamento), ela deverá ser
decomposta em mais tarefas;
• Se, ao decompor os itens, o time concluir que o tamanho do

Sprint Backlog está:
• Pequeno: Mais itens do Product Backlog, de acordo

com a prioridade de cada, devem ser selecionados e
decompostos para fazerem parte do Sprint Backlog;
• Grande: Retire do Selected Product Backlog os itens
com menor prioridade e os leve de volta para o
Product Backlog;
• O time reavalia a meta da Sprint e, se necessário, a altera.
ONDE ESTAMOS?
sua empresa Scrum
INICIANDO A SPRINT
3... 2... 1... JÁ!
Após as duas sessões da

reunião de planejamento
(Sprint Planning Meeting) o
Sprint é iniciado
imediatamente, de acordo
com a agenda definida.
ONDE ESTAMOS?
sua empresa Scrum
FACILITANDO O DAILY MEETING
Preparando-se para o Daily Meeting
necessário, pode ser solicitada a presença do Product Owner;
Durante esta reunião, é permitido que o time realize alterações de

inclusão,exclusão ou alteração no Sprint Backlog
• Certifique-se de que o local e horário do Daily Meeting esteja claro para todo o time;
• Certifique-se de que o quadro de acompanhamento esteja visível no ambiente físico em

que será realizada e reunião
A reunião
Todos os membros devem responder:
• O que fiz desde a última reunião?
• O que pretendo fazer até a próxima reunião?
• Estou tendo algum impedimento? Se sim, adicione-o ao Impediments Backlog
As armadilhas das reuniões diárias
Daily Meeting não é “hora do café”: As reuniões diárias (Daily Meetings) devem possuir uma
certa formalidade quanto à local e horário. Não deixe que esta atividade se torne um
“papinho” sobre o projeto em qualquer local e horário.
Daily Meeting não é “conversa sobre futebol”: Se você pretende abrir as reuniões diárias para
participação de pessoas apenas envolvidas com o projeto(chickens), deixe bem claro ao fazer o
convite que o mesmo dá apenas direito a participação como "ouvinte".
Daily Meeting não é “conversa sobre a relação”: Muitas equipes tem confundido os quinze
minutos da reunião diária com momentos de desabafo e resolução de impedimentos. Esta
reunião serve apenas para detectar impedimentos, e não para resolvê-los. Apenas após a
reunião, o Scrum Master deve providenciar uma solução para o impedimento apresentado (de
acordo com sua prioridade);
Daily Meeting não é um “julgamento”: Os times, principalmente aqueles compostos por
membros que não estão habituados a fazer parte de equipes auto-gerenciadas, insistem em
usar os quinze minutos da reunião para reportar-se ao Scrum Master, e na maioria das vezes
se justificando por algum atraso ou problema do gênero. A reunião diária foi criada
principalmente para o time, e não para o Scrum Master.
E é AO time que cada membro deve se reportar.
ONDE ESTAMOS?
sua empresa Scrum
A ENGENHARIA DE SOFTWARE EM SCRUM
Metodologia para Engenharia
• Scrum, como já comentado anteriormente, é uma metodologia focada em práticas para o
GERENCIAMENTO de projetos, não prevendo nenhuma atividade ou prática para a
engenharia ou desenvolvimento do produto;
• É comum, e na maioria das vezes necessário, que você adote uma metodologia que cubra
os processos de engenharia. Scrum pode facilmente se integrar com várias destas
metodologias – principalmente as ágeis.
• O ideal é que você estude algumas metodologias de engenharia e escolha a que mais se
adapta às suas necessidades. Após isso, estude com integra-la com o Scrum.
Sua metodologia de
Extreme Programming engenharia
FDD – Feature Driven

Development Iconix
ONDE ESTAMOS?
sua empresa Scrum
• Sprint Review: Apresentando o • Auxiliando o time no
resultado; planejamento do Scrum Review;
AUXILIANDO O TIME NO SPRINT REVIEW
Preparando o Sprint Review
• Os participantes da reunião são: Product Owner, Scrum Master e todos os membros do
time.
• A meta do Sprint deve estar visível a todo;
• O Selected Product Backlog deve estar visível e acessível a todos;
• O time deve preparar o ambiente para a demo: computador(es), data show, quadros, etc.
AUXILIANDO O TIME NO SPRINT REVIEW
A demonstração
• O time apresenta – de forma demonstrativa - os novos recursos do produto, item a item,
de acordo com a sequência do Selected Product Backlog;
• Se o Product Owner desejar alterar alguma funcionalidade, um novo item deve ser
acrescentado ao Product Backlog;
• Se uma nova idéia de funcionalidade emergir, um novo item deve ser acrescentado ao
Product Backlog;
• Se o time informar sobre algum impedimento ainda existente, incluí-lo no Impediments

Backlog;
ONDE ESTAMOS?
sua empresa Scrum
FACILITANDO A SPRINT RETROSPECTIVE
Preparando a Sprint Retrospective
necessário, pode ser solicitada a presença do Product Owner;
• Artefatos para facilitação (Post-its, marcadores, quadro branco e flipchart) devem estar
disponíveis e acessíveis a todos os participantes;
• Dividir o quadro-branco em três áreas (ou três flipcharts):
• O que pode ser melhorado?
• Quem está no controle? Com duas sub-divisões: “Empresa” e “Time”
FACILITANDO A SPRINT RETROSPECTIVE
A reunião
• Informe a todos o objetivo da reunião;
• Solicite que cada membro fixe post-its descrevendo acontecimentos importantes da Sprint
e acordo com a linha do tempo desenhada no quadro-branco. Defina um timebox para esta
atividade (5 a 10 min.). Cada membro é convidado a fazer uma rápida explanação sobre o
acontecimento citado;
• Em um timebox sugerido de 10 min., solicite aos membros que escreva post-its citando “O
que está bom?” e os fixe na área reservada. Cada membro é convidado a fazer uma rápida
explanação sobre os post-its “O que está bom?” que fixou;
• Repita para “O que pode ser melhorado?”;
• Para cada item de “O que pode ser melhorado?” mova-o para a área “Quem está no
controle?” na sub-divisão apropriada (Time ou Empresa);
• Priorize a lista de impedimentos (Impedments Backlog);
• Finalize a reunião com uma sessão de reflexão de todo o time sobre os resultados da
retrospectiva.
ONDE ESTAMOS?
sua empresa Scrum
REINICIANDO O JOGO
Prontos para recomeçar
Agora, mais experientes, Product Owner, Scrum Master e todo o time estão prontos para fazer
melhor!
Product Owner Scrum Master Time
ONDE ESTAMOS?
sua empresa Scrum
• Lições com o projeto
Kingsoftware;
GRANDES AMEAÇAS DE UM PROJETO SCRUM
Perda de ritmo: Variação no tamanho das Sprints;
“Galinhas” falantes: “Galinhas” são permitidas a falar

durante as reuniões diárias;
“Porcos” ausentes: Frequente ausência de “porcos”

durante as reuniões diárias;
Scrum Master atribuindo trabalho: Scrum Master

delegando tarefas para os desenvolvedores;
A reunião diária é para o Scrum Master: As respostas às

três perguntas das reuniões diárias estão sendo
direcionadas para o Scrum Master;
Papéis especializados: Um time de projeto com arquitetos,

testers, programadores, analistas, etc.
IMPLEMENTANDO SCRUM
PARTE III – EXPANDINDO O USO DE SCRUM
ONDE ESTAMOS?
sua empresa Scrum
SCRUM E RUP
O que é RUP?
• RUP é um framework de processo iterativo e incremental que provê uma abordagem
disciplinada para o desenvolvimento de software;
• Possui duas dimensões:

1. O eixo horizontal representa o aspecto dinâmico do processo e mostra as fases do
ciclo de vida à medida que este se desenvolve;
2. O eixo vertical representa o aspecto estático do processo, como ele é descrito em
termos de disciplinas;
• As disciplinas fundamentais do processo de desenvolvimento de software também estão

presentes na estrutura do RUP.
SCRUM E RUP
O que é RUP?
SCRUM E RUP
É possível?
• Mesmo acreditando que o RUP sozinho satisfaz as necessidades de gerenciamento de um
projeto de software, a IBM acredita que sim, você pode usar práticas do Scrum em projetos
RUP;
• Na minha opinião RUP e Scrum estão bastante distantes, separados principalmente pela
cadeia de valores de cada um. Também acredito que projetos com RUP sendo bem
aplicado possa utilizar algumas práticas do Scrum, mas só isso.
• Não espere que o comportamente de um time RUP – Scrum seja o mesmo de um time
Agile Engineering Methodology - Scrum;
• Se você tem interesse nesta combinação, procure saber mais sobre OpenUP, isto está bem
mais próximo do mundo ágil.
SCRUM E XP
O que é XP?
• Extreme Programming é uma metodologia ágil de desenvolvimento de software
designada, apoiada em um pequeno conjunto de valores, princípios e práticas que
norteiam a execução e o gerenciamento de um projeto, visando aumentar a agilidade de
equipes, qualidade de projeto e fornecer o máximo de valor para o cliente, em menor
tempo e de forma efetiva.
• XP foi iniciada por Kent Beck, nos Estados Unidos, em meados da década de 90, num
projeto da Chrysler chamado C3 (Chrysler Comprehensive Compensation).
SCRUM E XP
O que é XP?
Fonte: Manoel Pimentel Medeiros
SCRUM E XP
É possível?
• Scrum e XP são tão “plugáveis” que muitas vezes você chega a confundir se está utilizando
Scrum ou XP;
• Isto acontece pelo fato de muitas práticas do Scrum, tais como reunião diária, reunião de
planejamento e retrospectiva terem sido “importadas” pela Extreme Programming e
acrescentadas em suas práticas;
• Scrum no gerenciamento e XP na engenharia formam uma excelente combinação. Apenas

tenha cuidado para garantir que o gerenciamento esteja sendo conduzido realmente pelo
Scrum, pois suas práticas para este fim são mais completas e nos remetem à seriedade com
a qual o assunto deve ser tratado;
• Algumas práticas de engenharia da Extreme Programming, tais como refatoração,

programação em par e TDD (Test-Driven Development) colaboram para a formação de
times ágeis.
SCRUM E FDD
O que é FDD
• A FDD(Feature-Driven Development) é uma metodologia de desenvolvimento de software
que, seguindo os princípios propostos pelo Manifesto Ágil, fornece processos para a
distribuição repetível de software com valor para o cliente;
• Ela surgiu no ano de 1997 quando Peter Coad e Jeff De Luca foram contratados para salvar
um projeto bancário em Singapura. Reunindo experiências anteriores, eles chegaram ao
que hoje é a FDD, esse mesmo projeto deu ainda origem à técnica de modelagem da UML
em cores. Após pouco mais de um ano, o projeto estava salvo, tendo mais de 2.000
features (funcionalidades) desenvolvidas por uma equipe de 50 pessoas.
• A FDD possui características marcantes, entre elas podemos citar a importância que é dada
para a qualidade das funcionalidades entregues ao cliente, através de práticas como a
inspeção de modelo e de código. Outra característica não menos importante é a de
priorizar a entrega de resultados frequentes, tangíveis e funcionais para os clientes, através
do trabalho dividido em iterações, o que aliás é uma prática muito usada no mundo do
desenvolvimento ágil. Relatórios de estado e progresso das atividades (como o famoso
Parking Lot), adaptabilidade para projetos e equipes maiores ou menores, e um
desenvolvimento partindo de um modelo abrangente são outras fortes características da
FDD.
SCRUM E FDD
O que é FDD?
SCRUM E FDD
É possível?
• Scrum e FDD também são “plugáveis” e podem formar uma framework de gerenciamento
e engenharia muito poderosa;
• A FDD é a metodologia ágil que mais está próxima das práticas eficientes da engenharia de
software;
• A prática de Desenvolvimento de Modelo Abrangente da FDD pode ser uma excelente

atividade para o descobrimento de itens para um Product Backlog.
ONDE ESTAMOS?
sua empresa Scrum
SCRUM E CMMI
O que é CMMI?
• CMMI é uma framework que descreve práticas para
uma empresa de desenvolvimento de software;
• CMMI consiste de 5 níveis (1 a 5);
• O nível 1 significa que uma empresa não tem nada

definido e repetível para o desenvolvimento de
software; basicamente programadores escrevem
código sem nenhuma preocupação com práticas ou
padrões. Empresas de nível 1 são consideradas
imaturas.
• No nível 5, uma empresa tem processos definidos e

entrega repetível de software. Empresas de nível 5 são
consideradas maduras.
• Em cada um dos níveis as práticas que deverão ser

satisfeitas são definidas como Practice Areas (PAs);
• Bill Curtis e Mark Paulk do SEI (Software Engineering

Institute) desenvolveram a primeira versão do CMMI,
chamada CMM, em 1990.
SCRUM E CMMI
O que é CMMI?
SCRUM E CMMI
É possível?
ONDE ESTAMOS?
sua empresa Scrum
SCRUM E PMBOK
O que é PMBok?
• O PMBok, segundo o PMI, é uma denominação que
representa todo o somatório de conhecimento dentro da
área de gerenciamento de projetos. O guia inclui os
conhecimentos já comprovados através de práticas
tradicionais que são amplamente utilizadas, assim como
conhecimentos de práticas mais inovadoras e avançadas
que têm tido uma aplicação mais limitada, incluindo
material publicado ou não;
• O PMBok pretende também fornecer uma terminologia

comum, dentro da profissão e práticas, para a linguagem
oral e escrita sobre gerenciamento de projetos;
• No PMBok (3a. edição) são abordados quarenta e quatro

processos divididos nas nove áreas de conhecimento,
formando um fluxo contínuo de processos.
SCRUM E PMBOK
O que é PMBok?
SCRUM E PMBOK
É possível?
• Publicações mais atuais do PMI – Project Management Institute, órgão criador do PMBok,
vem mencionando freqüentemente temas relacionados às abordagens ágeis;
• A framework APM – Agile Project Management (que é baseada no Scrum), de Jim

Highsmith, vem sendo a mais “aceita” pelos PMPs. Tudo indica que, em futuras versões, o
PMBok inclua cada vez mais práticas ágeis de gerenciamento de projetos;
• Por mais que não pareça fazer muito sentido misturar Scrum com práticas do PMBok – e,
na minha opinião, realmente não faz – você pode sentir essa necessidade caso, por
exemplo, esteja desenvolvendo um projeto com Scrum dentro de um PMO – Project
Management Office – que exige que determinadas áreas de conhecimento do PMBok
sejam satisfeitas, como por exemplo o Gerenciamento. Você pode fazer isso!
ONDE ESTAMOS?
sua empresa Scrum
SCRUM E CORRENTE CRÍTICA
O que é Corrente Crítica?
• A corrente crítica é um dos processos mais inovadores e polêmicos no gerenciamento de
projetos. Proposta pelo físico israelense Eliyahu Goldratt, a corrente crítica é aplicação
direta da teoria das restrições. A restrição de um sistema pode ser considerada como
qualquer coisa que impeça o sistema de atingir um desempenho superior.
• Ele afirma que a inserção de uma proteção ou buffer no projeto o protege com menos
esforço e mais qualidade se comparado a inserção de proteções individuais em cada uma
das atividades, uma vez que o objetivo do projeto não é concluir uma atividade específica
no prazo e custo, mas concluir o projeto como um todo no prazo e custo especificado.
• A corrente crítica (CCPM – Critical Chain Project Management), assim como o Scrum, é uma
metodologia voltada ao gerenciamento de projetos;
• Algumas de suas estratégias, tais como os buffers (pulmões) de projetos, podem ser
adaptados para pulmões de Sprints e utilizados em projetos com gerenciamento Scrum.
ONDE ESTAMOS?
sua empresa Scrum
SCRUM E FERRAMENTAS
Avaliando algumas ferramentas disponíveis no mercado
XPlanner Rally
VersionOne xProcess
ÚLTIMAS DÚVIDAS
OBRIGADO

Scrum Courseware

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Scrum Courseware

Enviado por

Direitos autorais:

Formatos disponíveis

SCRUM

Gerenciamento de Projetos de Software

Empresa (breve descrição da empresa)

Quanto tempo na área de software?

Atua em outros áreas?

Foi (é) desenvolvedor?

Foi (é) gerente de projetos?

O que sabe sobre Agile? E sobre Scrum?

• Co-fundador e membro do time da AdaptWorks juntamente com Alexandre

Parte II – Como adotar Scrum em sua empresa

Parte III – Expandindo o uso de Scrum

• Conhecimento e • Personalidade coletiva

1. Que pessoas estão envolvidas?

2. Quais processos são observáveis?

3. Quais tecnologias são aplicadas?

4. Como a cultura influencia nesse (ou é influenciada por

Um projeto é um problema agendado

Dr. Joseph M. Juran

Um projeto é uma coleção de valor

• É temporário, isto é, possui uma data de início e uma data de término;

• Resulta em produto(s) que não exista(m) antes, ou existirá(ão) de forma diferente

• Possui restrições em custo, prazo, qualidade e/ou recursos;

• Conduzido por pessoas;

• Elaboração progressiva: desenvolver em etapas e continuar por incrementos

Muitas metodologias experimentaram algo como uma

no prazo adequado e eficiente em relação ao seu custo...

fornecendo informação precisa e significativa a todos os papéis principais, dentro e fora de

com o mínimo de interrupção para os desenvolvedores

Em nenhum lugar o desafio para chegar ao máximo da

A vasta maioria dos projetos de software falha por falta de

Fonte: Borland Software Corporation

• Precisamos saber como melhorar a comunicação entre os

• Precisamos saber como estimar as atividades para a produção de

• Precisamos saber como entregaremos os produtos para nossos

• Precisamos saber como difundir o conhecimento em nossas

• Precisamos saber o que e como documentamos;

• Precisamos saber qual o ciclo de vida da nossa produção;

• Precisamos saber como organizar nossa produção;

• Precisamos saber como conseguiremos qualidade;

“- Poderia me dizer, por favor, qual é o caminho para sair

Diálogo entre Alice e o Gato de Cheshire.

Fonte: ADM, 2004

Cite o que você espera de uma metodologia para

• É mais atitude do que um processo, mais ambiente que uma metodologia;

• Entregar produto com valor para o negócio, mais rápido e continuamente;

• Garantir progresso real;

• Melhorar a comunicação entre negócios e TI;

• Qualidade desde o início.

Agilidade é a habilidade para criar e

Agilidade é a habilidade para equilibrar

Indivíduos e interação entre eles mais que processos e ferramentas

• Processos fornecem direcionamento e suporte, e ferramentas produtividade, mas sem as

• Processos devem se adaptar ao time, e não o inverso;

Baseado em: Agile Project Management – Jim Highsmith

• Troque a entrega de documentação e artefatos por versões iterativas de um produto real

• Documentos não funcionam. Produtos sim;

• No entanto, produtos funcionando não excluem a necessidade de documentação.

• Documentação não deve substituir a interação.

Baseado em: Agile Project Management – Jim Highsmith

• Em projetos ágeis, clientes e gerentes de produto são os guias;

• A meta de um time em projetos ágeis é entregar valor para o cliente;

• Clientes definem o que é valor. Os stakeholders definem as restrições. Quando fazemos

• A fórmula para o sucesso é simples: Entregue hoje, adapte amanhã!