Links úteis

Revistas Visão Ágil – Edições gratuitas

http://www.visaoagil.com/edicoes

Grupo aberto sobre SCRUM no Facebook

scrumbrasil@groups.facebook.com

Organizações SCRUM

http://www.scrumalliance.org/
http://www.scrum.org.br/

Artigos

Desvendando o SCRUM
http://www.revistatidigital.com.br/downloads/Scrum.pdf

Coaching e Facilitação de Times Ágeis

http://www.sbcoaching.com.br/img/imprensa/revistas/JAVA-out2010.pdf

Livros gratuitos:

Scrum e XP direto das Trincheiras - http://www.infoq.com/br/minibooks/scrum-

xp-from-the-trenches

Kanban e Scrum - obtendo o melhor de ambos -

http://www.infoq.com/br/minibooks/kanban-scrum-minibook

Top dez livros de Agile

http://www.infoq.com/br/news/2010/08/top10-livros-agile
36 :: TIdigital / Reportage / Scrum
De sve ndando o
As feras brasileiras desta metodologia ágil de gerenciamento dão
uma tremenda aula para quem quer entrar no ciclo do Scrum.
Estádio lotado, torcedores apreensivos na hora
daquela jogada que pode valer a pontuação da virada
do jogo, e então ocorre uma infração. No jogo de
Rugby, se algum dos 15 jogadores do time deixar
a bola cair em um knock on, passá-la para frente,
causar um impedimento acidental ou se a bola não
sair de um ruck ou maul, é usado o Scrum como
forma de penalidade. No Scrum do Rugby (tinyurl.
com/scrum-rugby), apenas oito jogadores de cada time
se formam frente a frente e encaixam suas cabeças
formando um túnel. O jogador Scrum-half insere a
bola no meio do túnel para que o hooker, que tem toda
a responsabilidade do Scrum, a recue para o jogador
número 8, e o Scrum termina quando a bola sai deste
túnel. Agora vamos voltar no tempo e avaliar o porquê
da comparação desta jogada Scrum com a metodologia
ágil de gerenciamento de projetos Scrum, feita pelos
estudiosos japoneses Ikujiro Nonaka e Hirotaka
Takeuchi, no artigo "The New Product Development
Game" (O Novo Jogo de Desenvolvimento de Produtos),
publicado na revista Harvard Business Review, em
1986. Segundo eles, o Scrum foi concebido a partir
de um estilo de gerenciamento de projetos utilizado
na fábrica de automóveis Toyota. Ao notarem que a
empresa produzia melhores resultados com equipes
pequenas e multidisciplinares (cross-functional),
associaram estas equipes eficazes à formação Scrum
do Rugby, que conta com poucos jogadores, onde o
objetivo é retirar o obstáculo da frente do jogador e
correr com a bola, para que possa avançar o máximo
possível no campo e marcar pontos. Nonaka e Takeuchi
Fundamentos, Dicas super
teoria e interessantes
para quem já
prática utiliza .
Por Flávia Freire
também comparam o Scrum às regras do Rugby,
originadas do futebol, assim como a metodologia
do Scrum foi fortemente baseada no processo Lean
Software Development, utilizado pela Toyota. O project
manager Fabio Camara explica esta associação do
método ao esporte. “É sábio se preparar para cada
partida. Devemos entender cada partida de um esporte
como um Sprint (ciclos periódicos da metodologia
Scrum). Em outras palavras, não podemos proceder de
forma igual, robótica, sem inovação em cada Sprint.
E é justamente este o ponto do Scrum com os times
de esporte. É uma inversão da pirâmide, ou seja, os
programadores são muito importantes para o projeto,
assim como os jogadores para o time naquela partida.
Não adianta o gerente do projeto trazer controles
que mais parecem uma auditoria e burocratizam o
desenvolvimento. No fim, quem faz a diferença no
projeto são os desenvolvedores, como jogadores para o
time.” compara.
Em 1993, Jeff Sutherland, Ken Schwaber e
John Scumniotales documentaram, conceberam e
implementaram o Scrum pela primeira vez na empresa
Easel Corporation, de acordo com os estilos de
gerenciamento observados por Nonaka e Takeuchi e
com os conceitos da metodologia ágil Lean. Dois anos
depois, Ken Schwaber formalizou a definição de Scrum
e ajudou a divulgá-lo. O Scrum começou então a ser
implantado com sucesso por empresas do mundo todo,
para ser usado, principalmente, em gestão de projetos
de desenvolvimento de software.

Quem pode aplicar o Scrum em uma empresa?
A Scrum Alliance, organização fundada pelos criadores
da metodologia Scrum, para promover, apoiar e gerar recursos
aos usuários da metodologia, oferece cinco certificações:
ScrumMaster (CSM), Scrum Product Owner (CSPO), Scrum
Practitioner (CSP), Scrum Coach (CSC) e Scrum Trainer
(CST). Até agora, no Brasil, temos apenas um Scrum Trainer.
É o fundador do grupo Scrum-Brasil, principal comunidade
brasileira de debate sobre Scrum, e responsável pela área de
Agile da Caelum, Alexandre Magno, que ministra workshops e
dá treinamentos de Certified ScrumMaster e Certified Scrum
Product Owner. “Eu encontrei os métodos ágeis em um
momento da minha vida em que estava refletindo se valia
a pena seguir em frente na carreira de gerenciamento de
projetos na área de TI. Eu não aguentava mais os mesmos
problemas projeto a projeto, que se repetiam há mais de 20
anos.” conta. A primeira metodologia ágil de gerenciamento que
Alexandre utilizou foi a FDD (Feature-Driven Development), e
então conheceu o Scrum. “Adorei Scrum por sua simplicidade
e poder. Vi nele algo que pode ser levado para além dos
departamentos de TI. Eu acredito que Scrum pode mudar o
mundo do trabalho, das empresas. Estou muito contente em
estar aplicando Scrum dentro de boards de empresa, vendo
diretores de áreas diferentes (rh, financeiro, mkt etc.),
que antes se preocupavam apenas com o resultado de seus
departamentos, agora estarem trabalhando de uma forma
multidisciplinar colaborativa.” diz.
Para se certificar pela Scrum Alliance, é preciso,
primeiramente, frequentar uma das turmas dos treinamentos
de Certified ScrumMaster ou Certified Scrum Product Owner.
“Tendo um bom aproveitamento em uma destas turmas, você
recebe este primeiro nível de certificação, comprovando a sua
participação ativa em um treinamento de 16 horas ministrado
por um Certified Scrum Trainer, profissional que possui forte
conhecimento teórico e prático de Scrum e a confiança do
Ken Schwaber, Presidente da Scrum Alliance. Nos meses
seguintes será incluída a esta certificação um prova de
múltipla escolha para o aluno avaliar seus conhecimentos ao
final do treinamento.” explica Alexandre. Comprovando pelo
menos um ano de experiência com Scrum, o CSM ou CSPO pode
se candidatar ao título de Certified Scrum Practitioner. “Neste
processo de avaliação, você terá que enviar à Scrum Alliance
informações sobre algum projeto que tenha participado
utilizando Scrum, neste período de um ano. É uma prova que
representa uma experiência prática, que obriga o candidato
a contar a história daquele projeto. Sendo um CSP por
pelo menos um ano, e querendo focar em uma carreira com
Scrum, você pode se candidatar a Certified Scrum Trainer e/
ou Certified Scrum Coach. Aqui, além de sua habilidade com
Scrum ser avaliada novamente, você precisará de um bom
currículo em uma destas duas carreiras, preferencialmente
TIdigital / Reportagem / Scrum :: 38
com certificações na área escolhida (treinamento ou
coaching). Além disso, é fortemente indicado que um
candidato a CST tenha sido co-trainer de pelo menos dois
CSTs antes de enviar sua aplicação como candidato.”
completa Alexandre.
O interesse de muitos gerentes de software na
certificação Scrum está crescendo, não só pelo título, mas
também por adquirirem uma maneira de conseguir reger o
setor de desenvolvimento com mais confiança e segurança no
que é acordado com o cliente. Segundo Nelson Abu, o claro
benefício trazido por esses processos de gerenciamento de
projeto e o grande número de cases de sucesso, trouxeram a
atenção das organizações para processos como o Scrum. “A
demanda por profissionais com essa competência aumentou,
movimentando todo um mercado de cursos, workshops,
palestras, fóruns etc. Do ponto de vista dos profissionais
especializados, isso representa mais uma oportunidade de
trabalho, porque a demanda por esses conteúdos está cada
vez maior. Porém, para os que visam a capacitação em
processos ágeis, é importante buscar referências sobre o
conteúdo e os responsáveis por ele, uma vez que nem todos
os cursos têm boa qualidade. Para o Scrum especificamente,
a existência de um treinamento oficial em língua portuguesa,
pelo Alexandre Magno, foi um grande avanço para o mercado
nacional.” avalia Nelson, sobre os cursos de Scrum da Caellum.
À medida que cresce o interesse das empresas e de profissionais
por Scrum, mais aparecem instituições e cursos que ministram
workshops sobre a metodologia. Só que, nem sempre, estes
workshops realmente capacitam o profissional para a aplicação
do Scrum. “O nosso treinamento também é de 16 horas,
e nesta carga horária conseguimos ensinar aos alunos a
essência e práticas do Scrum e Agile, as armadilhas do
processo de aplicação, os papéis, e não menos importante: o
que não é Scrum! Esta parte aborda justamente alguns dos
grandes erros que as empresas estão cometendo ao aplicar
Scrum, o que vem sendo chamado pelo Ken Schwaber de
Scrumbut (Scrum, mas...).” descreve Alexandre.
O Scrum no Brasil
Antes do Scrum se tornar o “queridinho” entre as empresas
adeptas às metodologias ágeis de gerenciamento de software,
muitas outras foram apresentadas, mas a verdade é que a
grande maioria dos gerentes de desenvolvimento ainda utiliza
o modelo tradicional, ou seja, técnicas criadas pela própria
empresa. Alguns, por não terem sido apresentados às novas e
diversas metodologias ágeis. Outros, por ainda não confiarem
nestes métodos. “Uma empresa que já passou por processos
criados internamente, modificados de acordo com as suas
necessidades, ou padronizados (como RUP, PMBOK etc.)
e não teve sucesso, com certeza verá na simplicidade do
Scrum um meio de obter resultados rápidos. Porém, é
fundamental o apoio da alta direção e o comprometimento
38 :: TIdigital / Reportagem / iPhone
de todos, pois devemos lembrar que o Scrum exige muita
dedicação e persistência para que ele realmente funcione na
sua totalidade e, assim, gere os benefícios esperados.” conta
o ScrumMaster Nelson Abu, que garante melhorias no resultado
dos projetos se os funcionários da empresa estiverem dispostos
a enfrentar as mudanças que o Scrum causa no funcionamento
do time. “Se uma empresa não possui processos definidos,
o Scrum é uma das melhores opções, pois ele é simples
de entender e bem mais simples de implantar que outros
processos. Assim, as chances de sucesso são muito maiores.
Ken Schwaber fala que Scrum não é um processo, mas sim
um framework. O mais importante é que ele traz uma caixa de
ferramentas de boas práticas de trabalho, permitindo obter
bons resultados, mesmo que a equipe não tenha o domínio
completo das técnicas que estão sendo utilizadas.” completa.
“O Scrum é simples de entender
e bem mais simples de implantar que
outros processos.” Alexandre Magno
Em tempos de crise, este método de desenvolvimento de
software, que exige uma equipe pequena, acaba sendo um
caminho. “Quem atua na área de projetos em TI sabe o quão
ruim vem sendo os nossos resultados: pouco sucesso, alto
custo, equipes insatisfeitas, cliente inimigo, alta rotatividade
de profissionais etc. Agora, estamos entrando em um ano de,
no mínimo, atenção e cautela nos investimentos. A área de TI
sempre sofre com essas crises e é onde começam os cortes.
Scrum nos dá uma excelente oportunidade de começar a
mudar a cara de TI no mercado. Nós entregamos sim, estamos
fazendo mais rápido e com mais qualidade. Queremos o
cliente junto de nós, e podemos gerar resultados excelentes
para as empresa.” afirma Alexandre Magno.
O Scrum pode também ser aplicado junto às práticas de
engenharia do XP, do FDD e de outras metodologias ágeis. Elas
podem se complementar e gerar melhores resultados, utilizando
métodos de cada uma em processos diferentes, de acordo com
a adaptação da equipe. “É um erro achar que usar Scrum
sozinho trará agilidade para projetos de software. Scrum
é apenas uma ferramenta para facilitar o gerenciamento
de projetos, sejam eles de aviões, carros, softwares. Para
desenvolver software com Scrum é necessário adicionar
práticas ágeis de engenharia de software como as do XP,
que é específico para isto, para que aí sim você tenha
verdadeira agilidade. Por exemplo, se você não desenvolve
com testes (TDD) para criar um design flexível, mesmo que
o Scrum acomode as mudanças de requisitos dos clientes,
o software não acomodará, e com isso, toda a agilidade vai
por água abaixo.” diz Guilherme Chapiewski, coordenador de
WebMedia da Globo.com, onde Scrum, Lean e XP são aplicados
juntamente. “Muitas pessoas podem dizer que é inútil usar
Scrum quando todas as práticas dele já estão incluídas no
XP. Isso é verdade, as práticas do Scrum são um subconjunto
do XP. Porém, é muito mais fácil vender Scrum do que
XP. O mantra do Scrum é ‘maximização do retorno sobre o
investimento (ROI) ’ e tudo no Scrum gira em torno disso.
O foco é muito claro: Scrum foi feito para ser vendido para
gerentes, diretores e clientes. Já o XP é muito focado em
programadores e práticas de engenharia, o que o torna um
pouco mais difícil de ser entendido e aceito. Enfim, no final
das contas, acaba-se usando as duas coisas, e como as duas
são compatíveis, não há nenhum problema. Sobre Lean,
usamos, por exemplo, algumas métricas de desenvolvimento
como lead time, que é o tempo da requisição do cliente até a
entrega do produto, e vocabulários como ‘evitar desperdício’
e ‘ter a visão do todo’." afirma.
Para o ScrumMaster Igor Macaúbas, as práticas do Scrum
devem ser seguidas à risca quando a empresa nunca utilizou
nenhum método ágil. “Eu não recomendo que sejam feitas
implementações parciais do Scrum no começo. É por causa
disso que às vezes escuto ‘tentamos fazer scrum mas não
conseguimos’. Minha sugestão é que a adoção inicial seja
totalmente by the manual, ou seja, faça todas as práticas e
cerimônias que estão descritas na especificação do Scrum,
não deixe nada de fora, nem questione nada. Depois,
quando você já estiver experiente, após executar pelo menos
seis sprints, e já conhecer os benefícios que as práticas
trouxeram, aí sim você pode pensar em deixar de fazer
alguma coisa, ou mudar a forma como alguma coisa é feita.”
sugere.
“O mantra do Scrum é maximização
do retorno sobre o investimento (ROI).”
Guilherme Chapiewski
O Scrum se fez conhecido há 16 anos, mas há 40, o PMI
(Project Management Institute) vem melhorando o desempenho
das empresas em gerenciamento de projetos, com mais de 200
mil associados no mundo, e foi a primeira organização a ter um
programa de certificação reconhecido pela ISO 9001, em 1984,
concedendo o título PMP (Project Management Professional) aos
profissionais aprovados no exame realizado pelo PMI. “Ao meu
ver, o Scrum não veio para substituir as práticas definidas
pelo PMI, tanto que é perfeitamente possível gerenciar
projetos utilizando os dois frameworks, um complementando
o outro. Pela minha experiência, vejo que o Scrum preenche
algumas lacunas que o PMBOK (Project Management Body of
Knowledge) – conjunto de práticas em gerência de projetos
levantado pelo PMI - não contempla, especialmente quando
se considera o desenvolvimento de software. Assim, na minha
opinião, o ideal é que os gestores de projeto se capacitem
 TIdigital / Reportagem / Scrum :: 39

opinião, o ideal é que os gestores de projeto se capacitem

tanto nas práticas do PMI quanto em Scrum.” avalia Nelson. O
project Management Professional Robson Dantas tem aplicado Scrum
em seus projetos como metodologia ágil, utilizando alguns processos
definidos pelo PMBOK como suporte à metodologia. “É possível
utilizá-lo como complemento, levando apenas em consideração
os pontos fortes da metodologia ágil, como por exemplo o
desenvolvimento do plano de projeto de forma incremental.”
diz. Ser certificado pelo PMI ainda é um grande diferencial para as
empresas, mesmo diante de tantas metodologias ágeis disponíveis
para gestão de projetos. “Antigamente o gestor de projetos com
certificado PMP possuía um enorme diferencial. Hoje em dia,
a certificação virou praticamente uma exigência por parte das
empresas. No mercado de tecnologia, com o aumento da adoção
das metodologias ágeis, faz-se necessário que o gerente de
projetos recicle seus conhecimentos realizando cursos ou lendo
livros sobre metodologias ágeis. Obviamente que uma parte do
contexto do PMBOK pode ser utilizado com as metodologias
ágeis, formando um framework exclusivo de gestão de projetos
para a área de tecnologia.” conclui.
“O ideal é que os gestores de proje-
to se capacitem tanto nas práticas
do PMI quanto em Scrum.” Nelson Abu
Microsoft Solutions Framework (MSF) -
msdn.microsoft.com/pt-br/vsts2008/aa718795.aspx
Valoriza mais o tempo combinado do que o escopo combinado.
O cliente e a equipe de projeto devem ter a “atitude mental de
produto”, ou seja, forma de pensar e de agir sobre determinado
assunto. Utiliza um banco de dados para registrar e acompanhar
idéias, requisitos, problemas, boas idéias que surjam durante o
planejamento e desenvolvimento, e problemas críticos e não-críticos
na versão final que são capturados de modo a serem priorizados e
resolvidos na versão seguinte. Em 2005 lançou o editor de modelos
de processo Visual Studio Team System.

Conheça outras metodologias ágeis de gerenciamento

de Software:

Metodologias Crystal -

Feature Driven Development (FDD) - alistair.cockburn.us/crystal/crystal.html

É uma família, já que a metodologia defende que diferentes tipos de
www.featuredrivendevelopment.com
projetos exigem diferentes tipos de metodologias, e é definida através
Muito objetiva, combina as melhores práticas do gerenciamento
do número de pessoas no projeto e das consequências dos erros. Ela
ágil de projetos com uma abordagem completa para engenharia
compartilha a orientação humana, mas sua orientação às pessoas
de software orientada por objetos. Têm duas fases: Concepção &
é feita de forma diferente. O desenvolvimento iterativo existe para
Planejamento (pensar antes de fazer), e Construção (fazer de forma
detectar problemas cedo, e então habilitar as pessoas a corrigi-los,
repetitiva) com iterações de duas semanas. O FDD utiliza cinco
dando mais ênfase no monitoramento e ajuste do processo à medida
processos integrados: DMA (Desenvolver um Modelo Abrangente);
CLF (Construir a Lista de Funcionalidades); PPF (Planejar por que se desenvolve.
Funcionalidade); DPF (Detalhar por Funcionalidade); e CPF
(Construir por Funcionalidade). Jeff De Luca desenvolveu este método
originalmente para suprir as necessidades de um grande banco de
Cingapura, em 1997.

Dynamic Systems Development Method (DSDM) -

Lean Software Dvelopment (LD) -
www.poppendieck.com
Ou Lean Thinking (Mentalidade Enxuta), denomina uma filosofia
de negócios baseada no Sistema Toyota de Produção que identifica o
que é o desperdício e o que é o valor a partir da ótica dos clientes e
usuários. As práticas envolvem criação de fluxos contínuos e sistemas
puxados, baseados na demanda real dos clientes, além da análise e
melhoria do fluxo de valor das plantas e da cadeia completa, desde as
matérias-primas até os produtos finais. Surgiu no Japão, logo após a
Segunda Guerra Mundial.
www.dsdm.org
Ou Método de desenvolvimento dinâmico de sistemas. Origina-
se de técnicas de desenvolvimento rápido de aplicativos (RAD)
que enfatizam o envolvimento do usuário. Funciona melhor em
cenários onde o aplicativo precisa funcionar em um ambiente
de computador complexo que o desenvolvedor não entende
muito bem. O DSDM Consortium desenvolveu esta metodologia
em 1990, no Reino Unido, para consolidar experiências com
melhores práticas de programação.
40 :: TIdigital / Reportagem / Scrum
eXtremeProgramming (XP)-
www.extremeprogramming.org
Este método enfatiza muito a adaptabilidade em vez da
previsibilidade. Funciona melhor em cenários onde a
organização não sabe, com exatidão, de quais produtos
necessita. Foi idealizado por Kent Beck em 1996.
Adaptive Software Development (ASD) -
www.jimhighsmith.com
Prioriza a velocidade e flexibilidade. Funciona melhor em
cenários onde a organização precisa produzir resultados
com rapidez para um aplicativo que pode crescer à
medida que os clientes o utilizam. Foi desenvolvido em
1999 por Jim Highsmith.
Nelson Abu
Fontes: sites oficiais, tinyurl.com/anovametodologia, tinyurl.com/
cardapiometodologias, tinyurl.com/leanthinking e tinyurl.com/abcagil.
Como funciona o Scrum?
Para quem gosta de trabalhar em silêncio, ou só consegue
desenvolver desta maneira, o ambiente onde é aplicado o Scrum não é o
mais indicado. “A comunicação entre os desenvolvedores é sempre
muito grande, diferente de antigamente quando todos sempre
se falavam por e-mail para ‘documentar’ ou se comunicavam
através de documentos de requisitos. É muito fácil também
encontrar os desenvolvedores trabalhando em duplas e vários
grupinhos discutindo em frente a grandes quadros brancos ou flip
charts. Diferente da maioria das empresas onde é ‘cada um no
seu quadrado’, você vê por todos os lados pessoas tentando achar
soluções para os mais diversos tipos de problemas.”, descreve
Guilherme Chapiewski, que começou a implantar o Scrum na Globo.
com em 2008 e sempre que podia, atualizava o seu blog pessoal (gc.
blog.br) com as novidades e melhorias causadas pela metodologia.
“As dificuldades são muitas e até hoje ainda temos que melhorar
e adaptar constantemente. Quando você começa a usar esse
tipo de metodologia, percebe que havia um monte de problemas
escondidos por baixo das burocracias e documentos. Muitas
pessoas caem na armadilha de achar que são problemas do Scrum,
mas são problemas da sua empresa que sempre estiveram lá, mas
você tinha um monte de coisas na sua frente que te atrapalhavam a
enxergar a realidade.” conta.
O expediente começa com uma reunião de 15 minutos entre
os desenvolvedores, pela manhã, para decidirem o que vão fazer e
quais serão as metas do dia. Nestas reuniões diárias, chamadas Daily
Meetings, três perguntas são propostas: O que fiz ontem? O que farei
hoje? Quais são os impedimentos?. “Um dos maiores desafios na
liderança de um projeto é obter um feedback real, uma informação
binária de como está, de fato, aquela atividade no projeto. Se você,
como líder, for todos os dias até determinado integrante do time
para questionar o estado (status) da atividade, certamente criará
problemas de relacionamento com o time. As reuniões diárias
e todas as outras proporcionam métodos para obter o feedback
sem os melindres de outras formas de obter esta informação.
Por outro lado, estas reuniões também proporcionam um maior
comprometimento do time com o projeto. É o conceito de inversão
da pirâmide, ou seja, os integrantes operacionais do projeto são
muito mais importantes e ativos que os stakeholders, e eles se
sentem desta forma devido aos métodos proporcionados pela
reunião.” explica o ScrumMaster Fabio Camara.
O ScrumMaster deve tirar todos os impedimentos e
obstáculos da equipe da frente dos desenvolvedores, mas no contexto
do Scrum, o time deve ser autônomo, ou seja, eles resolvem todos os
problemas entre si, sem recorrer a membros mais experientes. “Isso é
maravilhoso, apesar de reconhecer o quanto é difícil a aplicação na
prática. Um indivíduo colaborador de um time pode ser muito mais
efetivo se for interdisciplinar do que sendo especialista somente.
O problema é que o modelo tradicional de gestão, cria, nutre e
engessa os especialistas. Quando se monta uma distribuição de
atividades, denomina-se aquele tipo de atividade sempre para o
mesmo recurso. Ou seja, a própria gestão do projeto vicia o código,
vicia o conhecimento do projeto, especializando em poucos. Auto-
organização significa eliminar o pensamento de indivíduo e pensar
no time como um único corpo. Desta forma, todos podem trabalhar
em todas as partes do projeto. Se todos conseguem ser produtivos
no projeto, não há estagnação, há crescimento contínuo.” avalia
Fabio.
Veja as habilidades interpessoais que o ScrumMaster deve ter,
segundo Nelson Abu:
Comunicação e Liderança: o Scrum Master deve sempre deixar
a equipe com visibilidade do projeto. Nos daily meetings, ele deve
relembrar a meta da atual Sprint (pacote de entrega, dentro do conceito
de iterações), além de manter o processo do Scrum em funcionamento.
Dessa forma, ele promove a comunicação e visibilidade entre a equipe e
o Product Owner.
Influenciar a organização: idealmente, o processo de Scrum tem
que ser implantado na equipe de TI e também na equipe de produto, para
que, nos projetos, existam equipes únicas formadas por profissionais de
TI e de Produto. O mesmo vale para quando os profissionais de produto
são externos à empresa, como no caso de consultores. Para tanto, é
fundamental que durante a fase de adoção do Scrum na empresa, os
ScrumMasters exerçam uma influência positiva, justificando o apoio
que fundamentalmente deve ser dado pela alta direção, que também
deve estar comprometida com a adoção dos processos ágeis. Sem esses

componentes, fica muito difícil a mudança da cultura coorporativa,
mesmo que o Scrum seja adotado apenas na área de TI.
Liderança: por ser comparado ao gestor de projetos, é importante
que ele tenha essa habilidade. Porém, não é obrigatório que ele seja um
grande líder, já que o Scrum permite uma liderança compartilhada,
pois a equipe participa ativamente dos processos decisórios do projeto.
Essa participação ativa de todos da equipe deve ser promovida e
incentivada a todo tempo pelo ScrumMaster, gerando naturalmente o
comprometimento de todos, reduzindo riscos e conduzindo o projeto para
o seu objetivo. A liderança também proporcionará que ele exerça melhor
sua influência na organização e na motivação de todos.
Motivação: o gestor sempre tem que estar proporcionando
condições para que a equipe execute suas atividades. Um grande fator de
alicerce no Scrum com relação à motivação é a gestão dos trabalhos em
metas possíveis e à adesão da equipe em todo o processo do projeto. Por
prever entregas constantes de forma iterativa, o próprio Scrum garante
que a equipe ganhe moral à medida em que vai cumprindo as metas
definidas, o que ajuda a manter todos motivados.
Negociação e gerenciamento de conflitos: a negociação ocorre a
cada Sprint, sendo esta negociação realizada junto com o Product Owner
e a equipe, onde são definidos o serviço da Sprint e a quantidade de
produção que a equipe consegue executar naquele período. A resolução
de problemas ocorre em cada daily meeting, quando os problemas são
identificados para serem resolvidos logo após a reunião, e nas reuniões
de retrospectiva com a equipe ao final de cada Sprint.
Resolução de problemas: a todo momento, o ScrumMaster deve
resolver problemas, para que a equipe não perca o seu foco. Aqui temos
o conceito de “gerente servidor”, que serve como apoio para a equipe,
tirando todos os obstáculos existentes no caminho de execução do
projeto.
Manter os indivíduos como um time: é fundamental ter todos
comprometidos com o projeto, várias pessoas juntas não formam um
time, mas se todas estiverem focadas em um objetivo e comprometidas
com ele, aí então temos um time. É primordial para se ter um time, que
o ScrumMaster seja uma figura que reúna este time e faça com que eles
pensem e ajam assim.
Eliminar a corrente crítica: é dever do ScrumMaster proteger
o time e desta forma não apontar quem está causando problema e sim
resolvê-lo sem transparecer ao cliente. O ScrumMaster deve sempre
estar atento a quem está sendo a corrente crítica para eliminar ou
reduzir ao máximo seus reflexos.
Para Igor Macaúbas, o ScrumMaster precisa ter habilidades
que não estão descritas no manual da metodologia.
“O ScrumMaster não é um gerente, e sim um líder. Ele
guia as pessoas e as ajuda a atingirem um objetivo. Remove
impedimentos, trabalha em conjunto com o Product Owner e com
o time para manter o Product Backlog, e faz a mediação de todas
as cerimônias do Scrum. Ele é, além de tudo, um facilitador. O
ScrumMaster também é um dos responsáveis pelo sucesso do time,
e a sua atuação é, por muitas vezes, decisiva. Um outro papel
importantíssimo do ScrumMaster é o de ‘escudo’, protegendo o
time de interferências internas e externas. Ele é um agente de
mudanças e às vezes precisa dizer não para o seu próprio chefe.
Também preza pela multidisciplinaridade do time e garante que o
TIdigital / Reportagem / Scrum :: 41
time se auto-organizará para executar o trabalho da Sprint. Uma
habilidade que não está no manual é a capacidade de ser um líder
servidor. É importantíssimo que o ScrumMaster desenvolva uma
liderança inspiradora sobre os seus liderados.” diz. Igor explica
também o por quê de, na metodologia Scrum, as equipes serem
chamadas de times. “Em um time, é necessário que os membros
tenham ‘rapport’. Rapport é a capacidade de entrar no mundo de
alguém, fazê-lo sentir que você o entende e que vocês têm um forte
laço em comum. É a capacidade de ir totalmente do seu mapa do
mundo para o mapa do mundo dele. É a essência da comunicação
bem-sucedida, e a base de uma sólida relação de confiança, tanto
entre si como para com o ScrumMaster. Além disso, é importante
frisar que os times precisam ser multidisciplinares, ou seja, dentro
do time devem existir todas as habilidades para executar o trabalho
da Sprint, sem a necessidade de recorrer à recursos externos, como
DBA’s, arquitetos, entre outros. O time precisa ser auto-contido, e
ter capacidade de entregar o que se comprometeu a fazer.”.
Além do ScrumMaster e do time, há o Product Owner
que, segundo Guilherme Chapiewski, tem o papel mais difícil de ser
executado, pois exige um conhecimento de domínio muito avançado,
aliado a uma grande experiência em gestão de negócios. “O Product
Owner deve inspirar o time, é ele quem lidera e conduz o time em
prol de um objetivo desafiador, e para isso, ele tem como principal
ferramenta a visão que compartilha com o time. O papel do Product
Owner foi inspirado nos papéis do Champion na 3M, e do Shusa
na Toyota. Em ambas as empresas, esse é um dos cargos mais
desejados da corporação, mas as exigências para se alcançar essa
posição também são grandes. Em geral, os profissionais que ocupam
essa posição são engenheiros seniores, que depois de mais de dez
anos de experiência são treinados por vários anos em Negócios e
Marketing, para só então assumirem esse papel.” avalia.
Uma das principais características do Scrum é a constante
interação do cliente com o projeto, recebendo assim um atendimento
mais ágil, mais flexível, tornando-o mais envolvido no desenvolvimento
do produto. “A participação do cliente é fundamental. Ter
o cliente disponível o tempo todo, para tirar dúvidas e
ajudar a escolher as melhores opções de acordo com o
desenvolvimento do produto, é o cenário ideal, mas nem
sempre possível. O mínimo que você precisa conseguir são
de duas a quatro horas de disponibilidade do seu cliente a
cada 15 dias, para participar em alguns pontos chave do
processo. Durante o Sprint Planning 1, onde é definido
‘o que’ será feito na próxima iteração, a participação do
cliente é de grande valia para ajudar a detalhar os requisitos,
sanar dúvidas, ou negociar o escopo buscando soluções que
atendam às necessidades do cliente a um custo menor. Se é
difícil contar com a disponibilidade do seu cliente, não deixe
de, pelo menos, envolvê-lo durante o Sprint Review ao final
de cada iteração. Esse momento é precioso, pois ao mostrar
uma parte do software funcionando para o cliente, você
pode colher feedback, anotar sugestões de melhorias, ou até
mesmo mudar totalmente a direção do projeto, pois à medida
que o cliente começa a interagir com o software funcionando,
 42 :: TIdigital / Reportagem / Scrum

ele começa a entender melhor o que realmente precisa para resolver o problema dele, e novas idéias vão surgindo. Se você
não conhece o seu cliente, não sabe o problema que ele tem, nem o que ele quer exatamente, como você pode desenvolver um
software para resolver o problema dele?” aconselha o gerente de desenvolvimento de aplicações Web na Globo.com, Danilo Bardusco.

Entenda o Ciclo do Scrum por Danilo Bardusco, responsável pela evangelização e implantação desta metodologia ágil na Globo.com:

3 5

9 8

1) O ciclo começa com o Product Owner definindo uma visão de produto compartilhada com o time.

2) Essa visão é então transformada, junto com o time, no que chamamos de Product Backlog. O Product Backlog contém uma lista de requisitos de todos os entregáveis para que
aquele produto faça sentido. Essa lista deve estar sempre priorizada por valor de negócio. Requisitos podem ser adicionados ou removidos a qualquer tempo, assim como a prioridade
também pode mudar. Ou seja, o Backlog precisa ser continuamente mantido pelo Product Owner, visando maximizar o retorno sobre o investimento.

3) Com o Backlog em mãos, o time e o Product Owner fazem o Sprint Planning 1, onde será definido “o quê” será feito durante o Sprint. Essa é a fase de “documentação” do
projeto. Histórias são refinadas, cenários de aceitação são escritos, e scketches feitos por designers podem ajudar a melhorar o entendimento do que precisa ser feito. As histórias
selecionadas, com os demais artefatos produzidos na reunião de trabalho, formam o Selected Product Backlog.

4) O Selected Product Backlog é o resultado do Sprint Planning 1, e define a quantidade de trabalho com a qual o time se comprometeu a entregar naquele Sprint. Ele se
mantém inalterado durante todo o Sprint.

5) O Sprint Planning 2 é a hora de definir “como” a solução será implementada. É a fase de “modelagem” do projeto. Nela, o time deve identificar as melhores soluções para
resolver cada um dos problemas, identificando as tarefas necessárias para atingir o objetivo.

6) O resultado do Sprint Planning 2 é o Sprint Backlog, uma lista de atividades necessárias para entregar a versão final das funcionalidades que serão aceitas pelo cliente.

7) Começa o Sprint. É a fase de “construção”, onde diariamente o time se reúne para sincronizar o trabalho que está sendo feito. O ciclo menor representa o primeira iteração,
em geral de duas a quatro semanas, onde todas as fases do projeto são exercitadas para que seja possível concluir um incremento de funcionalidade pronto para ser utilizado. Dentro
deste, o ciclo maior representa as iterações diárias onde o time se replaneja constantemente para achar soluções aos problemas que surgem durante o desenvolvimento.

8) Ao final do Sprint, uma reunião de Review acontece, onde são apresentadas ao cliente as funcionalidades que estão disponíveis para o uso. O cliente pode aceitar ou rejeitar as
funcionalidades nesse momento, além de sugerir melhorias ou novas ideias.

9) Finalmente, para encerrar o ciclo de melhoria contínua, acontece a Retrospectiva do Sprint, onde será identificado “o que deu certo” e “o que deu errado” no Sprint. São
identificados pontos de melhoria no processo e levantados impedimentos que atrapalham o melhor desempenho do time. Esse é um momento de reflexão do time, que precisa se sentir
seguro para falar tudo o que tem que ser dito. Por isso, participam desta reunião apenas os próprios membros do time e o ScrumMaster, fazendo a moderação. Qualquer exceção só
deve acontecer pela solicitação do próprio time.

O resultado
Não faltam bons exemplos de resultados positivos em empresas
brasileiras que adaptaram o Scrum aos seus projetos. A Provider Sistemas
começou a aplicar Scrum em abril de 2008, após um treinamento não
oficial sobre Scrum feito por Igor Macaúbas, ScrumMaster e Agile Coach
da empresa. “Durante quatro meses, convertemos todos os projetos
da empresa para Scrum. Hoje, temos quatro projetos rodando
simultaneamente, com cerca de trinta desenvolvedores trabalhando.
Isso só foi possível porque tivemos muito apoio da alta direção da
empresa, que percebeu de imediato os grandes benefícios e ganhos
que o método possibilitou ao nosso processo de desenvolvimento:
ganhamos transparência, visibilidade, previsibilidade, agilidade nas
entregas, e melhoria contínua no nosso processo. Como a cultura da
empresa já estava permeada com o conceito de melhoria contínua,
pois já tínhamos certificações ISO 9001 e MPS.BR nível G antes
do Scrum, aplicar o Scrum na organização nos ajudou a ser ainda
melhores. Após nossa implementação do Scrum, já passamos por
uma re-certificação da ISO, e estamos atualmente trabalhando para
aumentar o nosso nível de maturidade do MPS.BR (www.softex.
br/mpsbr) do nível G para o nível F – que é equivalente ao CMMi
nível 2. Tudo isso usando Scrum, aliado aos valores e princípios do
manifesto ágil, e às práticas de engenharia consistentes – como
programação em par, integração contínua, reuniões stand-up
(reuniões em pé de quinze minutos), refatoração, TDD etc.” conta
Igor. Na Globo.com, Guilherme Chapiewski resume o resultado em poucas
palavras: “Mais pessoas ficam satisfeitas com o resultado dos
projetos que fazemos. Os clientes tem mais oportunidade de opinar
e influenciar no resultado final, os desenvolvedores encontraram
mais organização para trabalhar e as mudanças já foram até além
dos projetos. Hoje em dia somos uma empresa muito melhor para
se trabalhar e conseguimos criar um ambiente de aprendizado
e colaboração que vejo em poucas empresas brasileiras.” diz.
Nelson Abu descreve o sucesso de um dos projetos do Instituto de Estudos
Avançados (IEA), que conta com onze desenvolvedores, um analista de
testes, três testadores de software, um DBA e um webdesigner na equipe
de TI, além de equipe de suporte e gestão de redes. “Uma das diretrizes
estratégicas do IEA é sempre contar com a tecnologia mais atual e,
para tanto, foi realizado um projeto para o desenvolvimento do seu
novo sistema de gestão de aprendizagem, o Learning Management
System (LMS), que durou sete meses, um tempo relativamente
curto, considerando o tamanho da equipe, os riscos do projeto e a
complexidade do sistema.” declara.
“Ganhamos transparência, visibilidade,
previsibilidade, agilidade nas entregas, e
melhoria contínua no nosso processo.” Ígor Macaúbas
Custa caro aplicar o Scrum?
No Brasil, empresas como a Caelum (www.caelum.com.br) e a
Teamware (www.teamware.com.br) oferecem cursos e workshops de
certificação ScrumMaster e Scrum Product Owner. O valor é um pouco
salgado para as 16 horas de duração do treinamento, divididas em dois
dias, variando de R$1.990,00 a R$2.300,00. As outras três certificações
Scrum, CSP, CSC e CST, são oferecidas apenas pela Scrum Alliance (www.
scrumalliance.org), a principal associação profissional para usuários
Scrum, que cultiva a troca de idéias e conhecimento através de bibliotecas,
certificações e grupos de usuários.
Algumas destas empresas trazem especialistas para o Brasil, como
o alemão Boris Gloger, um dos mais ativos ScrumMasters do mundo,
que ministra treinamentos Scrum desde 2004. Igor Macaúbas, um dos
TIdigital / Reportagem / Scrum :: 43
criadores do site Scrum Brasil (www.scrum.org.br), foi treinado por ele. “O
Boris é uma das pessoas mais experientes em Scrum do mundo. Ele
começou a utilizar Scrum em 2002, e desde então não parou mais.
Esteve presente na quarta turma oficial de CSMs, e foi treinado pelo
próprio Ken Schwaber. Além disso, o Boris foi o primeiro treinador
certificado pela Scrum Alliance (CST – Certified Scrum Trainer), e
já treinou mais de três mil pessoas. Sua didática é imbatível, e seus
treinamentos são sempre cheios de práticas e muito divertidos.”
conta Igor.
Hoje em dia somos uma empresa muito melhor
para se trabalhar e conseguimos criar um am-
biente de aprendizado e colaboração que vejo em
poucas empresas brasileiras. Nelson Abu
Outra maneira de implantar o Scrum é contratar um serviço de
treinamento e mentoring para implantação da metodologia nas empresas.
Na Dextra (www.dextra.com.br), que desenvolveu a metodologia PROUD
(Processo Unificado Dextra), baseada em RUP (Rational Unified Process),
Scrum e XP, o tempo e o custo de implantação variam de empresa para
empresa. “Depende diretamente de fatores como nível de senioridade
da equipe do cliente, resistência da equipe ao modelo, que é menos
burocrático porém mais participativo e exigente de dedicação,
tamanho da equipe, complexidade dos projetos e tecnologias
envolvidas e patrocínio ou não da alta direção ao novo modelo de
trabalho.” explica o MPS.Br nível F da Dextra, Marcos Alves. Os valores
para o investimento do serviço são altos, mas vale a pena pelo resultado
final. “O projeto de implantação do Scrum, partindo do zero até a
adoção definitiva e alcance de um nível de maturidade na empresa,
para que a equipe possa andar sozinha e evoluir continuadamente,
pode custar entre 30 e 70 mil reais, em prazos de seis meses a um
ano. São estimativas bem genéricas que variam muito de acordo
com a realidade e, principalmente, resistência interna da equipe do
cliente.” completa Marcos.
Para Alexandre Magno, é mais fácil preparar um profissional com
conhecimento cultural sobre o projeto e a empresa e capacitá-lo em Scrum
do que contratar um profissional com bom conhecimento de Scrum e
ensiná-lo a cultura da empresa. “Eu faço parte do time que defende as
empresas a formarem seus ScrumMasters. O principal motivo para
isso é que, ao meu ver, para ser um bom ScrumMaster você deve
conhecer e estar envolvido com a cultura da empresa.” diz.
O ScrumMaster contratado para certo projeto, deve avaliar o
tamanho do time, o tipo do projeto, os recursos disponíveis para treinamento
e consultoria, e o tempo disponível para execução de um projeto piloto.
“Normalmente, as empresas fazem um projeto piloto para testar
o Scrum e ver como ele se comporta. O custo varia de empresa
para empresa, de projeto para projeto, mas é senso comum que o
tempo para se ter uma implementação completa é entre seis a doze
semanas (três a seis Sprints de duas semanas). Se a empresa tiver
recursos para investir em um treinamento, pode recorrer a um dos
vários disponíveis no mercado.” explica Igor.
Apesar do pouco tempo da chegada do Scrum ao Brasil, a internet já
é uma ótima fonte de livros e artigos em português, para as empresas que
não possuem recursos para investir em treinamento. Um boa referência
é o e-book gratuito “XP e Scrum - direto das trincheiras” (tinyurl.com/
livro-scrum-e-xp). Além disso, pode-se recorrer às listas de discussão, como
a Scrum-Brasil do Yahoo! Groups, que tem cerca de 800 associados, e aos
diversos grupos de usuários de Scrum espalhados pelo mundo, com três em
atividade no Brasil, apoiados pela Scrum Alliance (www.scrumalliance.
org/pages/user_groups).
O Guia do Scrum

O Guia definitivo para o Scrum

As regras do jogo

Julho 2011

Desenvolvido e Mantido por Ken Schwaber e Jeff Sutherland

Traduzido para o Português por José Eduardo Deboni (eduardodeboni.com)

Conteúdo
Propósito do Guia do Scrum ........................................................................................................................ 3
Visão Geral do Scrum ................................................................................................................................... 3
Framework Scrum ........................................................................................................................................ 3
A Teoria do Scrum ........................................................................................................................................ 3
Transparência .............................................................................................................................................. 3
Inspeção ....................................................................................................................................................... 4
Adaptação .................................................................................................................................................... 4
Scrum ........................................................................................................................................................... 4
A Equipe de Scrum ....................................................................................................................................... 4
O Dono do produto ...................................................................................................................................... 5
A equipe de desenvolvimento ..................................................................................................................... 5
O Tamanho da Equipe de Desenvolvimento ................................................................................................ 6
O Scrum Master ........................................................................................................................................... 6
Os serviços do Scrum Master para o Dono do Produto ............................................................................... 6
Os serviços do Scrum Master para a Equipe de Desenvolvimento .............................................................. 6
Os serviços do Scrum Master para a Organização ....................................................................................... 7
Eventos do Scrum ........................................................................................................................................ 7
O Sprint ........................................................................................................................................................ 7
Cancelando um Sprint. ................................................................................................................................. 8
Reunião de Planejamento do Sprint ............................................................................................................ 8
Parte 1: O que será Pronto neste Sprint? .................................................................................................... 9
Parte 2: Como o trabalho escolhido será Pronto? ....................................................................................... 9
Objetivo do Sprint ........................................................................................................................................ 9
Scrum Diário............................................................................................................................................... 10
Revisão do Sprint ....................................................................................................................................... 10
A Retrospectiva do Sprint. ......................................................................................................................... 11
Backlog do produto .................................................................................................................................... 12
Monitorando o Progresso na direção de um Objetivo .............................................................................. 13
Backlog do Sprint ....................................................................................................................................... 13
Monitoramento do Progresso do Sprint .................................................................................................... 14
Incremento ................................................................................................................................................ 14
Definição do “Pronto” ................................................................................................................................ 14
Conclusão ................................................................................................................................................... 15
Agradecimentos ......................................................................................................................................... 16

© 1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos Pag. 2

Propósito do Guia do Scrum
Scrum é um framework para desenvolver e manter produtos complexos. Este Guia contém a definição
do Scrum. Esta definição consiste em papeis, eventos, artefatos do Scrum e as regras que mantém
tudo integrado. Ken Schwaber e Jeff Sutherland desenvolveram o Scrum, o Guia do Scrum é escrito e
oferecido por eles. Juntos, eles apoiam o Guia do Scrum.

Visão Geral do Scrum

Scrum (subs masc.): Um framework dentro do qual as pessoas podem resolver problemas adaptativos
complexos, enquanto, produtivamente e criativamente entregam produtos com o mais alto valor
possível. O Scrum é:

 Leve
 De entendimento simples
 Extremamente difícil de ter o domínio

O Scrum é um framework de processo quem tem sido usado para gerenciar o desenvolvimento de
produtos complexos desde o início dos anos 90. Scrum não é um processo ou técnica para construir
produtos, é mais um framework dentro do qual se pode empregar processos e técnicas variadas. O
Scrum torna clara a eficácia relativa das práticas de gerenciamento e desenvolvimento de produtos,
para que você possa melhorá-las.

Framework Scrum
O framework Scrum consiste nas equipes do Scrum, papéis, eventos, artefatos e regras associados.
Cada componente do framework serve a um propósito específico e é essencial para o sucesso e uso do
Scrum.

Estratégias específicas para uso do framework Scrum variam e são descritas em outros documentos.

As regras do Scrum integram os eventos, papéis e artefatos, governando as relações e interações entre
eles. As regras do Scrum são descritas ao longo do corpo deste documento.

A Teoria do Scrum
O Scrum está baseado nas teorias empíricas de controle de processo. O empirismo afirma que o
conhecimento vem da experiência e tomar decisões baseados no que se conhece. O Scrum aplica uma
abordagem iterativa e incremental para aperfeiçoar a previsibilidade e o controle de riscos.

Três pilares sustentam a implementação de um controle de processo empírico: transparência,

inspeção e adaptação.

Transparência
Aspectos significativos do processo devem estar visíveis para os responsáveis pelos resultados.
Transparência requer que aqueles aspectos sejam definidos por um padrão comum para que os
observadores compartilhem um entendimento comum do que está sendo visto.

© 1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos Pag. 3

Por exemplo:

 Uma linguagem comum para se referir ao processo, deve ser compartilhada por todos os
participantes,
 Uma definição comum de “Pronto1” deve ser compartilhada por aqueles que desempenham o
trabalho e aqueles que dão o aceite do produto do trabalho.

Inspeção
Os usuários do Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso com
objetivo de detectar variações não desejadas. Esta inspeção não deve ser tão frequente, que a
inspeção fique no caminho do trabalho. As Inspeções são mais benéficas quando desempenhadas por
inspetores habilidosos [diligentes] no local do trabalho.

Adaptação
Se um inspetor determina que um ou mais aspectos do processo desviar para longe de limites
aceitáveis, e que o resultado do produto não é aceitável, o processo ou o material que está sendo
processado deve ser ajustado. Um ajuste deve ser feito tão logo quanto possível para minimizar os
desvios futuros.

O Scrum prescreve quatro oportunidades formais para inspeção e adaptação, como descritas na seção
de Eventos do Scrum deste documento:

 Reunião de Planejamento do Sprint

 Scrum Diário
 Reunião de Revisão do Sprint
 Retrospectiva do Sprint

Scrum
O Scrum é um framework estruturado para suportar o desenvolvimento de produtos complexos. O
Scrum é formado pelas Equipes de Scrum e os papéis, eventos, artefatos e regras associadas. Cada
componente no framework serve para um propósito específico e é essencial para o uso e sucesso do
Scrum.

As regras do Scrum integram os eventos, papeis e artefatos, governando as relações e interações entre
eles. As regras do Scrum são descritas ao longo do corpo deste documento.

A Equipe de Scrum
A Equipe de Scrum é formada do Dono do Produto, da Equipe de Desenvolvimento e do ScrumMaster.
As Equipes de Scrum são auto organizadas e trans-funcionais. Equipes auto organizadas escolhem a
melhor forma de realizar seu trabalho, ao contrário de serem dirigidas por outros de fora da equipe.
Equipes trans-funcionais tem todas as competências necessárias para realizar o trabalho sem a
dependência de outras que não fazem parte da equipe. A equipe modelo no Scrum é projetada para
aperfeiçoar a flexibilidade, criatividade e produtividade.

1
Veja a definição na página 15.

© 1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos Pag. 4

As equipes do Scrum produzem iterativamente e incrementalmente, aproveitando ao máximo as
oportunidades para realimentação. Entregas incrementais de produtos “Prontos” garantem que uma
versão potencialmente útil do produto esteja sempre disponível.

O Dono do produto
O Dono do produto2 é responsável por maximizar o valor do produto e do trabalho da equipe de
desenvolvimento. Como isso é feito pode variar amplamente entre organizações, equipes de Scrum e
indivíduos.

O Dono do produto é a única pessoa responsável por gerenciar o Backlog do produto. O

gerenciamento do Backlog do produto inclui:

 Expressar com clareza os itens do Backlog do produto;

 Ordenar os itens do Backlog do produto para melhor alcançar os objetivos e missões;
 Garantir o valor do trabalho desempenhado pela equipe de desenvolvimento;
 Garantir que o Backlog do produto seja visível, transparente e claro para todos, e mostre no que
a equipe do Scrum irá trabalhar em seguida;
 Garantir que a equipe de desenvolvimento entenda os itens do Backlog do produto no nível
necessário.

O Dono do produto pode fazer o trabalho acima, ou deixar que a equipe de projeto o faça. Entretanto,
o Dono do produto é o responsável por ele.

O Dono do produto é uma pessoa, e não um comitê. O Dono do produto pode representar os desejos
de um comitê no backlog do produto, mas aqueles que quiserem mudar um item do backlog do
produto devem convencer o Dono do produto.

Para o Dono do produto ter sucesso, toda a organização deve respeitar a sua decisão. As decisões do
Dono do produto estão visíveis no conteúdo e na organização do backlog do produto. Ninguém está
autorizado a mandar a equipe de desenvolvimento trabalhar em um conjunto diferente de requisitos e
a equipe de desenvolvimento não está autorizada a agir sobre o que outras pessoas disserem.

A equipe de desenvolvimento
A equipe de desenvolvimento consiste de profissionais que realizam o trabalho de entregar uma
versão usável que potencialmente incrementa o produto “Pronto” no final de cada Sprint. Somente
membros da equipe de desenvolvimento criam o incremento.

As equipes de desenvolvimento são estruturadas e autorizadasligei pela organização para organizar e

gerenciar seu próprio trabalho. A sinergia resultante aperfeiçoa a eficiência e efetividade global. As
equipes de desenvolvimento têm as seguintes características:

 Elas são auto organizadas. Ninguém (nem mesmo o Scrum Master) diz para a equipe de
projetos como transformar o Backlog de produto em incrementos de funcionalidades
potencialmente utilizáveis;

2
Nota do Tradutor: O termo em inglês é Product Owner e foi traduzido aqui como Dono do Produto, em letra
maiúscula, para indicar que é um papel representado no processo do Scrum e não aquele que seria o
proprietário do produto de software.

© 1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos Pag. 5

  Equipes de desenvolvimento são trans funcionais, com todas as habilidades necessárias para
criar o incremento do produto.
 O Scrum não reconhece perfis dos membros da equipe de desenvolvimento além de
Desenvolvedor, independente do trabalho que está sendo realizado pela pessoa, não há
exceções a essa regra;
 Individualmente os membros da equipe de desenvolvimento podem ter habilidades
especializadas e áreas de especialização, mas pertencem e respondem à equipe de
desenvolvimento como um todo; e,
 Equipes de desenvolvimento não possuem sub-equipes dedicadas a domínios particulares do
conhecimento, como teste ou análise de negócio.

O Tamanho da Equipe de Desenvolvimento

O tamanho ótimo de uma equipe de desenvolvimento é suficientemente pequeno que se mantenha
ágil, e grande o suficiente para completar uma parcela representativa do trabalho. Menos do que três
membros em uma equipe de desenvolvimento diminui a interação e resulta em ganhos menores de
produtividade. Equipes pequenas podem encontrar limitações nas habilidades necessárias para um
Sprint, e como consequência não conseguindo entregar um incremento potencialmente utilizável.
Tendo mais do que nove membros se requer muita coordenação. Equipes de desenvolvimento grandes
geram muita complexidade para um processo empírico gerenciar. Os papeis de Dono do produto e o
Scrum Master não são incluídos nesta contagem a não ser que eles também executem o trabalho do
Sprint Backlog.

O Scrum Master
O Scrum Master é responsável para garantir que o Scrum seja entendido e aplicado. Os Scrum Masters
fazem isso garantindo que as equipes de Scrum obedeçam à teoria, práticas e regras do Scrum. O
Scrum Master é um líder-facilitador para a equipe do Scrum.

O Scrum Master ajuda aqueles de fora da equipe do Scrum entender quais são as interações com a
equipe do Scrum que são benéficas e quais não são. O Scrum Master ajudar todos a mudar suas
interações para maximizar o valor criado pela equipe de Scrum.

Os serviços do Scrum Master para o Dono do Produto

O Scrum Master serve ao Dono do produto de várias formas, incluindo:

 Encontrar técnicas para o gerenciamento efetivo do Backlog do produto,

 Comunicar claramente a visão, objetivos e os itens do Backlog do Produto para a Equipe de
Desenvolvimento,
 Ensinar a Equipe de Desenvolvimento como criar itens do Backlog do produto claros e concisos,
 Entender o planejamento de longo prazo do produto em um ambiente empírico,
 Entender e praticar a agilidade,
 Facilitar os eventos do Scrum quando solicitado ou necessário.

Os serviços do Scrum Master para a Equipe de Desenvolvimento

O Scrum Master serve a Equipe de Desenvolvimento de várias formas, incluindo:

© 1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos Pag. 6

  Orientar a Equipe de Desenvolvimento na sua auto organização e trans-funcionalidade,
 Ensinar ou liderar a Equipe de Desenvolvimento para criar um produto de alto valor,
 Remover impedimentos para o progresso da equipe de desenvolvimento,
 Facilitar os eventos do Scrum quando solicitado ou necessário,
 Orientar a Equipe de Desenvolvimento no ambiente organizacional no qual o Scrum ainda não é
amplamente adotado e compreendido.

Os serviços do Scrum Master para a Organização

O Scrum Master serve a organização de várias formas, incluindo:

 Liderar e Orientar a organização na adoção do Scrum,

 Planejar as implementações do Scrum dentro da organização,
 Ajudar empregados e stakeholders a entender e implantar o Scrum e o desenvolvimento
empírico de produtos,
 Provocar mudanças que aumentem a produtividade na Equipe de Scrum,
 Trabalhar com outros Scrum Masters para aumentar a efetividade da aplicação do Scrum na
organização.

Eventos do Scrum
Eventos prescritos são usados no Scrum para criar uma rotina e para minimizar a necessidade de
encontros não definidos no Scrum. O Scrum usa eventos time-boxed3, onde cada evento tem uma
duração máxima. Isso garante uma quantidade apropriada de tempo gasto em planejamento sem
permitir perdas no processo de planejamento.

Além da própria Sprint, que é um container para outros eventos, cada evento no Scrum é uma
oportunidade para inspecionar e adaptar algo. Estes eventos são projetados especificamente para
permitir uma transparência crítica e inspeção. Não incluir qualquer destes eventos é reduzir a
transparência e perder a oportunidade para inspecionar e adaptar.

O Sprint
O coração do Scrum é o Sprint, um time-box de um mês ou menos durante o qual uma versão
potencialmente utilizável de um incremento do produto é criada. Sprints tem durações consistentes ao
longo do esforço de desenvolvimento. Um novo Sprint começa imediatamente depois da conclusão do
Sprint anterior.

Sprints consistem em uma reunião de planejamento do Sprint, Scrums Diários, o trabalho de

desenvolvimento, a reunião de revisão do Sprint e a Retrospectiva do Sprint.

Durante o Sprint:

 Nenhuma mudança deve ser feita que afete o objetivo do Sprint,

3
N.T. Time-boxed foi deixado em inglês por que reflete mais precisamente o conceito do Sprint no Scrum de ter
um prazo fixo (intervalo de tempo fixo).

© 1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos Pag. 7

  A composição da equipe de desenvolvimento e a qualidade dos objetivos se mantêm
constantes,
 O escopo pode ser esclarecido e renegociado entre o Dono do produto e a equipe de
desenvolvimento quando for aprendido mais.

Cada Sprint pode ser considerado um projeto com um horizonte que não pode ser maior do que um
mês. Como projetos, Sprints são usados para se conquistar algo. Cada Sprint possui uma definição do
que deve ser construído, um projeto e um plano flexível que vai guiar a construção o trabalho e o
produto resultante.

Sprints são limitados a um mês corrido. Quando o horizonte do Sprint é muito longe a definição do que
será construído pode mudar, complexidade pode aumentar e o risco pode se elevar. Sprints permitem
a previsibilidade garantindo inspeção e adaptação do progresso na direção de um objetivo pelo menos
a cada mês. Sprints também limitam o risco ao custo de um mês.

Cancelando um Sprint.
Um Sprint pode ser cancelado antes cde o seu prazo ter se esgotado. Somente o Dono do produto tem
a autoridade para cancelar o Sprint, apesar de que ele (ou ela) pode fazer isso sob a influência dos
stakeholders, da equipe de Desenvolvimento ou do Scrum máster.

Um Sprint será cancelado se o Objetivo do Sprint se tornar obsoleto. Isso pode ocorrer se empresa
mudar a direção ou se as condições de mercado ou tecnologia mudarem. Em geral, um Sprint deve ser
cancelado se ele não fizer mais sentido às dadas circunstâncias. Mas, dada a curta duração do Sprint, o
cancelamento raramente faz sentido.

Quando um Sprint é cancelado,, qualquer dos itens do Backlog do Produto que estiver completado e
“Pronto” é revisado. Se uma parte do trabalho estiver potencialmente entregável, o Dono do produto
[tipicamente], o aceita. Todo o trabalho incompleto do Backlog do Produto são re-estimados e
colocados novamente no Backlog do Produto. O trabalho Pronto nele deprecia rapidamente e deve ser
constantemente re-estimado.

O cancelamento de Sprints consome recursos, desde que todos devem se reagrupar em outra reunião
de planejamento de Spring para iniciar outro Sprint. O cancelamento de Sprints é sempre traumático
para a Equipe de Scrum, e é muito incomum.

Reunião de Planejamento do Sprint

O trabalho a ser executado no Sprint é planejado na Reunião de Planejamento do Sprint. Este plano é
criado pelo trabalho colaborativo de toda a equipe do Scrum.

A reunião de planejamento do Sprint é fixa em oito horas para um Sprint de um mês. Para Sprints mais
curtos, o evento é proporcionalmente menor. Por exemplo, Sprints de duas semanas, tem Reunião de
Planejamento do Sprint de quatro horas.

A Reunião de Planejamento do Sprint é dividida em duas partes, cada uma tendo a metade do tempo
fixo, dedicado à reunião de planejamento do Sprint. As duas partes da Reunião de Planejamento do
Sprint respondem às seguintes questões, respectivamente:

© 1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos Pag. 8

  O que vai ser entregue como resultado do Incremento do próximo Sprint?
 Como será realizado o trabalho necessário para entregar o Incremento?

Parte 1: O que será Pronto neste Sprint?

Nesta parte, a Equipe de Desenvolvimento trabalhar para prever a funcionalidade que será
desenvolvida durante o Sprint. O Dono do Produto apresenta os itens do Backlog do produto
ordenado para a Equipe de Desenvolvimento e toda a Equipe do Scrum colabora no entendimento do
trabalho do Sprint.

Como dado de entrada para a reunião temos o Backlog do Produto, o último Incremento do produto, a
capacidade projetada da Equipe de Desenvolvimento durante o Sprint e o desempenho passado da
Equipe de desenvolvimento. Somente a equipe de desenvolvimento pode avaliar o que poderá
conseguir fazer no próximo Sprint.

Depois da previsão da Equipe de Desenvolvimento dos itens do Backlog do Produto que serão
entregues por este Sprint, a equipe de Scrum produz o Objetivo do Sprint. O Objetivo do Sprint é um
objetivo que será atingido pelo Sprint por meio da implementação do Backlog do Produto, e oferece
uma orientação para a Equipe de desenvolvimento sobre a construção do Incremento.

Parte 2: Como o trabalho escolhido será Pronto?

Tendo selecionado o trabalho do Sprint, a equipe de desenvolvimento decide como ela irá transformar
esta funcionalidade em Incrementos “Prontos” durante o Sprint. Os itens selecionados do Backlog do
Produto para este Sprint somado ao plano para entregá-los é chamados de Backlog do Sprint.

A equipe de desenvolvimento usualmente inicia desenhando o sistema e o trabalho que precisa ser
convertido de um Backlog do produto ao incremento executável do produto. O trabalho pode variar de
tamanho, ou estimativa de esforço. Entretanto, o trabalho suficiente é planejado durante a Reunião de
Planejamento do Sprint pela Equipe de Desenvolvimento para prever o que ela acredita possa fazer no
Sprint seguinte. O Trabalho planejado para os primeiro dias é decomposto em unidades de um dia ou
menos até o final da reunião. A equipe de Desenvolvimento se auto organiza para realizar o trabalho
no Backlog do Sprint, tanto durante a Reunião de Planejamento do Sprint e quando for necessário ao
longo do Sprint.

O Dono do Produto pode estar presente durante a segunda parte da Reunião de Planejamento do
Sprint para esclarecer itens selecionados do Backlog do Produto e para ajudar a realizar os
compromissos. Se a Equipe de Desenvolvimento determina que tenha demasiado trabalho ou que tem
pouco trabalho, ela pode renegociar itens do Backlog do Sprint com o Dono do Produto. A Equipe de
Desenvolvimento pode também convidar outras pessoas para participar da reunião, oferecendo
aconselhamento técnico ou do domínio.

No final da reunião de planejamento do Sprint, a Equipe de Desenvolvimento deve estar apta a

explicar ao Dono do Produto e ao Scrum Master como pretende trabalhar como uma equipe auto
organizada para conseguir criar o Incremento desejado e atingir o Objetivo do Sprint.

Objetivo do Sprint
O objetivo do Sprint dá alguma flexibilidade à equipe de desenvolvimento sobre as funcionalidades a
serem implementadas no Sprint.

© 1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos Pag. 9

Com o andamento do trabalho da Equipe de Desenvolvimento, ela mantém em mente o objetivo. De
modo a atender ao objetivo do Sprint, ela implementa a funcionalidade e a tecnologia. Se o trabalho
se torna diferente do que o que a Equipe de Desenvolvimento esperava, ela pode colaborar com o
Dono do produto para negociar o escopo do Backlog do Sprint dentro do Sprint.

O objetivo do Sprint pode ser um marco dentro do propósito maior no mapa do produto.

Scrum Diário
A Reunião do Scrum Diário é um evento com 15 minutos fixos para a Equipe de Desenvolvimento
sincronizar as atividades e criar um plano para as próximas 24 horas. Isso se faz inspecionando o
trabalho até o último Scrum Diário e prevendo o trabalho que pode ser Pronto antes do próximo.

O Scrum diário se dá no mesmo horário e lugar todo o dia para reduzir a complexidade. Durante o
encontro, cada membro da Equipe de Desenvolvimento esclarece:

 O que tem conseguido realizar desde o último encontro?

 O que vai ser Pronto até o próximo encontro?
 Quais são os obstáculos que estão no seu caminho?

A Equipe de Desenvolvimento usa o Scrum Diário para avaliar o progresso na direção do Objetivo do
Sprint e para avaliar se o progresso tende para completar o trabalho no Backlog do Sprint. O Scrum
Diário aumenta a probabilidade da Equipe de Desenvolvimento atingir o Objetivo do Sprint. A Equipe
de Desenvolvimento em geral, se encontra imediatamente depois do Scrum Diário para replanejar o
restante do trabalho do Sprint. Todo dia, a Equipe de Desenvolvimento deve estar apta a explicar para
o Dono do Produto e para o Scrum Master como pretende trabalhar em conjunto, como uma equipe
auto organizada para atingir o objetivo e criar o incremento desejado no restante do Sprint.

O Scrum Master garante que a equipe de desenvolvimento tem o encontro, mas a Equipe de
Desenvolvimento é responsável por conduzir o Scrum Diário. O Scrum Master ensina a Equipe de
Desenvolvimento a manter o Scrum Diário dentro do limite de tempo de 15 minutos.

O Scrum Master aplica a regra que somente os membros da Equipe de Desenvolvimento participem do
Scrum Diário. O Scrum Diário não é uma reunião de status, e é voltada para as pessoas que
transformam os itens do Backlog em um Incremento.

Os Scrums Diários melhoram a comunicação, eliminam outras reuniões, identificam e removem os

impedimentos para o desenvolvimento, destacam e promovem uma tomada de decisão rápida, e
melhoram o nível do conhecimento do projeto da Equipe de Desenvolvimento. Esta é a reunião chave
para inspeção e adaptação.

Revisão do Sprint
A Reunião de Revisão do Sprint é executada no final do Sprint para inspecionar o Incremento e adaptar
ao Backlog do Produto se necessário. Durante a Revisão do Sprint, a Equipe de Scrum e stakeholders
colaboram sobre o que foi Pronto no Sprint. Baseado nisso e em qualquer mudança no Backlog do
Produto durante o Sprint, os presentes colaboram nas próximas coisas que precisam ser feitas. Está é

© 1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos Pag. 10

uma reunião informal, e a apresentação do Incremento tem como intenção motivar uma
realimentação e incentivar a colaboração.

Esta é uma reunião de time-box de 4 horas para um Sprint de um mês. Proporcionalmente menos
tempo é alocado para Sprints mais curtos. Por exemplo, Sprints de duas semanas vão ter Revisões de
Sprint de duas horas.

A Revisão do Sprint inclui os seguintes elementos:

 O Dono do produto identifica que foi “Pronto” e o que não foi “Pronto”.
 A Equipe de Desenvolvimento discute que foi bem durante o Sprint, quais problemas ocorreram
e como estes problemas foram resolvidos;
 A Equipe de Desenvolvimento demonstra o trabalho que foi “Pronto” e responde as perguntas
sobre o incremento;
 O Dono do Produto discute o Backlog do Produto. Ele projeta a data mais provável de término
baseado no progresso até o momento; e,
 Todo o grupo colabora no que deve ser Pronto em seguida assim, a Revisão do Spring fornece
um entrada valiosa para as próximas reuniões de Planejamento do Sprint.

O resultado da revisão do Sprint é um Backlog do Produto revisado que define os prováveis itens do
Backlog do Produto para a próxima Sprint. O Backlog do produto pode ser ajustado como um todo
para atender novas oportunidades.

A Retrospectiva do Sprint.
A retrospectiva do Sprint é uma oportunidade para a Equipe do Scrum inspecionar-se a si mesma e
criar um plano de melhorias que deve ser valer durante o próximo Sprint.

A Retrospectiva do Sprint ocorre depois da Revisão do Sprint e antes da Próxima reunião de

planejamento do Sprint. Esta é uma reunião marcada para com um time-box de 3 horas para um mês
de Sprints. Proporcionalmente um tempo menor é alocado para Sprints menores.

O propósito da Retrospectiva do Sprint é:

 Inspecionar como foi o último Sprint no que diz respeito a pessoas, relações, processos e
ferramentas,
 Identificar e ordenar os principais itens que foram bem e as potenciais melhorias,
 Criar um plano para programar melhorias no modo de como a Equipe de Scrum trabalha.

O Scrum máster encoraja a Equipe de Scrum para melhorar, dentro do framework de processo do
Scrum, o processo de desenvolvimento e as práticas para fazê-lo mais efetivo e agradável para o
próximo Sprint. Durante cada Retrospectiva do Sprint, a Equipe de Scrum planeja modos para
aumentar a qualidade do produto adaptando a definição de “pronto” quando apropriado.

No final da retrospectiva do Sprint, a equipe de Scrum deve identificar melhorias que serão aplicadas
no próximo Sprint. Implementar estas melhorias no próximo Sprint é adaptar a inspeção na própria

© 1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos Pag. 11

Equipe do Scrum. Apesar de que melhorias podem ser adotadas a qualquer momento, a Retrospectiva
do Sprint oferece um evento dedicado focado na inspeção e adaptação.

Artefatos de Scrum
Os artefatos do Scrum representam o trabalho ou valor de várias formas que são úteis de oferecer
transparências e oportunidades para inspeção e adaptação. Os artefatos definidos no Scrum são
especialmente projetados para maximizar a transparência e a informação chave necessários para
garantir que as equipes do Scrum sejam bem sucedidas ao entregar o Incremento “Pronto”.

Backlog do produto
O Backlog do produto é uma lista ordenada de tudo o que pode ser necessário no produto e é a fonte
única dos requisitos para qualquer mudança a ser feita no produto. O Dono do Produto é responsável
para o Backlog do Produto, incluindo o seu conteúdo, disponibilidade e ordenação.

Um Backlog do produto nunca está completo. A versão inicial dele apenas descreve o que foi
conhecido no início e os requisitos mais bem conhecidos. O Backlog do produto evolui ao mesmo
tempo em que o produto e o ambiente no qual ele será usado evolui. O Backlog do Produto é
dinâmico; ele muda constantemente para identificar o que o produto precisa para ser útil, apropriado
e competitivo. Enquanto um produto existir, um Backlog do Produto deve existir.

O Backlog do Produto lista todas as funcionalidades, funções, requisitos, melhorias e consertos que
representam as mudanças a serem feitas no produto para as próximas versões. Os itens do Backlog do
Produto tem os atributos de descrição, ordem e estimativa.

O Backlog do produto é, geralmente, ordenado por valor, risco, prioridade e necessidade. Os itens
mais altos do Backlog do Produto determinam atividades de desenvolvimento mais imediatas. Quanto
mais alto a ordem do item, mais o item do Backlog do Produto deve ser considerado, e mais consenso
existe a respeito deste valor.

Itens do Backlog do produto de ordem mais alta devem ser mais claros e serem mais detalhados que
os de ordem inferior. Estimativas mais precisas são feitas com base na maior clareza e aumento de
detalhes; quanto mais baixa a ordem, menos detalhes. Os itens do Backlog do Produto que vão ocupar
a equipe de desenvolvimento no próximo Sprint são bem refinados, tendo sido decompostos para que
todos os itens possam ficar “Prontos” dentro dos limites do Time-box do Sprint. Os itens do Backlog do
Produto que podem ficar “Prontos” pela Equipe de Desenvolvimento dentro de um Sprint são
marcados como “disponíveis” ou “executáveis” para seleção na reunião de Planejamento do Sprint.

Enquanto um produto é usado, e ganha valor, e o mercado oferece uma realimentação, o Backlog do
Produto se torna uma lista longa e mais completa. Requisitos nunca param de mudar, assim o Backlog
do produto é um artefato vivo. Mudanças nos requisitos do negócio, condições de mercado ou
tecnologia podem provocar mudanças no Backlog do produto.

Múltiplas Equipes de Scrum frequentemente trabalham juntas no mesmo produto. Um Backlog do

Produto é usado para descrever o trabalho previsto para o produto. Um atributo do Backlog o Produto
que agrupa os itens é aplicado.

© 1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos Pag. 12

A preparação do Backlog do produto é o ato de adicionar detalhes, estimativas e ordenar os itens no
Backlog do produto. Este é um processo contínuo no qual o Dono do Produto e a Equipe de
Desenvolvimento colaboram nos detalhes dos itens do Backlog do produto. Durante a preparação do
Backlog do Produto, os itens são analisados e revisados. Entretanto, eles podem ser atualizados a
qualquer momento pelo Dono do Produto ou escolha do Dono do Produto.

Preparação é uma atividade em tempo parcial durante um Spring entre o Dono do Produto e da
Equipe de Desenvolvimento. Frequentemente as equipes de Desenvolvimento devem preparar o
próprio domínio do conhecimento. Como e quando a preparação é feita é decidida pela Equipe do
Scrum. Preparação usualmente consome não mais do que 10% da capacidade da Equipe de
Desenvolvimento.

A equipe de desenvolvimento é responsável por todas as estimativas. O Dono do produto pode

influenciar a equipe ajudando a entender e selecionar os compromissos, mas as pessoas que vão
realizar o trabalho é quem deve fazer a estimativa final.

Monitorando o Progresso na direção de um Objetivo

Em qualquer momento no tempo, o trabalho total restante para se atingir um objetivo pode ser
sumarizado. O Dono do Produto acompanha o trabalho total restante pelo menos em cada Revisão do
Sprint. O Dono do Produto compara o total de trabalho faltante na revisão anterior do Sprint para
avaliar o progresso na direção de completar o trabalho projetado pelo tempo estimado para o
objetivo. Esta informação se torna transparente para todos os stakeholders.

O Scrum não consideram o tempo gasto no trabalho com os Itens do Backlog do produto. O trabalho
restante e as datas são as únicas variáveis de interesse.

Várias práticas como burndown, burnup e outras práticas de estimativa tem sido usadas para prever o
progresso. Elas tem se provado úteis. Entretanto, Elas não substituem a importância do empirismo. Em
ambientes complexos, o que vai acontecer é desconhecido. Somente o que aconteceu pode ser usado
para uma tomada de decisão do que vai vir.

Backlog do Sprint
O Backlog do Sprint é um conjunto de itens do Backlog do produto selecionados para o Sprint além de
um plano para obter o incremento do produto e atingir o objetivo do Sprint. O Backlog do Sprint é uma
previsão da Equipe de Desenvolvimento sobre qual funcionalidade estará no próximo incremento e do
trabalho necessário para entregar esta funcionalidade.

O Backlog do Sprint define o trabalho que a Equipe de Desenvolvimento irá desempenhar para
transformar os itens do Backlog do produto em Incrementos “Prontos”. O Backlog do Sprint torna
visível todo o trabalho que a Equipe de Desenvolvimento identifica como necessário para atingir o
Objetivo do Sprint.

O Backlog do Sprint é um plano com detalhes suficiente que as mudanças em progresso sejam
entendidas no Scrum Diário. A Equipe de Desenvolvimento modifica o Backlog do Sprint ao longo do
Sprint, e o Backlog do Sprint surge durante o Sprint. Este surgimento ocorre quando a Equipe de
Desenvolvimento trabalha segundo o plano e aprende mais sobre o trabalho necessário para atingir o
objetivo do Sprint.

© 1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos Pag. 13

Se um novo trabalho for necessário, A Equipe de Desenvolvimento o adiciona ao Backlog do Sprint. Na
medida em que o trabalho é desempenhado e completado, a estimativa do trabalho restante é
atualizada. Quando elementos do plano se mostrarem desnecessários, eles são removidos. Somente a
Equipe de Desenvolvimento pode alterar o Backlog do Sprint durante o Sprint. O Backlog do Sprint é
uma figura em tempo real, altamente visível, do trabalho que a Equipe de Desenvolvimento planeja
atingir durante o Sprint, e pertence somente à Equipe de desenvolvimento.

Monitoramento do Progresso do Sprint

A qualquer instante do tempo de um Sprint, o trabalho total restante nos itens do Backlog do Sprint
pode ser sumarizado. A Equipe de desenvolvimento acompanha este total de trabalho restante pelo
menos todo Scrum Diário. A Equipe de Desenvolvimento acompanha estes totais diários e projeta a
que mais provavelmente vai alcançar o Objetivo do Sprint. Por rastrear o trabalho restante pelo Sprint,
a Equipe de Desenvolvimento pode gerenciar o seu progresso.

O Scrum não considera o tempo gasto nos itens do Backlog do Sprint. O trabalho restante e as datas
são as únicas variáveis de interesse.

Incremento
O incremento é a soma de todos os itens do Backlog do produto completados por um Sprint e por
todos os Sprints anteriores. No final de um Sprint, o novo Incremento deve estar “Pronto”, o que
significa que ele está em uma condição utilizável e atende à definição da Equipe do Scrum do “Pronto”.
Ele deve estar em uma condição utilizável independente da decisão do Dono do Produto decidir
realmente liberá-lo.

Definição do “Pronto”
Quando um item do Backlog do Produto ou um Incremento é descrito como “Pronto”, todos devem
entender o que “Pronto” significa. Apesar de que isso pode variar significativamente para cada Equipe
de Scrum, os membros devem ter um entendimento compartilhado do que significa que o trabalho
estar completo, para garantir transparência. Esta é a “definição de “Pronto”” para a equipe do Scrum e
é usado para avaliar quando o trabalho está completo no Incremento do Produto.

A mesma definição orienta a Equipe de Desenvolvimento em saber quantos itens do Backlog do

produto ela pode selecionar durante a Reunião de Planejamento do Sprint. O propósito de cada Sprint
é entregar Incrementos de funcionalidades potencialmente utilizáveis que atende à definição atual da
equipe de Desenvolvimento para “Pronto”.

A Equipe de Desenvolvimento entrega um Incremento da funcionalidade do Produto a cada Sprint.

Este Incremento é usável, assim o Dono do produto pode decidir liberá-lo imediatamente. Cada
Incremento é adicionável ao todos os Incrementos anteriores e por meio de testes, garantir que too o
incremento trabalha em conjunto.

Na medida de que a equipe de Scrum fica madura, se espera que a definição de “Pronto” expanda para
incluir critérios mais rigorosos de maior qualidade.

© 1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos Pag. 14

Conclusão
O Scrum é livre e proposto neste guia. Os papeis, artefatos, eventos e regras do Scrum são imutáveis e
apesar de que implementação apenas de partes do Scrum é possível, o resultado não é um Scrum. O
Scrum existe somente na sua totalidade e funciona bem como um container para outras técnicas,
metodologias e práticas.

© 1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos Pag. 15

Agradecimentos
Pessoas

Das milhares de pessoas que tem contribuído para o Scrum, nós gostaríamos de destacar aqueles que
foram essenciais nos seus primeiros anos. Inicialmente a Jeff Sutherland, trabalhando com Jeff
McKenna e Ken Schwaber, trabalhando com Mike Smith e Chris Martin. Muitos outros contribuiram
nos anos seguintes e sem a sua ajuda, o Scrum não seria refinado como é hoje. David Starr ofereceu
insights chave e habilidades editoriais na formulação desta versão do Guia do Scrum.

História

Ken Schwaber e Jeff Sutherland co-apresentaram inicialmente na conferencia OOPSLA em 1XXX. Esta
apresentação essencialmente documentou o aprendizado de Ken e Jeff nos anos que antecederam a
aplicação do Scrum. A história do Scrum já é considerada longa. Para honrar os primeiros lugares onde
ele foi tentado e refinado, nós reconhecemos a Individual, Inc., Fidelity Investments e IDX (hoje GE
Medical).

© 1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos Pag. 16

Revisões

O Guia do Scrum de Julho de 2011 é diferente do seu predecessor, o Guia de Fevereiro de 2010. Em
particular, nós tentamos remover técnicas e boas práticas do núcleo do Scrum. Elas podem variar
baseado nas circunstâncias. Nós vamos começar um compêndio de boas práticas para prover um
pouco da nossa experiência recente.

O Guia do Scrum documenta o Scrum enquanto ele se desenvolve e se mantém por mais de vinte
anos por Jeff Sutherland e Ken Schwaber. Outras fontes provêm padrões, processos e visões sobre
como as práticas, facilitadores e ferramentas complementam o framework do Scrum. Isto aperfeiçoa a
produtividade, valor, criatividade e orgulho.

Notas emitidas cobrindo as seguintes diferenças entre este guia e a versão de 2010 serão publicadas
em outros lugares, incluindo discussões sobre:

1. Planejamento de Release.

2. Burndown do Release.

3. Backlog do Sprint.

4. Burndown do Product e Backlog do Sprint Backlog.

5. Compromisso agora é previsão.

6. Equipe (para Equipe de Desenvolvimento).

7. Porcos e Galinhas … o conto do Scrum.

8. Ordenados no lugar de priorizados.

© 1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos Pag. 17

 27/02/2012

50,00
45,00 44
42
40,00 37
35,00 32
30,00
25,00 24
21
20,00
2009
2011
15,00
10,00
5,00
0,00
Sucesso Fracasso Contestados

Os primeiros 90% do trabalho

levam 90% do tempo para ficarem prontos

Os 10% finais

levam mais 90% do tempo para terminar

1
 27/02/2012

• Indivíduos e interações 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. Ser ágil = vantagem
competitiva

2
 27/02/2012

• Entregas contínuas com valor agregado

• Comunicação face a face método mais
eficaz de transmitir informações
• Trabalho sustentável ritmo constante
do time indefinidamente
• Reflexão em intervalos regulares o
time reflete sobre como se tornar mais eficaz,
refina e ajusta seu comportamento.

• Criado por Ken Schwaber e Jeff Sutherland

• Processo empírico
• Um framework, não uma metodologia
• Iterativo e incremental
• Entrega em ciclos curtos, de 2 a 4 semanas.
• Simples mas difícil, exige disciplina!
• Utiliza times autoorganizados e
autogerenciados
• Para times de alta performance

3
 27/02/2012

• Está em uso a mais de dez anos

• Cultura, cultura, cultura
• Em 2008, 84% dos projetos ágeis
• Não é exclusivo para TI, já é utilizado em
planejamento pessoal, áreas
administrativas, igrejas, escolas, e outras
organizações
• Responder de forma ágil a desafios
emergentes

• Baseado em:

• Transparência: garante que aspectos do

processo que afetam o resultado sejam
visíveis para os que gerenciam os resultados.

• Inspeção: Os diversos aspectos do processo

devem ser inspecionados com uma
freqüência suficiente para que variações
inaceitáveis no processo possam ser
detectadas

4
 27/02/2012

• Adaptação: À partir da inspeção, se um ou

mais aspectos do processo estão fora dos
limites aceitáveis, esse ajuste deve ser feito
o mais rápido para evitar desvios.

• Papéis
• Product Owner
• Scrum Master
• Team
• Cerimônias
• Release Planning
• Planning Meeting
• Dailly Meeting
• Sprint review
• Sprint Restrospective

• Artefatos
• Backlog do Produto
• Bourndown da Release
• Backlog da Sprint
• Bourndown da Sprint

• Estimativas
• Planning Poker

5
 27/02/2012

• Único responsável pela gestão do product

backlog
• Garante visibilidade do backlog a todos os
envolvidos
• Garante que especialistas de domínio
estejam disponíveis ao time

6
 27/02/2012

• Não é o gerente!
• Garante a aderência do time aos valores e
princípios do SCRUM
• Atua como Couch
• Auxilia o Product Owner com o Product
Backlog

7
27/02/2012

8
 27/02/2012

• Transformam o backlog em entregáveis

de valor
• Multidisciplinares
• Auto-organizáveis e auto-gerenciáveis
• Entre 5 e 9 membros
• Comprometidos

• Estimar e priorizar o backlog do produto

• Programar as entregas

9
 27/02/2012

• Coração da sprint
• Planejamento da próxima iteração
• O que e como fazer
• Definição do objetivo da sprint
• O product Owner prioriza o Product
Backlog para ser incluído na sprint

• Definição de pronto
• Um incremento potencialmente
entregável. Deve ser claro para toda a
equipe que quando está pronto,
realmente está pronto, não falta nada.
• A definição deve combinada entre os
envolvidos.

10
27/02/2012

11
27/02/2012

12
 27/02/2012

• Lista inicial de atividades para atender a

visão do produto
• Lista ordenada por valores
• Deve existir apenas um Product Backlog
ao longo do projeto
• Atualizado regularmente pelo PO

13
 27/02/2012

• Apresentação dos valores construídos

durante a Sprint
• Demonstrar o que foi finalizado ou não
• Estimar possível data de conclusão a
partir de hipóteses de velocidades

• Revisão das práticas e do processo

• Composição Time, Ferramentas, definição
de pronto

14
 27/02/2012

• MARSAL MELO
@MarsalMelo
marsalmelo@gmail.com
www.marsalmelo.com.br

15
As máximas Cerne do Scrum the unofficial Tradução: Demetrius Nunes
Se você atender a esses, você pode
ignorar o resto do checklist. Seu processo
está ótimo!
Esses são essenciais. Sem esses você
provavelmente não deveria chamar de Scrum. Scrum Checklist www.demetriusnunes.com

Entregando software testado a Retrospectivas ocorrem a cada

cada 4 semanas ou menos. sprint
Resulta em propostas de Henrik Kniberg
Entregando o que
melhorias concretas
o negócio mais precisa
Algumas propostas são Recomendado mas nem sempre necessário
Processo está realmente implementadas A maioria desses são necessários, mas nem todos eles. Experimente!
continuamente melhorando
Todo o time + PO
Time tem todas as Itens do PBL são quebrados
participam
competências necessárias em tarefas dentro da sprint
Product Owner (PO) PO tem um backlog do Membros não ficam dedicados Tarefas do sprint são
claramente definido produto (PBL) a papéis específicos estimadas
PO tem autoridade para Itens do topo priorizados Iterações que estão destinadas Estimativas são
priorizar por valor de negócio a falhar são abortadas cedo atualizadas diariamente
PO tem conhecimento Itens do topo estimados
para priorizar PO tem visão do produto que
Velocidade é medida
está sincronizada com o PBL
PO tem contato direto Estimativas feitas pelo
com time time PBL e visão do produto são Todos os itens do sprint
altamente visíveis tem uma estimativa
PO tem contato direto Itens do topo pequenos e
com clientes cabem em um sprint Todos no time participam das PO usa velocidade para
estimativas planejar lançamentos
PO fala com uma voz (se PO entende a razão de
o PO for um time) todos os itens do backlog PO disponível quando o time Velocidade inclui apenas
está estimando itens que estão Done
Existem reuniões de
Time tem backlog do sprint planejamento do sprint Estimativa em tamanho relativo Time tem um gráfico de
(pontos) ao invés de tempo burndown do sprint
Altamente visível PO participa
Todo time conhece os 1-3 Altamente visível
principais impedimentos
Atualizado diariamente PO traz PBL atualizado
SM tem estratégia para Atualizado diariamente
consertar impedimento
Pertence exclusivamente Todo time participa
ao time SM focado em remover Reunião Diária ocorre todo dia,
Resulta em um impedimentos na mesma hora & lugar
planejamento do sprint Gerência acionável
Reunião Diária ocorre PO participa ao menos de
Todo time acredita que quando time não resolve vez em quando
sprint é viável
Todo time participa Time tem Scrum Master (SM) Max 15 minutos
PO satisfeito com as
Problemas & impedimentos prioridades
Cada membro sabe o que
aparecem SM senta com o time
os outros estão fazendo
Iterações por timebox
Demo ocorre depois de cada
sprint
Duração da iteração de 4 Escalonando Indicadores positivos
semanas ou menos
Mostra software testado e Esses são fundamentais para qualquer Principais indicadores de uma boa
Sempre termina no tempo esforço de escalonamento de Scrum implementação de Scrum
funcionando
certo
Feedback recebido de Você tem um Chief Product
Time não é interrompido Divertido! Nível de energia alto.
clientes & PO Owner (se muitos POs)
ou controlado de fora
Times dependentes fazem Hora-extra é rara e ocorre
Existe Definição de Time costuma entregar o
Scrum de Scrums voluntariamente
Done (DoD) que foi prometido
Times dependentes integram a Discussões, críticas e
cada sprint experiências com o processo
DoD viável a cada iteração Time senta junto

PO = Product owner SM = Scrum Master PBL = Product Backlog DoD = Definição de Done
Time respeita DoD Max 9 pessoas no time
http://www.crisp.se/scrum/checklist | Versão 2.1 (2009-08-17)