Melhor

Scrum
Um conjunto no-oficial de dicas e idias
de como implementar bem Scrum.

Escrito por Peter Hundermark Instrutor (CST) e Coach (CSC) Certificado Scrum.
Traduzido para o portugus por Samuel Gonsales Certificado ScrumMaster (CSM).

Por que este guia?

Jim York, Instrutor (CST) e Coach (CSC) Certificado Scrum, disse:
Scrum simples. Praticar Scrum difcil. SM
Muitas pessoas que conheo dizem que elas tm dificuldade para saber como iniciar a
prtica de Scrum. Outros tm equipes que esto seguindo algumas prticas
geis, mas que ainda esto longe de se tornar o que Jeff Sutherland definiu como
hiper-produtivo.
Espero que este pequeno livro possa ser uma fonte de inspirao para ajud-lo a
praticar Scrum e conceitos geis melhor. Acima de tudo, espero poder incentiv-lo
a percorrer juntamente com sua equipe e toda a sua organizao para longe
das velhas formas de trabalho que simplesmente no fazer bem, trabalhar e encontrar
novos caminhos que levam a obter mais qualidade, entregar com mais velocidade
e acima de tudo, que seja mais divertido.
Deixe-me, ento, saber o que voc gosta e o que no gosta para que eu
possa melhor-lo.
Agora v e faa!
Peter Hundermark
Cape Town, Novembro de 2009
Segunda Edio

Melhor Scrum 1

O que Scrum?
Origens
Scrum um framework de gerenciamento de projetos que visa o desenvolvimento de
produtos
complexos. Scrum tem
suas
origens nas
reas
de gesto
conhecimento, sistemas adaptativos complexos e teoria de controle emprico de
processos. Foi tambm influenciado por padres observados no desenvolvimento de
Software e Teoria das Restries.

Scrum e gil
Scrum o mais popular dos mtodos geis. freqentemente utilizado em conjunto
com Extreme Programming (XP).

Qual o problema?
Releases demoram muito;
A estabilizao leva muito tempo;
As alteraes so difceis de fazer;
A Qualidade est caindo;
Marchas fnebres esto ferindo a moral;
Durante dcadas os desenvolvedores de software tm tentado empregar mtodos
definidos de trabalho e gerenciamento de projetos. Os mtodos definidos so
adequados quando as variveis que entram no sistema so bem definidas e o
mtodo empregado gera um resultado previsvel.Desenvolvimento de software e
outras formas de trabalho complexo no so adequados a tais mtodos. E a alta taxa
de falhas de projeto e insatisfao dos clientes ilustra isso claramente.

Como o Scrum ajuda a resolver esses problemas?

Alistair Cockburn [Cockburn 2008] descreve o desenvolvimento de software como um
"jogo cooperativo de inveno e comunicao".
Metodologias tradicionais de desenvolvimento so baseadas em documentos para
capturar e comunicar conhecimento de um especialista ao outro. Os ciclos de
feedback so muito longos ou mesmo no existem. Dcadas de projetos de baixa
produtividade mostram que esta forma de trabalho conduz inevitavelmente ao
fracasso.
Scrum fornece uma plataforma para as pessoas trabalharem em conjunto de forma
eficaz e expe implacavelmente todos os problemas tornando-os visveis em seu
caminho.
Melhor Scrum 2

Melhor Scrum 2

A Essncia do Scrum
A essncia do Scrum :
A equipe recebe metas claras;
A equipe se organiza em torno do trabalho;
A equipe entrega regularmente os recursos mais valiosos;
A equipe recebe feedback de pessoas de fora;
A equipe reflete sobre sua forma de trabalhar a fim de melhorar;
Toda a organizao tem visibilidade do progresso da equipe;
A equipe de gesto comunica aos outros de maneira honesta sobre
progressos e riscos.
Esta forma de trabalho baseada em valores de auto-respeito, respeito pelos outros,
confiana e coragem.

Por que Scrum no faz nenhuma meno a qualquer

prtica de desenvolvimento de software?
As ferramentas de desenvolvimento e prticas mudam e melhoram continuamente e
boas equipes iro trabalhar no sentido de obter o melhor uso delas.
Scrum no
tenta instruir equipes de
como
fazer seu
trabalho. Scrum espera
que as equipes faam o que for necessrio para entregar o produto desejado, dandolhes o poder para faz-lo. Prticas e ferramentas de desenvolvimento so atualizadas
constantemente e consistentemente e boas equipes trabalharo para tirar melhor
proveito delas.

Aplicabilidade
Embora seja verdade que o Scrum foi usado inicialmente para desenvolver produtos
de software, ele projetado para qualquer tipo de trabalho complexo. Hoje ele
usado para gerenciar desenvolvimento de software e hardware, publicidade e
marketing, igrejas e organizaes inteiras.

Como Scrum mapeado para os mtodos

tradicionais?
A resposta rpida que ele no mapeado. Mtodos geis e Scrum so baseados
em um paradigma diferente. Os fundadores Jeff Sutherland e Ken Schwaber tem
repetido em diversas ocasies que intil tentar mapear mtodos definidos com um
mtodo emprico.

Scrum ter sucesso em minha organizao?

Isso depende de voc! A implementao na sua organizao pode falhar por causa de
uma falta de determinao das pessoas para superar os problemas que Scrum
certamente ir expor. No entanto, milhares de equipes em todos os continentes e
em todos os setores esto conseguindo tornar o seu mundo de trabalho melhor
hoje do que era ontem.

Melhor Scrum 3

Manifesto gil
Em Fevereiro de 2001, dezessete especialistas em metodologias leves se
reuniram para discutir e tentar chegar a uma definio comum de trabalho. Entre eles
estavam Jeff Sutherland e Ken Schwaber, fundadores do Scrum, juntamente
com Mike Beedle que trabalhou no desenvolvimento dos padres iniciais e escreveu o
primeiro livro sobre Scrum. Este grupo chamava-se "A Aliana gil" (Agile Alliance) e
concordaram com um Manifesto para Desenvolvimento gil de Software. Eles
tambm definiram um conjunto de doze princpios por trs do manifesto que sero
reproduzidos na pgina seguinte.

Comentrio
O Manifesto gil e seus doze princpios permanecem intactos durante uma
dcada. Eles permanecem
at
hoje a
melhor
maneira
de julgar
se um
mtodo realmente funciona de forma gil ou no. A maior crtica tem sido a tendncia
para desenvolvimento de software, embora os mtodos geis possam ser mais
amplamente aplicados.

Nota
Scrum um dos sabores dos mtodos geis. A adeso ao Manifesto gil e todos os
seus princpios no significa necessariamente que uma equipe ou uma
organizao est praticando Scrum. No entanto, a no adeso a qualquer um destes
princpios implica que voc no est praticando Scrum (ou metodologia gil)!

Espao para anotaes

Melhor Scrum 4

Manifesto para Desenvolvimento gil de Software

Estamos descobrindo maneiras melhores de desenvolver software, tanto para nossa
prpria experincia como para ajudar os outros. Atravs deste trabalho,
chegamos aos seguintes valores:
- Indivduos e interaes so mais importantes que processos e ferramentas;
- Software funcionando mais importante que documentao extensa;
- Colaborao com o cliente mais importante que negociao de contrato;
- Responder s mudanas mais importante que seguir um plano.
Ou seja, enquanto no h valor nos itens direita, ns valorizamos mais os itens
esquerda.

Princpios por trs do Manifesto gil

1. Nossa maior prioridade satisfazer o cliente atravs da entrega antecipada e
contnua de software valioso.
2. Aceitamos que os requisitos mudem mesmo em estgios avanados de
desenvolvimento.
Processos
geis aproveitam a
mudana para
proporcionar vantagem competitiva ao cliente.
3. Entregar software funcionando freqentemente, a cada duas semanas ou a cada
dois meses, com preferncia para o prazo mais curto.
4. Os gerentes de negcios e desenvolvedores trabalham em conjunto diariamente
durante o projeto.
5. Os projetos so construdos em torno de indivduos motivados. D-lhes o
ambiente e apoio de que precisam, e confie neles para fazer o trabalho.
6. A maneira mais eficiente e eficaz de comunicar informaes para a equipe
de desenvolvimento atravs de conversa cara a cara.
7. O software em operao a medida primria do progresso do projeto.
8. Processos geis promovem o desenvolvimento sustentvel. Os patrocinadores,
desenvolvedores e usurios devem ser capazes de manter um ritmo constante por
tempo indeterminado.
9. Ateno contnua a excelncia tcnica e bom design aumentam a agilidade;
10. Simplicidade, ou a arte de maximizar a quantidade de trabalho no feito,
essencial.
11. As melhores arquiteturas, requisitos e projetos emergem de equipes autoorganizveis.
12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz, em
seguida, ajusta e melhora seu comportamento em conformidade.
Higsmith (2001)

Melhor Scrum 5

Os papis de Scrum
Introduo
No h papel de Gerente de Projetos em Scrum. As responsabilidades do gerente de
projeto tradicional so divididas ao longo dos trs papis na equipe Scrum:
O Product Owner que gerencia o produto (e o retorno sobre o investimento);
O ScrumMaster que gerencia os processos;
A equipe que gerencia a si mesma.
Este um desafio para os indivduos que atualmente cumprem esses papis e para os
gestores nas organizaes em que trabalham. Michele Sliger e Stacia Broderick
escreveram um guia til para a transio do Gerente de Projetos para o treinador de
metodologias geis [Sliger e Broderick 2008].
No h lderes designados em equipes Scrum alm do Product Owner e ScrumMaster,
e isso no necessrio. A necessidade de gestores de linha reduzida, porque as
equipes so
administradas numa
vasta
gama de funes.
No
raro
encontrar 50 membros de uma equipe que se reportam diretamente a um nico
gerente de linha em uma organizao que fez a transio para Scrum.

A auto-organizao
A auto-organizao no implica de forma alguma em uma abordagem laissez-faire (do
francs deixai fazer), ao contrrio, as equipes auto-organizadas so
altamente disciplinadas. Uma vez que elas tenham plena autonomia, esperamos que
tenham
mais responsabilidade para
cumprir
os
compromissos
que
assumiram. Elas so encorajadas a assumir riscos razoveis e de aprender atravs
de fracasso e auto-reflexo. Um alto grau de confiana e compromisso um
resultado automtico de equipes verdadeiramente auto-organizadas.
Novas equipes de Scrum vo exigir algum incentivo para explorar seus limites, e
super-los, respondendo aos desafios com maior responsabilidade. Elas
freqentemente precisam superar as armadilhas que muitas vezes impem as formas
antigas e improdutivas que fizeram em seu trabalho durante anos.
A auto-organizao no uma opo em Scrum, um princpio fundamental.Sem
isso, nunca teremos equipes de alta performance. Caveat emptor!

Melhor Scrum 6

Product Owner
As responsabilidades do papel do Product Owner so:
Trabalhar em uma viso compartilhada;
Coletar os requisitos;
Gesto e priorizao do Product Backlog;
Aceitar o software no final de cada iterao;
Gerenciar o plano de liberao de releases;
Gerenciar a rentabilidade do projeto (ROI);
Metfora: O Product Owner um CEO.

ScrumMaster
As responsabilidades do papel do ScrumMaster so:
Garantir um ambiente de trabalho protegido para a equipe, livre de
interferncias;
Remover impedimentos;
Manter o processo em movimento e incentivar o uso de Scrum;
Socializar Scrum para a maior parte da organizao;
Metfora: O ScrumMaster um facilitador, treinador e mentor!

Equipe Scrum (TIME)

As responsabilidades da funo de membro da equipe Scrum ou da equipe so:
Estimar o tamanho dos itens do backlog;
Comprometer-se com incrementos de software a ser entregue e entreg-los;
Acompanhar seu prprio progresso;
A auto-organizao, mas responsvel perante o Product Owner para a
entrega que foi comprometida.

Os membros da equipe podem ser desenvolvedores, testadores, analistas,

arquitetos, escritores, designers e at mesmo usurios. A equipe
multifuncional, o
que
significa
que
todos
os
seus
membros possuem habilidades suficientes para fazer todo o trabalho. No
h liderana definida previamente entre os membros da equipe.
A Equipe Scrum composta por todos os trs papis: um Product
Owner, um ScrumMaster e cinco a nove membros da equipe.

Melhor Scrum 7

As reunies do Sprint
O Sprint o corao do ciclo de Scrum. marcado pelo planejamento do Sprint no
incio e pela reviso do Sprint e retrospectiva do Sprint no final. O comprimento do
Sprint fixado e nunca estendido. A maioria das equipes escolhe duas, trs ou no
mximo quatro semanas como sendo a durao do Sprint. Durante o Sprint a
equipe realiza uma reunio diria. Cada reunio tem uma durao fixa de tempo. Isto
significa ter uma durao mxima para concluir a reunio e no significa que
necessrio ocupar todo o tempo fixado. Para um Sprint de 30 dias (ou quatro
semanas) geralmente so dedicados 2 perodos para reunio de planejamento, bem
como reviso e anlise retrospectiva com durao de cerca de quatro horas
cada. Para Sprints mais curtos devemos ajustar as propores de acordo com a
durao do Sprint.
Alguns dos principais atributos das vrias reunies so descritos nas sees
seguintes. Inicialmente compartilho com vocs algumas experincias pessoais que eu
acho que vale a pena contar.

Acho que duas semanas para cada Sprint um bom tempo para
comear. Depois de trs Sprints, deixe a equipe re-avaliar o tamanho do
Sprint.
As equipes precisam de trs Sprints para compreender os novos conceitos,
quebrar velhos hbitos e comear a agir como uma equipe.
Nunca faa planejamento de Sprints na manh de segunda-feira. A
equipe ainda no est na sua melhor forma e o dia mais comum para incio
de frias e eventuais doenas. Nunca faa qualquer reviso ou
retrospectiva na tarde de sexta-feira. A equipe est cansada e pensando
no fim de semana. Por isso, uma boa idia considerar o incio e
final de Sprints entre tera e quinta-feira.
As equipes que executam duas semanas de Sprints podem ser tentadas
a fazer as reunies no incio do Sprint em um dia. Em outras
palavras, comear o dia com a reviso, em seguida a retrospectiva, depois
do almoo fazer a primeira e segunda partes do planejamento. O
pensamento fazer com que todas as reunies terminem o mais rpido
possvel de modo que a equipe tenha 9 dias inteiros para fazer o trabalho. Na
minha experincia, h dois problemas com essa abordagem:
A equipe no acredita que estas reunies fazem parte do trabalho e de
fato
so a parte mais importante para o sucesso no restante do Sprint!
Durante ltima parte do dia de planejamento o time est mentalmente
exausto.

No entanto, como sempre, deixe a equipe experimentar esse modelo se

assim o desejarem!

Melhor Scrum 8

Sprint Planning - Parte 1

A primeira parte do planejamento do Sprint (PS1) realmente um workshop para
detalhar os requisitos. O Product Owner apresenta o conjunto de requisitos que
quer que sejam implementados e a equipe faz perguntas necessrias para
entender os requisitos em detalhes suficientes para entender o esforo necessrio
para entregar essas funcionalidades no final do Sprint.
A equipe decide o que pode entregar no Sprint, tendo em conta a durao Sprint, o
tamanho da equipe e as habilidades atuais de seus membros, a sua definio de
pronto, todos os feriados conhecidos ou dias de frias e quaisquer aes ou
compromissos assumidos durante a retrospectiva realizada pouco antes desta
reunio.
O Product Owner deve estar presente durante esta reunio para orientar a equipe na
direo correta e para responder s perguntas que normalmente so
muitas. O ScrumMaster deve
assegurar
que
quaisquer outras
partes
interessadas necessrias para ajudar a equipe a entender os requisitos est
presente ou de planto.
Todos os novos itens do backlog sero desenvolvidos durante o Sprint atual e o que
no estava estimado anteriormente ser dimensionado imediatamente durante esta
reunio. Esta, porm, no pode ser uma desculpa para evitar preparao do backlog veja abaixo!
No final do SP1 a equipe se compromete com o Product Owner o que eles acreditam
que pode entregar testado e funcionando. Uma equipe experiente pode usar seu
histrico de velocidade para prever o que conseguir entregar ('tempo passado'). Isto
conhecido como taxa baseada em planejamento. Minha recomendao para a
maioria das equipes fazer compromissos baseados em planejamento.
O conjunto de itens do backlog que foram confirmados pela equipe deve ser chamado
de Product Backlog selecionado.

Sprint Planning - Parte 2

Se a primeira parte do planejamento do Sprint um workshop de requisitos, a
segunda parte do planejamento do Sprint (SP2) um workshop de desenho.
Nesta reunio a equipe colabora para criar um desenho de alto nvel dos recursos que
se comprometeu a entregar. Um resultado desta reunio o Sprint backlog, ou lista de
tarefas que a equipe precisa executar coletivamente afim de entregar funcionalidades
testadas e funcionando. Este conjunto de tarefas chamado de Sprint backlog e
mais freqentemente representado por uma lista de tarefas.
Durante o SP2 a equipe pode ter dvidas adicionais sobre os requisitos. O
ScrumMaster deve garantir que o Product Owner e, se necessrio, outras partes
interessadas estejam de planto para respond-las.
O desenho, como todo o resto no desenvolvimento, emergente. Alm disso, a
reunio tem um tempo pr-estabelecido. Por isso, normal a equipe no ter o
desenho perfeitamente concludo nesta reunio e descobrir mais tarefas durante
o Sprint. Este no um sinal de que algo est errado. Eles devem simplesmente
pegar um post-it e uma caneta e criar mais tarefas sempre que necessrio durante
o Sprint.

Melhor Scrum 9

Voc saber que o SP2 est sendo executado quando a equipe se rene
em torno do quadro branco discutindo sobre a "melhor" maneira ou sobre a
maneira "certa" para implementar um recurso.

Reunio Diria do Scrum

A reunio diria do Scrum um dos trs principais pontos de inspeo e adaptao no
Scrum. A equipe se rene para se comunicar e sincronizar seus trabalhos. Uma vez
que a equipe est colaborando, isto essencial para garantir o progresso contnuo e
evitar bloqueios de trabalho. A equipe tambm ir avaliar continuamente o seu prprio
progresso no sentido de atingir sua meta no Sprint.
A
reunio diria
do
Scrum
no para
relatar
o
progresso para o
ScrumMaster ou Product Owner ou qualquer outra pessoa interessada. O Product
Owner pode participar desde que ele permanea em posio passiva, falando apenas
quando for questionado! O ScrumMaster deve garantir, usando todas as suas
habilidades de facilitador, que cada membro da equipe se comprometeu a fazer algum
trabalho para as prximas 24horas, que este tem como nico propsito ajudar a
equipe como um todo a entregar o item seguinte na lista de pendncias e que os
eventuais impedimentos para fazer este trabalho sero removidos para fora do
caminho o mais rpido possvel.
O ScrumMaster tambm deve garantir que a reunio seja restrita a 15 minutos, o que,
surpreendentemente, tempo suficiente.
Surpreendentemente reunies podem ser eficazes durante esse perodo curto de
tempo.
Jason Yip [Yip 2006] fornece um guia til para auxiliar o ScrumMasters na realizao
desta reunio.

Reviso do Sprint
A reviso do Sprint (Sprint Review) muitas vezes erroneamente denominado de
demo.Embora essa reunio inclua uma demonstrao das novas funcionalidades que
a equipe concluiu durante o Sprint, seu principal objetivo inspecionar o que a equipe
entregou e obter feedback dos participantes para adaptar o plano para o prximo
Sprint. Assim o Sprint Review muito mais do que uma demonstrao.
O foco da reviso do Sprint o produto que a equipe est construindo.
Quando perguntado sobre quem deve ser convidado para a reviso de Sprint, eu
respondo "o mundo inteiro". Minha inteno aqui ajudar o ScrumMaster e toda a
organizao a entender que a ateno direta e feedback de um eleitorado mais
amplo da organizao fundamental para maximizar o valor que a equipe vai
entregar em sucessivos Sprints. Revises do Sprint tem muitos resultados possveis,
incluindo o cancelamento do projeto. Na maioria dos casos, a equipe est autorizada
a continuar por mais um Sprint e uma meta para este prximo Sprint deve ser definida.

Espao para anotaes

Melhor Scrum 10

Retrospectiva do Sprint
A retrospectiva do Sprint a reunio final do Sprint. Segue-se imediatamente aps
a reviso do Sprint. Nunca devemos omiti-la! Considerando que a reviso do Sprint
focada no produto, a retrospectiva focada no processo e na forma em que a
equipe Scrum est trabalhando em conjunto, incluindo as suas habilidades tcnicas e
as
prticas de
desenvolvimento
de
software e
ferramentas que
esto
usando. Considerando que a reviso do Sprint aberta a todos, a retrospectiva do
Sprint restrita aos membros da equipe Scrum, que so o Product Owner,
os membros da equipe de desenvolvimento e o ScrumMaster. Pessoas externas
equipe, incluindo gerentes de todos os nveis da organizao so rigorosamente
excludos a no ser que sejam especificamente convidados pela equipe.
Esta regra deve ser entendida no contexto do objetivo da reunio, que
inspecionar em um nvel profundo como a equipe est colaborando e tomar
decises para melhorar. Isso muitas vezes exige introspeco profunda e
compartilhamento, que por sua vez requer um ambiente seguro. Em A diretiva bsica
da
Retrospectiva
(Retrospective
Prime
Directive)
Norman Kerth
ressalta o seguinte: "No importa em que evolumos, entendemos e acreditamos
que cada um fazia o melhor que podia, dado o que sabia na poca, suas habilidades,
recursos disponveis e a situao em que estavam." [Kerth 2001].
Boris Gloger [Gloger 2008] fornece um
padro
muito simples
chamado
Retrospectivas de Pulsao (Heartbeat Retrospectives) para que novas equipes
possam
aprender
rapidamente a
conduzir reunies
de
retrospectivas. Esther Derby e Diana Larsen [Derby e Larsen 2006] fornecem muitas
atividades para facilitadores usarem durante essa reunio.

Reunio de Estimativas.
Esta reunio no mencionada na literatura Scrum, mas essencial se voc quer
conseguir um fluxo contnuo dos recursos mais valiosos feitos a partir de suas
equipes.
Durante cada Sprint o Product Owner organiza uma ou duas reunies onde
devem participar a equipe e, se necessrio, outras pessoas interessadas. Nesta
reunio deve-se estimar o impacto de novos itens do backlog ou recalcular o tamanho
de itens grandes que devem ser divididos em vrios itens pequenos, de forma tal que
possam ser desenvolvidos no prximo Sprint.

As equipes precisam dedicar de 5 a 10% de seu tempo durante o Sprint

preparao para o prximo Sprint e subseqentes. A reunio de
estimativas descrita acima um bom exemplo. Outros exemplos so as
reunies de planejamento sobre como escrever histrias de usurios.
Isso importante para evitar uma paralisao no limite (fim e incio) de
cada Sprint. A outra implicao, claro que as equipes devem gastar de
90 a 95% de seu tempo fazendo o trabalho do Sprint atual!

Melhor Scrum 11

Artefatos Scrum
Scrum define apenas quatro artefatos:
Product Backlog;
Sprint Backlog;
Grfico Burndown;
Backlog de Impedimento;
Scrum propositadamente no menciona nenhum outro documento e / ou artefato. Isso
s vezes leva ao mal-entendido de que as equipes geis no precisam fazer qualquer
documentao. Devemos treinar equipes para produzir apenas os artefatos que so
realmente valiosos para si e para outros no futuro. Isso reduz o trabalho intil e a
desnecessria matana de florestas!

Product Backlog
O product backlog simplesmente uma lista de itens de trabalho que precisa ser
produzida ao longo do tempo. Os itens podem ser adicionados por qualquer
pessoa, mas apenas o Product Owner tem o direito para determinar a ordem na
qual eles vo ser executados pela equipe. Claro que um Product Owner bom vai
negociar isso com as partes interessadas e com a equipe.
Os requisitos esto emergindo, o que significa que no sabemos ou no podemos
saber de antemo todos os itens e cada uma das caractersticas que queremos no
produto final. por isso que o Product Backlog um documento vivo que exige a
reviso constante para mant-lo atualizado e til ao longo do tempo. Muitos novos
itens sero adicionados ao longo do tempo, itens existentes sero divididos em vrios
itens menores, alguns itens sero removidos a partir da constatao de que no so
mais necessrios. Alm disso, os itens devem ser estimados para determinar o custobenefcio de cada um, que influenciam diretamente na prioridade que cada um ter e
seus impactos em caso de atraso.
Em praticamente todos os casos suficiente, e geralmente prefervel, criar e manter
um Product Backlog num conjunto de histrias de usurios escritas em cartes de 150
x 100 mm. Ron Jeffries [Jeffries 2005] cunhou a aliterao Carto, Confirmao,
Conversao (Card, Confirmation, Conversation, - os 3 Cs) para descrever como eles
devem trabalhar com as histrias de usurios. As histrias so geralmente escritas a
partir da perspectiva de um usurio do produto. O livro de Mike Cohn sobre histrias
de usurios [Cohn 2004] vai dizer tudo o que voc precisa saber sobre elas.

Sprint Backlog
A maioria das equipes vai conhecer o Sprint Backlog como o quadro de tarefas, que
a representao fsica da lista de trabalho que se comprometeram a fazer durante
o Sprint atual.
O quadro de tarefas um exemplo de um Kanban, palavra japonesa que significa
sinalizao visvel. Ele comunica a equipe e qualquer outra pessoa que quiser saber
das tarefas planejadas para o Sprint e seu status atual.

Melhor Scrum 12

Sprint Burndown Chart

O grfico de Sprint Burndown projetado para ajudar a equipe a monitorar seu
progresso e ser um indicador importante para saber se eles vo cumprir o seu
compromisso no final do Sprint. O formato clssico exige que a equipe estime a
durao de cada tarefa em horas e em uma base diria para traar o total de
horas restantes para todas as tarefas no concludas.
Recomendo que as equipes construam em seu Sprint um grfico que demonstra
os pontos da histria que devem ser realizados durante o Sprint atual. A lgica por trs
disso :
A estimativa de novas tarefas e re-estimativa de tarefas que esto
em curso e que exigem um esforo considervel;
As estimativas so imprecisas;
A estimativa em unidades de tempo nos faz lembrar dos velhos hbitos de
trabalho;
A concluso das tarefas no entrega qualquer valor, apenas histrias
concludas entregam valor;
Portanto, em meu trabalho como consultor o Burndown Chart semelhante ao
release ou produto, exceto pelo fato que o eixo X representa dias em vez de Sprints.

Melhor Scrum 13

Produto ou Release Burndown Chart

O grfico Burndown do produto, s vezes conhecido como o grfico Burndown de
release, mede a taxa de entrega de funcionalidades, testadas ao longo do tempo. Esta
taxa conhecida como a velocidade da equipe.
Uma vez que as funes variam em complexidade e, portanto, em tempo e esforo,
usamos uma escala para comparar tamanho. A escala mais comum conhecida
como pontos de histrias de usurios. Uma vez que uma equipe tem trabalhado junto
por alguns poucos Sprints, geralmente estabelece a sua velocidade dentro de um
intervalo definido. Os Product Owners utilizam essa velocidade para prever a taxa
que a equipe ir fornecer recursos no futuro, que conduz planos de liberao de
produto e / ou release mais previsveis.
Aconselhamos que a equipe use uma forma alternativa do grfico Burndown do
produto que permita simultaneamente que os Product Owners controlem as
alteraes do Product Backlog. Isto essencial dada a natureza dinmica desta lista.
Usando esses grficos os Product Owners so capazes de relatar o progresso,
identificar as datas de lanamento do produto e prever a extenso dos mesmos.

Backlog de Impedimentos
O backlog de impedimentos simplesmente uma lista de situaes que esto
impedindo a equipe de progredir. Estas so situaes que o ScrumMaster deve
colocar fora do caminho em sua busca incessante para ajudar a equipe a funcionar
melhor. A gama de obstculos varia de precisar consertar a mquina de caf at ter
que substituir o CEO! Um bom ScrumMaster tentar remover os impedimentos dentro
de 24 horas desde sua identificao (OK, talvez substituir o CEO no se aplique!)

Melhor Scrum 14

Iniciando Scrum
Ken Schwaber [Schwaber 2007] disse certa vez que no h nada que precise ser
feito antes de comear a usar Scrum. Interpretamos isso para dizer que no h
adaptao do processo necessrio para iniciar. No entanto, praticamente nenhuma
literatura auxilia nossa equipe Scrum a alcanar os primeiros sucessos sem ajuda
externa.
A melhor coisa que voc pode fazer contratar um treinador (coach) experiente. Se
isso no for possvel, voc pode tentar usar um padro que j funciona com dezenas
de equipes.
Obviamente (eu espero) voc precisa de uma equipe Scrum. Isso significa ter
um Product Owner, um ScrumMaster e de cinco a nove membros da equipe. Em
seguida, siga essa seqncia de etapas, que sero detalhados nas prximas pginas.
1. Treinar a equipe Scrum nos princpios do Scrum;
2. Estabelecer a viso;
3. Escrever histrias de usurio para formar o product backlog;
4. Ordenar os itens do backlog por valor de negcio;
5. Estimar o tamanho dos itens do backlog;
6. Reordenar o backlog, se necessrio, com base em fatores adicionais;
7. Criar o plano de release inicial;
8. Planejar o primeiro Sprint;
9. Comear os Sprints!

Comeo o meu trabalho com uma nova equipe, com um treinamento de um

dia sobre os fundamentos que eles precisam saber sobre metodologias
geis e Scrum. Isto o suficiente para iniciar uma equipe Scrum que tenha
um experiente ScrumMaster para apoi-la durante os primeiros Sprints.
Os passos 2 a 7 podem ser definidos confortavelmente durante uma reunio
de definio do produto que precisa contar com a equipe Scrum inteira. As
melhores reunies so aquelas em que participam as partes interessadas,
como arquitetos corporativos, gerentes de negcios e demais interessados
no projeto.

Melhor Scrum 15

Treinamento
No treinamento da minha equipe eu uso um monte de exerccios em grupo e
jogos para ilustrar os princpios.
Tento cobrir a totalidade ou a maioria dos seguintes tpicos:
O poder da auto-organizao;
Processos empricos contra processos formalmente definidos;
O valor do trabalho no mesmo espao fsico;
A importncia da confiana;
Princpios geis (Manifesto gil);
O fluxo do Scrum (ciclo de reunies);
Funes e responsabilidades (3 principais papis do Scrum);
Usando histrias de usurios para os requisitos;
Estimativas usando Agile Planning Poker;
Conceitos de tamanho e velocidade;
Conceito de Pronto!
Usando um painel de tarefas;
Acompanhamento dos progressos (grficos de burndown);
Simulao de um Sprint inteiro.

Definindo a viso
Katzenberg e Smith [2002] confirmaram que ter objetivos claros essencial para
moldar equipes de alta performance.
O Product Owner geralmente ir partilhar a sua viso do produto. Uma tcnica que
uso pedir a cada membro da equipe para escrever a sua verso da viso. Ento
fazemos uma formao em pares e pedimos para chegar a uma viso que combina
para ambos. O processo continua com dois pares de trabalho da mesma maneira
e assim, at que a equipe completa conclui com uma viso nica.
Este exerccio usa o poder do grupo em conjunto, resultando em maior
compromisso com a viso obtida. A equipe deve apresentar a viso de modo
proeminente em seu ambiente de trabalho. O exerccio de definio da viso pode
ocupar cerca de trs horas.

Criando o Product Backlog

A prxima etapa a realizao de uma reunio para escrever histrias de usurios.
vantajoso envolver partes interessadas no negcio nessa reunio. Certamente toda a
equipe Scrum dever ser envolvida. Claro, o ScrumMaster ser o facilitador.
Escrever boas histrias de usurios simplesmente uma questo de prtica. O
princpio de Pareto (regra 80/20) tambm se aplica nessa etapa, assim como se aplica
em diversos outros casos.

Melhor Scrum 16

Mike Cohn [Cohn 2004] tem

proporcionado um
excelente
guia para escrever
histrias de usurio. Eu encorajo todos os Product Owners a terem uma cpia desse
exemplar sempre mo!
Template: Em um determinado papel, eu quero funcionalidade por uma razo.
Exemplo: Como um programador, eu quero caf para ficar acordado.

Bill Wake [Wake 2003] sugere a utilizao do acrnimo INVEST para lembrar os
atributos que uma boa histria de usurio deve ter.
Independent Independente pode ser implementada em qualquer ordem;
Negotiable Negocivel ou no negocivel;
Valuable Valiosa para o cliente;
Estimatable Suficientemente estimvel para classificar e agendar;
Small Pequeno e com breves descries;
Testable Testvel eu poderia escrever um teste para essa funcionalidade.
No mnimo, o backlog deve conter elementos suficientes para a equipe planejar o
primeiro Sprint. Comumente, o backlog contm todos os itens que compem o prximo
release do produto.
Como referncia, o backlog deve conter 80% de tarefas que possam ser concludas
at o final do primeiro dia. A primeira parte do dia dois pode ser usada para adicionar
os 20% restante e para resolver quaisquer questes pendentes. A pausa durante os
dois dias muito importante, pois pode desencadear uma nova reflexo sobre o
trabalho e gerar novas idias.

Ordenando o backlog
O backlog deve ser classificado por valor de negcio. Isto muito mais fcil de falar do
que fazer. Mike Cohn [Cohn 2006] descreve dois mtodos para priorizar: o modelo
Kano de satisfao do cliente e a abordagem Wiegers de ponderao relativa. O que
eu gosto sobre estes dois mtodos que no s consideram o benefcio esperado
para ter a funcionalidade, mas tambm leva em conta a penalizao por no ter tal
funcionalidade. Isto particularmente til quando o backlog contm itens tcnicos,
cujo valor do negcio no imediatamente bvio.
No mnimo precisamos do julgamento subjetivo do Product Owner para avaliar uma
funcionalidade em detrimento de outra. prefervel uma abordagem quantitativa
utilizando uma tcnica semelhante ao Planning Poker.
No importa como ser executada a ordenao do backlog uma das principais
responsabilidades do Product Owner.

Melhor Scrum 17

Estimando o Backlog
A estimativa tem sido sempre a chave para a conduo eficaz do planejamento de
projetos. Gerentes de projeto passam semanas avaliando modelos complexos com
dados histricos.
A dura realidade que o melhor dessas tcnicas no proporciona melhores
resultados que tcnicas muito simples, como o Planning Poker ou estimativa
por afinidade. O Planning Poker funciona em parte porque est embasado em uma
slida teoria, mas principalmente porque as pessoas que fazem as estimativas so as
mesmas que realizam o trabalho. Quem teria pensado nisso? O Planning Poker
rpido. Uma equipe com experincia estima em mdia um item a cada 3 minutos. O
Planning
Poker
preciso. As
estimativas
obtidas
usando
Planning Poker so to boas quanto s obtidas com mtodos tradicionais. E,
sobretudo,
o Planning
Poker
divertido. Remove parte
do tdio associado
esta fase.
A estimativa por afinidade ainda mais rpida do que o Planning Poker. tima para
comear quando temos um backlog grande e o tempo mais importante do que a
preciso e compartilhamento de informaes.
No entanto, ainda precisamos entender alguns conceitos-chave sobre estimativa gil:
Ns dimensionamos os itens do backlog atravs de comparao com outros
itens. Por qu? Porque, como seres humanos encontramos resultados
mais naturais e mais confiveis nas comparaes. Portanto, fcil concordar
que "uma determinada histria de usurio o dobro da complexidade de outra
histria" mesmo que ainda no saiba quanto tempo cada histria vai usar para
ser implementada.
Ns dimensionamos
os itens
do
backlog
usando unidades de
complexidade ao invs de tempo. Por qu? Porque permite separar a taxa
que uma equipe trabalha a partir do tamanho ou complexidade do
trabalho. Isso nos protege de ter que mudar nossas estimativas de acordo com
quem faz o trabalho, ou de acordo com as habilidades e capacidades de
mudana da equipe ao longo do tempo. Usamos pontos da histria de usurio
como unidades de medida.
Usamos uma escala no-linear para calibrar que a diferena entre um '1'
e um
'2'
,
obviamente, mais
significativa relativamente, do
que
entre '20' e '21'. Minha preferncia usar os nmeros pseudo-Fibonacci: 1, 2,
3, 5, 8, 13, 20, 40 e 100. E definindo de 1 a 13 como o intervalo de tamanho de
caractersticas que uma equipe pode entregar em um Sprint. Os nmeros mais
elevados so reservados para grandes histrias (picos) que precisaro ser
divididas em histrias menores antes que elas possam ser adotadas em
um Sprint.
Relatamos nossas estimativas de tamanho de tempo por meio de velocidade,
que a taxa na qual uma equipe pode entregar funcionalidades testadas ao
Product Owner. Dizemos que uma equipe tem uma velocidade de '25',
quando eles so capazes de entregar no final de cada Sprint histrias cujos
tamanhos, em mdia, somam 25 pontos.
No uma boa idia comparar as estimativas entre equipes, a menos que
estejam trabalhando
no
mesmo
backlog. Esta

uma
questo de escala Scrum e facilmente resolvida, mas no um tpico
para este pequeno guia.

Melhor Scrum 18

Reordenando o Backlog
Aps o dimensionamento dos itens do backlog podemos descobrir que alguns itens
devem ser reordenados. Devemos levar em conta, alm do valor de negcio, os
seguintes fatores:
Tamanho: naturalmente vamos optar por implementar uma histria pequena e
simples frente uma histria grande e complexa, se eles tm valor de
negcio similar;
Aprendizagem: podemos optar por implementar uma histria mais cedo
que ajudar a equipe a aprender sobre o domnio do negcio ou uma nova
tecnologia;
Risco: podemos optar por implementar uma histria no incio, porque isso vai
mitigar um risco identificado. Os exemplos mais bvios so os itens
que ajudaro a estabelecer limites de desempenho e escalabilidade.
Devemos sempre lembrar
ordenao do backlog.

que o

Product

Owner tem palavra

final sobre

Release Planning
Uma vez que tenhamos ordenado e avaliado o backlog, o prximo passo criar o
plano inicial de liberao (Release Planning). Para fazer isso precisamos de uma
estimativa da velocidade de nossa equipe. No entanto, como ainda no fizemos
nenhum trabalho nesse momento, usamos uma tcnica simples, conhecida como
planejamento baseado em compromisso.
Primeiro, claro, devemos ter a certeza de saber o tamanho da equipe durante
o Sprint e se qualquer membro da equipe ser afastado por licena, etc. Temos que
definir o tamanho do Sprint. Geralmente recomendo que seja de duas semanas para
uma nova equipe. Temos, ento, que criar uma definio de pronto para a equipe - o
que d a equipe a noo de dizer que completou uma histria.
O ScrumMaster agora pega o primeiro item a partir do topo do backlog e questiona
equipe: "vocs podem completar este item durante o Sprint?. Ele continua fazendo
isso at que a equipe decide no adicionar mais itens ao Sprint. Contando os pontos
de histria de todos os itens comprometidos, a equipe tem a sua estimativa inicial de
velocidade.
Este valor de velocidade utilizado para distribuir os itens restantes do backlog ao
longo de sucessivos Sprints. Esta lista de itens ligados Sprints o nosso Release
Planning inicial. Ele exato? Talvez no, mas provavelmente mais aceitvel que
qualquer coisa que um gerente de projetos possa produzir em um estgio inicial de um
projeto. Uma vez que comeamos a trabalhar e completar um Sprint atrs do
outro, vamos comear a traar a nossa velocidade atual e usar isto como um indicador
de produo futura. Assim, o plano de lanamento (Release Planning) uma entidade
viva que se torna mais e mais confivel medida que progredimos.

No deixe que o release planning seja desnecessariamente longo.

possvel preparar um backlog suficiente para o primeiro sprint em apenas
dois dias para quase qualquer combinao de equipe e produto.

Melhor Scrum 19

Localizao fsica de equipes Scrum

Alistair Cockburn [Cockburn 2007] define o desenvolvimento de software como um
jogo de inveno, cooperao e comunicao. O manifesto gil diz que os
desenvolvedores e representantes das empresas devem trabalhar juntos em uma
base diria e que conversas frente a frente so a melhor forma de transferir
informaes.
Sem dvida o mais importante para uma equipe colaborar de forma eficaz o
compartilhamento no mesmo espao fsico. Um estudo sobre as equipes de
desenvolvimento de software com equipes que compartilham o mesmo espao
fsico [Teasley, Covi, Krishnan, & Olson, 2000] mostraram que elas tinham duas vezes
mais produtividade que outras equipes onde os membros foram separados uns dos
outros.
A definio que eu uso para "compartilhar o mesmo espao fsico" que os membros
da equipe estejam sentados no mximo num raio de 6 metros de distncia. Essa
definio resulta na existncia de um limite para o nmero de pessoas que
podem se acomodar em tal espao. Na prtica, este nmero de 8 a 10 pessoas, que
felizmente corresponde ao tamanho mximo de uma equipe Scrum.
Alm disso, cada membro da equipe deve ser capaz de ver todos os outros
membros com o simples gesto de virar a cabea ou virar sua cadeira giratria para o
lado. Isto significa que no devem haver divisrias entre as mesas - Adeus Dilbertville!
Sem nenhuma boa razo alm do hbito, as organizaes dificilmente so
relutantes em mudar o ambiente de trabalho para facilitar essa colaborao. Isto , h
evidncias que mostram que os espaos das equipes no necessitam ser ampliados,
podendo manter os layouts atuais.
Qualquer proposta para uma reestruturao do espao fsico pode ser criticada pela
administrao como uma ameaa a flexibilidade. Isto no necessariamente a
verdade, pois a flexibilidade necessria na estrutura organizacional, e no
no escritrio!
Minha experincia que 90% das novas equipes de Scrum em organizaes que se
esforam para praticar metodologias geis tem reas de trabalho simplistas e que
esto se esforando para no horizonte de um ano realizar as mudanas necessrias
para desenvolver um ambiente ldico. E uma vez que essas mudanas so feitas,
todos concordam que converge para melhoria imediata e mensurvel. Por que isso
ocorre?
com a esperana de que esta resistncia absurda diminua com o tempo que
ofereo aqui um esquema simples de trabalho para uma equipe Scrum. Esse esquema
vai alm do escopo deste pequeno guia e para fornecer todo o raciocnio por trs
deste projeto, voc ter que contratar-me!
Salas
de
equipes reduzem
significativamente a
necessidade
de usar salas de reunies para fazer o Sprint Planning, reunies dirias e
revises em seu escritrio.
Saiba de antemo que o designer ou arquiteto que trabalha para a sua
empresa no vai ser de grande ajuda. Normalmente ele no estudou para
criar espaos para o trabalho em equipe.
O custo das mudanas ser recuperado no prazo de uma semana a
um ms! Parece inacreditvel, no ?

Melhor Scrum 20

Alguns parmetros de montagem da sala:

As mesas devem ser retangulares para facilitar o trabalho em pares;
Mesas de 1,5-1,8 m x 0,8 m so mesas de bom tamanho;
Entre uma mesa e uma parede recomendo 1,2 m de espao;
O canto de desenho deve medir cerca de 3 x 3 m;
O tamanho tpico da sala deve ter 7 x 8 m = 50 a 60 m;
O ScrumMaster deve ver toda equipe;
O Product Owner tem um local no permanente;
As paredes com janelas internas criam barreiras de rudo e do espao
suficiente para radiadores de informao sem reduzir a luz;

Melhor Scrum 21

Mtricas
razovel esperar de qualquer gestor que ele queira, dentro de um perodo
razovel, algumas medidas para ser capaz de aferir os resultados de uma equipe ou
da transio da organizao para metodologias geis.
Felizmente, existem mtricas que so fceis e rpidas de implementar. Baseado em
minha prpria pesquisa e de outros profissionais geis, eu descrevi um conjunto de
mtricas que sua equipe pode e deve implementar [Hundermark 2009]. Logo que
a equipe entende o bsico do Scrum e tem alguma idia de sua velocidade
- provavelmente no final do seu terceiro Sprint ser o momento para iniciar a
medio. Na verdade, voc pode executar pesquisas de satisfao com
clientes e equipes antes mesmo de comear com Scrum!
Sem mais explicaes aqui, o conjunto de mtricas que eu recomendo para uma
implementao inicial :
Pesquisas com clientes e equipes;
Grfico de velocidade;
Grfico Burndown;
A execuo de testes automatizados;
Dvida Tcnica;
Trabalho em processo;
Tempo mdio do ciclo de concluso de histrias de usurios;
E uma vez que a equipe foi capaz de colocar em algum tipo de medida para o valor do
negcio, adicione o seguinte:
Custo por Sprint ou pontos da histria;
Valor real entregue;
ROI Retorno sobre Investimento ou NPV Valor Presente Lquido (Net
Present Value).

Espao para anotaes

Melhor Scrum 22

Coaching
O que faz um treinador (coach)?
Coaching Scrum definido como um compromisso com uma ou mais
organizaes / equipes durante o qual o coach (treinador) atua como um
mentor ou facilitador para as equipes melhorarem sua compreenso e
aplicao de Scrum para chegar aos seus objetivos. O trabalho de orientao
(mentoring) inclui indivduos e
equipes, facilitao do processo de
desenvolvimento, facilitao organizacional, alinhamento e interao com todos
os nveis de liderana dentro de uma organizao. Pode tambm
incluir orientao em mtodos relacionados com a eficcia do Scrum, os
princpios descritos no Manifesto gil, os princpios Lean, e prticas de
Extreme Programming.
Certified Scrum Coach Application, Scrum Alliance
Um treinador (coach) orienta indivduos dentro de uma organizao das seguintes
maneiras:
Conselho e consultoria para melhorar e acelerar o processo de autodescoberta;
Facilitar a adoo, implementao e aprendizagem Scrum;
Liderana gil com base em um estilo de liderana servidora;
Desenvolvimento organizacional para melhorar as habilidades, recursos e
criatividade.

Por que minha organizao precisa de coaching?

Desenvolvimento de software e outros tipos de trabalhos realizados por trabalhadores
do conhecimento se baseia no conhecimento tcito, em oposio com o
conhecimento formal ou explcito. O conhecimento tcito difcil de se transmitir
de pessoa para pessoa e geralmente obtido atravs da experincia pessoal. Um
exemplo poderia ser o de aprender a andar de bicicleta.
O papel do ScrumMaster deve conduzir a adoo e definio do processo, tanto para
a equipe Scrum como para o restante da organizao. Formaes tericas, como por
exemplo
curso para
Certificao
ScrumMaster, um meio insuficiente
para
para
adquirir
o conhecimento
tcito necessrio
para utilizar
eficazmente
metodologias geis e Scrum na prtica. A equipe e a organizao precisam das
habilidades de um profissional experiente, para gui-los atravs do labirinto de
desafios que enfrentaro durante a transio para uma forma mais gil de trabalhar.
A resposta mais freqente quando perguntamos aos gestores das organizaes o que
fariam para terem uma transio mais eficaz para metodologias geis e Scrum
"Faramos mais Coaching.

Melhor Scrum 23

Referncias
1. Cockburn, Alistair (2007). Agile Software Development: The Cooperative Game
(2nd edition). Addison Wesley
2. Cohn, Mike (2004). User Stories Applied. Addison Wesley.
3. Cohn, Mike (2006). Agile Estimating and Planning. Prentice Hall.
4. Gloger, Boris (2008). Heartbeat Retrospectives. http://borisgloger.com/
2008/04/24/heart-beat-retrospectives-1-introduction/.
5. Highsmith, Jim, et al (2001). Manifesto for Agile Software Development. http://
www.agilemanifesto.org/.
6. Hundermark, Peter (2009). Measuring for Results. http://www.scrumsense.com/
coaching/measuring-for-results.
7. Jeffries, Ron (2001). Card, Conversation, Conrmation. http://
www.xprogramming.com/xpmag/expCardConversationConrmation.
8. Katzenberg, Jon R. And Smith, Douglas K. (2002). The Wisdom of Teams. Collins.
9. Nonaka, Ikujiro and Takeuchi, Hirotaka (1986). The New, New Product
Development Game. Harvard Business Review, Jan-Feb 1986.
10. Sliger, Michele and Broderick, Stacia (2008). The Software Project Managers
Bridge to Agility. Addison Wesley.
11. Schwaber, Ken (2007). The Enterprise and Scrum. Microsoft Press.
12. Schwaber, Ken (2009). Scrum Guide. http://www.scrumalliance.com/resources].
13. Teasley, Covi, Krishnan, & Olson (2000). How Does Radical Collocation Help a
Team Succeed? Proceedings of the 2000 ACM Conference on Computer
Supported Cooperative Work (pp. 339 - 346). New York: ACM.
14. Wake, William (2003). INVEST in Good Stories, and SMART Tasks. http://
xp123.com/xplor/xp0308/index.shtml
15. Yip, Jason (2006). It's Not Just Standing Up: Patterns of Daily Stand-up Meetings.
http://martinfowler.com/articles/itsNotJustStandingUp.html.

Melhor Scrum 24