GUIA DO SCRUM

Por Ken Schwaber, Maio de 2009

GUIA DO SCRUM
Por Ken Schwaber, Maio de 2009

Traduo
Heitor Roriz Filho
Michel Goldenberg
Rafael Sabbagh
Reviso
Anderson Marcondes
nderson Quadros
Ari do Amaral Torres Filho
Marcos Garrido
Rafael Fuchs
Rafael Prikladnicki
Rodrigo de Toledo
Rafael Sabbagh (coordenao)

INTRODUO AO SCRUM
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 qualquer 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 definio de pronto utilizada.

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. Os 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 Reunio Diria
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 Verso para
Entrega 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 Scrum e seus
papis associados, Eventos com Durao Fixa (Time-Boxes), Artefatos e
Regras.
Times Scrum so projetados para otimizar flexibilidade e produtividade. Para
esse fim, eles so auto-organizveis, interdisciplinares e trabalham em iteraes.
Cada Time Scrum possui trs papis: 1) o ScrumMaster, que responsvel por
garantir que o processo seja entendido e seguido; 2) o Product Owner, que
responsvel por maximizar o valor do trabalho que o Time 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.
Scrum emprega os eventos com durao fixa (time-boxes) para criar
regularidade. Entre os elementos do Scrum que tm durao fixa, temos a
reunio de Planejamento da Verso para Entrega, a Sprint, a Reunio Diria,
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 Backlog do Produto uma lista
priorizada de tudo que pode ser necessrio no produto. O Backlog da Sprint
uma lista de tarefas para transformar o Backlog do Produto, por uma Sprint, em
um incremento do produto potencialmente entregvel. Um burndown uma
medida do backlog restante pelo tempo. Um Burndown de Verso para
Entrega mede o Backlog do Produto restante ao longo do tempo de um plano
de entrega. Um Burndown de Sprint mede os itens do Backlog da Sprint
restantes ao longo do tempo de uma Sprint.
As Regras fazem o elo entre os eventos com durao fixa (time-boxes), os papis
e os artefatos do Scrum. Suas regras so descritas ao longo deste documento.
Por exemplo, uma regra do Scrum diz que somente membros do Time - as
pessoas comprometidas em transformar o Backlog do Produto em um
incremento - podem falar durante uma Reunio Diria. Modos de implementar
Scrum que no so regras, mas sim sugestes, esto descritas nas sees de
"Dicas".

Dica: Quando as regras no so declaradas, espera-se que os usurios de Scrum

descubram o que devem fazer. No tente descobrir uma soluo perfeita, porque
geralmente o problema muda rapidamente. Ao invs disso, tente algo e veja como
se sai. Os mecanismos de inspeo-e-adaptao inerentes natureza emprica de
Scrum iro lhe guiar.

PAPIS NO SCRUM
O Time Scrum composto pelo ScrumMaster, pelo Product Owner e pelo Time.
Os membros do Time Scrum so chamados porcos. 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
O ScrumMaster responsvel por garantir que o Time Scrum esteja aderindo
aos valores do Scrum, s prticas e s regras. O ScrumMaster ajuda o Time
Scrum e a organizao a adotarem o Scrum. O ScrumMaster educa o Time
Scrum treinando-o e levando-o a ser mais produtivo e a desenvolver produtos
de maior qualidade. O ScrumMaster ajuda o Time Scrum a entender e usar

autogerenciamento e interdisciplinaridade. No entanto, o ScrumMaster no

gerencia o Time Scrum; o Time Scrum auto-organizvel.

Dica: O ScrumMaster pode ser um membro do Time; por exemplo, um

desenvolvedor realizando tarefas da Sprint. No entanto, isso frequentemente leva a
conflitos quando o ScrumMaster deve escolher entre remover impedimentos e
realizar tarefas. O ScrumMaster nunca deve ser o Product Owner.

O PRODUCT OWNER
O Product Owner a nica pessoa responsvel pelo gerenciamento do Backlog
do Produto e por garantir o valor do trabalho realizado pelo Time. Essa pessoa
mantm o Backlog do Produto e garante que ele est visvel para todos. Todos
sabem quais itens tm a maior prioridade, de forma que todos sabem em que se
ir trabalhar. O Product Owner uma pessoa, e no um comit. Podem existir
comits que aconselhem ou influenciem essa pessoa, mas quem quiser mudar a
prioridade de um item, ter que convencer o Product Owner. Empresas que
adotam Scrum podem perceber que isso influencia seus mtodos para definir
prioridades e requisitos ao longo do tempo.

Dica: Para desenvolvimento comercial, o Product Owner pode ser o Gerente de

Produto. Para esforos internos de desenvolvimento, o Product Owner poderia ser o
gerente da funo de negcios em que se est trabalhando.

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 decises do Product Owner so
visveis no contedo e na priorizao do Backlog do Produto. Essa visibilidade
requer que o Product Owner faa seu melhor, o que faz o papel de Product
Owner exigente e recompensador ao mesmo tempo.

Dica: O Product Owner pode ser um membro do Time, trabalhando tambm em

desenvolvimento. Mas essa responsabilidade adicional pode reduzir a sua
habilidade de lidar com as partes interessadas. No entanto, o Product Owner nunca
pode ser o ScrumMaster.

O TIME
Times de desenvolvedores transformam o Backlog do Produto em incrementos
de funcionalidades potencialmente entregveis em cada Sprint. Times tambm
so interdisciplinares: 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, os conhecimentos que os
membros do Time devem compartilhar - isto , a habilidade de pegar 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 Backlog do Produto 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 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.
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 Eventos com Durao Fixa (Time-Boxes) no Scrum so a Reunio de
Planejamento da Verso para Entrega, a Sprint, a Reunio de Planejamento
da Sprint, a Reviso da Sprint, a Retrospectiva da Sprint e a Reunio Diria.

REUNIO DE PLANEJAMENTO DA VERSO

PARA ENTREGA
O propsito do planejamento da verso para entrega o de estabelecer um
plano e metas que o Time Scrum e o resto da organizao possam entender e
comunicar. O planejamento da verso para entrega 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 verso para entrega
estabelece a meta da verso, as maiores prioridades do Backlog do Produto, os
principais riscos e as caractersticas gerais e funcionalidades que estaro
contidas na verso. 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 verso para entrega a
cada Sprint.

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 verso para
entrega, e na maior parte desses processos o planejamento feito no incio do
trabalho da verso e no modificado com o passar do tempo. No
planejamento de verso para entrega 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 verso para entrega tradicional. No entanto, uma verso 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 Reunio Diria. De
forma geral, os esforos para uma verso para entrega com Scrum
provavelmente consomem ligeiramente mais esforo do que os esforos para
um planejamento de verso para entrega tradicional.
Planejamento de verso para entrega requer estimar e priorizar o Backlog do
Produto para a Verso. H diversas tcnicas para faz-lo que esto fora do
alcance do Scrum, mas que apesar disso so teis quando usadas com ele.

A SPRINT
A Sprint uma iterao. Sprints so eventos com durao fixa. Durante a Sprint,
o ScrumMaster garante que no ser feita nenhuma mudana que possa afetar a
Meta da Sprint. Tanto a composio do time quanto as metas de qualidade
devem permanecer constantes durante a Sprint. As Sprints contm e consistem
na 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.

10

Um projeto serve para cumprir alguma funo. Em desenvolvimento de

software, o projeto utilizado para desenvolver um produto ou sistema. Cada
projeto consiste em uma definio do que ser desenvolvido, um plano para
desenvolv-lo, o trabalho 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 menos a cada ms, e o risco de que o projeto saia de
controle ou se torne imprevisvel contido pelo menos a cada ms.

Dica: Se o time sentir que se comprometeu com mais do que podia, ele se encontra
com o Product Owner para remover ou reduzir o escopo do Backlog do Produto
selecionado para a Sprint. Se o time sentir que sobrar tempo, ele pode trabalhar
junto ao Product Owner para selecionar mais do Backlog do Produto.

Dica: Quando um Time comea com o Scrum, Sprints de duas semanas o permite
aprender sem se afundar na incerteza. Sprints desse tamanho podem ser
sincronizadas com outros Times adicionando-se dois incrementos juntos.

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.

11

Quando uma Sprint cancelada, todos os itens do Backlog do Produto que

estejam completados e "feitos" so revisados. Eles so aceitos se representarem
um incremento potencialmente entregvel. Todos os outros itens do Backlog do
Produto so devolvidos ao Backlog do Produto 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 quando a iterao planejada. fixada
em oito horas de durao para uma Sprint de um ms. Para Sprints mais curtas,
aloca-se para essa reunio aproximadamente 5% do tamanho total da Sprint, e
ela consiste de duas partes. A primeira parte, um evento com durao fixa em
quatro horas, quando decidido o que ser feito na Sprint. A segunda parte,
outro evento com durao fixa em quatro horas, quando o Time entende
como 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 Scrum juntam as duas. Na primeira parte, o
Time Scrum trata da questo do o qu?. Aqui, o Product Owner apresenta ao
Time o que mais prioritrio no Backlog do Produto. Eles trabalham em
conjunto para definir qual funcionalidade dever ser desenvolvida durante a
prxima Sprint. As entradas para essa reunio so o Backlog do Produto, 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 Backlog do Produto, a Meta da Sprint delineada. A
Meta da Sprint um objetivo que ser atingido atravs da implementao do
Backlog do Produto. Ela uma descrio que fornece orientao ao Time sobre

12

a razo pela qual ele est desenvolvendo o incremento. A Meta da Sprint um

subconjunto da Meta da Verso para Entrega.
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 colaborar 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 as quatro horas seguintes da Reunio de Planejamento da
Sprint, o Time define como transformar o Backlog do Produto selecionado
durante a Reunio de Planejamento (o qu) em um incremento pronto. O Time
geralmente comea projetando o trabalho. Enquanto projeta, o time identifica
tarefas. Essas tarefas so pedaos detalhados do trabalho necessrio para
converter o Backlog do Produto em software funcional. As tarefas devem ser
decompostas para que possam ser feitas em menos de um dia. Essa lista de
tarefas chamada de Backlog da Sprint. O time se auto-organiza para se
encarregar e se responsabilizar pelo trabalho contido no Backlog da Sprint,
tanto durante a Reunio de Planejamento da Sprint quanto no prprio
momento da execuo da Sprint.

Dica: Geralmente, somente 60-70% do total do Backlog da Sprint ser definido na

Reunio de Planejamento da Sprint. O restante deixado para ser detalhado mais
tarde ou so dadas estimativas grandes que sero decompostas mais tarde na
Sprint.

O Product Owner est presente durante a segunda parte da Reunio de

Planejamento da Sprint para esclarecer o Backlog do Produto e para ajudar a
efetuar trocas. Se o Time concluir que ele tem trabalho demais ou de menos, ele
pode renegociar o Backlog do Produto escolhido com o Product Owner. O Time
tambm pode convidar outras pessoas a participarem da reunio para

13

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 uma reunio de Reviso da Sprint. Para Sprints de um
ms, essa uma reunio com durao fixa em quatro horas. Para Sprints de
duraes mais curtas, essa reunio no deve tomar mais do que 5% do total da
Sprint. Durante a Reviso da Sprint, o Time Scrum e as partes interessadas
colaboram sobre o que acabou de ser feito. Baseados nisso e em mudanas no
Backlog do Produto 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
Backlog do Produto 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 Scrum tem uma reunio de Retrospectiva da Sprint. Nessa reunio, com
durao fixa em trs horas, o ScrumMaster encoraja o Time a revisar, dentro do

14

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, preparativos para reunies,
ferramentas, definio de pronto, mtodos de comunicao e processos para
transformar itens do Backlog do Produto em alguma coisa pronta. No final da
Retrospectiva da Sprint, o Time Scrum deve ter identificado medidas de
melhoria factveis que ele implementar na prxima Sprint. Essas mudanas se
tornam a adaptao para a inspeo emprica.

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

O que ele realizou desde a ltima reunio diria;

O que ele vai fazer antes da prxima reunio diria; e
Quais obstculos esto em seu caminho.

As Reunies Dirias 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.

15

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

por conduzir a Reunio Diria. O ScrumMaster ensina o time a manter a Reunio
Diria 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 Reunio Diria.
A Reunio Diria no uma reunio de status. Ela s para as pessoas que esto
transformando os itens do Backlog do Produto em um incremento (o Time), e
para mais ningum. O Time se comprometeu com uma Meta da Sprint, e a esses
itens do Backlog do Produto. A Reunio Diria uma inspeo do progresso na
direo da Meta da Sprint (as trs perguntas). Geralmente acontecem reunies
subsequentes para 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 Backlog do Produto, o Burndown da Verso
para Entrega, o Backlog da Sprint e o Burndown da Sprint.

BACKLOG DO PRODUTO E BURNDOWN DA

VERSO PARA ENTREGA
Os requisitos para o produto que o(s) Time(s) est(o) desenvolvendo esto
listados no Backlog do Produto. O Product Owner o responsvel pelo Backlog
do Produto, por seu contedo, por sua disponibilidade e por sua priorizao. O
Backlog do Produto nunca est completo. A seleo inicial para o seu
desenvolvimento somente mostra os requisitos inicialmente conhecidos e
melhor entendidos. O Backlog do Produto 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

16

necessita para ser apropriado, competitivo e til. Enquanto existir um produto, o

Backlog de Produto tambm existir.
O Backlog do Produto representa tudo que necessrio para desenvolver 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 verses futuras. Os itens do Backlog do
Produto 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.

Dica: Os itens do Backlog do Produto so geralmente representados como Estrias

de Usurio. Casos de Uso tambm so apropriados, mas so mais adequados para
desenvolvimento de softwares crticos em termos de vidas ou de desempenho.

O Backlog do Produto ordenado por prioridade. O Backlog do Produto 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
mais claro e possui mais informaes detalhadas do que o Backlog de prioridade
mais baixa. Fazem-se melhores estimativas quando baseadas em uma maior
clareza e em mais detalhes. Quanto mais baixa a prioridade, menor o nvel de
detalhe, at que mal se consiga entender o item.
medida que um produto utilizado, que seu valor aumenta e que o mercado
fornece feedback, o Backlog do Produto torna-se uma lista maior e mais
aprofundada. Os requisitos nunca param de mudar. O Backlog do Produto um
documento vivo. Mudanas nos requisitos de negcios, condies do mercado,
tecnologia e equipe causam mudanas no Backlog do Produto. Para minimizar o
retrabalho, apenas os itens de maior prioridade precisam ser mais detalhados.
Os itens do Backlog do Produto que ocuparo os Times Scrum pelas vrias
Sprints seguintes devero ter granularidade mais fina, tendo sido decompostos
de forma tal que cada um dos itens possa ser feito dentro da durao da Sprint.

17

Dica: Os Times Scrum geralmente gastam 10% de cada Sprint preparando o

Backlog do Produto para adequ-lo definio de Backlog do Produto feita acima.
Quando estiverem adequados a esse nvel de granularidade, os itens no topo do
Backlog do Produto (de maior prioridade e de maior valor) so decompostos de
forma que caibam em um Sprint. Eles foram analisados e se refletiu sobre eles
durante esse processo de preparao. Quando ocorre a reunio de Planejamento de
Sprint, esses itens de maior prioridade do Backlog do Produto esto bem entendidos
e so facilmente selecionados.

Frequentemente, mltiplos Times Scrum trabalham juntos no mesmo produto.

Um nico Backlog do Produto usado para descrever o trabalho a ser realizado
no produto. Ento, um atributo que agrupe os itens aplicado no Backlog do
Produto. 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 Scrum.

Dica: Testes de aceitao so frequentemente utilizados como um outro atributo

para o item do Backlog do Produto. Eles podem frequentemente substituir
descries textuais mais detalhadas com uma descrio testvel do que o item do
Backlog do Produto deve fazer uma vez que esteja completo.

O grfico de Burndown da Verso para Entrega registra a soma das estimativas

dos esforos restantes do Backlog do Produto ao longo do tempo. O esforo
estimado deve estar em qualquer unidade de medida de trabalho que o Time
Scrum e a organizao tenham decidido usar. As unidades de tempo
geralmente so Sprints.
As estimativas dos itens do Backlog do Produto so inicialmente calculadas
durante o Planejamento da Verso para Entrega, e posteriormente medida
que itens forem sendo criados. Durante a preparao do Backlog de Produto, os
itens so revistos e revisados. Entretanto, eles podem ser atualizados em
qualquer momento. O Time responsvel por todas as estimativas. O Product
Owner pode influenciar o Time, ajudando-o a entender e a escolher as

18

mudanas, mas a estimativa final feita pelo Time. O Product Owner mantm o
Backlog do Produto e o Burndown do Backlog da Verso para Entrega
atualizados e publicados todo o tempo. Uma linha de tendncia pode ser
traada baseada na mudana do trabalho restante.

Dica: Em algumas organizaes, acrescenta-se mais trabalho ao Backlog do que se

realiza. Isso pode criar uma linha de tendncia plana ou at com inclinao
crescente. Para compensar isso e manter a transparncia, um novo piso pode ser
criado quando se adiciona ou quando se subtrai trabalho. O piso deve adicionar ou
remover somente mudanas significativas e deve ser bem documentado.

Dica: A linha de tendncia pode no ser confivel pelas duas ou trs primeiras
Sprints de uma verso, a menos que os times j tenham trabalhado juntos
anteriormente, conheam bem o produto e entendam a tecnologia envolvida.

BACKLOG DA SPRINT E BURNDOWN DA

SPRINT
O Backlog da Sprint consiste nas tarefas que o time executa para transformar
itens do Backlog do Produto em um incremento pronto. Muitas delas so
elaboradas durante a Reunio de Planejamento da Sprint. O Backlog da Sprint
todo trabalho que o Time identifica como necessrio para alcanar a Meta da
Sprint. Os itens do Backlog da Sprint devem ser decompostos. A decomposio
deve ser suficiente para que mudanas no progresso possam ser entendidas na
Reunio Diria.
O Time modifica o Backlog da Sprint no decorrer da Sprint, bem como surge
Backlog da Sprint 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 Backlog da Sprint.
medida que se trabalha nas tarefas ou que elas so completadas, as horas

19

estimadas de trabalho restantes para cada tarefa so atualizadas. Quando se

verifica que determinadas tarefas so desnecessrias, elas so removidas.
Somente o Time pode modificar o seu Backlog da Sprint durante uma Sprint.
Somente o Time pode mudar o seu contedo ou as suas estimativas. O Backlog
da Sprint 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 Backlog da Sprint um grfico da quantidade restante de
trabalho do Backlog da Sprint em uma determinada Sprint ao longo do tempo
da Sprint. Para criar esse grfico, determine quanto trabalho resta somando as
estimativas do Backlog a cada dia da Sprint. A quantidade de trabalho restante
para uma Sprint a soma do trabalho restante para tudo do Backlog da Sprint.
Acompanhe essas somas diariamente e utilize-as para criar um grfico que
mostre 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.

Dica: Sempre que possvel, desenhe o grfico de burndown mo em uma folha

grande de papel exibida na rea de trabalho do Time. mais provvel que o Time
veja um grfico grande e visvel do que um grfico de Burndown da Sprint no Excel
ou em alguma ferramenta.

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

20

completo do produto. Ele deve estar pronto. 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 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 Backlog do Produto 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 Backlog do Produto 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 definio de pronto
tudo o que necessrio para a implantao. Isto deve estar claro para o Product
Owner. Esse trabalho restante dever ser feito antes que o produto possa ser
implantado e utilizado.

Dica: Trabalho "no pronto" geralmente acumulado em um item do Backlog do

Produto chamado "Trabalho No Pronto" ou "Trabalho de Implantao". medida
que esse trabalho acumula, o Burndown do Backlog do Produto se mantm mais
preciso do que se esse trabalho no fosse acumulado.

Dica: 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

21

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
Backlog do Produto chamado trabalho no pronto, de forma que ele se acumula e
isso refletido corretamente no grfico de Burndown da Verso para Entrega. 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 Backlog do
Produto, 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 Backlog do
Produto 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 entrega so adicionados ao final de
cada verso para completar o trabalho no pronto. O nmero de Sprints
imprevisvel visto que o acmulo de trabalho no pronto no linear.

Algumas tcnicas teis para conduzir uma Retrospectiva em Scrum podem ser
encontradas em:
Agile Retrospectives: Making Good Teams Great, Esther Derby e Diana Larsen,
Pragmatic Bookshelf, 2006.
User Stories Applied: For Agile Software Development, Mike Cohn, Addison-Wesley,
2004.
Writing Effective Use Cases, Alistair Cockburn, Addison-Wesley, 2000.

22