Fevereiro 2010

Scrum: Desenvolvido e mantido por Ken Schwaber e Jeff Sutherland

Agradecimentos

Geral
Scrum baseado nas melhores prticas aceitas pelo mercado,
utilizadas e provadas por dcadas. Ele definido ento em uma teoria
de processos empricos. Como Jim Coplien certa vez observou para o
Jeff, Todos iro gostar de Scrum; isso o que j fazemos quando nos
pressionam contra a parede.

Pessoas

Das milhares de pessoas que contribuiram para o Scrum, devemos

destacar aquelas que contribuiram em seus primeiros dez anos.
Primeiro havia o Jeff Sutherland, trabalhando com o Jeff McKenna, e
Ken Schwaber com Mike Smith e Chris Martin. Scrum foi formalmente
apresentado e publicado no OOPSLA 1995. Durante os cinco anos
seguintes, Mike Beadle e Martine Devos fizeram contribuies
significativas. E ento todos os outros, que sem a sua ajuda o Scrum
no teria sido aprimorado no que atualmente.

Histria

A histria do Scrum j pode ser considerada longa no mundo de

desenvolvimento de software. Para honrar os primeiros lugares onde
foi testado e aprimorado, honramos a Individual, Inc., Fidelity
Investments e IDX (hoje GE Medical).

Traduo

Este guia foi traduzido da verso original em ingls, fornecida por Ken
Schwaber e Jeff Sutherland. Em ordem alfabtica, realizaram a
traduo: Heitor Roriz Filho, Michel Goldenberg e Rafael Sabbagh.
Realizaram a reviso os integrantes do grupo scrumguide_br,
inicialmente formado por: Anderson Marcondes, nderson Quadros, Ari
do Amaral Torres Filho, Marcos Garrido, Rafael Fuchs, Rafael
Prikladnicki, Rodrigo de Toledo e Rafael Sabbagh (coordenao).

2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 2

Propsito
Scrum vem sendo utilizado para o desenvolvimento de produtos
complexos desde o incio dos anos 90. Este guia descreve como usar o
Scrum para desenvolver produtos. Scrum no um processo ou uma
tcnica para o desenvolvimento de produtos. Ao invs disso, um
framework dentro do qual voc pode empregar diversos processos e
tcnicas. O papel do Scrum fazer transparecer a eficcia relativa das
suas prticas de desenvolvimento para que voc possa melhor-las,
enquanto prov um framework dentro do qual produtos
complexos podem ser desenvolvidos.

Teoria do Scrum
Scrum, que fundamentado na teoria de controle de processos
empricos, emprega uma abordagem iterativa e incremental para
otimizar a previsibilidade e controlar riscos. Trs pilares sustentam
cada implementao de controle de processos empricos.

O primeiro pilar a transparncia

A transparncia garante que aspectos do processo que afetam o
resultado devem ser visveis para aqueles que gerenciam os
resultados. Esses aspectos no apenas devem ser transparentes, mas
tambm o que est sendo visto deve ser conhecido. Isto , quando
algum que inspeciona um processo acredita que algo est pronto,
isso deve ser equivalente sua definio de pronto.

O segundo pilar a inspeo

Os diversos aspectos do processo devem ser inspecionados com uma
frequncia suficiente para que variaes inaceitveis no processo
possam ser detectadas. A frequncia da inspeo deve levar em
considerao que qualquer processo modificado pelo prprio ato da
inspeo. O problema acontece quando a frequncia de inspeo
necessria excede a tolerncia do processo inspeo. Felizmente,
isso no parece ser verdade no desenvolvimento de software. Os

2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 3

outros fatores so a habilidade e a aplicao das pessoas em
inspecionar os resultados do trabalho.

O terceiro pilar a adaptao

Se o inspetor determinar, a partir da inspeo, que um ou mais
aspectos do processo esto fora dos limites aceitveis e que o produto
resultante ser inaceitvel, ele dever ajustar o processo ou o material
sendo processado. Esse ajuste deve ser feito o mais rpido possvel
para minimizar desvios posteriores.

Existem trs pontos para inspeo e adaptao em Scrum. A Daily

Scrum uma reunio utilizada para inspecionar o progresso em
direo Meta da Sprint e para realizar adaptaes que otimizem o
valor do prximo dia de trabalho. Alm disso, as reunies de Reviso
da Sprint e de Planejamento da Sprint so utilizadas para inspecionar
o progresso em direo Meta da Release e para fazer as adaptaes
que otimizem o valor da prxima Sprint. Finalmente, a Retrospectiva
da Sprint utilizada para revisar a Sprint passada e definir que
adaptaes tornaro a prxima Sprint mais produtiva,
recompensadora e gratificante.

Contedo do Scrum
O framework Scrum consiste em um conjunto formado por Times de
Scrum e seus papis associados, Time-Boxes (eventos com durao
fixa), Artefatos e Regras.

Times de Scrum so projetados para otimizar flexibilidade e

produtividade. Para esse fim, eles so auto-organizveis,
multidisciplinares e trabalham em iteraes. Cada Time de Scrum
possui trs papis: 1) o ScrumMaster, que responsvel por garantir
que o processo seja compreendido e seguido; 2) o Product Owner,
que responsvel por maximizar o valor do trabalho que o Time de
Scrum faz; e 3) o Time, que executa o trabalho propriamente dito. O
Time consiste em desenvolvedores com todas as habilidades
necessrias para transformar os requisitos do Product Owner em um
pedao potencialmente entregvel do produto ao final da Sprint.

2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 4

Scrum emprega eventos com durao fixa os time-boxes para criar
regularidade. Entre os elementos do Scrum que tm durao fixa,
temos a Reunio de Planejamento da Release, a Reunio de
Planejamento da Sprint, a Sprint, a Daily Scrum, a Reviso da
Sprint e a Retrospectiva da Sprint. O corao do Scrum a Sprint,
que uma iterao de um ms ou menos, de durao consistente com
o esforo de desenvolvimento. Todas as Sprints utilizam o mesmo
modelo de Scrum e todas as Sprints tm como resultado um
incremento do produto final que potencialmente entregvel. Cada
Sprint comea imediatamente aps a anterior.

Scrum utiliza quatro artefatos principais. O Product Backlog uma

lista priorizada de tudo que pode ser necessrio no produto. O Sprint
Backlog uma lista de tarefas para transformar o Product Backlog,
por uma Sprint, em um incremento do produto potencialmente
entregvel. Um burndown uma medida do backlog restante pelo
tempo. Um Burndown de Release mede o Product Backlog restante
ao longo do tempo de um plano de release. Um Burndown de Sprint
mede os itens do Sprint Backlog restantes ao longo do tempo de uma
Sprint.

As Regras fazem o elo entre os Dica

time-boxes, os papis e os Quando as regras no so
artefatos do Scrum. Suas regras declaradas, espera-se que os
usurios de Scrum descubram
so descritas ao longo deste o que devem fazer. No tente
documento. Por exemplo, uma descobrir uma soluo
regra do Scrum diz que somente perfeita, porque geralmente o
problema muda rapidamente.
membros do Time - as pessoas Ao invs disso, tente algo e
comprometidas em transformar o veja como se sai. Os
Product Backlog em um mecanismos de inspeo-e-
adaptao inerentes
incremento - podem falar durante natureza emprica de Scrum
uma Daily Scrum. Modos de iro lhe guiar.
implementar Scrum que no so
regras, mas sim sugestes, esto descritas nas sees de "Dicas".

2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 5

Papis no Scrum
O Time de Scrum composto pelo ScrumMaster, pelo Product Owner e
pelo Time. Os membros do Time de Scrum so chamados porcos. O
Product Owner o porco do Product Backlog. O Time o porco do
trabalho da Sprint. O ScrumMaster o porco do processo do Scrum.
Qualquer outra pessoa chamada de galinha. Galinhas no podem
dizer aos porcos como eles devem fazer seu trabalho. Galinhas e
porcos vm da seguinte histria:

Uma galinha e um porco esto

juntos quando a galinha diz:
Vamos abrir um restaurante!
O porco reflete e ento diz:
Como seria o nome desse
restaurante?
A galinha diz: Presunto com
Ovos!
O porco diz: No, obrigado, eu
estaria comprometido, mas voc
estaria apenas envolvida!
Dica
O ScrumMaster trabalha com
os clientes e a gerncia para
identificar e designar um
Product Owner. O
ScrumMaster ensina ao
Product Owner como fazer
seu trabalho. Espera-se dos
Product Owners que eles
saibam como conseguir
otimizar valor atravs do
Scrum. Se eles no
souberem, consideramos o
ScrumMaster responsvel.

O ScrumMaster Dica
O ScrumMaster responsvel por O ScrumMaster pode ser um
garantir que o Time de Scrum membro do Time; por
esteja aderindo aos valores do exemplo, um desenvolvedor
realizando tarefas da Sprint.
Scrum, s prticas e s regras. O No entanto, isso
ScrumMaster ajuda o Time de frequentemente leva a
Scrum e a organizao a adotarem conflitos quando o
ScrumMaster deve escolher
o Scrum. O ScrumMaster educa o entre remover impedimentos
Time de Scrum treinando-o e e realizar tarefas. O
ScrumMaster nunca deve ser
levando-o a ser mais produtivo e a
o Product Owner.
desenvolver produtos de maior
qualidade. O ScrumMaster ajuda o

2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 6

Time de Scrum a entender e usar auto-organizao e
multidisciplinaridade. O ScrumMaster tambm ajuda o Time de Scrum
a fazer o seu melhor em um ambiente organizacional que pode ainda
no ser otimizado para o desenvolvimento de produtos complexos.
Quando o ScrumMaster ajuda a realizar essas mudanas, isso
chamado de remoo de impedimentos. O papel de ScrumMaster o
de lder-servidor para o Time de Scrum.

O Product Owner
O Product Owner a nica pessoa
responsvel pelo gerenciamento Dica
do Product Backlog e por garantir
Para desenvolvimento
o valor do trabalho realizado pelo comercial, o Product Owner
Time. Essa pessoa mantm o pode ser o Gerente de Produto.
Para esforos internos de
Product Backlog e garante que ele desenvolvimento, o Product
est visvel para todos. Todos Owner poderia ser o gerente da
sabem quais itens tm a maior funo de negcios em que se
est trabalhando.
prioridade, de forma que todos
sabem em que se ir trabalhar.

O Product Owner uma pessoa, e

no um comit. Podem existir Dica
comits que aconselhem ou O Product Owner pode ser um
influenciem essa pessoa, mas membro do Time, trabalhando
quem quiser mudar a prioridade tambm em desenvolvimento.
Mas essa responsabilidade
de um item, ter que convencer o adicional pode reduzir a sua
Product Owner. Empresas que habilidade de lidar com as
partes interessadas. No
adotam Scrum podem perceber
entanto, o Product Owner
que isso influencia seus mtodos nunca pode ser o ScrumMaster.
para definir prioridades e
requisitos ao longo do tempo.

Para que o Product Owner obtenha sucesso, todos na organizao

precisam respeitar suas decises. Ningum tem a permisso de dizer
ao Time para trabalhar em um outro conjunto de prioridades, e os
Times no podem dar ouvidos a ningum que diga o contrrio. As

2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 7

decises do Product Owner so visveis no contedo e na priorizao
do Product Backlog. Essa visibilidade requer que o Product Owner faa
seu melhor, o que faz o papel de Product Owner exigente e
recompensador ao mesmo tempo.

O Time
Times de desenvolvedores transformam o Product Backlog em
incrementos de funcionalidades potencialmente entregveis em cada
Sprint. Times tambm so multidisciplinares: membros do Time
devem possuir todo o conhecimento necessrio para criar um
incremento no trabalho. Membros do Time frequentemente possuem
conhecimentos especializados, como programao, controle de
qualidade, anlise de negcios, arquitetura, projeto de interface de
usurio ou projeto de banco de dados. No entanto, o conhecimento
que os membros do Time devem compartilhar - isto , a habilidade de
trabalhar um requisito e transform-lo em um produto utilizvel -
tendem a ser mais importantes do que aqueles que eles no dividem.
As pessoas que se recusam a programar porque so arquitetas ou
designers no se adaptam bem a Times. Todos contribuem, mesmo
que isso exija aprender novas habilidades ou lembrar-se de antigas.
No h ttulos em Times, e no h excees a essa regra. Os Times
tambm no contm subtimes dedicados a reas particulares como
testes ou anlise de negcios.

Times tambm so auto-organizveis. Ningum nem mesmo o

ScrumMaster diz ao time como transformar o Product Backlog em
incrementos de funcionalidades entregveis. O Time descobre por si
s. Cada membro do Time aplica sua especialidade a todos os
problemas. A sinergia que resulta disso melhora a eficincia e eficcia
geral do Time como um todo.

O tamanho timo para um Time de sete pessoas, mais ou menos

duas pessoas. Quando h menos do que cinco membros em um Time,
h menor interao e, como resultado, h menor ganho de
produtividade. Mais do que isso, o time poder encontrar limitaes de
conhecimento durante partes da Sprint e no ser capaz de entregar

2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 8

uma parte pronta do produto. Se h mais do que nove membros, h
simplesmente a necessidade de muita coordenao. Times grandes
geram muita complexidade para que um processo emprico consiga
gerenciar. No entanto, temos encontrado alguns Times bem-sucedidos
que excederam os limites superior e inferior dessa faixa de tamanhos.
O Product Owner e o ScrumMaster no esto includos nessa conta, a
menos que tambm sejam porcos, trabalhando em tarefas do Sprint
Backlog.

A composio do Time pode mudar ao final da Sprint. Toda vez que o

Time muda, a produtividade ganha atravs da auto-organizao
reduzida. Deve-se tomar cuidado ao mudar a composio do Time.

Time-Boxes
Os time-boxes no Scrum so a Reunio de Planejamento da
Release, a Sprint, a Reunio de Planejamento da Sprint, a
Reviso da Sprint, a Retrospectiva da Sprint e a Daily Scrum.

Reunio de Planejamento da Release

O propsito do planejamento da release o de estabelecer um plano e
metas que o Time de Scrum e o resto da organizao possam
entender e comunicar. O planejamento da release responde s
questes: Como podemos transformar a viso em um produto
vencedor da melhor maneira possvel? Como podemos alcanar ou
exceder a satisfao do cliente e o Retorno sobre Investimento (ROI)
desejados? O plano da release estabelece a meta da release, as
maiores prioridades do Product Backlog, os principais riscos e as
caractersticas gerais e funcionalidades que estaro contidas na
release. Ele estabelece tambm uma data de entrega e custo
provveis que devem se manter se nada mudar. A organizao pode
ento inspecionar o progresso e fazer mudanas nesse plano da
release a cada Sprint.

O planejamento da release inteiramente opcional. Se um Time de

Scrum iniciar o trabalho sem essa reunio, a ausncia de seus
artefatos aparecer como um impedimento que dever ser resolvido.

2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 9

O trabalho para resolver o impedimento se tornar um item no Product
Backlog.

Ao se utilizar Scrum, os produtos so construdos iterativamente, de

modo que cada Sprint cria um incremento do produto, iniciando pelo
de maior valor e maior risco. Mais e mais Sprints vo adicionando
incrementos ao produto. Cada incremento um pedao
potencialmente entregvel do produto completo. Quando j tiverem
sido criados incrementos suficientes para que o produto tenha valor e
uso para seus investidores, o produto entregue.

Muitas organizaes j possuem um processo de planejamento de

release, e na maior parte desses processos o planejamento feito no
incio do trabalho da release e no modificado com o passar do
tempo. No planejamento de release do Scrum, so definidos uma meta
geral e resultados provveis. Esse planejamento geralmente no
requer mais do que 15-20% do tempo que uma organizao
costumava utilizar para produzir um plano de release tradicional. No
entanto, uma release com Scrum realiza planejamento no momento da
execuo de cada reunio de Reviso de Sprint e de Planejamento de
Sprint, da mesma forma que realiza um planejamento dirio no
momento da execuo de cada Daily Scrum. De forma geral, os
esforos para uma release com Scrum provavelmente consomem
ligeiramente mais esforo do que os esforos para um planejamento
de release tradicional.

O planejamento da release requer estimar e priorizar o Product

Backlog para a release. H diversas tcnicas para faz-lo que esto
fora do alcance do Scrum, mas que apesar disso so teis quando
usadas com ele.

2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 10

A Sprint
A Sprint uma iterao. Sprints
tm durao fixa. Durante a Dica
Sprint, o ScrumMaster garante Se o time sentir que se
que no ser feita nenhuma comprometeu com mais do que
podia, ele se encontra com o
mudana que possa afetar a Meta
Product Owner para remover ou
da Sprint. Tanto a composio do reduzir o escopo do Product
time quanto as metas de Backlog selecionado para a
Sprint. Se o time sentir que
qualidade devem permanecer
sobrar tempo, ele pode
constantes durante a Sprint. As trabalhar junto ao Product
Sprints contm e consistem na Owner para selecionar mais do
Product Backlog.
reunio de Planejamento de
Sprint, o trabalho de
desenvolvimento, a Reviso da Sprint e a Retrospectiva da Sprint. As
Sprints ocorrem uma aps a outra, sem intervalos entre elas.

Um projeto serve para cumprir

alguma funo. Em
desenvolvimento de software, o Dica
projeto utilizado para Quando um Time comea com o
desenvolver um produto ou Scrum, Sprints de duas
semanas o permite aprender
sistema. Cada projeto consiste em
sem se afundar na incerteza.
uma definio do que ser Sprints desse tamanho podem
desenvolvido, um plano para ser sincronizadas com outros
Times adicionando-se dois
desenvolv-lo, o trabalho incrementos juntos.
realizado de acordo com o plano e
o produto resultante. Cada projeto
possui um horizonte, que o perodo de tempo para o qual o plano
vlido. Se o horizonte for longo demais, a definio poder ter
mudado, variveis demais podero ter surgido, o risco poder ser
grande demais etc. Scrum um framework para projetos cujo
horizonte no superior ao perodo de um ms, onde j h
complexidade suficiente tal que um horizonte mais longo seria
arriscado demais. A previsibilidade do projeto deve ser controlada pelo

2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 11

menos a cada ms, e o risco de que o projeto saia de controle ou se
torne imprevisvel contido pelo menos a cada ms.

As Sprints podem ser canceladas antes que o prazo fixo da Sprint

tenha acabado. Somente o Product Owner tem a autoridade para
cancelar a Sprint, embora ele possa faz-lo sob influncia das partes
interessadas, do Time ou do ScrumMaster. Sob que tipo de
circunstncias pode ser necessrio cancelar uma Sprint? A gerncia
pode precisar cancelar uma Sprint se a Meta da Sprint se tornar
obsoleta. Isso pode ocorrer se a empresa mudar de direo ou se as
condies do mercado ou tecnologia mudarem. Em geral, uma Sprint
deve ser cancelada se ela no fizer mais sentido dadas as
circunstncias atuais. Porm, por causa da curta durao das Sprints,
raramente isso faz sentido.

Quando uma Sprint cancelada, todos os itens do Product Backlog

que estejam completados e "feitos" so revisados. Eles so aceitos se
representarem um incremento potencialmente entregvel. Todos os
outros itens do Product Backlog so devolvidos ao Product Backlog
com suas estimativas iniciais. Assume-se que qualquer trabalho
realizado nesses itens perdido. Cancelamentos de Sprints consomem
recursos, j que todos tm que se reagrupar em outra reunio de
Planejamento de Sprint para iniciar uma nova Sprint. Cancelamentos
de Sprints so frequentemente traumticos para o Time e so muito
incomuns.

Reunio de Planejamento da Sprint

A Reunio de Planejamento da Sprint o momento no qual a iterao
planejada. fixada em oito horas de durao para uma Sprint de um
ms. Para Sprints mais curtas, deve-se alocar proporcionalmente ao
tamanho total da Sprint para essa reunio (por exemplo, para duas
semanas teramos uma Reunio de Planejamento da Sprint de quatro
horas). A Reunio de Planejamento da Sprint consiste de duas partes.
A primeira parte o momento no qual decidido o que ser feito na
Sprint. A segunda parte (com durao fixa de quatro horas para uma
Sprint de um ms) o momento no qual o Time entende como

2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 12

desenvolver essa funcionalidade em um incremento do produto
durante a Sprint.

H duas partes na Reunio de Planejamento da Sprint: a parte do o

qu? e a parte do como?. Alguns Times de Scrum juntam as duas.
Na primeira parte, o Time de Scrum trata da questo do o qu?.
Aqui, o Product Owner apresenta ao Time o que mais prioritrio no
Product Backlog. Eles trabalham em conjunto para definir qual
funcionalidade dever ser desenvolvida durante a prxima Sprint. As
entradas para essa reunio so o Product Backlog, o incremento mais
recente ao produto, a capacidade do Time e o histrico de
desempenho do Time. Cabe somente ao Time a deciso de quanto do
Backlog ele deve selecionar. Somente o Time pode avaliar o que ele
capaz de realizar na prxima Sprint.

Uma vez selecionado o Product Backlog, a Meta da Sprint delineada.

A Meta da Sprint o objetivo que ser atingido atravs da
implementao do Product Backlog. Ela uma descrio que fornece
orientao ao Time sobre a razo pela qual ele est desenvolvendo o
incremento. A Meta da Sprint um subconjunto da Meta da Release.

O motivo para se ter uma Meta da Sprint dar ao time alguma

margem com relao funcionalidade. Por exemplo, a meta para a
Sprint acima poderia tambm ser: Automatizar a funcionalidade de
modificao de conta de clientes atravs de um middleware seguro
capaz de recuperar transaes. Conforme o Time trabalha, ele
mantm a meta em mente. Para satisfazer a meta, ele implementa a
funcionalidade e a tecnologia. Se o trabalho se mostrar mais difcil do
que o time esperava, o time ento ir trabalhar em conjunto com o
Product Owner e implementar a funcionalidade apenas parcialmente.

Na segunda parte da Reunio de Planejamento da Sprint, o Time trata

a questo do como?. Durante a segunda parte da Reunio de
Planejamento da Sprint (com durao fixa de quatro horas para
Sprints de um ms), o Time define como transformar o Product
Backlog selecionado durante a Reunio de Planejamento (o qu) em
um incremento pronto. O Time geralmente comea projetando o

2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 13

trabalho. Enquanto projeta, o time identifica tarefas. Essas tarefas so
pedaos detalhados do trabalho necessrio para converter o Product
Backlog em software funcional. As tarefas devem ser decompostas
para que possam ser feitas em menos de um dia. Essa lista de tarefas
chamada de Sprint Backlog. O time se auto-organiza para se
responsabilizar pelo trabalho contido no Sprint Backlog, tanto durante
a Reunio de Planejamento da Sprint quanto no prprio momento da
execuo da Sprint.

O Product Owner est presente Dica

durante a segunda parte da
Geralmente, somente 60-70%
Reunio de Planejamento da do total do Sprint Backlog ser
Sprint para esclarecer o Product definido na Reunio de
Planejamento da Sprint. O
Backlog e para ajudar a efetuar
restante deixado para ser
trocas. Se o Time concluir que detalhado mais tarde ou so
ele tem trabalho demais ou de dadas estimativas grandes que
sero decompostas mais tarde
menos, ele pode renegociar o na Sprint
Product Backlog escolhido com o
Product Owner. O Time tambm
pode convidar outras pessoas a participarem da reunio para
fornecerem conselhos tcnicos ou sobre o domnio em questo.
Geralmente, um Time novo percebe pela primeira vez se ir ganhar ou
perder como um Time - no individualmente - nessa reunio. O Time
percebe que deve contar consigo mesmo. Conforme ele percebe isso,
ele comea a se auto-organizar para assumir as caractersticas e
comportamento de um verdadeiro Time.

Reviso da Sprint
Ao final da Sprint, feita a reunio de Reviso da Sprint. Para Sprints
de um ms, essa uma reunio com durao fixa de quatro horas.
Para Sprints de duraes mais curtas, deve-se alocar
proporcionalmente menos do tamanho total da Sprint para essa
reunio (por exemplo, para duas semanas deve-se ter uma Reviso da
Sprint de duas horas). Durante a Reviso da Sprint, o Time de Scrum
e as partes interessadas colaboram sobre o que acabou de ser feito.

2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 14

Baseados nisso e em mudanas no Product Backlog feitas durante a
Sprint, eles colaboram sobre quais so as prximas coisas que podem
ser feitas. Essa uma reunio informal, com a apresentao da
funcionalidade, que tem a inteno de promover a colaborao sobre o
que fazer em seguida.

A reunio inclui ao menos os seguintes elementos. O Product Owner

identifica o que foi feito e o que no foi feito. O Time discute sobre o
que correu bem durante a Sprint e quais problemas foram
enfrentados, alm de como esses problemas foram resolvidos. O Time
ento demonstra o trabalho que est pronto e responde a
questionamentos. O Product Owner ento discute o Product Backlog da
maneira como esse se encontra. Ele faz projees de datas de
concluso provveis a partir de vrias hipteses de velocidade. Em
seguida, o grupo inteiro colabora sobre o que foi visto e o que isso
significa com relao ao que fazer em seguida. A Reviso da Sprint
fornece entradas valiosas para as reunies de Planejamento de Sprints
seguintes.

Retrospectiva da Sprint
Aps a Reviso da Sprint e antes da prxima reunio de Planejamento
da Sprint, o Time de Scrum tem a reunio de Retrospectiva da Sprint.
Esta uma reunio com durao fixa de trs horas para Sprints de um
ms (deve-se alocar proporcionalmente ao tamanho total da Sprint
para essa reunio). Nessa reunio, o ScrumMaster encoraja o Time a
revisar, dentro do modelo de trabalho e das prticas do processo do
Scrum, seu processo de desenvolvimento, de forma a torn-lo mais
eficaz e gratificante para a prxima Sprint. Muitos livros documentam
tcnicas que so teis em Retrospectivas.

A finalidade da Retrospectiva inspecionar como correu a ltima

Sprint em se tratando de pessoas, das relaes entre elas, dos
processos e das ferramentas. A inspeo deve identificar e priorizar os
principais itens que correram bem e aqueles que, se feitos de modo
diferente, poderiam ter deixado as coisas ainda melhores. Isso inclui a
composio do Time de Scrum, preparativos para reunies,

2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 15

ferramentas, definio de pronto, mtodos de comunicao e
processos para transformar itens do Product Backlog em alguma coisa
pronta. No final da Retrospectiva da Sprint, o Time de Scrum deve
ter identificado medidas de factveis melhoria que ele implementar na
prxima Sprint. Essas mudanas se tornam a adaptao para a
inspeo emprica.

Daily Scrum
Cada time se encontra diariamente para uma reunio de 15 minutos
chamada Daily Scrum. Essa reunio sempre feita no mesmo horrio
e no mesmo local durante as Sprints. Durante a reunio, cada membro
explica:

1. O que ele realizou desde a ltima reunio;

2. O que ele vai fazer antes da prxima reunio; e

3. Quais obstculos esto em seu caminho.

As Daily Scrums melhoram a comunicao, eliminam outras reunies,

identificam e removem impedimentos para o desenvolvimento,
ressaltam e promovem a tomada rpida de decises e melhoram o
nvel de conhecimento de todos acerca do projeto.

O ScrumMaster garante que o Time realize essa reunio. O Time

resposvel por conduzir a Daily Scrum. O ScrumMaster ensina o time a
manter a Daily Scrum com curta durao, reforando as regras e
garantido que as pessoas falem brevemente. O ScrumMaster tambm
enfatiza a regra de que galinhas no esto autorizadas a falar e nem a
interferir de modo algum na Daily Scrum.

A Daily Scrum no uma reunio de status. Ela s para as pessoas

que esto transformando os itens do Product Backlog em um
incremento (o Time), e para mais ningum. O Time se comprometeu
com uma Meta da Sprint, e a esses itens do Product Backlog. A Daily
Scrum uma inspeo do progresso na direo da Meta da Sprint (as
trs perguntas). Geralmente acontecem reunies subsequentes para

2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 16

realizar adaptaes ao trabalho que est por vir na Sprint. A inteno
otimizar a probabilidade de que o Time alcance sua Meta. Essa
uma reunio fundamental de inspeo e adaptao no processo
emprico do Scrum.

Artefatos do Scrum
Os artefatos do Scrum incluem o Product Backlog, o Burndown da
Release, o Sprint Backlog e o Burndown da Sprint.

Product Backlog e Burndown da Release

Os requisitos para o produto que o(s) Time(s) est(o) desenvolvendo
esto listados no Product Backlog. O Product Owner o responsvel
pelo Product Backlog, por seu contedo, por sua disponibilidade e por
sua priorizao. O Product Backlog nunca est completo. A seleo
inicial para o seu desenvolvimento somente mostra os requisitos
inicialmente conhecidos e melhor entendidos. O Product Backlog evolui
medida que o produto e o ambiente em que ele ser usado evoluem.
O Backlog dinmico, no sentido de que ele est constantemente
mudando para identificar o que o
produto necessita para ser Dica
apropriado, competitivo e til.
Os itens do Product Backlog so
Enquanto existir um produto, o geralmente representados
Backlog de Produto tambm como Estrias de Usurio.
Casos de Uso tambm so
existir.
apropriados, mas so mais
adequados para
O Product Backlog representa tudo desenvolvimento de softwares
que necessrio para desenvolver crticos em termos de vidas ou
de desempenho.
e lanar um produto de sucesso.
uma lista de todas as
caractersticas, funes,
tecnologias, melhorias e correes de defeitos que constituem as
mudanas que sero efetuadas no produto para releases futuras. Os
itens do Product Backlog possuem os atributos de descrio, prioridade
e estimativa. A prioridade determinada por risco, valor e
necessidade. H diversas tcnicas para dar valor a esses atributos.

2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 17

O Product Backlog ordenado por prioridade. O Product Backlog de
mais alta prioridade leva a atividades de desenvolvimento imediatas.
Quanto mais alta sua prioridade, mais urgente ele , mais se pensou
sobre ele e h mais consenso no
que diz respeito ao seu valor. O
Backlog de mais alta prioridade Dica
mais claro e possui mais Os Times Scrum geralmente
informaes detalhadas do que o gastam 10% de cada Sprint
Backlog de prioridade mais baixa. preparando o Product Backlog
para adequ-lo definio de
Fazem-se melhores estimativas Product Backlog feita acima.
quando baseadas em uma maior Quando estiverem adequados a
esse nvel de granularidade, os
clareza e em mais detalhes.
itens no topo do Product
Quanto mais baixa a prioridade, Backlog (de maior prioridade e
menor o nvel detalhe, at que de maior valor) so
decompostos de forma que
mal se consiga entender o item.
caibam em um Sprint. Eles
foram analisados e se refletiu
medida que um produto sobre eles durante esse
utilizado, que seu valor aumenta processo de preparao.
Quando ocorre a reunio de
e que o mercado fornece
Planejamento de Sprint, esses
feedback, o Product Backlog itens de maior prioridade do
torna-se uma lista maior e mais Product Backlog esto bem
entendidos e so facilmente
aprofundada. Os requisitos nunca selecionados.
param de mudar. O Product
Backlog um documento vivo.
Mudanas nos requisitos de
negcios, condies do mercado, Dica
tecnologia e equipe causam Testes de aceitao so
frequentemente utilizados como
mudanas no Product Backlog. um outro atributo para o item
Para minimizar o retrabalho, do Product Backlog. Eles podem
apenas os itens de maior frequentemente substituir
descries textuais mais
prioridade precisam ser mais detalhadas com uma descrio
detalhados. Os itens do Product testvel do que o item do
Product Backlog deve fazer uma
Backlog que ocuparo os Times
vez que esteja completo.
de Scrum pelas vrias Sprints
seguintes devero ter

2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 18

granularidade mais fina, tendo sido decompostos de forma tal que
cada um dos itens possa ser feito dentro da durao da Sprint.

Frequentemente, mltiplos Times de Scrum trabalham juntos no

mesmo produto. Um nico Product Backlog usado para descrever o
trabalho a ser realizado no produto. Ento, um atributo que agrupe os
itens aplicado no Product Backlog. O agrupamento pode ocorrer por
conjuntos de caractersticas, por tecnologia ou por arquitetura, e ele
frequentemente utilizado como uma forma de se organizar o trabalho
por Time de Scrum.

O grfico de Burndown da
Release registra a soma das
estimativas dos esforos Dica
restantes do Product Backlog ao Em algumas organizaes,
longo do tempo. O esforo acrescenta-se mais trabalho ao
Backlog do que se realiza. Isso
estimado deve estar em qualquer pode criar uma linha de
unidade de medida de trabalho tendncia plana ou at com
que o Time de Scrum e a inclinao crescente. Para
compensar isso e manter a
organizao tenham decidido transparncia, um novo piso
usar. As unidades de tempo pode ser criado quando se
adiciona ou quando se subtrai
geralmente so Sprints.
trabalho. O piso deve adicionar
ou remover somente
As estimativas dos itens do mudanas significativas e deve
Product Backlog so inicialmente ser bem documentado.
calculadas durante o
Planejamento da Release, e
posteriormente medida que
itens forem sendo criados. Dica
Durante a preparao do Backlog A linha de tendncia pode no
ser confivel pelas duas ou trs
de Produto, os itens so revistos primeiras Sprints de uma
e revisados. Entretanto, eles release, a menos que os times
podem ser atualizados em j tenham trabalhado juntos
anteriormente, conheam bem
qualquer momento. O Time o produto e entendam a
responsvel por todas as tecnologia envolvida.
estimativas. O Product Owner

2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 19

pode influenciar o Time, ajudando-o a entender e a escolher as
mudanas, mas a estimativa final feita pelo Time. O Product Owner
mantm o Product Backlog e o Burndown do Backlog da Release
atualizados e publicados todo o tempo. Uma linha de tendncia pode
ser traada baseada na mudana do trabalho restante.

Sprint Backlog e Burndown da Sprint

O Sprint Backlog consiste nas tarefas que o time executa para
transformar itens do Product Backlog em um incremento pronto.
Muitas delas so elaboradas durante a Reunio de Planejamento da
Sprint. O Sprint Backlog todo trabalho que o Time identifica como
necessrio para alcanar a Meta da Sprint. Os itens do Sprint Backlog
devem ser decompostos. A decomposio deve ser suficiente para que
mudanas no progresso possam ser entendidas na Daily Scrum. Um
dia ou menos um tamanho comum para um item do Sprint Backlog
no qual se est trabalhando.

O Time modifica o Sprint Backlog no decorrer da Sprint, bem como

surge Sprint Backlog durante a Sprint. Quando chega s tarefas
individuais, o Time pode descobrir que mais ou menos tarefas sero
necessrias, ou que uma determinada tarefa levar mais ou menos
tempo do que era esperado. medida que novo trabalho surge, o
Time o adiciona ao Sprint Backlog. medida que se trabalha nas
tarefas ou que elas so completadas, o trabalho restante para cada
tarefa atualizado. Quando se verifica que determinadas tarefas so
desnecessrias, elas so removidas. Somente o Time pode modificar o
seu Sprint Backlog durante uma Sprint. Somente o Time pode mudar o
seu contedo ou as suas estimativas. O Sprint Backlog um retrato
em tempo real altamente visvel do trabalho que o Time planeja
efetuar durante a Sprint, e ele pertence unicamente ao Time.

O Burndown do Sprint Backlog um grfico da quantidade restante de

trabalho do Sprint Backlog em uma determinada Sprint ao longo do
tempo da Sprint. Para criar esse grfico, determine quanto trabalho

2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 20

resta somando as estimativas do
Backlog a cada dia da Sprint. A Dica
quantidade de trabalho restante Sempre que possvel, desenhe
o grfico de burndown mo
para uma Sprint a soma do em uma folha grande de papel
trabalho restante para tudo do exibida na rea de trabalho do
Sprint Backlog. Acompanhe essas Time. mais provvel que o
Time veja um grfico grande e
somas diariamente e utilize-as visvel do que um grfico de
para criar um grfico que mostre Burndown da Sprint no Excel ou
em alguma ferramenta.
o trabalho restante ao longo do
tempo. Traando uma linha
atravs dos pontos no grfico, o Time pode gerenciar seu progresso
em completar o trabalho de uma Sprint. A durao no considerada
em Scrum. O trabalho restante e a data so as nicas variveis de
interesse.

Uma das regras do Scrum est ligada ao objetivo de cada Sprint, que
ter como resultado incrementos de funcionalidade potencialmente
entregveis que estejam de acordo com uma definio de pronto
operacional.

Pronto
Scrum exige que os Times desenvolvam um incremento de
funcionalidade do produto a cada Sprint. Esse incremento deve ser
potencialmente entregvel, pois o Product Owner pode optar por
implantar a funcionalidade imediatamente. Para isso ser possvel, o
incremento deve ser um pedao completo do produto. Ele deve estar
pronto (ou done, em ingls). Cada incremento deve ser adicionado
a todos os incrementos anteriores e exaustivamente testado,
garantindo que todos os incrementos funcionem juntos.

No desenvolvimento de produtos, afirmar que a funcionalidade est

pronta pode levar algum a presumir que ela est pelo menos bem
codificada, refatorada, que tenha passado por testes unitrios, que
tenha sido feito o build e que tenha passado por testes de aceitao.
Outros podem presumir que apenas o cdigo tenha sido desenvolvido.
Se ningum sabe qual a definio de pronto, os outros dois pilares

2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 21

do controle de processos empricos no funcionam. Quando algum
descreve algo como pronto, todos devem entender o que pronto
significa.

Pronto define o que o Time quer dizer quando se compromete a

aprontar um item de Product Backlog em uma Sprint. Alguns
produtos no contm documentao, de forma que sua definio de
pronto no inclui documentao. Um incremento completamente
pronto inclui toda a anlise, projeto, refatoramento, programao,
documentao e testes para o incremento e todos os itens do Product
Backlog no incremento. Os testes incluem testes de unidade, de
sistema, de usurio e de regresso, bem como testes no-funcionais
como de performance, de estabilidade, de segurana e de integrao.
Pronto inclui tambm qualquer internacionalizao necessria.
Alguns Times ainda no so
capazes de incluir em sua Dica
definio de pronto tudo o que
Trabalho "no pronto"
necessrio para a implantao. geralmente acumulado em um
Isto deve estar claro para o item do Product Backlog
chamado "Trabalho No Pronto"
Product Owner. Esse trabalho ou "Trabalho de Implantao".
restante dever ser feito antes medida que esse trabalho
que o produto possa ser acumula, o Burndown do
Product Backlog se mantm
implantado e utilizado. mais preciso do que se esse
trabalho no fosse acumulado.
Consideraes Finais
Algumas organizaes so incapazes de desenvolver um incremento
completo dentro de uma Sprint. Elas podem ainda no ter
infraestrutura automatizada de testes para completar todos os testes.
Nesse caso, duas categorias so criadas para cada incremento: o
trabalho pronto e o trabalho no pronto. O trabalho no pronto
a poro de cada incremento que ter que ser completada mais
tarde. O Product Owner sabe exatamente o que ele est
inspecionando ao final da Sprint, porque o incremento atende
definio de pronto e o Product Owner entende essa definio. O
trabalho no pronto adicionado a um item do Product Backlog

2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 22

chamado trabalho no pronto, de forma que ele se acumula e isso
refletido corretamente no grfico de Burndown da Release. Essa
tcnica cria transparncia no progresso em direo entrega. A
inspeo e a adaptao na Reviso da Sprint sero to precisas quanto
essa transparncia for.

Por exemplo, se um Time no capaz de realizar os testes de

performance, regresso, estabilidade, segurana e integrao para
cada item do Product Backlog, a proporo desse trabalho em relao
ao trabalho que pode ser pronto (anlise, projeto, refatoramento,
programao, documentao, testes unitrio e testes de usurio)
calculada. Vamos supor que essa proporo de seis peas de
pronto e quatro peas de no pronto. Se o Time terminar um item
de Backlog de Produto de seis unidades de trabalho (o Time est
estimando baseado no que ele sabe como aprontar), quatro unidades
sero acrescidas ao item do Product Backlog denominado trabalho
no pronto quando eles tiverem terminado.

Sprint a Sprint, o trabalho no pronto de cada incremento vai se

acumulando e deve ser tratado antes da entrega do produto. Esse
trabalho acumulado linearmente, embora haja algum tipo de
acmulo exponencial que dependente das caractersticas de cada
organizao. Sprints de Release so adicionados ao final de cada
release para completar o trabalho no pronto. O nmero de Sprints
imprevisvel, visto que o acmulo de trabalho no pronto no
linear.

2008-2010 Ken Schwaber e Jeff Sutherland, todos os direitos reservados. Pg. | 23