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

Traduzi do para o Portugus por Jos Eduardo Deboni (eduardodeboni.com)


1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos Pag. 2
Contedo
Propsito do Guia do Scrum ........................................................................................................................ 3
Viso Geral do Scrum ................................................................................................................................... 3
Framework Scrum ........................................................................................................................................ 3
A Teoria do Scrum ........................................................................................................................................ 3
Transparncia .............................................................................................................................................. 3
Inspeo ....................................................................................................................................................... 4
Adaptao .................................................................................................................................................... 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 servios do Scrum Master para o Dono do Produto ............................................................................... 6
Os servios do Scrum Master para a Equipe de Desenvolvimento .............................................................. 6
Os servios do Scrum Master para a Organizao ....................................................................................... 7
Eventos do Scrum ........................................................................................................................................ 7
O Sprint ........................................................................................................................................................ 7
Cancelando um Sprint. ................................................................................................................................. 8
Reunio 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 Dirio............................................................................................................................................... 10
Reviso do Sprint ....................................................................................................................................... 10
A Retrospectiva do Sprint. ......................................................................................................................... 11
Backlog do produto .................................................................................................................................... 12
Monitorando o Progresso na direo de um Objetivo .............................................................................. 13
Backlog do Sprint ....................................................................................................................................... 13
Monitoramento do Progresso do Sprint .................................................................................................... 14
Incremento ................................................................................................................................................ 14
Definio do Pronto ................................................................................................................................ 14
Concluso ................................................................................................................................................... 15
Agradecimentos ......................................................................................................................................... 16


1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos Pag. 3
Propsito do Guia do Scrum
Scrum um framework para desenvolver e manter produtos complexos. Este Guia contm a definio
do Scrum. Esta definio consiste em papeis, eventos, artefatos do Scrum e as regras que mantm
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.
Viso 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
possvel. O Scrum :
Leve
De entendimento simples
Extremamente difcil de ter o domnio
O Scrum um framework de processo quem tem sido usado para gerenciar o desenvolvimento de
produtos complexos desde o incio dos anos 90. Scrum no um processo ou tcnica para construir
produtos, mais um framework dentro do qual se pode empregar processos e tcnicas variadas. O
Scrum torna clara a eficcia relativa das prticas de gerenciamento e desenvolvimento de produtos,
para que voc possa melhor-las.
Framework Scrum
O framework Scrum consiste nas equipes do Scrum, papis, eventos, artefatos e regras associados.
Cada componente do framework serve a um propsito especfico e essencial para o sucesso e uso do
Scrum.
Estratgias especficas para uso do framework Scrum variam e so descritas em outros documentos.
As regras do Scrum integram os eventos, papis e artefatos, governando as relaes e interaes entre
eles. As regras do Scrum so descritas ao longo do corpo deste documento.
A Teoria do Scrum
O Scrum est baseado nas teorias empricas de controle de processo. O empirismo afirma que o
conhecimento vem da experincia e tomar decises baseados no que se conhece. O Scrum aplica uma
abordagem iterativa e incremental para aperfeioar a previsibilidade e o controle de riscos.
Trs pilares sustentam a implementao de um controle de processo emprico: transparncia,
inspeo e adaptao.
Transparncia
Aspectos significativos do processo devem estar visveis para os responsveis pelos resultados.
Transparncia requer que aqueles aspectos sejam definidos por um padro 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. 4
Por exemplo:
Uma linguagem comum para se referir ao processo, deve ser compartilhada por todos os
participantes,
Uma definio comum de Pronto
1
deve ser compartilhada por aqueles que desempenham o
trabalho e aqueles que do o aceite do produto do trabalho.
Inspeo
Os usurios do Scrum devem, frequentemente, inspecionar os artefatos Scrum e o progresso com
objetivo de detectar variaes no desejadas. Esta inspeo no deve ser to frequente, que a
inspeo fique no caminho do trabalho. As Inspees so mais benficas quando desempenhadas por
inspetores habilidosos [diligentes] no local do trabalho.
Adaptao
Se um inspetor determina que um ou mais aspectos do processo desviar para longe de limites
aceitveis, e que o resultado do produto no aceitvel, o processo ou o material que est sendo
processado deve ser ajustado. Um ajuste deve ser feito to logo quanto possvel para minimizar os
desvios futuros.
O Scrum prescreve quatro oportunidades formais para inspeo e adaptao, como descritas na seo
de Eventos do Scrum deste documento:
Reunio de Planejamento do Sprint
Scrum Dirio
Reunio de Reviso 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 papis, eventos, artefatos e regras associadas. Cada
componente no framework serve para um propsito especfico e essencial para o uso e sucesso do
Scrum.
As regras do Scrum integram os eventos, papeis e artefatos, governando as relaes e interaes entre
eles. As regras do Scrum so 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 so auto organizadas e trans-funcionais. Equipes auto organizadas escolhem a
melhor forma de realizar seu trabalho, ao contrrio de serem dirigidas por outros de fora da equipe.
Equipes trans-funcionais tem todas as competncias necessrias para realizar o trabalho sem a
dependncia de outras que no fazem parte da equipe. A equipe modelo no Scrum projetada para
aperfeioar a flexibilidade, criatividade e produtividade.

1
Veja a definio na pgina 15.

1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos Pag. 5
As equipes do Scrum produzem iterativamente e incrementalmente, aproveitando ao mximo as
oportunidades para realimentao. Entregas incrementais de produtos Prontos garantem que uma
verso potencialmente til do produto esteja sempre disponvel.
O Dono do produto
O Dono do produto
2
responsvel por maximizar o valor do produto e do trabalho da equipe de
desenvolvimento. Como isso feito pode variar amplamente entre organizaes, equipes de Scrum e
indivduos.
O Dono do produto a nica pessoa responsvel 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 alcanar os objetivos e misses;
Garantir o valor do trabalho desempenhado pela equipe de desenvolvimento;
Garantir que o Backlog do produto seja visvel, 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 nvel
necessrio.
O Dono do produto pode fazer o trabalho acima, ou deixar que a equipe de projeto o faa. Entretanto,
o Dono do produto o responsvel por ele.
O Dono do produto uma pessoa, e no 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 organizao deve respeitar a sua deciso. As decises do
Dono do produto esto visveis no contedo e na organizao do backlog do produto. Ningum est
autorizado a mandar a equipe de desenvolvimento trabalhar em um conjunto diferente de requisitos e
a equipe de desenvolvimento no 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
verso usvel que potencialmente incrementa o produto Pronto no final de cada Sprint. Somente
membros da equipe de desenvolvimento criam o incremento.
As equipes de desenvolvimento so estruturadas e autorizadasligei pela organizao para organizar e
gerenciar seu prprio trabalho. A sinergia resultante aperfeioa a eficincia e efetividade global. As
equipes de desenvolvimento tm as seguintes caractersticas:
Elas so auto organizadas. Ningum (nem mesmo o Scrum Master) diz para a equipe de
projetos como transformar o Backlog de produto em incrementos de funcionalidades
potencialmente utilizveis;

2
Nota do Tradutor: O termo em ingls Product Owner e foi traduzido aqui como Dono do Produto, em letra
maiscula, para indicar que um papel representado no processo do Scrum e no aquele que seria o
proprietrio do produto de software.

1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos Pag. 6
Equipes de desenvolvimento so trans funcionais, com todas as habilidades necessrias para
criar o incremento do produto.
O Scrum no reconhece perfis dos membros da equipe de desenvolvimento alm de
Desenvolvedor, independente do trabalho que est sendo realizado pela pessoa, no h
excees a essa regra;
Individualmente os membros da equipe de desenvolvimento podem ter habilidades
especializadas e reas de especializao, mas pertencem e respondem equipe de
desenvolvimento como um todo; e,
Equipes de desenvolvimento no possuem sub-equipes dedicadas a domnios particulares do
conhecimento, como teste ou anlise de negcio.
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 trs
membros em uma equipe de desenvolvimento diminui a interao e resulta em ganhos menores de
produtividade. Equipes pequenas podem encontrar limitaes nas habilidades necessrias para um
Sprint, e como consequncia no conseguindo entregar um incremento potencialmente utilizvel.
Tendo mais do que nove membros se requer muita coordenao. Equipes de desenvolvimento grandes
geram muita complexidade para um processo emprico gerenciar. Os papeis de Dono do produto e o
Scrum Master no so includos nesta contagem a no ser que eles tambm executem o trabalho do
Sprint Backlog.
O Scrum Master
O Scrum Master responsvel para garantir que o Scrum seja entendido e aplicado. Os Scrum Masters
fazem isso garantindo que as equipes de Scrum obedeam teoria, prticas e regras do Scrum. O
Scrum Master um lder-facilitador para a equipe do Scrum.
O Scrum Master ajuda aqueles de fora da equipe do Scrum entender quais so as interaes com a
equipe do Scrum que so benficas e quais no so. O Scrum Master ajudar todos a mudar suas
interaes para maximizar o valor criado pela equipe de Scrum.
Os servios do Scrum Master para o Dono do Produto
O Scrum Master serve ao Dono do produto de vrias formas, incluindo:
Encontrar tcnicas para o gerenciamento efetivo do Backlog do produto,
Comunicar claramente a viso, 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 emprico,
Entender e praticar a agilidade,
Facilitar os eventos do Scrum quando solicitado ou necessrio.
Os servios do Scrum Master para a Equipe de Desenvolvimento
O Scrum Master serve a Equipe de Desenvolvimento de vrias formas, incluindo:

1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos Pag. 7
Orientar a Equipe de Desenvolvimento na sua auto organizao 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 necessrio,
Orientar a Equipe de Desenvolvimento no ambiente organizacional no qual o Scrum ainda no
amplamente adotado e compreendido.
Os servios do Scrum Master para a Organizao
O Scrum Master serve a organizao de vrias formas, incluindo:
Liderar e Orientar a organizao na adoo do Scrum,
Planejar as implementaes do Scrum dentro da organizao,
Ajudar empregados e stakeholders a entender e implantar o Scrum e o desenvolvimento
emprico de produtos,
Provocar mudanas que aumentem a produtividade na Equipe de Scrum,
Trabalhar com outros Scrum Masters para aumentar a efetividade da aplicao do Scrum na
organizao.
Eventos do Scrum
Eventos prescritos so usados no Scrum para criar uma rotina e para minimizar a necessidade de
encontros no definidos no Scrum. O Scrum usa eventos time-boxed
3
, onde cada evento tem uma
durao mxima. Isso garante uma quantidade apropriada de tempo gasto em planejamento sem
permitir perdas no processo de planejamento.
Alm da prpria Sprint, que um container para outros eventos, cada evento no Scrum uma
oportunidade para inspecionar e adaptar algo. Estes eventos so projetados especificamente para
permitir uma transparncia crtica e inspeo. No incluir qualquer destes eventos reduzir a
transparncia e perder a oportunidade para inspecionar e adaptar.
O Sprint
O corao do Scrum o Sprint, um time-box de um ms ou menos durante o qual uma verso
potencialmente utilizvel de um incremento do produto criada. Sprints tem duraes consistentes ao
longo do esforo de desenvolvimento. Um novo Sprint comea imediatamente depois da concluso do
Sprint anterior.
Sprints consistem em uma reunio de planejamento do Sprint, Scrums Dirios, o trabalho de
desenvolvimento, a reunio de reviso do Sprint e a Retrospectiva do Sprint.
Durante o Sprint:
Nenhuma mudana deve ser feita que afete o objetivo do Sprint,

3
N.T. Time-boxed foi deixado em ingls 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. 8
A composio da equipe de desenvolvimento e a qualidade dos objetivos se mantm
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 no pode ser maior do que um
ms. Como projetos, Sprints so usados para se conquistar algo. Cada Sprint possui uma definio do
que deve ser construdo, um projeto e um plano flexvel que vai guiar a construo o trabalho e o
produto resultante.
Sprints so limitados a um ms corrido. Quando o horizonte do Sprint muito longe a definio do que
ser construdo pode mudar, complexidade pode aumentar e o risco pode se elevar. Sprints permitem
a previsibilidade garantindo inspeo e adaptao do progresso na direo de um objetivo pelo menos
a cada ms. Sprints tambm limitam o risco ao custo de um ms.
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 influncia dos
stakeholders, da equipe de Desenvolvimento ou do Scrum mster.
Um Sprint ser cancelado se o Objetivo do Sprint se tornar obsoleto. Isso pode ocorrer se empresa
mudar a direo ou se as condies de mercado ou tecnologia mudarem. Em geral, um Sprint deve ser
cancelado se ele no fizer mais sentido s dadas circunstncias. Mas, dada a curta durao 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 entregvel, o Dono do produto
[tipicamente], o aceita. Todo o trabalho incompleto do Backlog do Produto so 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 reunio
de planejamento de Spring para iniciar outro Sprint. O cancelamento de Sprints sempre traumtico
para a Equipe de Scrum, e muito incomum.
Reunio de Planejamento do Sprint
O trabalho a ser executado no Sprint planejado na Reunio de Planejamento do Sprint. Este plano
criado pelo trabalho colaborativo de toda a equipe do Scrum.
A reunio de planejamento do Sprint fixa em oito horas para um Sprint de um ms. Para Sprints mais
curtos, o evento proporcionalmente menor. Por exemplo, Sprints de duas semanas, tem Reunio de
Planejamento do Sprint de quatro horas.
A Reunio de Planejamento do Sprint dividida em duas partes, cada uma tendo a metade do tempo
fixo, dedicado reunio de planejamento do Sprint. As duas partes da Reunio de Planejamento do
Sprint respondem s seguintes questes, respectivamente:

1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos Pag. 9
O que vai ser entregue como resultado do Incremento do prximo Sprint?
Como ser realizado o trabalho necessrio 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 reunio 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 prximo Sprint.
Depois da previso da Equipe de Desenvolvimento dos itens do Backlog do Produto que sero
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 implementao do Backlog do Produto, e oferece
uma orientao para a Equipe de desenvolvimento sobre a construo 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 executvel do produto. O trabalho pode variar de
tamanho, ou estimativa de esforo. Entretanto, o trabalho suficiente planejado durante a Reunio 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 reunio. A equipe de Desenvolvimento se auto organiza para realizar o trabalho
no Backlog do Sprint, tanto durante a Reunio de Planejamento do Sprint e quando for necessrio ao
longo do Sprint.
O Dono do Produto pode estar presente durante a segunda parte da Reunio 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 tambm convidar outras pessoas para participar da reunio, oferecendo
aconselhamento tcnico ou do domnio.
No final da reunio 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. 10
Com o andamento do trabalho da Equipe de Desenvolvimento, ela mantm 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 propsito maior no mapa do produto.
Scrum Dirio
A Reunio do Scrum Dirio um evento com 15 minutos fixos para a Equipe de Desenvolvimento
sincronizar as atividades e criar um plano para as prximas 24 horas. Isso se faz inspecionando o
trabalho at o ltimo Scrum Dirio e prevendo o trabalho que pode ser Pronto antes do prximo.
O Scrum dirio se d no mesmo horrio 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 prximo encontro?
Quais so os obstculos que esto no seu caminho?
A Equipe de Desenvolvimento usa o Scrum Dirio para avaliar o progresso na direo do Objetivo do
Sprint e para avaliar se o progresso tende para completar o trabalho no Backlog do Sprint. O Scrum
Dirio aumenta a probabilidade da Equipe de Desenvolvimento atingir o Objetivo do Sprint. A Equipe
de Desenvolvimento em geral, se encontra imediatamente depois do Scrum Dirio 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 responsvel por conduzir o Scrum Dirio. O Scrum Master ensina a Equipe de
Desenvolvimento a manter o Scrum Dirio 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 Dirio. O Scrum Dirio no uma reunio de status, e voltada para as pessoas que
transformam os itens do Backlog em um Incremento.
Os Scrums Dirios melhoram a comunicao, eliminam outras reunies, identificam e removem os
impedimentos para o desenvolvimento, destacam e promovem uma tomada de deciso rpida, e
melhoram o nvel do conhecimento do projeto da Equipe de Desenvolvimento. Esta a reunio chave
para inspeo e adaptao.
Reviso do Sprint
A Reunio de Reviso do Sprint executada no final do Sprint para inspecionar o Incremento e adaptar
ao Backlog do Produto se necessrio. Durante a Reviso do Sprint, a Equipe de Scrum e stakeholders
colaboram sobre o que foi Pronto no Sprint. Baseado nisso e em qualquer mudana no Backlog do
Produto durante o Sprint, os presentes colaboram nas prximas coisas que precisam ser feitas. Est

1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos Pag. 11
uma reunio informal, e a apresentao do Incremento tem como inteno motivar uma
realimentao e incentivar a colaborao.
Esta uma reunio de time-box de 4 horas para um Sprint de um ms. Proporcionalmente menos
tempo alocado para Sprints mais curtos. Por exemplo, Sprints de duas semanas vo ter Revises de
Sprint de duas horas.
A Reviso do Sprint inclui os seguintes elementos:
O Dono do produto identifica que foi Pronto e o que no 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 provvel de trmino
baseado no progresso at o momento; e,
Todo o grupo colabora no que deve ser Pronto em seguida assim, a Reviso do Spring fornece
um entrada valiosa para as prximas reunies de Planejamento do Sprint.

O resultado da reviso do Sprint um Backlog do Produto revisado que define os provveis itens do
Backlog do Produto para a prxima 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 prximo Sprint.
A Retrospectiva do Sprint ocorre depois da Reviso do Sprint e antes da Prxima reunio de
planejamento do Sprint. Esta uma reunio marcada para com um time-box de 3 horas para um ms
de Sprints. Proporcionalmente um tempo menor alocado para Sprints menores.
O propsito da Retrospectiva do Sprint :
Inspecionar como foi o ltimo Sprint no que diz respeito a pessoas, relaes, 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 mster encoraja a Equipe de Scrum para melhorar, dentro do framework de processo do
Scrum, o processo de desenvolvimento e as prticas para faz-lo mais efetivo e agradvel para o
prximo Sprint. Durante cada Retrospectiva do Sprint, a Equipe de Scrum planeja modos para
aumentar a qualidade do produto adaptando a definio de pronto quando apropriado.
No final da retrospectiva do Sprint, a equipe de Scrum deve identificar melhorias que sero aplicadas
no prximo Sprint. Implementar estas melhorias no prximo Sprint adaptar a inspeo na prpria

1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos Pag. 12
Equipe do Scrum. Apesar de que melhorias podem ser adotadas a qualquer momento, a Retrospectiva
do Sprint oferece um evento dedicado focado na inspeo e adaptao.
Artefatos de Scrum
Os artefatos do Scrum representam o trabalho ou valor de vrias formas que so teis de oferecer
transparncias e oportunidades para inspeo e adaptao. Os artefatos definidos no Scrum so
especialmente projetados para maximizar a transparncia e a informao chave necessrios 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 necessrio no produto e a fonte
nica dos requisitos para qualquer mudana a ser feita no produto. O Dono do Produto responsvel
para o Backlog do Produto, incluindo o seu contedo, disponibilidade e ordenao.
Um Backlog do produto nunca est completo. A verso inicial dele apenas descreve o que foi
conhecido no incio 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
dinmico; 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, funes, requisitos, melhorias e consertos que
representam as mudanas a serem feitas no produto para as prximas verses. Os itens do Backlog do
Produto tem os atributos de descrio, 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 so feitas com base na maior clareza e aumento de
detalhes; quanto mais baixa a ordem, menos detalhes. Os itens do Backlog do Produto que vo ocupar
a equipe de desenvolvimento no prximo Sprint so 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 so
marcados como disponveis ou executveis para seleo na reunio de Planejamento do Sprint.
Enquanto um produto usado, e ganha valor, e o mercado oferece uma realimentao, 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. Mudanas nos requisitos do negcio, condies de mercado ou
tecnologia podem provocar mudanas no Backlog do produto.
Mltiplas 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. 13
A preparao do Backlog do produto o ato de adicionar detalhes, estimativas e ordenar os itens no
Backlog do produto. Este um processo contnuo no qual o Dono do Produto e a Equipe de
Desenvolvimento colaboram nos detalhes dos itens do Backlog do produto. Durante a preparao do
Backlog do Produto, os itens so analisados e revisados. Entretanto, eles podem ser atualizados a
qualquer momento pelo Dono do Produto ou escolha do Dono do Produto.
Preparao 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
prprio domnio do conhecimento. Como e quando a preparao feita decidida pela Equipe do
Scrum. Preparao usualmente consome no mais do que 10% da capacidade da Equipe de
Desenvolvimento.
A equipe de desenvolvimento responsvel por todas as estimativas. O Dono do produto pode
influenciar a equipe ajudando a entender e selecionar os compromissos, mas as pessoas que vo
realizar o trabalho quem deve fazer a estimativa final.
Monitorando o Progresso na direo 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 Reviso do
Sprint. O Dono do Produto compara o total de trabalho faltante na reviso anterior do Sprint para
avaliar o progresso na direo de completar o trabalho projetado pelo tempo estimado para o
objetivo. Esta informao se torna transparente para todos os stakeholders.
O Scrum no consideram o tempo gasto no trabalho com os Itens do Backlog do produto. O trabalho
restante e as datas so as nicas variveis de interesse.
Vrias prticas como burndown, burnup e outras prticas de estimativa tem sido usadas para prever o
progresso. Elas tem se provado teis. Entretanto, Elas no substituem a importncia do empirismo. Em
ambientes complexos, o que vai acontecer desconhecido. Somente o que aconteceu pode ser usado
para uma tomada de deciso do que vai vir.
Backlog do Sprint
O Backlog do Sprint um conjunto de itens do Backlog do produto selecionados para o Sprint alm de
um plano para obter o incremento do produto e atingir o objetivo do Sprint. O Backlog do Sprint uma
previso da Equipe de Desenvolvimento sobre qual funcionalidade estar no prximo incremento e do
trabalho necessrio 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
visvel todo o trabalho que a Equipe de Desenvolvimento identifica como necessrio para atingir o
Objetivo do Sprint.
O Backlog do Sprint um plano com detalhes suficiente que as mudanas em progresso sejam
entendidas no Scrum Dirio. 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 necessrio para atingir o
objetivo do Sprint.

1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos Pag. 14
Se um novo trabalho for necessrio, 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 desnecessrios, eles so 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 visvel, 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 Dirio. A Equipe de Desenvolvimento acompanha estes totais dirios e projeta a
que mais provavelmente vai alcanar o Objetivo do Sprint. Por rastrear o trabalho restante pelo Sprint,
a Equipe de Desenvolvimento pode gerenciar o seu progresso.
O Scrum no considera o tempo gasto nos itens do Backlog do Sprint. O trabalho restante e as datas
so as nicas variveis 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 condio utilizvel e atende definio da Equipe do Scrum do Pronto.
Ele deve estar em uma condio utilizvel independente da deciso do Dono do Produto decidir
realmente liber-lo.
Definio 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 transparncia. Esta a definio de Pronto para a equipe do Scrum e
usado para avaliar quando o trabalho est completo no Incremento do Produto.
A mesma definio orienta a Equipe de Desenvolvimento em saber quantos itens do Backlog do
produto ela pode selecionar durante a Reunio de Planejamento do Sprint. O propsito de cada Sprint
entregar Incrementos de funcionalidades potencialmente utilizveis que atende definio atual da
equipe de Desenvolvimento para Pronto.
A Equipe de Desenvolvimento entrega um Incremento da funcionalidade do Produto a cada Sprint.
Este Incremento usvel, assim o Dono do produto pode decidir liber-lo imediatamente. Cada
Incremento adicionvel 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 definio de Pronto expanda para
incluir critrios mais rigorosos de maior qualidade.

1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos Pag. 15
Concluso
O Scrum livre e proposto neste guia. Os papeis, artefatos, eventos e regras do Scrum so imutveis e
apesar de que implementao apenas de partes do Scrum possvel, o resultado no um Scrum. O
Scrum existe somente na sua totalidade e funciona bem como um container para outras tcnicas,
metodologias e prticas.

1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos Pag. 16
Agradecimentos
Pessoas
Das milhares de pessoas que tem contribudo para o Scrum, ns gostaramos 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 no seria refinado como hoje. David Starr ofereceu
insights chave e habilidades editoriais na formulao desta verso do Guia do Scrum.
Histria
Ken Schwaber e Jeff Sutherland co-apresentaram inicialmente na conferencia OOPSLA em 1XXX. Esta
apresentao essencialmente documentou o aprendizado de Ken e Jeff nos anos que antecederam a
aplicao do Scrum. A histria do Scrum j considerada longa. Para honrar os primeiros lugares onde
ele foi tentado e refinado, ns reconhecemos a Individual, Inc., Fidelity Investments e IDX (hoje GE
Medical).

1991-2011 Ken Schwaber e Jeff Sutherland, Todos os direitos garantidos Pag. 17
Revises
O Guia do Scrum de Julho de 2011 diferente do seu predecessor, o Guia de Fevereiro de 2010. Em
particular, ns tentamos remover tcnicas e boas prticas do ncleo do Scrum. Elas podem variar
baseado nas circunstncias. Ns vamos comear um compndio de boas prticas para prover um
pouco da nossa experincia recente.
O Guia do Scrum documenta o Scrum enquanto ele se desenvolve e se mantm por mais de vinte
anos por Jeff Sutherland e Ken Schwaber. Outras fontes provm padres, processos e vises sobre
como as prticas, facilitadores e ferramentas complementam o framework do Scrum. Isto aperfeioa a
produtividade, valor, criatividade e orgulho.
Notas emitidas cobrindo as seguintes diferenas entre este guia e a verso de 2010 sero publicadas
em outros lugares, incluindo discusses 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 previso.
6. Equipe (para Equipe de Desenvolvimento).
7. Porcos e Galinhas o conto do Scrum.
8. Ordenados no lugar de priorizados.