Scrume XP

FREE ONLINE EDITION
(non-printable free online version)
Trazido para voc como

Cortesia de
Este livro distribudo gratuitamente no portal

InfoQ.com. Se voc recebeu este livro de
qualquer outra fonte, por favor, suporte o autor e
o editor cadastrando-se em InfoQ.com.
Visite a pgina deste livro em:

http://infoq.com/br/minibooks/scrum-xp-fromthe-trenches
Scrum e XP direto das

Trincheiras
Como fazemos Scrum
Escrito Por:
Henrik Kniberg
2007 C4Media Inc

All rights reserved.
C4Media, Publisher of InfoQ.com.
Este livro parte da srie InfoQ de livros sobre Desenvolvimento
de Software Corporativo.
Para informaes sobre compra desse ou outros livros InfoQ, entre
em contato com books@c4media.com.
Nenhuma parte dessa publicao pode ser reproduzida, gravada
em um sistema de busca e recuperao de dados ou transmitida
sob qualquer forma ou por quaisquer meios, eletrnicos,
mecnicos, fotocopiado, gravado, escaneado ou qualquer outro,
sem prvia permisso do Publicador, exceto se autorizado pelas
Sees 107 ou 108 da Lei de Copyright dos Estados Unidos de
1976.
Designaes usadas por companhias para distinguir seus produtos
so frequentemente conhecidas como marcas registradas. Em
todos os locais onde a C4Media Inc. tem conhecimento desse fato,
os nomes dos produtos aparecem com a letra inicial Maiscula ou
TODAS AS LETRAS MAISCULAS. Os leitores, entretanto,
devem contactar as respectivas empresas para informaes mais
completas sobre suas marcas registradas.
Editor: Diana Plesa / Felipe Rodrigues
Tradutores: Vrios voluntrios gerenciados pela SEA Tecnologia
Dados de Publicao-em-Catlogo da Biblioteca do Congresso
Norte-Americano:
ISBN: 978-1-4303-2264-1
Dedicatria
O primeiro rascunho desse livro demorou apenas um final de semana para
ser digitado, mas com certeza foi um final de semana intenso! Fator de
foco de 150% :o)
Obrigado minha esposa Sophia e aos meus filhos Dave e Jenny por
agentar minha falta de sociabilidade naquele fim de semana. E obrigado
tambm aos pais de Sophia, Eva e Jrgen por virem ajudar a tomar conta
da famlia.
Obrigado tambm aos meus colegas da Crisp, em Estocolmo, e s pessoas
do grupo de discusso do yahoo scrumdevelopment por revisarem e me
ajudarem a melhorar este trabalho.
E, finalmente, obrigado a todos os leitores que forneceram um canal
constante de feedback bastante til. Eu estou particularmente satisfeito
por ouvir que esse trabalho tem impactado tantos de vocs a ponto de
darem uma chance ao desenvolvimento gil de software.
Contedo
3
PREFCIO POR JEFF SUTHERLAND
PREFCIO POR MIKE COHN
I
III
PREFCIO EI, SCRUM FUNCIONOU!
INTRODUO
Termo de Responsabilidade
Porque eu escrevi isso
Mas o que Scrum?
6
7
7
8
COMO FAZEMOS PRODUCT BACKLOGS

Campos adicionais da estria
9
11
COMO NS MANTEMOS O PRODUCT BACKLOG A NVEL DE

NEGCIO
12
COMO NOS PREPARAMOS PARA O PLANEJAMENTO DO

SPRINT
13
COMO PLANEJAMOS SPRINT
15
POR QUE O PRODUCT OWNER DEVE PARTICIPAR
15
POR QUE QUALIDADE NO NEGOCIVEL

Reunies de planejamento do sprint que se arrastam sem fim
Agenda da reunio de planejamento do sprint
Definindo o tamanho do sprint
Definindo o objetivo do sprint
Decidindo quais estrias incluir no sprint
Como o product owner afeta quais estrias estaro neste Sprint?
Como a equipe decide que estrias incluir no sprint?
Definio de pronto
Estimativa de tempo usando planning poker
Esclarecendo Estrias
Quebrando estrias em estrias menores
Dividindo estrias em tarefas
Definindo a hora e lugar da reunio diria
17
18
19
20
21
22
23
25
33
34
36
37
38
39
Onde traar a linha

Estrias tcnicas
Sistema de acompanhamento de bugs vs. product backlog
A reunio de planejamento do sprint est finalmente terminada!
39
40
43
44
COMO COMUNICAMOS SPRINTS
45
COMO FAZEMOS OS SPRINT BACKLOGS

Formato do sprint backlog
Como funciona o quadro de tarefas
Exemplo 1 depois da primeira reunio diria
Exemplo 2 poucos dias depois
Como funciona o grfico de burndown
Sinais de alarme do quadro de tarefas
Ei, e a rastreabilidade?!
Estimando dias vs horas
46
46
48
48
49
50
51
52
52
COMO ARRUMAMOS A SALA DA EQUIPE

O canto do design
Sente a equipe junta!
Mantenha o product owner por perto
Mantenha os gerentes e coaches por perto
53
53
54
55
55
COMO FAZEMOS AS REUNIES DIRIAS

Como atualizamos o quadro de tarefas
Lidando com atrasados
Lidando com o no sei o que fazer hoje
57
57
58
58
COMO FAZEMOS APRESENTAES DE SPRINT

Por que insistimos que todos os sprints terminem com uma apresentao
Checklist para as apresentaes de sprint
Lidando com coisas no demonstrveis
61
61
62
62
COMO FAZEMOS RETROSPECTIVAS DE SPRINTS

Por que insistimos que todas as equipes faam retrospectivas
Como organizamos retrospectivas
Divulgando lies aprendidas entre equipes
Mudar ou no mudar
Exemplos de coisas que podem aparecer durante as retrospectivas
64
64
64
66
67
67
INTERVALO ENTRE SPRINTS
70
COMO FAZEMOS O PLANEJAMENTO DE RELEASE E

CONTRATOS COM PREO FIXO
Defina seus critrios de aceitao
72
72
Faa estimativas de tempo para os itens mais importantes

Estime velocidade
Junte tudo num plano de release
Adaptao do plano de release
73
75
76
77
COMO COMBINAMOS SCRUM E XP

78
Programao em par
78
Desenvolvimento Orientado a Testes (TDD)
79
Design incremental
82
Integrao contnua
82
Propriedade coletiva do cdigo
83
Ambiente de trabalho informativo
83
Padro de codificao
83
Ritmo Sustentvel / Trabalho energizado
84
Como fazemos testes
86
Voc provavelmente no vai conseguir eliminar a fase dos testes de aceitao86
Minimize a fase de testes de aceitao
87
Aumente a qualidade colocando os testadores na equipe Scrum
87
Aumentar a qualidade fazendo menos por Sprint
90
O teste de aceitao deveria fazer parte do sprint?
90
Ciclos de sprint vs. ciclos de testes de aceitao
91
No exponha o elo mais fraco de sua corrente
95
De volta realidade
96
COMO LIDAMOS COM VRIAS EQUIPES
Quantas equipes criar
Sincronizar sprints ou no?
Por que criamos o papel de Lder de Equipe
Como alocamos pessoas s equipes
Equipes especializadas ou no?
Reorganizar as equipes entre os sprints ou no?
Membros de equipe em tempo parcial
Como fazemos Scrum-de-Scrums
Intercalando as reunies dirias
Equipes de bombeiros
Dividir o product backlog ou no?
Fazendo Branching de cdigo
Retrospectivas com vrias equipes
97
97
100
101
102
104
106
107
108
110
111
113
117
118
COMO LIDAMOS COM EQUIPES DISTRIBUDAS

GEOGRAFICAMENTE
Equipes em outro pas
Membros da equipe trabalhando em casa.
121
122
124
CHECKLIST DO SCRUM MASTER

Comeando o sprint
Todo dia
Fim do Sprint
125
125
125
126
LTIMAS PALAVRAS
Leituras recomendadas
Sobre o autor
Sobre a Traduo
127
128
130
131
Prefcio por Jeff Sutherland

As equipes precisam conhecer o bsico do Scrum. Como voc cria e
estima um product backlog? Como voc o transforma num sprint
backlog? Como voc gerencia um grfico burndown e calcula a
velocidade de sua equipe? O livro do Henrik um kit para iniciantes com
prticas bsicas que ajudam equipes a irem alm de apenas tentativas de
praticar o Scrum para execut-lo bem.
Uma boa execuo do Scrum est se tornando mais importante para as
equipes que buscam investimento de fundos externos. Como um mentor
gil para um grupo de capital de risco, eu os ajudo a investirem em
empresas que executam as prticas geis com eficincia. O Parceiro
Snior do grupo tem perguntado a todas as empresas do portflio se elas
conhecem a velocidade de suas equipes. Elas tm dificuldade em
responder a essa questo de imediato. Oportunidades futuras de
investimento iro exigir que as equipes de desenvolvimento saibam sua
velocidade de produo.
Por que isso to importante? Se as equipes no conhecem sua prpria
velocidade, o product owner no pode criar um guia de produto com datas
de releases com credibilidade. E sem datas de release interdependentes, a
empresa poder falhar e os investidores podero perder seu dinheiro!
Esse problema enfrentado por companhias grandes e pequenas, novas ou
antigas, com investimento prprio ou externo. Numa discusso recente
sobre a implantao do Scrum no Google, numa conferncia em Londres,
eu perguntei s 135 pessoas presentes quantos deles estavam praticando
Scrum, e 30 responderam positivamente. Ento eu perguntei se eles
estavam fazendo o desenvolvimento iterativo usando os padres da Nokia.
Desenvolvimento iterativo fundamental no Manifesto gil entregue
software funcionando cedo e com freqncia. Depois de anos de
retrospectivas com centenas de equipes de Scrum, a Nokia desenvolveu
alguns requisitos bsicos para o desenvolvimento iterativo:
As iteraes devem ter um tempo fixo com menos de seis
semanas de durao.
Ao final da iterao, o cdigo deve ser testado pelo CQ e
funcionar corretamente.
Das 30 pessoas que responderam estar usando o Scrum, apenas metade
disse que estava atendendo o primeiro princpio do Manifesto gil pelos
padres da Nokia. Ento eu perguntei se eles atendiam aos padres da
Nokia para o Scrum:
ii | SCRUM E XP DIRETO DAS TRINCHEIRAS

Uma equipe de Scrum deve ter um product owner e saber quem
ele .
O product owner deve ter um product backlog com estimativas
criadas pela equipe.
A equipe deve ter um grfico burndown e saber sua velocidade.
No deve haver nenhuma interferncia externa sobre a equipe
durante um sprint.
Das 30 pessoas praticantes do Scrum, apenas 3 atendiam o teste da Nokia
para identificar uma equipe de Scrum. Essas seriam as nicas que
receberiam futuros investimentos dos meus parceiros.
O valor do livro do Henrik que se voc seguir as prticas que ele
recomenda, voc ter um product backlog, estimativas para o product
backlog, um grfico burndown, e saber a velocidade de sua equipe, alm
de outras prticas fundamentais para um Scrum altamente funcional. Voc
passar no teste da Nokia e estar apto a receber investimento no seu
trabalho. Se voc for uma empresa iniciante, poderia at receber
investimento de um grupo de capital de risco. Voc pode ser o futuro do
desenvolvimento de software e o criador da prxima gerao dos produtos
lderes de mercado.
Jeff Sutherland,
Ph.D., Co-Criador do Scrum
Prefcio por Mike Cohn

Ambos Scrum e Extreme Programming (XP) pregam que a equipe
complete alguma parte palpvel de trabalho que seja entregvel ao fim de
cada iterao. Essas iteraes so pensadas para serem curtas e com
espao de tempo definido. Este foco em entregas de cdigo funcionando
em um curto espao de tempo significa que equipes Scrum e XP no tm
tempo para teorias. Eles no perseguem o desenho do diagrama UML
perfeito em ferramentas case, a escrita do documento de requsitos
perfeito, ou a escrita do cdigo que poder acomodar todas as mudanas
futuras imaginveis. Ao invs disso, equipes Scrum e XP focam em ter as
coisas prontas. Essas equipes aceitam que cometem erros ao longo do
caminho, mas tambm compreendem que o melhor modo de identificar
esses erros parar de pensar sobre o software em um nvel terico de
anlise e design e mergulhar fundo, sujar as mos e comear a construir o
produto.
esse mesmo foco em fazer ao invs de teorizar que distingue esse livro.
E aparentemente Henrik Kniberg entende isso direito, desde o princpio.
Ele no oferece uma longa descrio sobre o que Scrum; ele nos remete
a alguns sites simples para isso. Ao invs disso, Henrik d um salto e
comea imediatamente descrevendo como suas equipes gerenciam e
trabalham com seu product backlog. Da, ele parte para todos os outros
elementos e prticas de um projeto gil bem executado. Sem teorias, sem
referncias. Sem notas de rodap. Nada disso necessrio. O livro de
Henrik no uma explanao filosfica sobre por que Scrum funciona ou
por que voc poderia querer experiment-lo. uma descrio de como
uma boa equipe gil funciona.
Eis o porqu do subttulo do livro, Como fazemos Scrum, ser to
apropriado. Pode no ser o modo como voc faz Scrum, mas o modo
como as equipes do Henrik fazem Scrum. Voc pode perguntar por que
deveria se importar com a forma como outra equipe faz Scrum. Voc
deveria se importar porque todos podemos aprender como fazer melhor
Scrum ouvindo histrias de como foi feito por outros, especialmente
aqueles que esto fazendo direito. No existe, e nunca existir uma lista
de melhores prticas em Scrum, porque o contexto dos projetos e
equipes descarta todas as outras consideraes. Ao invs de melhores
prticas, o que precisamos conhecer so boas prticas e o contexto onde
foram bem sucedidas. Leia histrias suficientes de equipes bem sucedidas
e como elas fizeram as coisas e voc estar preparado para os obstculos
que se apresentarem a voc e ao seu uso de Scrum e XP.
iv | SCRUM E XP DIRETO DAS TRINCHEIRAS

Henrik prov as boas prticas e o contexto necessrio para nos ajudar a
aprender melhor como fazer Scrum e XP, nas trincheiras dos seus
projetos.
Mike Cohn
Autor de Agile Estimating and Planning e User Stories Applied for
Agile Software Development.
Prefcio Ei, Scrum funcionou!

Scrum funcionou! Pelo menos para ns (me refiro ao meu cliente atual em
Stockholm, cujo nome no pretendo mencionar aqui). Espero que ele
funcione pra voc tambm. Talvez esse livro te ajude ao longo do
caminho.
Esta a primeira vez que vi uma metodologia de desenvolvimento
(desculpe Ken, um framework) funcionar diretamente de um livro. Plug n
Play. Todos estamos felizes com isso desenvolvedores, testadores,
gerentes. Nos ajudou a sair de situaes difceis e nos permitiu manter o
foco e momentum, apesar das severas turbulncias de mercado e redues
de pessoal.
Eu no deveria dizer que estava surpreso, mas estava. Aps digerir
inicialmente alguns livros sobre Scrum, me parecia bom, mas quase to
bom para ser verdade (e todos ns conhecemos o ditado quando alguma
coisa parece muito boa para ser verdade...). Ento eu estava
justificadamente um pouco ctico. Mas aps fazer Scrum por um ano,
estou suficientemente impressionado (e a maioria das pessoas nas minhas
equipes tambm) que continuarei a usar Scrum como padro em novos
projetos sempre que no haja uma forte razo para no us-lo.
1
Introduo
Voc est para comear a utilizar Scrum em sua empresa. Ou talvez voc
esteja usando Scrum h alguns meses. Conhece os princpios, leu alguns
livros, ou talvez at j tenha feito a certificao de scrum master.
Parabns!
Mas ainda se sente confuso.
Como disse Ken Schwaber, Scrum no uma metodologia, um
framework. O que significa que Scrum no vai te dizer exatamente o que
fazer.
A boa notcia que vou te dizer exatamente como fao Scrum, em um
nvel de detalhes excruciantemente doloroso. A m noticia , bem, esta a
maneira como EU fao Scrum. E isto no significa que Voc deva faz-lo
exatamente da mesma maneira. De fato, eu tambm faria de maneira
diferente, se encontrasse situaes diferentes.
O melhor e o pior do Scrum que voc forado a adaptar o processo
para sua situao especifica.
Minha abordagem atual para o Scrum o resultado de um ano de
experincias numa equipe de desenvolvimento de aproximadamente 40
pessoas. A empresa estava em uma situao difcil com tarefas levando
mais tempo que o previsto, problemas de qualidade severos, constantes
incndios, deadlines estourados, etc. A empresa decidiu utilizar Scrum
mas no completou a implantao, o que foi como minha tarefa. Para a
maioria das pessoas na equipe de desenvolvimento naquela poca, Scrum
era uma buzzword que escutavam de vez em quando nos corredores, mas
que no tinha nenhuma implicao para o trabalho dirio.
Aps um ano, implementamos Scrum em todas as camadas da empresa,
tentamos diferentes tamanhos de equipes (3-12 pessoas), diferentes
tamanhos de sprint (2-6 semanas), diferentes formas de definir pronto,
diferentes formatos para os product backlog e de sprint backlogs (Excel,
Jira, cartes), diferentes estratgias de testes, diferentes formas de realizar
apresentaes de sprint, diferentes formas de sincronizao de mltiplas

equipes Scrum, etc. Tambm fizemos experimentos com prticas de XP
diferentes formas de realizar a build contnua, programao em pares,
desenvolvimento orientado a testes, etc, e como combin-los com Scrum.
Este um processo de aprendizado contnuo, de modo que a estria no
termina aqui. Estou convencido que esta empresa continuar aprendendo
(se continuarem a realizar as retrospectivas dos sprints) e terem novos
insights sobre como melhor implementar Scrum em seus contextos
particulares.
Termo de Responsabilidade
Este documento no assume representar a forma correta de usar Scrum!
Ele apenas representa uma forma de usar Scrum, o resultado da melhoria
contnua ao longo de um ano. Voc pode at mesmo decidir que ns
entendemos tudo errado.
Tudo o que h neste documento reflete minhas prprias opinies pessoais
e subjetivas e no de forma alguma uma declarao oficial da Crisp ou
do meu cliente atual. Por esta razo eu intencionalmente evitei mencionar
quaisquer produtos ou pessoas especficas.
Porque eu escrevi isso

Quando estava aprendendo Scrum, li os livros relevantes sobre Scrum e
agile, acessei muitos sites e fruns sobre Scrum, fiz a certificao do Ken
Schwaber, perturbei-o com perguntas e passei muito tempo conversando
com meus colegas. Uma das mais valiosas fontes de informao,
entretanto, foram as histrias de guerra. As histrias de guerra
transformam princpios e prticas em... bem... Como voc realmente faz
isso. Elas tambm me ajudaram a identificar (e algumas vezes evitar)
erros comuns de iniciantes em Scrum.
Logo, essa minha chance de devolver algo. Aqui est minha histria de
guerra.
Eu espero que este documento provoque algum retorno til daqueles que
estejam na mesma situao. Por favor, me iluminem!
Mas o que Scrum?

Oh, me desculpe. Voc completamente novo no Scrum ou XP? Neste
caso talvez voc queira dar uma olhada nos seguintes links:
8 | SCRUM E XP DIRETO DAS TRINCHEIRAS

http://agilemanifesto.org/
http://www.mountaingoatsoftware.com/scrum
http://www.xprogramming.com/xpmag/whatisxp.htm
Se voc impaciente demais para fazer isso, sinta-se livre para continuar
lendo. Muito do jargo do Scrum explicado conforme avanamos, logo
ainda assim voc poder achar isso interessante.
2
Como fazemos product backlogs
O product backlog o corao do Scrum. aqui que tudo comea. O
product backlog basicamente uma lista de requisitos, estrias, Coisas
que o cliente deseja, descritas utilizando a terminologia do cliente.
Ns as chamamos de estrias, ou algumas vezes apenas de itens do
backlog.
Nossas estrias incluem os seguintes campos:
ID Uma identificao nica, apenas um nmero com autoincremento. Isso para evitar que percamos o controle sobre as
estrias quando ns mudamos seus nomes.
Nome Um nome curto e descritivo para a estria. Por exemplo,
Ver o histrico de transaes. Suficientemente claro para que
os desenvolvedores e o product owner entendam mais ou menos
sobre o que estamos falando, e claro o bastante para distingui-la
das demais estrias. Normalmente de 2 a 10 palavras.
Importncia a pontuao de importncia dessa estria para o
product owner. Por exemplo 10. Ou 150. Mais pontos = mais
importante.
o Eu tento evitar o termo prioridade j que prioridade 1
tipicamente interpretado como prioridade mais alta, o
que fica feio se mais tarde voc decidir que algo ainda
mais importante. Qual pontuao de prioridade esse item
deveria receber? Prioridade 0? Prioridade -1?
Estimativa inicial As estimativas iniciais da equipe sobre
quanto tempo necessrio para implementar aquela estria, se
comparada a outras estrias. A unidade pontos por estria e
geralmente corresponde mais ou menos a relao homem/dias
ideal.
1. Pergunte equipe se vocs puderem ter o nmero
ideal de pessoas para esta estria (nem muitas, nem
poucas, normalmnte duas), e se trancarem em uma
sala cheia de comida e trabalharem sem distrbio

algum, aps quantos dias vocs apresentaro uma
implementao pronta, demonstrvel e testada? Se a
resposta for com 3 pessoas trancados em uma sala
levar aproximadamente 4 dias ento a estimativa
inicial de 12 pontos por estria.
2. O importante no ter estimativas absolutamente
precisas (por exemplo, dizer que uma estria com 2
pontos dever gastar 2 dias), mas sim obter
estimativas relativas corretas (por exemplo, dizer
que uma estria com 2 pontos gastar cerca da
metade de uma estria com 4 pontos).
Como demonstrar Uma descrio em alto nvel de como a
estria ser demonstrada na apresentao do sprint. Isso
simplesmente uma simples especificao de teste. Faa isso,
ento faa aquilo e ento isso dever acontecer.
o Se voc pratica TDD (desenvolvimento orientado a
testes) essa descrio pode ser usada como pseudocdigo para o seu cdigo de teste de aceitao.
Notas
quaisquer outras informaes, esclarecimentos,
referncias a outras fontes de informao, etc. Normalmente gil
bem breve.
PRODUCT BACKLOG (exemplo)
ID Nome
Imp
Est Como demonstrar
1
Depsito
30
5
Logar-se, abrir a
pgina de depsito,
depositar R$ 10,00,
ir para a pgina do
meu saldo e
verificar que este
aumentou em R$
10,00.
2
Verificar
10
8
Logar-se, clicar em
seu prprio
transaes. Fazer
histrico de
um depsito. Voltar
transaes
para transaes,
verificar se o novo
depsito listado.
Notas
Precisa de uma
diagrama
UML de
sequncia. No
necessrio se
preocupar com
criptografia
por enquanto.
Usar
paginao para
evitar
consultas
muito grandes
ao banco de
dados. Projetar
de forma
similar
pgina de
visualizao de
usurios.
Ns experimentamos com muitos outros campos, mas ao final do dia os

seis campos acima eram os nicos realmente utilizados sprint aps sprint.
Ns normalmente fazemos isso em um documento do Excel com
compartilhamento habilitado (isso , mltiplos usurios podem edit-lo
simultaneamente). Oficialmente o product owner o dono do documento,
mas ns no queremos deixar os outros usurios de fora. Vrias vezes um
desenvolvedor desejar abrir o documento para esclarecer algo ou alterar
uma estimativa.
Pela mesma razo, ns no mantemos este documento no repositrio de
controle de verses, ns o colocamos em um drive compartilhado na rede.
Essa a forma mais simples de permitir mltiplos editores simultneos
sem causar conflitos de lock ou merge.
Quase todos os outros artefatos, entretanto, so colocados no repositrio
de controle de verses.
Campos adicionais da estria

Algumas vezes ns usamos campos adicionais no product backlog,
principalmente como convenincia para ajudar o product owner na hora
de decidir as priorizaes.
Track (Tilha/Rastro) uma categorizao bsica dessa estria,
por exemplo, back office ou otimizao. Dessa forma, o
product owner pode facilmente filtrar por todos os itens de
otimizao e definir sua prioridade para baixa, etc.
Componentes Geralmente so includos campos na forma de
checkboxes em um documento no Excel, por exemplo base de
dados, servidor, cliente. Aqui a equipe ou o product owner
podem identificar quais componentes tcnicos esto envolvidos
na implementao dessa histria. Isto til quando se tem vrias
equipes de Scrum, como por exemplo uma equipe de back office
e outra de cliente, assim facilitando a deciso de cada equipe na
escolha das estrias.
Solicitante o product owner pode querer manter o rastro de
qual cliente ou o stakeholder que solicitou o item, para poder
fornecer um feedback sobre o progresso desse item.
ID do bug se houver um sistema separado para registro de
erros (bug tracking), como ns fazemos com o Jira, til manter
a rastreabilidade da estria com um ou mais erros reportados
sobre ela.
Como ns mantemos o product backlog

a nvel de negcio
Se o product owner tem uma formao tcnica, ele pode adicionar estrias
como Adicionar ndice na tabela de eventos. Por que ele quer algo
assim? O verdadeiro objetivo implcito provavelmente algo como
acelerar o formulrio de pesquisa de eventos no back office.
Pode ocorrer que os ndices no sejam os gargalos que causam a lentido
no formulrio. Pode ser algo completamente diferente. A equipe
normalmente melhor adaptada para descobrir como resolver algo, assim o
product owner deveria focar-se nos objetivos de negcio.
Quando vejo estrias com orientao tcnica como essa, normalmente eu
pergunto ao product owner uma srie de questes de mas por qu, at
encontrar o objetivo subjacente. Ento ns reformulamos a estria nos
termos do objetivo subjacente (acelerar o formulrio de pesquisa de
eventos no back office). A descrio tcnica original acaba virando uma
nota (Indexar a tabela de eventos poderia resolver isso).
3
Como nos preparamos para o
planejamento do sprint
Est bem, o dia de planejamento do sprint est chegando rpido. Uma
lio que aprendemos sempre :
Lio: Tenha certeza de que o product backlog est organizado e fechado
antes da reunio de planejamento do sprint.
E o que isso significa? Que todas as estrias esto perfeitamente bem
definidas? Que todas as estimativas esto corretas? Que todas as
prioridades devem permanecer fixas? No, no e no! O que isso significa
:
O product backlog deveria existir! (j pensou nisso?)
Deveria haver apenas um product backlog e apenas um product
owner (por produto).
Todos os itens importantes deveriam ter uma escala de
importncia associada a eles. Cada um com a sua escala diferente
da dos outros.
o Na verdade, no h problema se todos os itens de pouca
importncia tiverem a mesma escala, j que eles no
sero o foco da reunio de planejamento.
o Qualquer estria que o product owner acredite ter a mais
remota possibilidade de ser includa no prximo sprint,
deve ter uma escala nica de importncia.
o O nvel de importncia s usado para classificar os
itens por importncia. Assim, se o item A tem
importncia de 20 e o item B 100, significa apenas que B
mais importante que A. No significa que B cinco
vezes mais importante do que A. Se B tivesse com a
escala 21, significaria a mesma coisa!
o til deixar espaos vazios entre as numeraes para
poder inserir novos itens. Supondo que o item C seja
descoberto como mais importante do que A, mas menos
importante do que B, ele poderia ganhar a escala 30, ao
invs de 20,5. Assim, deixe os espaos. bem mais

prtico.
O product owner deveria entender cada estria (normalmente ele
o autor, mas em alguns casos outras pessoas adicionam
requisitos, mas o product owner ainda precisa prioriz-los). Ele
no precisa conhecer exatamente o que necessrio para
implementar, mas ele deveria entender o porqu dessa estria
estar ali.
Nota: Outras pessoas alm do product owner podem adicionar estrias ao

product backlog. Mas elas no podem associar uma escala de importncia.
Esse um papel exclusivo do product owner. Eles tambm no podem
estimar prazos. Essa uma tarefa exclusiva da equipe.
A seguir, outras abordagens que ns tentamos ou avaliamos:
Usar Jira (nosso sistema de bug tracking) para hospedar o
product backlog. A maioria de nossos product owners acharam
que era preciso dar muitos cliques para realizar as tarefas. Excel
bom e fcil de manusear. Voc pode usar cores facilmente,
reordenar os itens, adicionar novas colunas quando necessrio,
adicionar notas, importar e exportar dados, etc.
Usar uma ferramenta de suporte a processos geis, como
VersionOne, ScrumWorks, XPlanner, etc. Ainda no testamos
nenhuma delas, mas provavelmente faremos isso no futuro.
4
Como planejamos sprint
O planejamento de sprint uma reunio crtica, provavelmente o evento
mais importante no Scrum (na minha opinio, claro). Um encontro de
planejamento de sprint mal feito pode bagunar totalmente um sprint.
O propsito da reunio de planejamento do sprint dar equipe
informao suficiente para trabalharem em paz por algumas semanas, e
para dar ao product owner confiana suficiente para deix-los fazerem
isto.
OK, isto foi confuso. O resultado concreto do encontro de planejamento
de sprint :
Um objetivo de sprint.
Uma lista de membros da equipe (e seus nveis de
comprometimento, se no 100%).
Um sprint backlog (= uma lista de estrias inclusas no sprint).
Uma data definida para a apresentao do sprint.
Data e local definidos para a reunio diria.
Por que o product owner deve participar

s vezes, os product owners relutam em despender horas com a equipe
fazendo planejamento do sprint. Pessoal, eu j listei o que eu quero. Eu
no tenho tempo para estar na sua reunio de planejamento. Isto um
problema muito grave.
A razo pela qual toda equipe e o product owner devam estar na reunio
de planejamento do sprint porque cada estria contm trs variveis que
so muito dependentes umas das outras.
Escopo e importncia so definidos pelo product owner. Estimativa

definida pela equipe. Durante uma reunio de planejamento do sprint,
estas trs variveis so refinadas continuamente por dilogo cara-a-cara
entre equipe e product owner.
Normalmente, o product owner inicia a reunio resumindo seu objetivo
para o sprint e as estrias mais importantes. Em seguida, a equipe toma a
frente e estima o tempo de cada estria, comeando pela mais importante.
Ao fazer isto, eles vo se deparar com questes de escopo importantes
esta estria apagar usurio inclui passar por cada transao pendente
para o usurio e cancelar cada uma? Em alguns casos, as respostas sero
surpreendentes para a equipe, fazendo com que eles mudem suas
estimativas.
Em alguns casos, a estimativa de tempo para uma estria no ser aquela
que o product owner esperava. Isto poder faz-lo mudar a importncia da
estria. Ou mudar o escopo da estria, que por sua vez far a equipe reestimar, etc., etc.
Este tipo de colaborao direta fundamental para o Scrum e, de fato,
todo o desenvolvimento gil de software.
E se o product owner ainda insistir que ele no tem tempo para tomar
parte das reunies de planejamento do sprint? Eu normalmente tento uma
das estratgias, na seguinte ordem:

Tento ajudar o product owner a entender por que a sua

participao direta crucial e espero que ele mude de idia.
Tento fazer com que algum da equipe se voluntarize a ser o
intermediador do product owner. Diga ao product owner Como
voc no pode participar de nossa reunio, ns deixaremos Jeff
represent-lo como um intermediador. Ele ter plenos poderes
para mudar as prioridades e escopo das estrias na sua ausncia
durante a reunio. Eu sugiro que voc sincronize com ele o
mximo possvel antes da reunio. Se voc no quiser que Jeff
seja o seu intermediador, por favor sugira alguma outra pessoa,
COMO PLANEJAMOS SPRINT | 17

que possa se juntar a ns durante toda a durao da reunio.

Tente convencer a equipe de gerenciamento a designar um novo
product owner.
Adie o lanamento do sprint at que o product owner ache tempo
para se juntar reunio. Enquanto isto, se recuse a entregar
qualquer coisa. Deixe a equipe passar cada dia fazendo aquilo
que sentir ser mais importante para o dia.
Por que qualidade no negocivel

No tringulo acima, eu intencionamente evitei a quarta varivel
qualidade.
Eu tento distinguir entre qualidade interna e qualidade externa:

Qualidade externa o que percebido pelos usurios do sistema.

Uma interface de usurio lenta e no intuitiva um exemplo de
baixa qualidade externa.
Qualidade interna refere-se a questes que normalmente no so
visveis ao usurio, mas que tm profundos efeitos na
manutenibilidade do sistema. Coisas como consistncia do
projeto do sistema, cobertura dos testes, facilidade de leitura do
cdigo, refactoring etc.
No geral, um sistema com alta qualidade interna pode ainda ter uma baixa
qualidade externa. Entretanto, um sistema com baixa qualidade interna
raramente ter uma qualidade externa alta. difcil construir algo legal a
partir de fundaes podres.
Eu trato qualidade externa como parte do escopo. Em alguns casos pode
fazer perfeito sentido, negocialmente, lanar uma verso do sistema que
tenha uma interface deselegante e lenta, e lanar uma verso melhorada
posteriormente. Eu deixo o dilema para o product owner, uma vez que ele
responsvel por determinar o escopo.
Qualidade interna, porm, no est em discusso. responsabilidade da
equipe manter a qualidade do sistema sob todas as circunstncias e isso
simplesmente no negocivel. Nunca.
(Bem, OK, quase nunca)

Ento, como mostramos a diferena entre problemas de qualidade interna
e problemas de qualidade externa?
Digamos que o product owner diga OK pessoal, eu respeito sua
estimativa de tempo de seis pontos de estria, mas eu tenho certeza de que
vocs podem fazer algum tipo de quebra-galho para isso na metade do
tempo se vocs se concentrarem nisso.
A-ha! Ele est tentando usar qualidade interna como uma varivel. Como
eu sei? Porque ele quer que ns reduzamos a estimativa da estria sem
pagar o preo de reduzir o escopo.. A palavra quebra-galho deve
ativar um alarme na sua cabea...
E por que ns no permitimos isso?
Minha experincia que sacrificar qualidade interna quase sempre uma
idia muito, muito ruim. O tempo economizado largamente superado
pelo custo, tanto em curto quanto em longo prazo. Uma vez que se
permita que uma base de cdigo se deteriore, muito difcil recuperar a
qualidade mais tarde.
Ao invs disso, eu tento levar a discusso para o escopo. J que
conseguir essa feature mais cedo importante para voc, podemos reduzir
o escopo de modo que seja mais rpido implement-la. Talvez possamos
simplificar o tratamento de erros e fazer 'Tratamentos de erros avanados'
numa estria separada, que reservamos para o futuro. Ou podemos reduzir
a prioridade das outras estrias, de modo que possamos focar nessa. Que
tal?
Uma vez que o product owner tenha aprendido que qualidade interna no
negocivel, ele geralmente se especializa em manipuar as outras
variveis.
Reunies de planejamento do sprint que se

arrastam sem fim
O mais difcil em reunies de planejamento de sprint o fato de:
1) As pessoas pensarem que elas no iro demorar tanto
2) ... mas elas demoram!
Tudo no Scrum delimitado pelo tempo. Eu amo essa regra, simples e
consistente. Tentamos nos ater a ela.

Ento, o que devemos fazer quando o prazo estipulado para a reunio de
planejamento do sprint est prestes a se esgotar e ainda no temos nem
sinal de um objetivo do ou de um sprint backlog? Interrompemos a
reunio?? Ou melhor estendermos a discusso por mais uma hora? Ou
suspendemos temporiamente e continuamos no dia seguinte?
Isso acontece vrias vezes, especialmente em equipes novatas no
framework. Ento, o que voc faz? Eu no sei. Mas o que podemos fazer?
Bem, geralmente eu interrompo a reunio abruptamente. Finalizo-a. Deixa
o sprint sofrer as consequncias. Mais especificamente, eu digo equipe e
ao product owner: ento, esta reunio terminar em 10 minutos. Ns no
temos ainda o planejamento do sprint. Vamos trabalhar com o que temos
ou vamos agendar outra reunio de 4 horas para amanh, a partir das 8
horas da manh?. Adivinha o que iro escolher :o)
J tentei deixar a reunio rolar solta, extrapolando o prazo previsto.
Geralmente, no resolve nada, pois as pessoas j esto cansadas. Se a
equipe no conseguiu produzir um planejamento decente para o sprint em
2 ou 8 horas (ou seja l qual for a durao escolhida para sua reunio),
provavelmente 1 hora a mais no ir resolver em nada o problema. A
proposta de agendar uma nova reunio para o dia seguinte, seria bem
razovel, se no fosse o fato de as pessoas geralmente j estarem
impacientes para iniciar logo o sprint e no quererem perder mais tempo
com horas de planejamento.
Por isso, minha deciso de interromper mesmo a reunio. Deixa o sprint
sofrer com isso. O lado bom disso que a equipe aprende uma boa lio,
e a prxima reunio de planejamento do sprint ser bem mais eficiente.
Alm disso, as pessoas sero menos resistentes quando voc propor um
prazo para a reunio que outrora teria sido considerado muito longo.
Aprenda a respeitar a delimitao do tempo e aprenda a defini-la de forma
realstica. Isso se aplica tanto para prazos de reunies quanto para prazos
de sprints.
Agenda da reunio de planejamento do sprint

Possuir algum tipo de cronograma para a reunio de planejamento do
sprint reduzir o risco de ultrapassar o espao de tempo previsto.
Eis um exemplo de um cronograma tpico.

Reunio de planejamento do sprint: 13:00 17:00 (10 minutos de
intervalo a cada hora)
13:00 13:30. O product owner repassa o objetivo do sprint e
sumariza o product backlog. Definir lugar, data e hora da
demonstrao.
13:30 15:00. A equipe estima o tempo e quebra os itens
conforme necessrio. O product owner atualiza as taxas de
importncia conforme necessrio. Os itens so esclarecidos.
Como demonstrar preenchido para todos os itens de maior
importncia.
15:00 16:00. A equipe escolhe as estrias a serem includas no
sprint. Calculam a velocidade para verificar se o planejamento
ficou realista.
16:00 17:00. Escolher data e lugar para a reunio diria (se no
forem os mesmo do ltimo sprint). Complementar a quebra de
estrias em tarefas.
Esse cronograma no precisa, de forma alguma, ser seguido risca. O
scrum master pode aumentar ou diminuir os tempos conforme necessrio,
ao longo da reunio.
Definindo o tamanho do sprint

Uma das sadas da reunio de planejamento do sprint uma data definida
para a apresentao. Isso significa que vocs precisam definir o tamanho
do sprint.
Ento, qual seria um bom tamanho de sprint?
Bem, sprints curtos so bons. Eles permitem que a equipe seja gil, isto
, mude de direo freqentemente. Sprints curtos = ciclo curto de
feedback = entregas mais freqentes = feedback mais freqente do cliente
= menos tempo perdido, indo na direo errada = aprender e melhorar
rpido, etc.
Entretanto, sprints longos so bons tambm. A equipe tem mais tempo
para ganhar ritmo, ela tem mais espao para se recuperar dos problemas, e
conseguir atingir o objetivo do sprint, voc tem menos overhead em
termos de reunies de planejamento, apresentaes, etc.
No geral, product owners gostam de sprints curtos e desenvolvedores
preferem os longos. Ento o tamanho do sprint representa um

compromisso. Ns experimentamos bastante isso, e chegamos ao nosso
tamanho favorito: 3 semanas. A maioria das nossas equipes (mas no
todas) faz sprints de 3 semanas. Curtas o bastante para nos dar agilidade
corporativa adequada, longas o bastante para a equipe conseguir fluidez e
se recuperar de eventuais problemas durante o sprint.
Uma coisa que conclumos foi: faa experimentos com o tamanho do
sprint, no incio. No perca muito tempo analisando, apenas escolha um
tamanho decente, e d-lhe uma chance por um sprint ou dois, ento mude
o tamanho.
No entanto, uma vez que vocs decidiram o tamanho que mais gostam,
mantenham ele por um bom tempo. Depois de alguns meses de
experimentao, ns achamos que 3 semanas estava bom. Ento ns
fazemos sprints de 3 semanas, ponto. Algumas vezes parecer um pouco
longo demais, outras vezes parecer um pouco curto demais. Mas,
mantendo o mesmo tamanho, isso se torna como um batimento cardaco
corporativo, com que todos se identificam confortavelmente. No h
discusso quanto s datas de entregas ou coisas do tipo, porque todos
sabem que a cada trs semanas haver uma entrega, ponto.
Definindo o objetivo do sprint

Acontece quase toda vez. Em algum momento durante o planejamento do
sprint, eu pergunto ento, qual o objetivo deste sprint? e todo mundo
fica parado me olhando e o product owner franze a sobrancelha e coa o
queixo.
Por algum motivo difcil definir um objetivo para o sprint. Mas ainda
sim eu percebi que compensa se esforar para espremer um. Melhor um
objetivo meia-boca do que nenhum objetivo. O objetivo poderia ser
ganhar mais dinheiro ou completar as 3 estrias mais importantes ou
impressionar o CEO ou tornar o sistema bom o suficiente para
distribuir uma verso beta ou adicionar funcionalidades bsicas de
retaguarda ou qualquer coisa. O importante que seja em termos de
negcio, no termos tcnicos. Isto quer dizer, em termos que as pessoas
de fora da equipe possam entender.
O objetivo do sprint deve responder a pergunta fundamental Por que ns
estamos fazendo este sprint? Porque no samos de frias ao invs de
faz-lo?. De fato, uma maneira de extrair o objetivo de um sprint do
product owner literalmente fazer esta pergunta.

O objetivo deve ser algo que j no tenha sido atingido. Impressionar o
CEO pode ser um objetivo timo, mas no se ele j est impressionado
com o sistema atualmente. Neste caso, todos poderiam ir embora para a
casa que mesmo assim o objetivo seria atingido.
O objetivo do sprint pode parecer bobo e artificial durante o planejamento
do sprint, mas freqentemente se torna til no meio dele, que quando as
pessoas comeam a ficar confusas sobre o que elas deveriam estar
fazendo. Se voc tem vrias equipes Scrum (como ns temos) trabalhando
em produtos diferentes, muito til poder listar os objetivos de todas as
equipes em uma nica pgina wiki (ou o que seja) e coloc-la em um local
evidente para que todos na companhia (no somente a gerncia) saibam o
que a empresa est fazendo e por qu!
Decidindo quais estrias incluir no sprint

Uma das principais atividades da reunio de planejamento do sprint
decidir quais estrias incluir no sprint. Mais especificamente, quais
estrias do product backlog copiar para o sprint backlog.
Observe a figura acima. Cada retngulo representa uma estria, ordenado

pela importncia. A estria mais importante est no topo da lista. O
tamanho de cada retngulo representa o tamanho daquela estria (ou seja,
o tempo estimado nos pontos de estria). A altura do brao azul
representa a velocidade estimada da equipe, ou seja, quantos pontos de
estria a equipe acredita poder completar durante o prximo sprint.

O sprint backlog da direita um snapshot das estrias do product
backlog. Ele representa a lista de estrias que a equipe executar para o
sprint.
A equipe decide como as muitas estrias sero includas no sprint. No o
product owner ou qualquer outra pessoa.
Isso levanta duas questes:
1. Como fazer a equipe decidir quais estrias incluir no sprint?
2. Como pode o product owner afetar a deciso dela?
Eu comearei com a segunda questo.
Como o product owner afeta quais estrias

estaro neste Sprint?
Digamos que ns tenhamos a seguinte situao durante uma reunio de
planejamento de sprint.
O product owner est desapontado com o fato de que a estria D no ser

includa no sprint. Quais so as suas opes durante a reunio de
planejamento do sprint?
Uma opo reordenar a priorizao. Se ele der estria D a maior
prioridade, a equipe ser obrigada a adicion-la ao sprint (neste caso
tirando a estria C).
Uma segunda opo mudar o escopo reduzir o escopo da estria A at

que a equipe acredite que a estria D caber no sprint.
Uma terceira opo dividir uma estria. O product owner pode decidir
que existem aspectos na estria A que no so realmente importantes,
ento ele divide a estria A em A1 e A2 separando-as em prioridades
diferentes.
Como v, mesmo que o product owner no possa alterar a velocidade

estimada, h vrias formas como este pode influenciar quais estrias
estaro presentes num sprint.
Como a equipe decide que estrias incluir no

sprint?
Utilizamos duas tcnicas para isso:
1.
No sentimento/instinto
2.
Clculo da Velocidade
Estimativa usando o sentimento ou instinto

Scrum master: Ol pessoal, podemos terminar a estria A neste

Sprint? (apontando para o item mais importante no backlog de
produtos)
Lisa: D. Claro que podemos. Temos 3 semanas, e uma
funcionalidade bastante trivial
Scrum master: OK, e se incluirmos a estria B tambm?
(apontando para o Segundo item mais importante)
Tom & Lisa em unssono: Continua fcil
Scrum master: OK, e que tal as estrias A, B e C?
Sam (ao cliente): a estria C inclui os tratamentos avanados de
erros?
Cliente: no, podemos ignorar por enquanto, somente
implemente o tratamento de erros bsicos
Sam: ento C pode entrar tambm?
Scrum master: OK, e se incluirmos a estoria D?
Lisa: Hmm....
Tom: acredito que podemos faz-lo
Scrum master: 90% certo? 50%?
Lisa & Tom: Mais pra 90%.
Scrum master: OK, ento D entra tambm. Que acham de
incluirmos a estria E?
Sam: Talvez.
Scrum master: 90%? 50%?
Sam: Perto de 50%.
Lisa: Estou na dvida.
Scrum master: OK, ento vai ficar de fora. Nos
comprometemos com A, B, C e D. Se pudermos, terminaremos E
tambm, mas ningum poder contar com isso, assim deixaremos
fora do plano do sprint. Que acham disso?
Todos: OK!
O sentimento ou instinto funciona muito bem para pequenas equipes e

sprint curtos.
Estimativas usando clculos de velocidade

Essa tcnica envolve dois passos:
1.
Defina a velocidade estimada.
2.
Calcular quantas estrias voc pode adicionar sem exceder a
velocidade estimada.
Velocidade uma medida da quantidade trabalho realizado, onde cada
item medido com base na sua estimativa inicial.
A figura abaixo mostra um exemplo de velocidade estimada no incio de
um sprint e a velocidade real no final do sprint. Cada retngulo uma
estria, e o nmero dentro dele a estimativa inicial dela.
Note que a velocidade real baseada na estimativa inicial de cada estria.

Quaisquer modificaes na estimativa de tempo da estria durante o sprint
devem ser ignoradas.
J posso ouvir voc dizendo: Como isso til? Maior ou menor
velocidade depende de uma srie de fatores! Programadores
inexperientes, estimativas iniciais incorretas, diminuio de escopo,
problemas no previstos durante o sprint, etc.!
Eu concordo, esse um nmero cru mesmo. Mas ainda assim uma
medida til, especialmente quando no for comparado com nada mais. Ele
te fornece alguns fatos fixos. Independentemente dos motivos, aqui est
uma diferena aproximada de o quanto ns achvamos que gastaramos na
atividade e o quanto realmente gastamos.
E o que dizer sobre uma estria que ficou quase completa durante o
sprint? Por que no pegamos medidas parciais em nossa velocidade real?
Bem, para tirar proveito do fato de que Scrum (e de fato o
desenvolvimento gil de software e os processos lean de fabricao em
geral) trata de ter as tarefas realizadas, prontas para serem entregues! O
valor de uma coisa feita pela metade zero (de fato, at negativo). Leia

o livro Managing the Design Factory de Donald Reinertsen ou algum
dos livros de Poppendieck para saber mais sobre o assunto.
Ento, com que varinha mgica estimamos velocidade?
Uma maneira muito simples de fazer isso olhar para o histrico da
equipe. Qual foi a velocidade dela nos sprints mais recentes? Ento
assuma que a velocidade nesse sprint ser equivalente.
Essa tcnica conhecida como tempo de ontem. Isso s possvel para
equipes que j tenham terminado alguns sprints (com as estatsticas
disponveis) e faro o prximo praticamente da mesma forma com o
mesmo nmero de membros e mesmas condies de trabalho, etc.
Obviamente, nem sempre esse o caso.
Uma variante mais sofisticada fazer um clculo simples de recursos.
Vamos supor que estamos planejando um sprint de 3 semanas (15 dias de
trabalho) com uma equipe de 4 pessoas. Lisa estar de folga por 2 dias.
Dave est disponvel somente 50% e estar de folga por 1 dia. Colocando
tudo isso junto...
... resulta em 50 homem-dias disponveis para este sprint.

Ser esta a nossa velocidade estimada? No! Porque nossa unidade de
estimativa pontos por estria, os quais, no nosso caso, correspondem a
uma aproximao de homens-dia ideal. Um homem-dia ideal um dia
perfeitamente efetivo, sem distrbios, o que raro. Alm disso, temos que
levar em considerao coisas como o trabalho no planejado que
adicionado ao sprint, pessoas que ficam doentes, etc.
Portanto, nossa velocidade estimada ser certamente menor que 50. Mas o
quanto menor? Utilizamos para isso o termo fator de foco.
O fator de foco uma estimativa de como a equipe focada. Um fator de

foco baixo, pode significar que a equipe espera ter muitas interferncias
ou percebe que suas prprias estimativas de tempo so otimistas.
A melhor maneira para determinar um fator de foco razovel considerar
o ltimo sprint (ou melhor ainda, a mdia de alguns sprints anteriores).
A velocidade atual a soma das estimativas iniciais de todas as estrias

que foram finalizadas no ltimo sprint.
Vamos supor que o ltimo sprint terminou 18 pontos por estria
utilizando uma equipe de 3 pessoas, com Tom, Lisa e Sam trabalhando 3
semanas, resultando em um total de 45 homens-dia. E agora ns estamos
tentando calcular nossa velocidade estimada para o prximo sprint. Para
complicar as coisas, um cara novo, o Dave, est se juntando equipe para
esse sprint. Levando em considerao as folgas e as obstrues ns temos
50 homem-dias para o prximo sprint.
Portanto, nossa velocidade estimada para o prximo sprint de 20 pontos

por estria. O que significa que a equipe deveria adicionar estrias ao
sprint at atingir uma soma de aproximadamente 20.
Neste caso, a equipe talvez escolha as 4 primeiras estrias para obter um

total de 19 pontos por estria, ou as 5 primeiras totalizando 24 pontos por
estria. Vamos supor que eles escolham 4 estrias, visto que o mais
prximo de 20 pontos por estria que se chega. Na dvida, selecione
menos estrias.
Como estas 4 estrias adicionaram 19 pontos por estria, a velocidade
estimada final para este sprint 19.
Tempo de ontem uma tcnica acessvel, mas use-a com uma dose de
bom senso. Se o ltimo sprint foi excepcionalmente ruim porque a maior
parte da equipe esteve doente por uma semana, ento pode ser seguro
assumir que voc no ter esta falta de sorte de novo e voc pode estimar
um fator de foco alto para o prximo sprint. Se a equipe instalou
recentemente um novo e rpido sistema de build contnuo voc pode,
provavelmente, aumentar o fator de foco devido a isto tambm. Se uma
pessoa nova est se juntando a este sprint voc precisa reduzir o fator de
foco para considerar seu treinamento. Etc.
Sempre que possvel olhe para os sprints passados e faa a mdia dos
nmeros para obter uma estimativa mais confivel.
E se a equipe for completamente nova e voc no tiver nenhuma
estatstica? Olhe para o fator de foco de outras equipes em circunstncias
similares.
E se voc no tiver nenhuma outra equipe para olhar? Suponha um fator
de foco. A boa notcia que o seu chute ser usando somente no primeiro
sprint. Depois disto voc ter estatsticas e pode medir e melhorar
continuamente seu fator de foco e a velocidade estimada.

O fator de foco padro que eu uso para novas equipes usualmente
70%, porque este o ponto onde muitos de nossas outras equipes
chegaram com o tempo.
Qual tcnica de estimativa ns usamos ?

Eu mencionei diversas tcnicas acima instinto/sentimento, clculo de
velocidade baseado no tempo de ontem, e clculo de velocidade baseada
no homens-dia disponveis e fator de foco.
Ento, qual tcnica ns usamos ?
Geralmente combinamos estas tcnicas em certas medidas. Realmente no
toma muito tempo.
Olhamos para o fator de foco e na velocidade atual do ltimo sprint.
Olhamos para a disponibilidade total de nossos recursos disponveis e
estimamos o fator de foco. Discutimos quaisquer diferenas entre estes
fatores de foco e fazemos os ajustes necessrios.
Uma vez que temos a listagem preliminar das estrias a serem includas
no sprint, eu fao uma reviso baseada no meu sentimento. Eu peo a
equipe para ignorar os nmeros por um momento e pensar apenas em suas
percepes sobre a parte em questo do sprint. Se acham que levar
bastante tempo ento removemos uma ou duas estrias. E vice-versa.
Ao final do dia, o objetivo simplesmente decidir quais estrias ns
incluiremos no sprint. Fator de foco, disponibilidade de recursos e
velocidade estimada so apenas meios de atingir o objetivo.
Por que ns usamos cartes

A maior parte da reunio de planejamento do sprint gasto lidando com
as estrias no product backlog. Estimando-as, repriorizando-as,
esclarecendo-as, quebrando-as, etc.
Como fazemos isso na prtica ?
Bem, normalmente, as equipes ligam o projetor e mostram um backlog
feito em Excel, ento um cara (tipicamente o product owner ou o scrum
master) pega o teclado, esboa cada estria e estimula uma discusso. A
medida que as prioridades e detalhes so discutidas pela equipe e pelo
product owner, a pessoa ao teclado atualiza a estria direto no Excel.

Parece bom? Bem, no . Normalmente um saco. E o que pior, a
equipe normalmente no avisa que um saco at eles chegarem no fim da
reunio e perceberem que ainda no conseguiram passar para lista de
estrias!
Uma soluo que funciona muito melhor criar cartes e coloc-los na
parede (ou numa mesa grande).
Esta uma interface de usurio superior comparada a computador &

projetor porque:
Pessoas ficam em p e caminham => elas ficam acordadas e
alerta por mais tempo.
Todos se sentem mais pessoalmente envolvidos (ao invs de s o
cara com o teclado).
Mltiplas estrias podem ser editadas simultaneamente.
A repriorizao trivial - s trocar a posio dos cartes.
Aps a reunio, os cartes podem ser levados para a sala da
equipe e ser usado como um quadro de tarefas na parede (veja pg
49 "Como ns fazemos o sprint backlog)
Voc pode tanto escrev-los mo ou (como geralmente fazemos),
quanto usar um script simples para gerar cartes imprimveis diretamente
do product backlog.
PS o script est disponvel no meu blog em

http://blog.crisp.se/henrikkniberg.
Importante: Depois da reunio de planejamento do sprint, nosso scrum
master atualiza manualmente o product backlog no Excel com respeito a
quaisquer mudanas que foram feitas aos cartes fsicos de estrias. Sim,
isso um pequeno inconveniente administrativo, mas ns achamos
perfeitamente aceitvel considerando o quo mais eficiente a reunio de
planejamento do sprint com cartes fsicos.
Uma nota sobre o campo Importncia. Essa a importncia como
especificado no product backlog do Excel no momento da impresso. Tlo no carto torna fcil ordenar os cartes fisicamente por importncia
(normalmente colocamos os itens mais importantes esquerda, e os
menos direita). Entretanto, uma vez que os cartes esto na parede, voc
pode ignorar a classificao de importncia e usar a ordenao fsica na
parede para indicar importncia relativa. Se o product owner troca dois
itens, no perca tempo atualizando a classificao de importncia no
papel. Certifique-se de atualizar a classificao de importncia no product
backlog do Excel somente depois da reunio.
Estimativas de tempo so mais fceis (e mais precisas) de fazer se a
estria quebrada em tarefas. Ns usamos o termo atividade pois a
palavra tarefa significa algo completamente diferente em sueco :o)
Isso tambm bom e fcil de fazer com nossos cartes. Voc pode dividir
a equipe em pares e cada um quebra uma estria, em paralelo.
Fisicamente ns fazemos isso adicionando pequenas notas em post-it
embaixo de cada estria, cada post-it refletindo uma tarefa dentro daquela
estria.
Ns no atualizamos o product backlog do Excel com respeito a nossas

quebras em tarefas por duas razes:
A quebra de tarefas geralmente bastante voltil, i.e. elas so
freqentemente alteradas e refinadas durante o sprint, ento d
muito trabalho manter product backlog do Excel sincronizado.
O product owner no precisa estar envolvido neste nvel de
detalhes, mesmo.
Assim como com os cartes de estrias, os post-its de quebra de tarefas
podem ser reusados diretamente no sprint backlog (veja pg. 49 Como
fazemos os sprint backlogs).
Definio de pronto
importante que o product owner e a equipe concordem com uma
definio clara de pronto. Uma estria est completa quando todo o
cdigo est no repositrio? Ou est completa apenas quando foi feito
deploy em um ambiente de teste e a estria foi verificada por uma equipe
de testes de integrao? Sempre que possvel ns usamos a definio
pronto para deploy em produo, mas algumas vezes precisamos usar a

definio feito deploy em servidor de teste e pronto para os testes de
aceitao.
No incio costumvamos ter checklists detalhados para isso. Atualmente
ns frequentemente dizemos uma estria est pronta quanto o tester da
equipe Scrum diz que est. responsabilidade do tester se certificar de
que a inteno do product owner foi compreendida pela equipe e que o
item est suficientemente pronto para que passe pela definio de
pronto acordada.
Ns percebemos que nem todas as estrias podem ser tratadas da mesma
forma. Uma estria com o nome Formulrio para pesquisa de usurios
ser tratada de forma muito diferente de uma estria com o nome Manual
de operaes. No segundo caso, a definio de pronto pode
simplesmente significar aceito pela equipe de operaes. por isso que
o senso comum geralmente melhor do que checklists formais.
Se voc frequentemente se confunde quanto definio de pronto (o
que ocorreu conosco no incio) voc provavelmente deveria ter um campo
definio de pronto para cada estria individual.
Estimativa de tempo usando planning poker

Estimar uma atividade da equipe cada membro freqentemente
envolvido pra estimar cada estria. Por que?

Quando vamos planejar, normalmente ns no sabemos

exatamente quem vai implementar quais partes de quais estrias.
Estrias normalmente envolvem diversas pessoas e diversos tipos
de expertise (design de interface de usurio, codificao, teste,
etc).
Para prover uma estimativa, o membro da equipe precisa de
algum tipo de entendimento do qu trata a estria. Pedindo para
todos estimarem cada item, ns nos certificamos que cada
membro da equipe compreende do que cada item se trata. Isso
aumenta a probabilidade de que os membros se ajudaro durante
o sprint. Isso tambm aumenta a probabilidade de que questes
importantes sobre a estria surjam cedo.
Quando pedimos que todos estimem uma estria, freqentemente
descobrimos discrepncias onde duas pessoas da equipe tm
estimativas bastante diferentes para a mesma estria. Esse tipo de
coisa melhor ser descoberto e discutido o quanto antes.

Se voc pedir equipe para que gere uma estimativa, normalmente a
pessoa que melhor entende a estria ser a primeira a revelar a sua.
Infelizmente, isso afetar fortemente as estimativas de todo o resto.
H uma tcnica excelente para evitar isso ela chamada planning poker
(cunhada por Mike Cohn, eu acho).
Cada membro da equipe recebe um baralho de 13 cartas como mostrado

acima. Sempre que uma estria deve ser estimada, cada membro escolhe
uma carta que representa a sua estimativa de tempo (em pontos por
estria) e coloca-a virada para baixo sobre a mesa. Quando todos os
membros da equipe tiverem feito sua estimativa, as cartas so reveladas
simultaneamente. Dessa forma, cada membro da equipe forado a
pensar por si prprio ao invs de basear-se na estimativa de outra pessoa.
Se houver uma grande divergncia entre duas estimativas, a equipe
discute as diferenas e tenta chegar a uma viso comum do trabalho
envolvido na estria. Eles podem fazer algum tipo de decomposio de
tarefas. Depois disso, a equipe faz novamente a estimativa. Esse processo
repetido at que as estimativas de tempo cheguem a uma convergncia,
isto , todas as estimativas sejam aproximadamente a mesma para cada
estria.
importante lembrar aos membros da equipe que eles devem estimar a
quantidade total de esforo envolvido na estria. No somente a sua
parte do trabalho. O testador no deve somente estimar a quantidade de
esforo de teste.
Note que a seqncia de nmeros no linear. For exemplo, no h nada
entre 40 e 100. Por qu?
Assim evita-se a falsa sensao de preciso para grandes estimativas de
tempo. Se uma estria estimada em aproximadamente 20 postos por
estria, no relevante se ela deve ser 20 ou 18 ou 21. Todos sabemos
que uma estria grande e que difcil estimar. Portanto, 20 o nosso
palpite aproximado.
Quer estimativas mais detalhadas? Ento, quebre a estria em estrias
menores e estime-as!
E no, voc no pode trapacear combinando um 5 e um 2 para fazer um 7.
Voc deve escolher 5 ou 8. No h um 7 nas cartas.

Existem algumas cartas especiais:
0 = esta estria j est feita ou esta estria to pequena que
leva somente alguns minutos de trabalho;
? = Eu no fao idia alguma;
Xcara de caf = Estou cansado demais para pensar. Vamos
fazer uma pequena pausa.
Esclarecendo Estrias
O pior quando uma equipe orgulhosamente demonstra uma nova
funcionalidade durante o sprint e o product owner franze as
sombrancelhas e diz: Bem, est bonito, mas isso no o que eu pedi!
Como voc assegura que a compreenso que o product owner tem, casa
com a compreenso que a equipe tem sobre a estria? Ou que cada
membro da equipe tem a mesma compreenso de cada estria? Bem, voc
no tem como. Mas aqui vo algumas simples tcnicas para identificar as
piores confuses.
A tcnica mais simples ter certeza que todos os campos foram
preenchidos em cada estria (ou mais especificamente, para cada estria
que for mais importante de ser considerada para essa reunio).
Exemplo 1:
A equipe e o product owner esto felizes com o sprint e prontos para
terminar o encontro. O scrum master diz Esperem um segundo, na
estria chamada adiciona usurio, no h estimativa. Vamos estimar!
Depois de algumas rodadas de planning poker a equipe concorda com 20
pontos por histria enquanto o product owner levanta e enfaticamente diz:
-O queeeee?!. Depois de alguns minutos de discusso acalourada, ela se
transforma numa no compreenso, por parte da equipe, sobre o escopo
adicionar usurio, eles acreditaram ser uma boa interface web para
adicionar, remover e proucurar por usurios, enquanto o product owner
compreendeu adicionar usurios como uma chamada manual usando
SQL num banco de dados. Eles estimam novamente e concordam em 5
pontos por estria.
Exemplo 2:
A equipe e o product owner esto felizes com o plano do sprint e prontos
para terminar o encontro. O scrum master diz: Esperem um segundo,
como a estria adicionar usurios ser demonstrada? algum murmurinho
depois e algum se levanta e diz: Bem, primeiro logamos no site e a
ento... e o product owner interrompe: Logamos no site?! No, no,

no, essa funcionalidade no dever ser parte do web site de forma
alguma, isso dever ser apenas um script SQL para administradores
tcnicos.
A descrio de como demonstrar a estria pode e deve ser muito breve!
Ou voc nunca vai encerrar a reunio de planejamento do sprint a tempo.
Isso basicamente uma descrio por alto de como executar os mais
tpicos testes de cenrio manualmente. Faa isso, faa aquilo, e verifique
isso.
Eu descobri que essa simples descrio cobre freqentes
desentendimentos sobre o escopo da estria. Bom descobri-las cedo,
certo?
Quebrando estrias em estrias menores

Estrias no deveriam ser muito pequenas nem muito grandes (em termos
de estimativas). Se voc possui um grupo de estrias de 0.5 ponto, voc
provavelmente ser uma vtima do microgerenciamento. Da mesma
forma, uma estria de 40 pontos ter grande risco de terminar
parcialmente completa, o que no produz valor sua empresa e apenas
amplia a administrao. Ainda assim, se sua velocidade for 70 e as duas
estrias de maior prioridade possuirem o peso de 40 pontos por estria
cada, o planejamento torna-se um pouco difcil. Voc dever escolher
entre comprometer-se pouco (ex. produzir apenas um item) ou
comprometer-se demais (ex.produzir os dois itens).
Descobrimos que quase sempre possvel quebrar uma estria em
pedaos menores. Apenas tenha certeza de que as partes (estrias
menores) ainda representam entregas com valor de negcio.
Ns normalmente nos empenhamos para estrias estimadas em 2 - 8
homens-dia. Nossa velocidade geralmente entre 40 e 60 para uma
equipe tpica, e isso nos d algo em torno de 10 estrias por sprint.
Algumas vezes sero to poucas quanto 5 e outras vezes sero tantas
quanto 15. Este um nmero gerencivel de cartes para se trabalhar.
Dividindo estrias em tarefas

Espere um momento, qual a diferena entre tarefas e estrias? Uma
pergunta muito apropriada.

A distino bem simples. Estrias so trabalhos que podem ser
entregues e que o product owner tem que se preocupar. Tarefas so
atividades que no podem ser entregues, ou atividades que o product
owner no precisa se preocupar.
Exemplo da diviso de uma estria em outras menores:
Exemplo da diviso de uma estria em tarefas:
Seguem aqui algumas observaes importantes:
Equipes novas no Scrum so relutantes em gastar tempo

dividindo um conjunto de estrias em tarefas como essas.
Algumas sentem que essa uma abordagem em cascata.
Para estrias que no foram claramente entendidas, to simples

fazer essa diviso logo, ou mais tarde.
Esse tipo de diviso freqentemente revela trabalho adicional que

faz com que a estimativa de tempo aumente, mas por outro lado
resulta em um planejamento do sprint mais realista.
Esse tipo de diviso logo cedo torna as reunies dirias do scrum

notavelmente mais eficientes (veja pgina 64 Como fazemos as
reunies dirias).
Mesmo que a diviso seja imprecisa e mude quando o trabalho

iniciar, as vantagens acima ainda aplicam-se.
Assim, ns tentamos fazer o espao de tempo do planejamento do scrum
grande o bastante para acomod-la, mas se o tempo esgota-se, deixemos
ela de lado (veja Onde desenhar a linha abaixo).
Nota ns praticamos TDD (test driven development desenvolvimento
orientado a testes) que na prtica significa que a primeira tarefa para
quase todas as estrias escrever um teste de defeito e a ltima tarefa
refazer (= melhorar a legibilidade do cdigo e remover duplicidades).
Definindo a hora e lugar da reunio diria

Uma sada frequentemente esquecida da reunio de planejamento de
sprint hora e local para a reunio diria do scrum definidos. Sem isto,
seu sprint ter um mau incio. A primeira reunio diria essencial para o
lanamento onde todos decidem comear a trabalhar.

Eu prefiro reunies matutinas. Mas, eu devo admitir, ns no tentamos
fazer reunies dirias na tarde ou meio-dia..
Desvantagem de reunies vespertinas: quando voc for trabalhar de
manh, voc tem que tentar se lembrar do que falou ontem para as pessoas
sobre o que faria hoje.
Desvantagem de reunies matutinas: quando voc for trabalhar de
manh, voc tem que se lembrar do que fez ontem, pra que possa reportar
isto.
Na minha opinio, a primeira desvantagem pior, porque o mais
importante o que voc vai fazer, no o que voc fez.
Nosso procedimento padro selecionar o horrio mais cedo sem que
ningum reclame. Normalmente 9:00, 9:30 ou 10:00. O mais importante
que seja uma hora que todos da equipe aceitem completamente, de
corao.
Onde traar a linha

OK, ento o tempo est acabando. De todas as coisas que queremos fazer
durante a reunio de planejamento do sprint, o que ns devemos cortar, se
o tempo acabar?
Bem, eu uso a seguinte lista de prioridades:
Prioridade 1: Um objetivo para o sprint e uma data para a realizao da
demonstrao. Isto o mnimo que voc precisa para iniciar um sprint. A
equipe tem um objetivo e uma data de trmino, e eles podem trabalhar a
partir do product backlog. ruim, sim, e voc deve seriamente considerar
o agendamento de uma nova reunio para planejamento do sprint para o
dia seguinte, mas se voc realmente precisa iniciar o sprint, isto dever
ajudar. Para ser honesto, eu nunca iniciei um sprint com esta pequena
informao.
Prioridade 2: Lista de estrias que a equipe aceitou trabalhar neste sprint.
Prioridade 3: Preencha a informao de estimativa para cada estria do
sprint.

Prioridade 4: A informao Como demonstrar deve ser preenchida em
cada estria do sprint.
Prioridade 5: Clculos de velocidade e recursos, como uma verificao
de realidade para o seu plano de sprint. Inclui lista de membros da equipe
e o comprometimento deles (de outra forma no se consegue calcular
velocidade).
Prioridade 6: Hora e local especfico para a reunio diria. Se decide isto
de forma muito rpida, mas se voc no tiver tempo o scrum master pode
simplesmente decidir isto depois da reunio e pode avisar todos por email.
Prioridade 7: Estrias quebradas em tarefas. Esta quebra pode ser feita
diariamente, assim como as reunies dirias, mas isto vai gerar uma leve
interrupo no fluxo do sprint.
Estrias tcnicas
Eis aqui um problema complexo: Estrias tcnicas. Ou itens no
funcionais. Ou como voc preferir cham-los.
Estou referindo-me quelas coisas que precisam ser feitas mas que no
fazem parte das entregas, no esto relacionadas diretamente com
nenhuma estria especfica e no agregam valor para o product owner.
Ns as chamamos de estrias tcnicas.
Por exemplo:
Instalar um servidor de build
o Por que necessrio: porque economiza uma enorme
quantidade de tempo para os desenvolvedores e reduz o
risco dos problemas de integrao ao fim da iterao.
Escrever um resumo do projeto do sistema

o Por que necessrio: Porque os desenvolvedores
insistem em esquecer-se do projeto geral e, em
conseqncia, de escrever um cdigo consistente.
Precisam de um documento do tipo resumo para
manter todos na mesma linha de projeto.
Refazer a camada DAO

o
Por que necessrio: Porque a camada DAO tem sido

uma total desordem e tem tomado tempo de todos devido
a essa confuso e aos bugs desnecessrios. Limpar esse
cdigo vai economizar tempo de todos e aumentar a
robustez do sistema.
Fazer o upgrade do Jira (bug tracker)

o Por que necessrio: A verso atual tem muitos bugs e
lenta. Fazer o upgrade vai economizar tempo de todos.
Essas estrias fazem parte do senso comum? Ou elas esto conectadas

com alguma estria especfica? Quem as prioriza? O product owner
deveria envolver-se com essas coisas?
Fizemos vrias experincias com diferentes maneiras de lidar com
estrias tcnicas. Tentamos trat-las como estrias de primeira classe,
como todas as outras. No funcionou bem. Quando o product owner
priorizou o backlog, foi como comparar maas com laranjas. De fato, por
razes obvias as estrias tcnicas obtinham sempre prioridade menor
devido ao modo de pensar como: ok, pessoal, Estou certo de que um
servidor de build contnuo importante, mas vamos atacar primeiro
alguma coisa que possamos faturar! E ento podemos adicionar o
brinquedo tecnolgico mais tarde, OK?
Em alguns casos o product owner tem razo, mas quase sempre no tem.
Conclumos que o product owner nem sempre esta qualificado para tomar
estas decises. Assim, o que fazemos :
1) Tentamos evitar as estrias tcnicas. Procure transformar uma
estria tcnica em uma estria normal, com valores de negcio
mensurveis. Desse jeito o product owner vai ter uma chance
maior de tomar as decises corretas.
2) Se no conseguirmos transformar uma estria tcnica em uma
estria normal, veja se o trabalho pode ser feito como uma tarefa
dentro de outra estria. Por exemplo: refatorar a camada DAO
pode ser uma tarefa dentro da estria editar usurio, pois ela
envolve a camada DAO.
3) Se os dois itens anteriores falharem, defina-o como uma estria
tcnica, e mantenha uma lista separada destas estrias. Deixe que
o product owner a veja, mas no permita que modifique-a.
Utilizamos o parmetros fator de foco e velocidade estimada
para negociar com o product owner e separar algum tempo no
sprint para implementar as estrias tcnicas.

Exemplo (um dilogo muito semelhante este ocorreu durante uma de
nossas reunies de planejamento do sprint.)

Equipe: "Ns temos trabalho tcnico interno que precisa ser

feito. Gostaramos de dedicar 10% do nosso tempo para faz-lo,
por exemplo, reduzir o fator de foco de 75% para 65%. Tudo
bem?"
product owner: "De jeito nenhum! Ns no temos tempo!"
Equipe: : "Bem, olhe para o ltimo sprint (todas as cabeas
viram pra curva de velocidade no quadro branco). Nossa
velocidade estimada era 80, a atual 30, certo?"
PO: "Exatamente! Ento ns no temos tempo pra servio
interno! Precisamos de novas caractersticas!"
Equipe: "Bem, a razo de nossa velocidade ter se tornado to
baixa foi que perdemos muito tempo tentando integrar verses
funcionais para testes".
PO: Sim, e?
Equipe: Bem, nossa velocidade vai continuar sendo ruim se no
fizermos alguma coisa sobre isso.
PO: Sim, e?
Equipe: "Ento ns propomos subtrairmos aproximadamente
10% deste sprint para configurar um servidor de produo e para
cuidar de outras coisas que iro resolver os problemas de
integrao. Isto provavelmente ir aumentar nossa velocidade de
sprint em pelo menos 20% para cada sprint subsequente. Pra
sempre!"
PO: "Verdade? Ento por qu ns no fizemos isto no sprint
passado?"
Equipe: "Err porque voc no quis que fizssemos."
PO: "Oh, hum, muito bem, parece uma boa idia fazermos isto
agora ento!"
claro, a outra opo s deixar o product owner desinformado ou darlhe um fator de foco no negocivel. Mas no tem desculpa para no
tentar chegar um consenso primeiro.
Se o product owner for um companheiro competente e razovel (e ns
tivemos sorte aqui) sugiro mant-lo to informado quanto possvel e
deix-lo decidir sobre as prioridades. Transparncia um dos valores
centrais do Scrum, certo?
Sistema de acompanhamento de bugs vs.

product backlog
Eis aqui uma armadilha. Excel um timo formato para o product
backlog. Mas voc ainda precisa de um sistema de acompanhamento de
bugs, e o Excel provavelmente no lhe atender. Ns usamos Jira.
Ento, como ns levamos os defeitos registrados no Jira para as reunies
de planejamento do sprint? Eu quero dizer que no devemos apenas
ignor-los e focarmos apenas nas estrias.
Ns tentamos vrias estratgias:
1) O product owner imprime os bugs prioritrios registrados no Jira,
leva-os reunio de planejamento do sprint e afixa-os na parede
junto com as outras estrias (especificando, desse modo,
implicitamente, a prioridade desses itens em comparao com as
outras estrias).
2) O product owner cria estrias que fazem referncia aos itens do
Jira. Por exemplo: consertar os bugs mais crticos dos relatrios
do back office, Jira-124, Jira-126 e Jira-180.
3) O concerto de bugs considerado fora do sprint, p.ex., a equipe
mantm um fator de foco pequeno o suficiente (50%, por
exemplo) para garantir que tenham tempo para consert-los.
Assim, assumem que gastaro um certo perodo de tempo de cada
sprint consertando os bugs.
4) Colocar o product backlog dentro do Jira (p.ex. descartar o
Excel). Trate os bugs como qualquer outra estria.
Ns ainda no conclumos qual dessas estratgias a melhor para ns. De
fato, elas variam de equipe para equipe e de sprint para sprint. Eu sou
propenso a apostar na primeira estratgia. Ela mais legal e mais simples.
A reunio de planejamento do sprint est

finalmente terminada!
Uau, Eu nunca imaginei que este captulo sobre planejamento do sprint
fosse ser to longo! Eu acho que isso reflete a minha opinio de que a
reunio de planejamento do sprint a coisa mais importante que se faz no
Scrum. Empenhe-se bastante para faz-la corretamente e todo o resto ser
muito mais fcil.

A reunio de planejamento do sprint obteve sucesso se todos (os membros
da equipe e o product owner) sairem da reunio com um sorriso no rosto,
acordam na outra manh com um sorriso e todos fazem a primeira reunio
diria com um sorriso.
Ento, claro, tudo pode dar errado no restante do projeto, mas pelo
menos voc no poder culpar o planejamento do sprint :o)
5
Como comunicamos sprints
importante manter a empresa inteira informada sobre o que est
acontecendo. Embora as pessoas reclamem, ou mesmo pior, faam falsas
suposies sobre o que est acontecendo.
Ns usamos a pgina de informaes do sprint para isso.
As vezes ns inclumos informaes sobre como cada estria ser
demonstrada tambm.
O mais cedo possvel depois da reunio de planejamento do sprint, o
scrum master cria esta pgina, pe no ar no Wiki, e envia para a empresa
inteira.
Ns tambm temos a pgina dashboard no nosso wiki, que junta tudo
que est acontecendo nos sprints.
Alm disso, o scrum master imprime a pgina de informao do sprint e

coloca no mural do lado de fora da sala da equipe. Ento todo mundo que
passa pode v-la e descobrir o que a equipe fazendo. Desde que isso
inclua o tempo e o lugar da reunio diria e da apresentao do sprint, se
saber onde ir para descobrir mais.
Quando o sprint est perto do fim, o scrum master lembra todo mundo
sobre a apresentao que ocorrer em breve.
Feito tudo isso, ningum tem desculpa pra no saber o que est
acontecendo.
6
Como fazemos os sprint backlogs
Voc j fez isso alguma vez? Uau! Bom trabalho.
Bem, agora que j completamos a reunio de planejamento do sprint e
contamos ao mundo sobre nosso sprint novinho em folha, hora do
Scrum master criar um sprint backlog. Ele precisa ser feito depois da
reunio de planejamento do sprint, mas antes da primeiro reunio diria
do Scrum.
Formato do sprint backlog

Ns j tentamos alguns formatos diferentes para o sprint backlog,
incluindo Jira, Excel e um quadro de tarefas pregado na parede. No
princpio ns usamos principalmente Excel. Existem vrios modelos
prontos de sprint backlogs em Excel, incluindo grficos de burndown
automticos e coisas do gnero. Eu poderia falar bastante como ns
refinamos nossos sprint backlogs em Excel. Mas no farei isso. No vou
nem incluir um exemplo aqui.
Ao invs disso, irei descrever em detalhes o que ns temos visto ser o
formato mais produtivo para o sprint backlog um quadro de tarefas
pregado na parede!
Encontre uma parede grande que no utilizada ou que tem coisas inteis,
como o smbolo da empresa, diagramas velhos e quadros feios. Limpe a
parede (s pea permisso se for necessrio). Cole uma folha de papel
bem grande, bem grande mesmo (pelo menos 2m de altura x 2m de
largura, ou 3x2m para uma equipe grande). Ento faa assim:
claro que voc poderia usar um quadro branco. Mas seria um
desperdcio. Se possvel, use os quadros-brancos para rascunhos de
projeto e as outras paredes para os quadros de tarefas.
COMO FAZEMOS SPRINT BACKLOGS | 47

NOTA se voc usar post-its para tarefas, no esquea de col-los usando
durex ou fita crepe mesmo, ou voc ir encontrar todos eles misturados no
cho no dia seguinte.
Como funciona o quadro de tarefas

Voc pode, claro, adicionar todo tipo de colunas adicionais. Esperando
pelo teste de integrao por exemplo. Ou Cancelado. Entretanto antes
de complicar as coisas, pense profundamente. Esta adio de coluna
realmente necessria?
Eu descobri que simplicidade extremamente vlida para este tipo de
coisa, ento eu apenas adiciono complicaes quando o custo de no fazer
muito alto.
Exemplo 1 depois da primeira reunio diria

Depois da primeira reunio diria, o quadro de tarefas vai parecer como
este:
Como se pode ver, trs tarefas foram selecionadas e colocadas em
produo. A equipe vai trabalhar nestas tarefas hoje.
s vezes, para equipes grandes, uma tarefa fica presa na etapa de
produo pois ningum lembra quem estava trabalhando nela. Se isto
acontecer de forma recorrente em uma equipe, normalmente se define
uma poltica como rotular as tarefas em produo com o nome da pessoa
que est trabalhando nela.
Exemplo 2 poucos dias depois

Poucos dias depois, o quadro de tarefas pode se parecer com algo assim:
Como pode ver, completamos a estria depsito (i.e. foi integrada ao

repositrio com o cdigo fonte, testada, refatorada, etc). A ferramenta de
migrao est parcialmente completa, a parte do login foi iniciada e a
parte de administrao de usurios no comeou.
Tivemos 3 itens no-planejados, como pode se ver na parte inferior
direita. Guard-los til para que sejam lembrados quando voc for fazer
a retrospectiva do sprint.
Eis um exemplo de um sprint backlog real perto do fim do sprint. Ele de

fato fica meio bagunado com o andamento do sprint, mas isso est OK
pois sua vida curta. A cada novo sprint, ns criamos um fresco, limpo e
novo sprint backlog.
Como funciona o grfico de burndown

Vamos dar um zoom no grfico de burndown:
Este grfico mostra que:

No primeiro dia do sprint, 1 de agosto, a equipe estimou que
havia aproximadamente 70 pontos por estria de trabalho a serem
feitos. Isso foi na verdade a velocidade estimada de todo o sprint.
Em 16 de agosto a equipe estimou que havia aproximadamente
15 pontos por estria de trabalho a serem feitos. A linha de
tendncia tracejada mostra que eles esto aproximadamente
dentro do prazo, isto , neste ritmo eles completaro tudo at o
final do sprint
Ns pulamos os finais de semana no eixo-x, uma vez que o trabalho
raramente executado aos finais de semana. Ns costumvamos incluir
finais de semana mas isso tornaria o grfico de burndown um pouco
confuso, j que o mesmo ficaria reto
nos finais de semana e isso
poderia parecer um sinal de alarme.
Sinais de alarme do quadro de tarefas

Uma olhada rpida no quadro de tarefas daria a qualquer um uma
indicao de quo bem o sprint est progredindo. O scrum master
responsvel por garantir que a equipe haja quando surgirem sinais de
alarme como:
Ei, e a rastreabilidade?!
A melhor rastreabilidade que eu posso sugerir neste modelo tirar uma
foto digital do quadro de tarefas todo dia. Eu fao isso s vezes, mas eu
nunca encontrei um motivo para vasculhar estas fotos.
Se rastreabilidade muito importante para voc, ento o quadro de tarefas
talvez no seja uma boa soluo para voc.
Mas eu sugiro que voc realmente tente estimar o valor real de ter uma
rastreabilidade detalhada do sprint. Uma vez que o sprint est pronto, o
software funcionando e a documentao entregue, algum realmente se
preocupa com quantas estrias foram completadas no dia 5 de um sprint?
Algum realmente se preocupa com qual era o tempo estimado para
escrever um teste de falha para Depsito?
Estimando dias vs horas

Na maioria dos livros e artigos sobre Scrum, voc vai encontrar que as
tarefas so estimadas em horas, e no em dias. Costumvamos fazer isto.
Nossa formula geral era: 1 homem-dia = 6 horas-homem reais.
Atualmente deixamos de fazer assim, pelo menos na maior parte de nosso
grupo, pelas seguintes razes:
As estimativas em homem-hora eram muito granulares, e isto
provocava uma tendncia a estimar muitas tarefas de 1-2 horas e
a conseqente micro gerencia.
De qualquer forma, como todos estavam pensando em temos de
homens-dias, e simplesmente multiplicavam por 6 antes de
escrever homem-hora. Hmmmm, esta tarefa deve gastar um dia.
Bom, tenho que escrever horas, ento escrevo 6 horas.
Duas unidades diferentes podem causar confuso. Esta
estimativa em homem-hora ou homem-dia?
Assim, atualmente usamos o homem-dia para todas as nossas estimativas
(embora continuemos chamando de pontos por estria - story points).
Nosso menor valor 0,5, isto , qualquer tarefa que menor que 0,5 ser
eliminada, combinada com outras tarefas ou receber o valor de 0,5. (No
tem problema superestimar um pouco). Simples e elegante.
7
Como arrumamos a sala da equipe
O canto do design
Eu notei que muitas das mais interessantes e valiosas discusses sobre
design acontecem espontaneamente na frente do quadro de tarefas.
Por esta razo, ns tentamos arrumar esta rea explicitamente como um
canto do design.
Isto realmente bem til. No h forma melhor de ter uma viso geral do
sistema do que ficar no canto do design e dar uma olhadela em ambas as
paredes, e ento dar uma olhadela no computador e tentar o ltimo build
do sistema (se voc for sortudo o bastante para ter build contnuo, veja pg
81 Como combinamos Scrum e XP).
A parede do design s um grande quadro-branco contendo os rabiscos
de design e esboos (printouts) da documentao de design mais
importante (grficos de seqncias, prottipos de GUI, modelos de
domnio, etc).
Acima: uma reunio diria acontecendo no canto mencionado.

Hmmmm..... aquele burndown parece suspeitosamente legal e direto, no. Mas a
equipe insiste que real :o)

Com relao aos assentos e a organizao das mesas de trabalho h uma
coisa que pode no ter sido reforada o suficiente:

Para esclarecer um pouquinho mais, o que eu estou dizendo

As pessoas so relutantes para mudar. Pelo menos nos lugares onde eu
trabalhei. Eles no querem ter que juntar todas as suas coisas, desconectar
o computador, mover todas as suas tralhas para uma nova mesa, e
conectar tudo de novo. Quanto menor a distncia, maior a relutncia,
Vamos l chefe, para que mudar somente 5 metros?.
Mas quando estamos construindo equipes de Scrum eficientes no h
outras alternativas. Somente mantenha a equipe junta. Mesmo que voc
tenha que pessoalmente ameaar cada um, carregar todo o equipamento
deles, e limpar suas velhas manchas de caf. Se no h espao para a
equipe, crie um espao. Qualquer lugar. Mesmo se voc tiver que colocar
a equipe no poro. Mova as mesas ao redor, suborne o gerente
responsvel, faa o que for necessrio. Somente mantenha a equipe junta.
Uma vez que voc tenha a equipe toda junta, o retorno ser imediato.
Depois de somente um sprint a equipe ir concordar que foi uma boa idia
sentar junto (falando por experincia pessoal, mas no h nada dizendo
que a sua equipe no ser to teimosa para no admitir isto).
Agora o que junto significa? Como devem ser distribudas as mesas de
trabalho? Bem, eu no tenho nenhuma opinio firme sobre a melhor
distribuio das mesas. E mesmo que eu tivesse, eu acredito que a maioria
das equipes no tenha o luxo de decidir exatamente como posicionar suas
mesas de trabalho. Geralmente existem restries fsicas a equipe
vizinha, a porta do banheiro, uma grande mquina caa-nqueis no meio
da sala, o que for.
Junto significa:
Audibilidade: Qualquer um da equipe pode conversar com o
outro sem gritar ou sair da mesa.
COMO ARRUMAMOS A SALA DA EQUIPE | 55
Visibilidade: Todos da equipe podem ver todos os demais. Cada

um da equipe consegue ver o quadro de tarefas. No
necessariamente perto o suficiente para l-lo, mas pelo menos
para v-lo.
Isolamento: Se toda equipe de repente levantar e se envolver em
uma espontnea e animada discusso sobre implementao, no
haver ningum de fora da equipe perto o suficiente para ser
perturbado. E vice-versa.
"Isolamento" no significa que a equipe tenha que ficar completamente

isolada. Em um ambiente de trabalho aberto e repartido em cubculos
pode ser suficiente que a equipe tenha seu prprio cubculo com paredes
altas o bastante para filtrar o mximo do barulho das outras equipes.
E se voc tiver uma equipe distribuda? Bem, ento voc est sem sorte.
Use o mximo de resursos tcnicos que voc puder para minimizar o dano
vdeo conferncia, webcams, ferramentas de compartilhamento da rea
de trabalho, etc.
Mantenha o product owner por perto

O product owner deve estar suficientemente perto para permitir que a
equipe possa ir onde esta e perguntar qualquer coisa, e tambm para que
ele possa ir ao quadro de tarefas. Mas ele no deve estar junto a equipe.
Por que? Porque ele provavelmente no ser capaz de se controlar e no
se meter em detalhes e a equipe no fluir adequadamente (isto ,
alcanar um estado focado, hiperprodutivo e auto-gerenciado)
Para ser honesto, isto uma especulao. Nunca vi um caso em que o
product owner esteve junto da equipe, de modo que no tenho nenhum
motivo para dizer que no uma boa idia. s uma intuio pessoal e o
que comentam outros scrum masters.
Mantenha os gerentes e coaches por perto

Isto um pouco difcil para escrever, pois fui tanto gerente quanto
coach...
Minha tarefa era trabalhar o mais prximo possvel da equipe. Formei os
grupos, me movia entre eles, programava em pares com outras pessoas,
ajudava outros scrum masters, organizava reunies de planejamento de
sprint, etc. Fazendo um retrospecto, a maioria das pessoas considerou isso

como uma Coisa Boa, j que tinha alguma experincia com o
desenvolvimento gil de software.
Mas, ento, eu era tambm (entra a musica tema do Darth Vader) o chefe
de desenvolvimento, um perfil funcional gerencial. O que significa que ao
entrar em uma equipe ela se tornava automaticamente menos autogerenciavel. caramba, o chefe est aqui, ele provavelmente tem um
monte de opinies sobre o que deveramos estar fazendo e sobre quem
deveria estar fazendo o que. Vamos deixar ele falar!
Meu ponto de vista : se voc um coach Scrum (e talvez tambm um
gerente), envolva-se o mximo possvel. Porem s por uma perodo
limitado de tempo, ento saia e deixe o grupo fluir e se auto-gerenciar.
Verifique a equipe de vez em quando (no muito freqentemente)
participando das apresentaes de sprint e observando o quadro de tarefas
e escutando os scrum matinais. Se voc encontrar uma rea onde pode
haver melhorias, rena-se com o scrum master e ajude-o. NUNCA em
frente a equipe. Outra boa idia participar das retrospectivas do sprint
(veja na pagina 77 Como fazemos as retrospectivas do sprint), desde que
sua equipe confie suficientemente em voc para que sua presena no os
iniba.
Para as equipes Scrum que funcionam bem, garanta que tenham tudo o
que precisam e tire do caminho tudo aquilo que pode atrapalhar (exceto
durante as apresentaes de sprint).
8
Como fazemos as reunies dirias
Nossas reunies dirias (daily scrums) so seguidas bem a risca. Elas
comeam exatamente na hora, todo dia no mesmo lugar. No comeo ns
amos para um sala separada para fazer o planejamento do sprint (esses
eram os dias que usvamos o sprint backlog eletrnico). No entanto, agora
ns fazemos nossas reunies dirias na sala da equipe na frente do quatro
de tarefas. Nada supera isso.
Ns normalmente fazemos as reunies em p, uma vez que isso reduz o
risco de ultrapassar 15 minutos.
Como atualizamos o quadro de tarefas

Normalmente atualizamos o quadro de tarefas durante a reunio diria.
Conforme cada pessoa descreve o que fez ontem e o que far hoje, vai
colocando post-its no quadro de tarefas. Enquanto essa pessoa descreve
um item no planejado, tambm cria um post-it para este item. Quando
atualiza uma estimativa de prazo, atualiza a mesma no respectivo post-it
escrevendo a nova e riscando a estimativa antiga. s vezes o scrum
master faz o trabalho com os post-its enquanto as outras pessoas
conversam.
Algumas equipes tm a poltica de que cada pessoa deve atualizar o

quadro de tarefas antes de cada reunio. Isso tambm funciona bem.
Apenas escolha uma poltica e se atenha a ela.
Independente do formato em que seu sprint backlog est, tente fazer com
que toda a equipe se envolva na tarefa de manter o sprint backlog
atualizado. Ns tentamos realizar sprints onde o scrum master era o nico
mantenedor do sprint backlog e todos os dias tinha que sair e perguntar as
pessoas sobre suas estimativas de prazo. As desvantagens disso so:

O Scrum master gasta tempo demais administrando essas coisas,

ao invs de apoiando a equipe e removendo impedimentos.
Os membros da equipe perdem a noo do status do sprint, uma
vez que o sprint backlog no algo com o que eles precisem se
preocupar. Essa falta de feedback reduz a agilidade e o foco da
equipe.
Se o sprint backlog for bem definido, cada membro da equipe poder

atualiz-lo facilmente.
Imediatamente aps a reunio diria do Scrum, algum totaliza todas as
estimativas de prazo (obviamente, excluindo aquelas que estiverem na
coluna de prontos) e marca um novo ponto no sprint burndown.
Lidando com atrasados

Algumas equipes possuem um pote de moedas e notas. Quando voc se
atrasa, mesmo que apenas um minuto, voc coloca um valor prdeterminado no pote. Sem argumentao. Se voc ligar antes da reunio
avisando que vai se atrasar, ainda assim tem que pagar.
Voc s se livra dessa se tiver uma boa desculpa, como consulta mdica,
seu prprio casamento ou algo do tipo.
O dinheiro do pote usado para eventos sociais. Comprar sanduches
quando temos noite de jogo, por exemplo. :o)
Isso funciona bem. Mas s necessrio para equipes onde as pessoas se
atrasam freqentemente. Algumas equipes no precisam desse tipo de
mtodo.
Lidando com o no sei o que fazer hoje

No raro algum dizer "Ontem eu fiz bla bla bla, mas hoje eu no tenho
a mnima ideia do que fazer " (ei, essa ultima parte rimou). E agora?
Vamos dizer que Joe e Lisa so os que no sabem o que fazer hoje.
Se eu sou scrum master, eu apenas passo e deixo a prxima pessoa falar,
mas anoto a pessoa que no tem nada para fazer. Depois de todos terem
falado, eu vou ao quadro de tarefas com toda a equipe, de cima para
baixo, e verifico que tudo est em sincronia, que todos sabem o que cada
COMO FAZEMOS AS REUNIES DIRIAS | 59

item significa, etc. Eu convido as pessoas a adicionarem mais post-its.
Ento eu volto para aquelas pessoas que no sabem o que fazer: "agora
que ns passamos pelo quadro de tarefas, vocs tem alguma idia sobre o
que vocs podem fazer hoje"? Tomara que tenham.
Se no, eu avalio se h uma oportunidade de programao em par. Vamos
dizer que Niklas est indo implementar a GUI de back office do usurio
administrador hoje. Nesse caso eu educadamente sugiro que talvez Joe e
Lisa possam fazer par com Niklas nisso. Normalmente funciona.
E se aquilo no funcionar, aqui est o prximo truque.
Scrum master: OK, quem quer mostrar a release beta pra gente?
(considerando que isso era o objetivo do sprint)
Equipe: silncio confuso
Scrum master: No estamos prontos?
Equipe: hum... no
Scrum master: Mas que coisa. Por que no? O que est faltando?
Equipe: Bem, no temos o servidor de testes pra rodar, e o script de
gerao de build est falhando.
Scrum master: Aha. (adiciona dois post-its no quadro de tarefas). Joe
e Lisa, como podem nos ajudar hoje?
Joe: Hum.... Acho que vou tentar algum servidor de testes em algum
lugar.
Lisa: ... e eu vou tentar arrumar o script da build.
Se tiver sorte, algum de fato ir mostrar a release que pediu. timo!
Voc atingiu o objetivo do sprint. Mas e se estiver no meio do sprint?
Fcil. Parabenize a equipe pelo trabalho bem feito, pegue uma ou duas
estrias da seo prximos no seu quadro de tarefas e passe para a
fazer esquerda. Ento refaa a reunio diria. Notifique o product
owner que voc adicionou novos itens no sprint.
Mas o que acontece se a equipe no alcanou o objetivo e Joe e Lisa ainda
se recusam a fazer algo til. Eu normalmente considero uma das seguintes
estratgias (nenhuma delas muito agradvel mas uma ltima
alternativa):
Vergonha: Bem eu no tenho nenhuma idia de como vocs

podem ajudar a equipe mas acho que talvez vocs possam ir para
casa, ler um livro ou alguma outra coisa. Ou apenas se sentar e
ver se algum precisa de ajuda..
Velha-Escola: Apenas atribua-os uma tarefa.
Presso do par: Diga Usem o tempo que for necessrio, Joe e

Lisa. Ns todos estaremos esperando aqui sem pressa at que
vocs possam arrumar algo que nos ajude a alcanar o objetivo.
Servido: Diga Vocs podem ajudar a equipe indiretamente
sendo mordomos hoje. Faam caf, massageiem as pessoas,
limpem o lixo, cozinhem-nos algo para comer, e qualquer outra
coisa que ns pedirmos durante o dia. Vocs se surpreendero
em quo rapidamente Joe e Lisa se apresentaro para as tarefas
tcnicas :o)
Se uma pessoa freqentemente te forar a tomar esse tipo de medidas,

voc precisa remov-la do grupo e dar um srio treinamento. Se o
problema persistir, voc deve avaliar o quanto a pessoa importante para
a equipe.
Se no for, tente remov-la da equipe.
Se for, tente pare-lo com algum que possa ser o seu pastor. Joe ser
um timo desenvolvedor e arquiteto, apenas ele prefere que outra pessoa
lhe fale o que fazer . Perfeito. D Nicklas o dever de ser o pastor
permanente de Joe. Ou assuma a responsabilidade voc mesmo. Se Joe
importante o suficiente para sua equipe, isso ser um esforo vlido. Ns
tivemos casos como esse e isso funcionou mais ou menos.
9
Como fazemos apresentaes de sprint
A apresentao de sprint (ou reviso de sprint como algumas pessoas
chamam), uma parte importante do Scrum que as pessoas tendem a
subestimar.
Oh ns realmente precisamos fazer uma apresentao? Realmente no h
muita diverso para mostrar!
Ns temos tempo para preparar a &%$# de uma apresentao!
Eu no tenho tempo para assistir s apresentaes de outras equipes!
Por que insistimos que todos os sprints

terminem com uma apresentao
Uma apresentao de sprint bem feita, apesar disso poder parecer
dramtico, tem um efeito profundo.
A equipe ganha crdito por suas realizaes. Eles se sentem bem.
Outros aprendem o que sua equipe est fazendo.
A apresentao atrai feedback vital dos stakeholders.
Apresentaes so (ou deveriam ser) um evento social onde
equipes diferentes podem interagir umas com as outras e discutir
seu trabalho. Isso tem muito valor.
Fazer uma apresentao fora a equipe a realmente terminar as
coisas e liber-las (mesmo que seja apenas em um ambiente de
teste). Sem apresentaes, ns continuamos recebendo imensas
pilhas de coisas 99% prontas. Com apresentaes ns podemos
ter menos itens prontos, mas estes itens estaro realmente
prontos, o que (no nosso caso) muito melhor do que termos
uma pilha inteira de coisas que esto apenas parcialmente prontas
e que iro poluir o prximo sprint.
Se uma equipe mais ou menos forada a fazer uma apresentao do
sprint mesmo no tendo muita coisa funcionando para ser mostrada, a
apresentao ser constrangedora. A equipe ir gaguejar e tropear

durante a apresentao e os aplausos no final sero fingidos. As pessoas
se lamentaro pela equipe, alguns podem ficar irritados por terem perdido
tempo indo uma apresentao ruim.
Isso machuca. Mas o efeito como o de um remdio amargo. No prximo
sprint, a equipe realmente tentar concluir as coisas! Eles pensaro
talvez ns possamos demonstrar apenas 2 coisas no prximo sprint ao
invs de 5, mas poxa, dessa vez elas iro funcionar!. A equipe sabe que
de qualquer forma eles tero que fazer uma apresentao, o que aumenta
significantemente a chance de que haja algo til para demonstrar. Eu vi
isso acontecer muitas vezes.
Checklist para as apresentaes de sprint
Certifique-se de apresentar claramente o objetivo do sprint. Se

houver pessoas na apresentao que no sabem absolutamente
nada sobre seu produto, utilize alguns minutos para descrev-lo.
No gaste muito tempo preparando a apresentao, especialmente
evite enfeitar demais as apresentaes. Corte tudo que no
interessa e foque-se apenas em demonstrar cdigo realmente
funcionando.
Mantenha um bom ritmo, isto , foque sua preparao em fazer
com que a apresentao seja rpida ao invs de bonita.
Mantenha a apresentao em um nvel orientado ao negcio,
deixe de fora detalhes tcnicos. Foque em o que ns fizemos ao
invs de como ns fizemos.
Se possvel, deixe a audincia testar o produto.
No demonstre um monte de correes de pequenos bugs e
funcionalidades triviais. Mencione-as mas no as demonstre, j
que isso geralmente leva muito tempo e desvia o foco das estrias
mais importantes.
Lidando com coisas no demonstrveis

Membro da equipe: Eu no vou demonstrar esse item, porque isso no
pode ser demonstrado. A estria Melhorar a escalabilidade para que o
sistema possa suportar 10.000 usurios simultaneamente. Eu no posso
preparar 10.000 usurios simultaneamente para uma apresentao,
posso?
Scrum master: Voc terminou a estria?
Membro da equipe. Sim, claro.
Scrum master: Como voc sabe?
COMO FAZEMOS AS REUNIES DIRIAS | 63

Membro da equipe: Eu configurei o sistema em um ambiente de teste
de performance, iniciei 8 servidores de carga e disparei requisies
simultneas contra o sistema.
Scrum master: Mas voc tem alguma indicao de que o sistema iria
suportar 10.000 usurios?.
Membro da equipe: Sim. As mquinas de teste estavam com o limite
insignificante, elas ainda poderiam suportar 50.000 requisies
simultneas durante meu teste.
Scrum master: Como voc sabe?
Membro da equipe (frustrado): Bem, eu tenho esse relatrio! Voc
mesmo pode ver, o relatrio mostra como o teste estava configurado e
quantas requisies eu enviei!
Scrum master: Oh excelente! Ento essa sua apresentao. Apenas
mostre o relatrio e passe-o para a platia. Melhor do que nada, n?.
Membro da equipe: Oh, isto suficiente? Mas isso feio, preciso
melhor-lo..
Scrum master: OK, mas no gaste muito tempo. O relatrio no tem
que estar bonito, apenas informativo.
10
Como fazemos retrospectivas de Sprints
Por que insistimos que todas as equipes
faam retrospectivas
A coisa mais importante sobre retrospectivas assegurar-se de que elas
aconteam.
Por alguma razo, equipes nem sempre parecem propensas a fazer
retrospectivas. Sem um estmulo, muitas de nossas equipes
freqentemente no fariam a retrospectiva e seguiriam adiante para o
prximo sprint. Pode ser algo cultural na Sucia, no tenho certeza.
Mesmo assim, todos concordam que retrospectivas so extremamente
teis. Na verdade, eu diria que a retrospectiva o segundo evento mais
importante no Scrum (o primeiro seria a reunio de planejamento do
sprint), pois essa a sua melhor chance de melhorar!
claro, voc no precisa que de uma reunio de retrospectiva, saiam boas
idias. Voc pode fazer isso na sua banheira em casa! Mas a equipe
aceitar a idia? Talvez, mas a probabilidade de obter a aceitao da
equipe muito maior se a idia vem da equipe, isto , ocorre durante a
retrospectiva, quando todos tm permisso para contribuir e discutir as
idias.
Sem retrospectivas, voc descobrir que a equipe continua a cometer os
mesmos erros repetidamente.
Como organizamos retrospectivas

O formato geral varia um pouco, mas geralmente ns fazemos assim:
COMO FAZEMOS RETROSPECTIVAS DE SPRINTS | 65
Ns alocamos 1 a 3 horas dependendo de quanto a discusso j

estiver adiantada.
Participantes: o product owner, a equipe toda, e eu mesmo
(Scrum master).
Ns vamos para uma sala fechada, ou um confortvel sof de
canto, um terrao, ou algum outro lugar como estes. Onde ns
pudermos no ter interrupes.
Ns geralmente no fazemos retrospectivas no espao de trabalho
da equipe, pois as pessoas tendem a perder a ateno.
Algum designado como secretrio.
O Scrum master mostra o sprint backlog e, com a ajuda da
equipe, resume o sprint. Eventos e decises importantes, etc.
Ns fazemos as rodadas. Cada pessoa tem a chance de dizer,
sem ser interrompido, o que eles acharam que foi bom, o que eles
acharam que poderia ter sido melhor, e o que eles gostariam de
fazer de forma diferente no prximo sprint.
Ns comparamos a velocidade estimada com a velocidade
realizada. Se existir uma grande diferena ns tentamos analisar o
motivo.
Quando o tempo j est quase acabado, o Scrum master tenta
resumir as sugestes concretas sobre o que ns poderemos fazer
melhor no prximo sprint.
Nossas retrospectivas no so geralmente muito estruturadas. Mas o tema

subjacente sempre o mesmo: o que ns podemos fazer melhor no
prximo sprint.
Aqui est um quadro de exemplo de uma retrospectiva recente:
Trs colunas:
Bom: se pudssemos refazer o mesmo sprint novamente,
faramos as coisas do mesmo modo;
Poderia ter sido melhor: se pudssemos refazer o mesmo sprint
novamente, faramos as coisas de uma maneira diferente;
Melhorias: idias concretas sobre como podemos melhorar no
futuro;
Assim sendo, as colunas 1 e 2 olham pro passado enquanto que a coluna 3
olha pro futuro.
Depois que a equipe fez o brainstorming com todos esses post-its, eles
usaram uma votao para determinar quais melhorias devem dar ateno

durante o prximo sprint. A cada membro da equipe foi dado trs ms e
foram convidados a votar em quaisquer das melhorias que gostariam que
a equipe priorizasse para execuo durante o prximo sprint. Cada
membro da equipe poderia distribuir os ms como quisesse, at mesmo
colocar todos no mesmo item.
Baseado nisso, selecionaro cinco melhorias de processo para dar ateno
e verificaro isso durante a prxima retrospectiva do sprint.
importante no ser ambicioso demais nesse momento. Mantenha o foco
somente em algumas melhorias por sprint.
Divulgando lies aprendidas entre equipes

A informao que surge durante uma retrospectiva do sprint
normalmente muito valiosa. Esta equipe est com dificuldades de foco por
que o gerente de vendas est sequestrando programadores para
participarem como "especialistas tcnicos" em reunies de vendas? Esta
uma informao importante. Quem sabe outras equipes estejam tendo os
mesmos problemas? Deveramos educar mais o gerente de produtos a
respeito de nossos produtos, para que ele possa ser o apoio s vendas?
Uma retrospectiva de sprint no diz respeito a apenas como uma nica
equipe pode fazer um bom trabalho para o prximo sprint. Possui
implicaes muito maiores que isso.
Nossa estratgia para tratar isso bastante simples. Uma pessoa (neste
caso, eu) participa de todas as retrospectivas de sprint, e age como uma
ponte de conhecimento. Bastante informal.
Uma alternativa seria fazer com que cada equipe publicasse um relatrio
da reunio de retrospectiva. Ns tentamos, mas descobrimos que poucas
pessoas liam estes relatrios, e menos ainda so os que agem atravs
deles. Ento fizemos realmente do jeito mais fcil.
Regras importantes para uma pessoa "ponte de conhecimento":
Deve ser um bom ouvinte
Se a retrospectiva estiver em muito silncio, ele deve estar
preparado para fazer perguntas simples mas estratgicas para
estimular a discusso do grupo. Por exemplo: "se voc pudesse
retornar no tempo e refazer o mesmo sprint por 1 dia, o que seria
feito diferente?"

Deve estar disposto a investir tempo visitando todas as
retrospectivas de todas as equipes.
Deve estar em algum tipo de posio de autoridade, para que
possa agir em sugestes melhorias que estejam fora do controle
da equipe.
Isto funcionou perfeitamente bem, mas podem existir outras abordagens
que funcionariam muito melhor. Neste caso, por favor me elucide.
Mudar ou no mudar
Digamos que a equipe conclua que nos comunicamos muito pouco entre
ns, ento pisamos nos calos dos outros e bagunamos os designs uns dos
outros.
O que voc deve fazer sobre isso? Introduzir reunies dirias de design?
Introduzir novas ferramentas para facilitarem a comunicao? Adicionar
mais pginas wiki? Bem, talvez. Pensando novamente, talvez no.
Descobrimos que, em muitos casos, s identificar o problema com clareza
suficiente o bastante para resolv-lo automaticamente no prximo
sprint. Especialmente se voc cola a retrospectiva do sprint na parede
(sempre nos esquecemos disso, que vergonha pra gente!). Cada mudana
que voc introduz, adiciona algum tipo de custo. Ento, antes de
introduz-las, considere no fazer nada e esperar o problema desaparecer
(ou se tornar menor) automaticamente.
O exemplo acima (nos comunicamos pouco entre ns), um tpico
exemplo de algo que melhor resolvido sem se fazer absolutamente nada.
Se voc intorduzir uma nova mudana a cada vez que algum reclamar de
alguma coisa, pessoas podem se tornar relutantes a revelar problemas
menores, o que seria terrvel.
Exemplos de coisas que podem aparecer

durante as retrospectivas
Aqui vo alguns exemplos de situaes comuns que podem aparecer
durante o planejamento do sprint, e algumas aes.
Ns deveramos ter gasto mais tempo quebrando as

estrias em sub-itens e tarefas
Isto bem comum. Todos os dias na reunio diria, membros da equipe se
pegam dizendo: Eu realmente no sei o que fazer hoje. Ento aps cada
reunio diria voc gasta mais tempo tentando encontrar as tarefas
concretas. Geralmente mais eficaz adiar isto para um momento mais
oportuno.
Aes tpicas: Nenhuma. A equipe provavelmente encontrar uma
soluo por ela mesma durante o prximo planejamento do sprint. Se isto
acontece frequentemente, aumente o tempo do planejamento do sprint.
Interferncias externas demais

Aes tpicas:
pea equipe para reduzir o fator de foco no prximo sprint, assim tero
um plano mais realista
pea equipe para recordar melhor as interferncias no prximo sprint.
Quem interrompeu, quanto tempo tomou. Ser mais fcil resolver o
problema depois.
pea equipe para concentrar as interferncias no scrum master ou
product owner
pea equipe para designar uma pessoa para ser o goleiro. Todas as
interrupes sero repassadas ele, assim o resto da equipe pode se
concentrar. Pode ser o scrum master ou ser revezado entre o resto.
Ns nos comprometemos com coisas demais e s

metade est pronta
Aes tpicas: nada. A equipe provavelmente no vai se comprometer
com coisas demais no prximo sprint. Ou no mnimo no errar por tanto.
Nosso ambiente barulhento e bagunado demais

Aes tpicas:
tente criar um ambiente melhor, ou tire a equipe do local. Alugue

um quarto de hotel, Qualquer coisa. Veja pg 59 Como
arrumamos a sala da equipe ).
Se no for possvel, diga equipe para diminuir o fator de foco no

prximo sprint, e deixar claro que isso se deve ao ambiente
barulhento e bagunado. Espera-se que que isto faa o product
owner tomar alguma atitude sobre isto.

Felizmente nunca tive que mudar a equipe de lugar. Mas faria isto se fosse
necessrio :o)
11
Intervalo entre sprints
Na vida real, nem sempre voc pode estar em uma corrida (sprint). Voc
precisa descansar entre as corridas (sprint). Se voc est sempre correndo,
na verdade voc est caminhando.
O mesmo acontece no Scrum e no desenvolvimento de software em geral.
Sprints so muito intensos. Como desenvolvedor, voc nunca ir querer
estar descansando, todos os dias voc tem que ir naquela reunio infeliz e
dizer diante de todo mundo o que voc fez ontem. Poucos iro dizer: Eu
gastei a maior parte do meu dia navegando por blogs e servindo
cappuccino.
Adicionalmente ao descanso propriamente dito, existe uma outra boa
razo para ter um intervalo entre os sprints. Aps a apresentao do sprint
e a retrospectiva, a equipe e o product owner estaro ambos cheios de
informaes e idias para digerir. Se eles imediatamente correrem e
comearem a planejar o prximo sprint, existir grande possibilidade de
ningum ter tempo de digerir qualquer informao ou lies aprendidas, o
product owner no ter tido tempo para ajustar suas prioridades aps a
demonstrao do sprint, etc.
Ruim:
Ns tentaremos introduzir algum tipo de intervalo aps comear um novo
sprint (mais especificamente, no perodo aps a retrospectiva do sprint e
antes da prxima reunio de planejamento do sprint). Nem sempre
conseguimos.
Por ltimo, ns tentamos ter a certeza que a retrospectiva do sprint e suas
reunies de planejamento subseqentes no ocorram no mesmo dia.
Todos devem ter uma boa noite-sem-sprint de sono antes de comear um
novo sprint.
COMO FAZEMOS O PLANEJAMENTO DE RELEASE E CONTRATOS COM PREO

FIXO |71
Melhor:
Melhor ainda:
Uma forma de fazer isso com os lab days (ou qualquer nome que voc
quiser dar). So dias que os desenvolvedores podem fazer o que eles
quisererm (OK, fui inspirado pelo Google). Por exemplo, eles podem ler
sobre as ltimas verses de algumas ferramentas ou APIs, estudar para
certificao, discutir temas tcnicos com os colegas, participar de um
projeto pessoal, etc.
Nosso objetivo ter um lab day entre cada sprint. Dessa forma voc
ganha um descanso natural entre os sprints, e ao mesmo tempo, voc
permite sua equipe de desenvolvedores manter os conhecimentos em
dia. Alm disso, um benefcio bem atraente para contratao.
Melhor de todos?
Atualmente ns temos um lab day por ms. Especificamente, a primeira
sexta-feira de cada ms. Por que no entre os sprints? Bem, porque eu
senti que era importante para a empresa toda ter o lab day ao mesmo
tempo. De outra forma, as pessoas tendem a no levar isso muito a srio.
E j que ns no temos os sprints de todos os produtos alinhados, eu tive
que selecionar um lab day independente dos sprints.
Um dia ns poderamos tentar sincronizar os sprints de todos os produtos
(p.ex., a mesma data de incio e fim dos sprints para todos os produtos e
equipes). Nesse caso, ns colocaramos o lab day entre cada sprint.
12
Como fazemos o planejamento de
release e contratos com preo fixo
Algumas vezes ns precisamos planejar antecipadamente mais de um
sprint por vez. Tipicamente em conjunto com um contrato de preo fixo
onde ns temos que planejar antecipadamente, ou ento arriscar assinar
algo que no poderemos entregar a tempo.
Tipicamente, o planejamento de release para ns uma tentativa de
responder questo quando, no pior caso, ns seremos capazes de
entregar a verso 1.0 deste novo sistema.
Se voc realmente quer aprender sobre planejamento de release eu sugiro
que voc pule este captulo e compre o livro Agile Estimating and
Planning, de Mike Cohn. Eu realmente gostaria de ter lido esse livro
mais cedo (eu o li aps termos percebido as coisas por conta prpria...).
Minha verso de planejamento de release um pouco simplista mas deve
servir como um bom ponto de partida.
Defina seus critrios de aceitao

Alm do product backlog, o product owner define uma lista de critrios
de aceitao, que uma simples classificao do que os nveis de
importncia no product backlog realmente significam em termos do
contrato.
Aqui est um exemplo de regras para critrios de aceitao:
Todos os itens com importncia >= 100 devem ser includos na
verso 1.0, caso contrrio seremos mortalmente penalizados.
Todos os itens com importncia entre 50 e 99 deveriam ser
includos na verso 1.0, mas ns devemos ser capazes de conclulos em um release subsequente feito rapidamente.
Itens com importncia entre 25 e 49 so necessrios, mas podem
ser feitos em release 1.1 subsequente.

FIXO |73
Itens com importncia < 25 so especulativos e podem at
mesmo nunca vir a ser necessrios.
E aqui est um exemplo de um product backlog, codificado em cores com
base nas regras acima.
Importncia
130
120
115
110
100
95
80
70
60
40
35
10
10
Nome
banana
ma
laranja
goiaba
pra
passa
amendoim
donut
cebola
framboesa
mamo
mirtilo
pssego
Vermelho = deve ser includo na verso 1.0 (banana - pra)

Amarelo = deveria ser includo na verso 1.0 (passa - cebola)
Verde = pode ser feito mais tarde (framboesa - pssego)
Logo se ns entregarmos tudo entre banana e cebola dentro do prazo,
estamos a salvo. Se o tempo encurtar ns podemos deixar de entregar
passa, amendoim, donut ou cebola. Tudo abaixo disso bnus.
Faa estimativas de tempo para os itens mais

importantes
Afim de fazer o planejamento de release o product owner precisa de
estimativas, ao menos para todas as histrias que esto inclusas no
contrato. Assim como no planejamento do sprint, este um esforo
cooperativo entre o product owner e a equipe a equipe estima, o product
owner descreve os itens e responde questes.

Uma estimativa de tempo valiosa ao se mostrar perto do correto, menos
valiosa ao se distanciar, digamos, por um fator de 30% e completamente
sem valor se no possuir qualquer conexo com a realidade.
Aqui est um exemplo do valor de uma estimativa de tempo em funo de
quem fez os clculos e de quanto tempo eles gastaram fazendo isso.
Tudo isso foi apenas uma maneira complicada de dizer:

Deixa a equipe fazer as estimativas.
No faa com que eles gastem tempo demais.
Certifique-se de que eles tenham entendido que as estimativas de
tempo so estimativas cruas, no compromissos.
Normalmente o product owner rene toda a equipe em uma sala, fornece
algumas distraes e lhes diz que o objetivo da reunio fazer uma
estimativa de tempo para as 20 estrias mais importantes no product
backlog (ou algo do tipo). Ele passa por cada estria uma vez e ento
deixa a equipe trabalhar. O product owner permanece na sala para
responder perguntas e esclarecer o escopo de cada item conforme
necessrio. Assim como no planejamento de sprint, o campo como
apresentar uma maneira bastante til de diminuir o risco de equvocos.
Esta reunio deve ocorrer dentro de um intervalo de tempo fixo, caso
contrrio as equipes tendem a gastar tempo demais estimando poucas
estrias.
Se o product owner desejar que mais tempo seja gasto nessa tarefa, ele
simplesmente agenda outra reunio para mais tarde. A equipe deve se
certificar de que o impacto destas reunies nos seus sprints seja
claramente visvel para o product owner, para que ele possa compreender
que o trabalho de estimativas de tempo possui um custo.
Imp
130
120
115
110
100
95
80
70
60
40
35
10
10
Nome
Estimativa
banana
12
ma
9
laranja
20
goiaba
8
pra
20
passa
12
amendoim
10
donut
8
cebola
10
framboesa
14
mamo
4
mirtilo
pssego
Aqui est um exemplo de como

estimativas de tempo devem
terminar (em pontos por estria):

FIXO |75
Estime velocidade
OK, agora ns temos uma estimativa de tempo, bem a grosso modo, para
as estrias mais importantes.
Prximo passo estimar nossa velocidade mdia por sprint.
Isso significa que ns precisamos decidir nosso fator de foco. Veja a pg
24 "Como a equipe decide quais estrias incluir no sprint".
O fator de foco basicamente quanto do tempo da equipe gasto
focando na execuo da estria em questo. Nunca de 100%, visto que
equipes perdem tempo fazendo itens no planejados, trocando o contexto
que esto fazendo, ajudando outras equipes, verificando seus e-mails,
consertando seus computadores com defeito, discutindo polticas na
cozinha, etc.
Vamos dizer que ns determinemos o fator de foco da equipe em 50%
(um pouco baixo, ns normalmente paramos em torno de 70%). E vamos
dizer que o tamanho do nosso sprint ser de 3 semanas (15 dias) e nossa
equipe composta por 6 membros.
Cada sprint tem 90 dias-homem de durao, mas podemos esperar uma
produo completa de 45 dias-homem no valor das estrias (devido o
fator de foco ser de 50%).
Ento nossa velocidade estimada de 45 pontos.
Se cada estria tinha uma estimativa de 5 dias (que eles no) ento essa
equipe poderia desenvolver aproximadamente 9 histrias por sprint.
Junte tudo num plano de release

Agora que temos estimativas de tempo e uma velocidade (45) podemos
facilmente fatiar o product backlog em sprints:
Imp
130
120
115
110
100
95
80
70
60
40
35
10
10
Name
Estimativa
Sprint 1
banana
12
ma
9
laranja
20
Sprint 2
goiaba
8
pra
20
passa
12
Sprint 3
amendoim
10
donut
8
cebola
10
framboesa
14
Sprint 4
mamo
4
mirtilo
pssego
Cada sprint inclui tantas estrias quanto possvel sem exceder a

velocidade estimada de 45.
Agora podemos ver que precisaremos de provavelmente 3 sprints para
terminar todos os deve ter e os deveria ter.
3 sprints = 9 semanas = 2 meses. essa a deadline que prometemos ao
cliente? Depende completamente da natureza do contrato; quo fixo o
escopo, etc. Muitas vezes adicionamos um buffer significante para nos
proteger de ms estimativas, problemas inesperados, funcionalidades
inesperadas, etc. Neste caso devemos acordar em uma entrega para daqui
a 3 meses, nos dando um ms de reserva.
O lado bom que podemos demonstrar algo usvel para o cliente a cada 3
semanas e convid-lo a mudar os requisitos conforme vamos avanando
(claro que dependendo de como o contrato).

FIXO |77
Adaptao do plano de release

A realidade no se adaptar ao plano, ento o plano deve adaptar-se
realidade.
Aps cada sprint, observamos a velocidade para aquele sprint. Se a
velocidade atual foi muito diferente da velocidade estimada, revisamos a
velocidade estimada para os sprints futuros e atualizamos o plano de
release. Se isso nos deixar em apuros, o product owner pode ento
negociar com o cliente ou verificar como reduzir o escopo sem
descumprir o contrato. Tambm pode ser que ele e a equipe descubram
alguma maneira de aumentar a velocidade ou o fator de foco, atravs da
remoo de alguns impedimentos graves que foram identificados durante
o sprint.
O product owner pode ligar para o cliente e dizer Ol, ns estamos um
pouco atrasados, mas acredito que podemos entregar no prazo
simplesmente removendo a funcionalidade Pacman embutido que leva
um grande tempo de desenvolvimento. Se voc quiser, poderemos
adicion-la em um release posterior, 3 semanas aps o primeiro release.
Talvez no seja uma boa notcia para o cliente, mas pelo menos estaremos
sendo honestos e daremos ao cliente a opo de adiantar a entrega
devemos entregar as coisas mais importantes no prazo ou entregar tudo
atrasado. Geralmente, esta no uma deciso difcil. :o)
13
Como combinamos Scrum e XP
Dizer que Scrum e XP (eXtreme Programming) podem ser combinados de
forma vantajosa no seria uma afirmao polmica. A maioria do material
que vejo na internet apoia essa hiptese, ento no vou me demorar
justificando o porqu.
Bem, terei que dizer uma coisa. O Scrum focado nas prticas de
gerenciamento e organizao, enquanto o XP d mais ateno s tarefas
de programao mesmo. A est o porqu de elas trabalharem bem juntas
elas abrangem reas diferentes e uma complementa a outra.
Eu deixo aqui minha opinio de que o Scrum e o XP podem ser
combinados de forma a dar resultados muito bons!
Eu vou destacar algumas das melhores prticas do XP e como elas se
aplicam ao nosso dia-a-dia. Nem todas nossas equipes decidiram adotar
todas elas, mas no total ns experimentamos a maioria das combinaes
de XP/Scrum. Algumas dessas prticas so diretamente tratadas pelo
Scrum e podem ser vistas como sobrepostas, por exemplo, Toda a
Equipe, Sentar Juntos, Estrias e Planning game. Em todos esses
casos, ns simplesmente usamos o Scrum ao invs do XP.
Programao em par
Ns comeamos com esta prtica em uma de nossas equipes. Atualmente
tem funcionado bem. A maioria de nossas outras equipes no usam
programao em par freqentemente, mas como tentamos em uma equipe
por alguns sprints, eu me sinto encorajado a incentivar mais equipes a
colocarem em prtica.
Algumas concluses sobre programao em par:
Programao em par aumenta a qualidade do cdigo
COMO COMBINAMOS SCRUM E XP | 79

Programao em par aumenta o foco da equipe (por exemplo:

quando o par lhe diz: Ei, estas coisas realmente so necessrias
para este sprint?)
Surpreendentemente muitos desenvolvedores que so fortemente
contra programao em par nunca tentaram antes e rapidamente
aprendem a gostar uma vez que experimentam.
Programao em par cansativa e no deve ser feito todos os dias
Trocar os pares freqentemente bom.
Programao em par nivela o conhecimento da equipe.
Surpreendentemente de forma rpida tambm.
Algumas pessoas simplesmente no se sentem confortveis com
programao em par. No jogue fora um excelente programador
simplesmente porque ele no se sente confortvel com
programao em par
Reviso de cdigo uma alternativa vlida para a programao
em par.
O navegador (o cara que no est digitando) deve ter um
computador para si prprio. No para ser usado no
desenvolvimento, mas para pequenas atividades quando
necessrio, navegar na documentao enquanto o piloto (o cara
nos teclados) o espera, etc.
No force as pessoas a praticarem a programao em par.
Encoraje as pessoas e fornea as ferramentas corretas, mas deixeas experimentar por si mesmas.
Desenvolvimento Orientado a Testes (TDD)

Amm! Isso para mim mais importante que Scrum e XP. Voc pode tirar
minha casa, minha TV e meu cachorro, mas no tente me fazer parar de usar
TDD! Se voc no gosta de TDD ento no me deixe no recinto, porque eu
vou tentar fazer isso passar de um jeito ou de outro :o)
Aqui vai um sumrio de 10 segundos de TDD:
Desenvolvimento orientado a testes significa que voc escreve
um teste automatizado, ento escreve apenas cdigo suficiente
para faz-lo passar, ento voc refatora o cdigo
primeiramente para melhorar a legibilidade e remover
duplicao. Enxague e repita.
Algumas reflexes sobre o desenvolvimento orientado a testes.

TDD difcil. Leva um tempo para o programador pegar o jeito. Na
verdade, em muitos casos no importa quanto voc ensina, treina e

demonstra - em muitos casos a nica maneira de um programador

"pegar o jeito" fazendo ele programar em par com algum que
bom em TDD. Contudo, uma vez que pega o jeito, normalmente
severamente infectado e nunca mais ir querer trabalhar de outra
forma.
TDD tem um efeito profundamente positivo no design do sistema.
Leva tempo para deixar o TDD efetivamente pronto e funcionando
em um novo produto, especialmente em testes de integrao de
caixa-preta, mas o retorno de investimento rpido.
Tenha certeza que voc investe o tempo necessrio para tornar mais
fcil escrever os testes. Isso significa obter as ferramentas certas,
educar as pessoas, prover o utilitrio de classes ou base de classes
certo, etc.
Ns usamos as seguintes ferramentes para desenvolvimento orientado a

testes.

JUnit / httpUnit / jWebUnit. Estamos considerando TestNG e

Selenium.
HSQLDB como BD embutido na memria para fins de teste.
Jetty como container web embutido na memria para fins de testes.
Cobertura para mtricas de cobertura de testes.
Spring framework para ligao dos diferentes tipos de fixtures de
teste (com mocks, sem mocks, com banco de dados externo, com
banco de dados na memria, etc).
Em nossos produtos mais sofisticados (da perspectiva do TDD) ns

automatizamos os testes e aceitao fechados. Esses testes carregam o
sistema todo na memria, incluindo bases de dados e servidores web, e
acessam o sistema usando apenas as interfaces pblicas (por exemplo
HTTP).
Dessa forma ns aceleramos muito os ciclos de desenvolvimento-buildteste. Esse ambiente tambm funciona como uma rede de segurana,
dando aos desenvolvedores a confiana suficiente para refatorar com
freqncia, o que significa que o projeto mantem-se limpo e simples
medida que o sistema cresce.
TDD em cdigos novos

Ns usamos o TDD para todo novo desenvolvimento, mesmo que o incio
do projeto demore mais (j que precisamos de mais ferramentas e suporte
para os testes. uma dose de no-brainer, os benefcios so to grandes
que no h nenhuma desculpa para no praticarmos o TDD.
TDD em cdigos j existentes

TDD difcil, mas tentar aplic-lo numa base de cdigo que no foi
construda visando o TDD desde o princpio... realmente muito difcil!
Por que? Bem, na verdade, eu poderia escrever muito sobre isso, mas
acho que vou parar aqui. Vou tratar disso num prximo artigo meu TDD
from the Trehches :o)
Ns gastamos bastante tempo tentando automatizar os testes de integrao
num dos nossos sistemas mais complexos. Os cdigos foram bastante
mexidos e estavam bastante bagunados e completamente desprovidos de
teste.
Para cada verso do sistema ns temos uma equipe dedicada de testadores
que fazem um conjunto completo de testes de regresso e performance.
Os testes de regresso so normalmente trabalho manual. Isso atrasa
bastante o ciclo de desenvolvimento e liberao da verso. Nosso objetivo
automatizar esses testes. Depois de termo batido nossas cabeas contra o
muro alguns meses, no chegamos muito perto do que queramos.
Depois disso, mudamos nossa abordagem. Ns aceitamos o fato de que
estvamos estagnados nos testes manuais de regresso e, ao invs disso,
deveramos estar nos perguntando Como posso fazer esse processo de
testes manuais ficar mais rpido? Isso era um jogo, e ns constatamos
que muito trabalho de teste da equipe foi gasto fazendo tarefas triviais de
instalao como navegar no back office para configurar tournments para
os propsitos dos testes, ou esperando pelo agendamento de um
tournament para comear. Ento ns criamos utilidades para isso.
Pequenas, de fcil acesso como atalhos e scripts que dispensavam o
trabalho duro e deixava o foco nos testes efetivamente.
Esse esforo realmente se pagou. Na verdade, isso provavelmente o que
deveramos ter feito desde o incio. Ns estvamos to ansiosos em
automatizar os testes que esquecemos de fazer o passo a passo, onde o
primeiro passo seria fazer os testes manuais mais eficientes.
Lio Aprendida: se voc estiver estagnado com os testes manuais de
regresso, e quiser automatizar desse jeito, no o faa (a menos que isso
seja realmente muito fcil). Ao invs disso, construa coisas que faam os
testes de regresso mais fceis. A sim considere automatizar o teste
efetivo.
Design incremental
Significa manter o design simples desde o incio e melhor-lo
continuamente, ao invs de tentar deix-lo perfeito desde o incio e ento
congel-lo.
Ns estamos indo muito bem assim, isto , ns gastamos uma quantidade
considervel de tempo melhorando o design existente e ns raramente
perdemos tempo projetando de forma precipitada. s vezes ns
estragamos tudo, claro, por exemplo quando deixamos que um design
instvel crie muitas razes, de forma que refatorar se torna um grande
projeto. Mas no geral estamos muito satisfeitos.
Melhoria contnua do design praticamente um efeito coleteral do
Desenvolvimento Orientado a Testes.
Integrao contnua
A maioria dos nossos produtos possui uma configurao de integrao
contnua razoavelmente sofisticada, baseada em Maven e QuickBuild. Isto
extremamente vlido e poupa tempo. Essa a soluo definitiva para
um velho problema Ei, mas isso funciona na minha mquina. Nosso
servidor de construo contnua age como o juiz ou ponto de referncia
a partir do qual se determina a qualidade de todas as nossas bases de
cdigo.
Toda vez que algum atualiza alguma coisa no sistema de controle de
verso o servidor de construo contnua ir acordar, construir tudo desde
o incio num servidor compartilhado e realizar todos os testes. Se alguma
coisa der errado, ele enviar um email avisando a equipe inteira que a
construo falhou, incluindo informaes sobre exatamente qual mudana
de cdigo quebrou a construo, links para relatrios de teste, etc.
Todas as noites o servidor de construo contnua ir reconstruir o
produto desde o incio e publicar binrios (ears, wars, etc),
documentaes, relatrios de teste, relatrios de cobertura de testes,
relatrios de dependncias, etc, no nosso portal de documentaes
internas. Alguns produtos sero tambm automaticamente implementados
em um ambiente de teste.
Configurar isso deu muito trabalho, mas valeu cada minuto.
Propriedade coletiva do cdigo

Ns encorajamos a propriedade coletiva do cdigo mas ainda nem todas
as equipes tm adotado esse mtodo de trabalho. Descobrimos que a
programao em pares (pair programming) com a mudana freqente dos
pares leva automaticamente a um maior nvel de propriedade coletiva de
cdigo. As equipes com essa caracterstica tm provado ser muito
robustas, o sprint delas, por exemplo, no morre apenas porque algum
importante ficou doente.
Ambiente de trabalho informativo

Todas as equipes tm acesso aos quadros brancos e a uma parede vazia e
fazem um bom uso desses recursos. Na maioria das salas voc encontrar
as paredes preenchidas com todo tipo de informao sobre o produto e o
projeto. Assim, o maior problema passa a ser o lixo antigo acumulado nas
paredes. Por isso deveramos introduzir o papel do faxineiro em cada
equipe.
Encorajamos o uso do quadro de tarefas, mas nem todas as equipes ainda
o adotaram. Veja na pgina 59 Como ns organizamos a sala da equipe.
Padro de codificao
Recentemente ns comeamos a definir o nosso padro de codificao.
Teria sido muito til se tivssemos feito isso antes. No leva quase tempo
nenhum. Comece com ele simples e v crescendo conforme a
necessidade. Escreva apenas regras que no sejam bvias para todo
mundo e correlacione com algum material j existente, sempre que
possvel.
A maioria dos programadores tem seu estilo prprio de codificao. So
pequenos detalhes como, por exemplo, a forma de tratar excees, como
comentar o cdigo, quando retornar valor nulo, etc. Em alguns casos as
diferenas no causam problemas, mas em outros casos pode levar ao
projeto de um sistema extremamente inconsistente e um cdigo fonte
difcil de entender. Um padro de codificao aqui muito til, j que
voc foca em coisas que realmente importam.
Aqui esto alguns exemplos do nosso padro de codificao:
Voc pode quebrar qualquer uma dessas regras, mas tenha a

certeza que por uma boa razo e documente isso.

Use a conveno de codificao da Sun como padro:
Nunca, jamais, nem pense em capturar excees sem logar o

stack trace ou rethowing. log.debug() uma boa, mas no perca o
stack trace.
Use a dependncia baseada em mtodos setter para desacoplar as
classes umas das outras. (exceto quando um acoplamento forte
for desejvel).
Evite abreviaes. Abreviaes bem conhecidas como DAO so
bem-vindas.
Os mtodos que retornam collections ou arrays no devem
retornar nulo. Retorne colees ou arrays vazios ao invs de
nulo.

http://java.sun.com/docs/codeconv/html/CodeConvTOC.
doc.html
Ritmo Sustentvel / Trabalho energizado

Muitos livros sobre desenvolvimento gil de software dizem que horasextras so anti-produtivas no desenvolvimento de software.
Aps algumas experincias relutantes com isso eu s posso concordar
plenamente com eles!
H aproximadamente um ano atrs uma de nossas equipes (a maior delas )
estava trabalhando horas extras excessivas.
A qualidade do software legado era horrvel e eles tinham que gastar boa
parte do tempo apagando incndios. A equipe de teste (que tambm estava
fazendo horas extras) no tinha chance de fazer nenhuma garantia de
segurana. Nossos usurios estavam furiosos e os relatrios internos
queriam comer-nos vivos.
Depois de alguns meses ns tnhamos negociado cargas horrias menores
e mais decentes. Pessoas trabalhando cargas horrias normais (exceto
durante alguns picos eventuais no projeto). E, surpresa, produtividade e
qualidade notveis.
Claro, reduzir a carga horria no foi o nico aspecto que nos levou essa
melhoria, mas ns todos estvamos convencidos que foi um dos grandes
responsveis.
14
Como fazemos testes
Essa a parte mais difcil. No tenho certeza se a parte mais difcil do
Scrum ou do desenvolvimento de software em geral.
A etapa de testes , provavelmente, a que mais varia de uma empresa para
outra. Ela depende de quantos testadores voc tem, de quo automatizados
so os testes, de que tipo de sistema voc tem (apenas servidor+aplicao
web? ou na verdade voc entrega pacotes de software?), do tamanho dos
ciclos de release, quo crtico o sistema (servidor de blog versus
controle de trfego areo), etc.
Ns temos feito muitos experimentos em como fazer testes com Scrum.
Tentarei descrever o que temos feito e o que aprendemos at agora.
Voc provavelmente no vai conseguir

eliminar a fase dos testes de aceitao
No mundo Scrum ideal, um sprint resulta em um verso potencialmente
instalvel do seu sistema. Ento s instalar, certo?
Errado.
Nossa experincia que isso na verdade no funciona. Haver bugs
desagradveis. Se a qualidade tem qualquer tipo de valor para voc,
necessrio algum tipo de fase de testes de aceitao manuais. nessa hora
que testadores dedicados que no fazem parte da sua equipe martelam o
sistema com aqueles tipos de testes que a equipe Scrum no imaginou, ou
no teve tempo para fazer, ou no tiveram o hardware necessrio para
fazer. Estes testadores acessam o sistema exatamente da mesma forma
que os usurios finais, o que significa que eles devem ser realizados
manualmente (assumindo que seu sistema seja feito para usurios
humanos).
A equipe de testes encontrar bugs, a equipe Scrum ter que produzir

releases para correo de bugs e mais cedo ou mais tarde (espera-se que
mais cedo) voc estar apto para liberar uma verso 1.0.1 sem bugs aos
usurios finais, ao invs de entregar uma verso 1.0.0 instvel.
Quando eu digo fase de testes de aceitao eu estou me referindo a todo
o perodo de teste, debug e re-release at que exista uma verso boa o
bastante para ser colocada em produo.
Minimize a fase de testes de aceitao

A fase de testes de aceitao machuca. Ela principalmente no-gil.
Apesar de no podermos elimin-la, ns podemos (e devemos) minimizla. Mais especificamente, minimizar a quantidade de tempo necessria
para a fase de testes de aceitao. Isso pode ser afeito:
Maximizando a qualidade do cdigo entregue pela equipe Scrum
Maximizando a eficincia do trabalho de teste manual (isto ,
encontrar os melhores testadores, dar-lhes as melhores
ferramentas, certificar-se de que eles lhe avisam quando houver
tarefas que consomem muito tempo e que podem ser
automatizadas
Ento, como ns maximizamos a qualidade do cdigo entregue pela
equipe Scrum? Bem, existem diversas maneiras. Aqui esto duas que ns
achamos que funcionam muito bem:
Coloque os testadores na equipe Scrum
Faa menos a cada sprint
Aumente a qualidade colocando os testadores

na equipe Scrum
Sim, eu costumo escutar as duas objees:

Mas isso bvio! Equipes Scrum devem

ser multi-funcionais!
Equipes Scrum no devem possuir cargos!
Ns no podemos ter um cara que apenas
COMO FAZEMOS TESTES | 87

testador!
Deixe-me explicar. O que eu quero dizer com testador neste caso ter
uma pessoa cuja habilidade primria testar, ao invs de uma pessoa
cuja funo apenas testar
Desenvolvedores so quase sempre maus testadores. Especialmente
desenvolvedores que testam o seu prprio cdigo.
O testador o cara que aprova
Alm de ser apenas mais um membro da equipe, o testador tem uma

importante funo. Ele o cara que aprova. Nada considerado 'pronto
em um sprint at que ele diga que est. Eu descobri que desenvolvedores
frequentemente dizem que algo est pronto quando na verdade no est.
Mesmo que voc tenha uma definio de pronto muito clara (o que
realmente deveria ser o caso, veja pgina 34 Definio de pronto),
desenvolvedores freqentemente iro se esquecer disso. Ns
programadores somos pessoas impacientes e queremos sempre passar para
a prxima etapa o mais rpido possvel.
Ento como o Sr. T (nosso testador) sabe que algo est pronto? Bem,
antes de mais nada, ele deve (surpresa!) testar! Em muitos casos algo que
o desenvolvedor considerou como pronto no era nem mesmo possvel de
ser testado! Seja porque o cdigo no foi adicionado ao sistema de
controle de verses, ou porque no foi instalado no servidor de testes, ou
no pde ser inicializado, ou qualquer outra causa. Assim que o Sr. T tiver
testado a funcionalidade, ele deve repassar a lista de pronto com o
desenvolvedor (caso voc tenha uma). Por exemplo, se a definio de
pronto diz que deve existir uma nota de release, ento o Sr. T verifica se
existe uma nota de release. Se houver algum tipo de especificao mais
formal para esta funcionalidade (o que raro no nosso caso) ento o Sr. T
tambm verifica isso, etc.
Um interessante efeito colateral disso que agora a equipe tem uma
pessoa que perfeitamente apta para organizar a apresentao do sprint.
O que o testador faz quando no h nada para testar?

Essa pergunta sempre vem tona. Sr. T: Scrum master, no tenho nada
para testar agora, o que mais eu posso fazer?. Ainda vai demorar uma
semana para que a equipe termine a primeira estria. Ento, o que o
testador poderia fazer nesse perodo?

Bem, antes de tudo, ele deveria estar se preparando para os testes. Ou
seja, escrevendo as especificaes de teste, preparando um ambiente de
testes, etc. Assim, quando um desenvolvedor liberar alguma
funcionalidade para ser testada, no haveria nenhuma espera. O sr. T
poderia comear o teste imediatamente.
Se a equipe est usando TDD, as pessoas ocupam tempo escrevendo
cdigos de teste desde o primeiro dia. O testador deveria fazer par com os
desenvolvedores que esto escrevendo esses cdigos de teste. Se o
testador no sabe programar, ele ainda assim deveria fazer par com os
desenvolvedores, a menos que ele apenas navegue e deixe o
desenvolvedor digitar. Um bom testador normalmente adiciona tipos
diferentes de testes aos de um bom desenvolvedor. Assim, um
complementa o outro.
Se a equipe no est usando TDD, ou se no h casos de teste suficientes
para ocupar todo o tempo do testador, ele deveria simplesmente fazer o
possvel para ajudar a equipe alcanar o objetivo do sprint. Igual a
qualquer outro membro da equipe. Se o testador sabe programar ento
timo. Se no, sua equipe ter que identificar as tarefas extra programao
que devem ser feitas no sprint.
Quando voc quebrar as estrias em tarefas, durante a reunio de
planejamento do sprint, a equipe tende a focar nas tarefas de
programao. Entretanto, normalmente existem muita outras que no so
programao e que tambm precisam ser feitas no sprint. Se voc investir
tempo tentando identificar as tarefas que no so programao durante a
fase de planejamento do sprint, as chances de o sr. T contribuir so muito
grandes, mesmo que ele no programe e que no haja nenhum teste para
fazer agora.
Exemplos de tarefas necessrias ao sprint, mas que no so programao:
Preparar um ambiente de teste.
Esclarecer requisitos.
Discutir detalhes de deploy com a operao.
Escrever documentos de deploy (release notes, RFC, ou qualquer
outro que sua empresa use).
Contatar recursos externos (projetistas de interface com usurio,
por exemplo).
Melhorar os scripts de build.
Mais quebras de estrias em tarefas.
Identificar perguntas-chave dos desenvolvedores e conseguir a
resposta para elas.

Por outro lado, o que fazer se o sr. T tornar-se um gargalo? Vamos supor
que estejamos no ltimo dia do sprint e de repente muita coisa est pronta
e o sr. T no teve a oportunidade de testar tudo. O que fazer? Bem, vamos
transformar todo o resto da equipe em ajudantes do sr. T. Ele decide qual
funcionalidade ele prprio precisa fazer e delega as outras para o restante
da equipe. Isso o que significa ter uma equipe multi-disciplinar!
Resumindo, sim, o sr. T tem um papel especial na equipe, mas ele
tambm pode fazer outras coisas. E os outros membros da equipe tambm
podem fazer o trabalho dele.
Aumentar a qualidade fazendo menos por

Sprint
Voltando reunio de planejamento do sprint. Colocando de forma
simples, no coloque muitas estrias no sprint! Se voc tem problemas de
qualidade, ou longos ciclos de aceitao, faa menos por sprint! Isso ir
meio que automaticamente elevar a qualidade. Menores ciclos de teste
para aceitao, menos bugs afetando o usurio, e maior produtividade ao
longo da caminhada. Isso pois a equipe poder focar nas novas coisas ao
invs de ficar consertando coisas velhas que vivem quebrando.
Quase sempre mais barato construir menos, mas construir algo estvel.
Melhor do que construir montes de coisas que te deixam em pnico com
consertos de urgncia.
O teste de aceitao deveria fazer parte do

sprint?
Ns variamos muito aqui. Algumas de nossas equipes incluem o teste de
aceitao no sprint. Porm, a maioria delas, no. Por duas razes:
Um sprint tem um limite de tempo. Testes de aceitao (Usando
minha definio que inclui debugar e re-instalar), so muito
difceis de se mensurar o tempo. O que fazer se o tempo se
esgotar e voc ainda tiver um bug crtico? Voc vai lanar uma
release com um bug crtico? Voc vai esperar at o prximo
sprint? Na maioria dos casos ambos so inaceitveis. Ento deixe
o teste manual de aceitao de lado.
Se voc tem vrias equipes trabalhando no mesmo produto, o
teste manual de aceitao deve ser seguido combinado com o
trabalho de ambas equipes. Se ambas fizeram o teste manual de
aceitao dentro do tempo do sprint, voc ainda precisa de uma

equipe para fazer o teste final de release, que a integrao do
trabalho das equipes.
Isso pode no significar a soluo perfeita mas boa o suficiente pra

gente na maioria dos casos.
Ciclos de sprint vs. ciclos de testes de

aceitao
Idealmente, no mundo perfeito do Scrum, voc no precisa de testes de
aceitao, uma vez que as releases geradas ao final de cada sprint j esto
prontas para a produo.
Bem, no bem assim. Segue um esquema mais realista:
Aps o sprint 1, uma release bugada 1.0.0 lanada. Da, durante o sprint
2, os bugs da ltima release comeam a ser notificados, a equipe gasta
grande parte do tempo corrigindo-os e forada a lanar uma verso
intermediria 1.0.1 no meio do sprint 2. Ento, ao final do sprint 2, uma
release
1.1.0 com novas funcionalidades disponibilizada.
Provavelmente esta verso 1.1.0 estar ainda mais bugada que a release
1.0.0, j que o tempo nela investido foi prejudicado devido necessidade
urgente de correo da primeira release 1.0.0, e isso sempre se repetir.
As linhas diagonais em vermelho da figura simbolizam o caos.
No fica muito bonito, n? A m notcia, entretanto, que este problema
permanecer mesmo se voc tiver uma equipe s para testes de aceitao
de releases. A nica diferena ser que a maioria dos relatos de bugs viro
da equipe de teste, e no de usurios raivosos. Sob a perspectiva de
negcios, isso j faz uma grande diferena. Para desenvolvedores,
contudo, d na mesma. Talvez a nica exceo seja o fato de testadores
serem menos agressivos que usurios. Geralmente.
No encontramos ainda nenhuma soluo simples para este problema,

apesar de j termos experimentado diferentes modelos.
Primeiro de tudo, novamente, maximize a qualidade do cdigo que a
equipe gera. O custo de encontrar e corrigir bugs cedo, durante o sprint,
extremamente menor se comparado ao mesmo custo aps o trmino da
iterao.
De qualquer forma, permanence o mesmo fato. Ainda que minizemos a
quantidade de bugs, haver registros de bugs aps o sprint ter sido
finalizado. Como lidar com isso?
Abordagem 1: No inicie a construo de coisas

novas antes das coisas antigas estarem em
produo
Parece bom no? Voc tambm sentiu aquele sentimento aconchegante de
incerteza?
Ns estivemos prximos de adotar esta abordagem diversas vezes, e
desenhamos modelos requintados sobre como poderamos fazer isto.
Entretanto sempre mudamos de idia quando visualizamos o lado
negativo disto. Ns teramos que adicionar um perodo de liberao sem
um espao de tempo fixo entre cada sprint, onde faramos apenas teste e
depurao at que pudssemos realizar um release em produo.

Ns no gostamos da noo de ter perodos sem espao de tempo fixo
entre os sprints, principalmente porque isto iria quebrar o ritmo que a
equipe possui nos sprints. Ns no poderamos mais dizer que a cada 3
semanas ns iniciamos um novo sprint. Alm do que, isto no resolve
completamente o problema. Mesmo que tivssemos um perodo de
release, vo aparecer relatos de defeitos urgentes de tempos em tempos, e
precisamos estar preparados para tratar deles.
1. Abordagem 2: OK para comear a implementar

novas funcionalidades, mas priorizar colocar as
coisas antigas em produo
Esta nossa abordagem preferida. Pelo menos at agora.
Basicamente quando terminamos um sprint, ns vamos para o prximo.
Mas esperamos gastar algum tempo deste prximo sprint consertando
coisas do ltimo sprint. Se os prximos sprints se tornarem severamente
prejudicados por causa do gasto excessivo de tempo na correo de bugs
do ltimo sprint, ns avaliamos por que isto aconteceu e como podemos
melhorar a qualidade. Ns procuramos ter a certeza de que sprints so
duradouros o suficiente para no serem impactados por um punhado de
tempo gasto concertando bugs do sprint anterior.
Gradualmente, aps um perodo de muitos meses, a quantidade de tempo
gasto consertando bugs do sprint anterior diminuiu. Assim nos tornamos
hbeis em escalar menos pessoas envolvidas quando estes bugs
acontecem, e nem toda equipe precisa ser incomodada todas as vezes.
Agora estamos em um nvel mais aceitvel.
Durante as reunies de planejamento do sprint, ns ajustamos o fato de

foco baixo o suficiente para considerar o tempo que gastamos concertando
os bugs do ltimo sprint. Com o tempo, as equipes se tornaram bastante
eficazes em fazer esta estimativa. A mtrica de velocidade ajuda muito
(veja pgina 25 Como a equipe decide quais estrias so includas no
sprint?)
Abordagem ruim foco em construir novas coisas

Este efeito significa foco em construir novas coisas ao invs de colocar
as coisas antigas em produo. Quem gostaria de fazer isto? Mesmo
assim cometemos este erro de vez em quando no comeo, e eu tenho a
certeza de que muitas empresas fazem o mesmo. uma doena
relacionada a presso do projeto. Muitos gerentes realmente no
compreendem que quando toda a codificao terminar, voc geralmente
estar longe do release de produo. Pelo menos para sistemas
complexos. Ento o gerente (ou product owner) pede para a equipe
continuar adicionando novas funcionalidades enquanto a mochila de
cdigo das coisas quase prontas se torna cada vez mais e mais pesada,
diminuindo a velocidade de tudo.
No exponha o elo mais fraco de sua corrente

Digamos que o teste de aceitao seja o seu elo mais fraco. Voc tem
pouqussimos testadores ou o perodo de testes demora mais devido
baixa qualidade do cdigo.
Digamos que a equipe de testes de aceitao possa testar no mximo 3
funcionalidades por semana (no, ns no usamos funcionalidades por
semana como mtrica; s estou dando um exemplo). E digamos que seus
desenvolvedores produzam 6 novas funcionalidades por semana.
tentador para os gerentes ou product owners (ou talvez mesmo para a
equipe) prever o desenvolvimento de 6 novas funcionalidades por semana.
No faa isso! A realidade ir peg-lo de um modo ou de outro. E vai
machuc-lo.
Ao invs disso, planeje 3 novas funcionalidades por semana e invista o
restante do tempo para aliviar o gargalo de testes. Exemplo:
Aloque alguns desenvolvedores como testadores (Ah, eles iro
am-lo por isso).
Implemente ferramentas e scripts que facilitem os testes.
Adicione mais cdigo que automatize os testes.
Aumente o tamanho do sprint e tenha os testes de aceitao
includos nele.
Defina alguns sprints como sprints para teste onde a equipe
inteira atuar como uma equipe de testes de aceitao.
Contrate mais testadores (mesmo que isso signifique dispensar
alguns desenvolvedores).

Ns temos usado todas essas alternativas (exceto a ltima). As melhores
solues a longo prazo so obviamente a 2 e 3, isto , melhores
ferramentas e scripts para automao dos testes
Anlises retrospectivas so um bom frum para identificar o elo mais
fraco de sua corrente.
De volta realidade
Provavelmente eu tenho passado a impresso de que ns temos testadores
em todas as equipes, que temos uma enorme equipe de testes de aceite
para cada produto, que entregamos depois de cada sprint, etc, etc.
Bem, ns no temos.
Ns algumas vezes gerenciamos projetos com testes, e ns temos visto
efeitos positivos. Mas ainda estamos longe de um aceitvel processo de
garantia de qualidade, e ainda temos muito a aprender.
15
Como lidamos com vrias equipes
Muitas coisas se complicam quando se tem vrias equipes trabalhando no
mesmo produto. Esse problema universal e no tem nada a ver com o
Scrum. Mais desenvolvedores = mais complicaes.
Ns temos (como sempre) experincia com isso. No mximo, ns temos
aproximadamente 40 pessoas trabalhando no mesmo produto.
A questes chaves so:
Como alocar pessoas nas equipes

Se lidar com vrias equipes to difcil, por que vamos nos incomodar?
Por que simplesmente no colocar todos na mesma equipe?
A maior equipe de scrum que ns tivemos tinha aproximadamente 11
pessoas. Ela funcionava, mas no muito bem. Reunies dirias tendiam a
durar mais de 15 minutos. Os membros da equipe no sabiam o que os
membros das outras equipes estavam fazendo, e isso gerava confuso. Era
muito dificil para o scrum master manter todos alinhados ao objetivo, e
dificil de encontrar tempo de enderear todos os obstculos que eram
reportados.
A alternativa era dividir em duas equipes. Mas isso melhor? No
necessariamente.
Se a equipe tem experincia e confortvel com o Scrum, e h um jeito
lgico de dividir o roadmap em duas pistas diferentes, e essas duas pistas
no envolvem o mesmo cdigo fonte, ento eu deveria dizer que uma
boa idia dividir a equipe. De outra forma eu optaria por manter a equipe
nica, a despeito das desvantagens de uma grande equipe.
COMO LIDAMOS COM VRIAS EQUIPES | 97

Minha experincia diz que melhor ter menos equipes, embora grandes,
do que ter muitas equipes pequenas que interfiram umas nas outras. Faa
pequenas equipes apenas se no forem interferir umas nas outras!
Equipes virtuais
Como voc sabe se tomou a deciso certa ou errada em relao aos prs e
contras de ter uma equipe grande ou uma equipe pequena?
Se voc manteve seus olhos e ouvidos abertos voc deve ter notado o
termo equipes virtuais.
Exemplo 1: Voc escolhe ter uma equipe grande. Mas quando voc
comea a observar quem fala com quem durante o sprint, percebe que a
equipe acabou se dividindo em duas sub-equipes.
Exemplo 2: Voc escolhe ter trs equipes menores. Mas quando voc
comea a observar quem fala com quem durante o sprint, percebe que as
equipes 1 e 2 esto conversando entre si o tempo todo, enquanto que a
equipe 3 est trabalhando isoladamente.
O que isso significa? Que sua estratgia de diviso de equipes estava

errada? Sim, se as equipes virtuais parecerem permanentes. No, se as
equipes virtuais parecerem temporrias.

Olhe novamente para o exemplo 1. Se as duas sub-equipes virtuais
tendem a mudar de vez em quando (por exemplo, as pessoas vo de uma
sub-equipe para outra) ento provavelmente voc tomou a deciso certa
ao mant-las como uma nica equipe. Se as duas sub-equipes virtuais
mantm-se as mesmas durante todo o sprint, talvez voc queira separ-las
em duas equipes reais no prximo sprint.
Agora olhe novamente para o exemplo 2. Se as equipes 1 e 2 esto
conversando entre si (e no com a equipe 3) durante todo o sprint, talvez
voc queira combinar as equipes 1 e 2 em uma nica equipe no prximo
sprint. Se as equipes 1 e 2 esto conversando muito entre si durante a
primeira metade do sprint e ento as equipes 1 e 3 comeam a conversar
durante a segunda metade do sprint, ento voc deve considerar a
possibilidade de combinar as trs equipes em uma, ou ento deix-las
como trs equipes. Cite esta questo durante a retrospectiva do sprint e
deixe que as equipes decidam por si.
Diviso de equipes das partes realmente difceis do Scrum. No pense
ou se esforce demais em otimizao. Experimente, observe as equipes
virtuais e certifique-se que voc tem tempo suficiente para discutir esse
tipo de coisa durante as retrospectivas. Mais cedo ou mais tarde voc
encontrar a soluo correta para o seu caso. O importante que as
equipes estejam confortveis e no fiquem trombando umas na outras com
freqncia.
Tamanho de equipe ideal
A maioria dos livros que eu li dizem que o tamanho de equipe ideal est
em algum ponto entre 5 e 9 pessoas.
Do que eu vi at agora a nica coisa que eu posso fazer concordar.
Apesar de que eu diria de 3 a 8 pessoas. Na verdade, eu acredito que vale
pena pagar o preo para chegar em uma equipe deste tamanho.
Digamos que voc tem uma nica equipe com 10 pessoas. Considere a
possibilidade de retirar da equipe os dois membros mais fracos. Oops, eu
disse isso?
Digamos que voc tenha dois produtos diferentes, com uma equipe de trs
pessoas por produto, e as duas esto lentas. Seria uma boa idia combinlas em uma nica equipe de 6 pessoas responsvel pelos dois produtos.
Neste caso retire um dos dois product owners da funo (ou lhe d outra
funo de consultoria ou algo do tipo).
Digamos agora que voc possui uma nica equipe com 12 pessoas, porque
a base de cdigo est to ruim que no h como duas equipes diferentes
trabalharem independentemente. No poupe esforos em consertar a base
de cdigo (ao invs de criar novas funcionalidades) at que voc chegue a
um ponto onde possvel dividir a equipe. Rapidamente este investimento
ir compensar.
Sincronizar sprints ou no?

Digamos que voc tenha trs equipes trabalhando no mesmo produto. Os
sprints delas deveriam ser sincronizados, p.ex. comear e terminar juntos?
Ou eles deveriam se sobrepor?
Nossa primeira escolha foi ter sprints sobrepostos (com respeito ao
tempo).
Essa situao parece boa. A qualquer momento haveria um sprint perto de

terminar e um outro quase comeando. O trabalho do product owner
estaria diludo durante todo o tempo. Haveria releases jorrando
continuamente do sistema. Apresentaes toda semana. Aleluia!
Esse cenrio realmente me pareceu convincente!

Ns comeamos assim, at que um dia eu tive a oportunidade de
conversar com Ken Schwaber (na poca de minha certificao em Scrum).
Ele me mostrou que essa era uma pssima idia, que seria muito melhor
sincronizar os sprints. Eu no lembro direito os motivos, mas depois de
debatermos um pouco, ele me convenceu.
Essa a soluo que temos usando desde ento, e eu nunca me arrependi

disso. Eu nunca saberei se os sprints sobrepostos funcionariam, mas acho
que no. As vantagens dos sprints sincronizados so:
Existe naturalmente um tempo para rearranjar as equipes entre
os sprints! Com a sobreposio, no h como rearranjar uma
equipe sem atrapalhar pelo menos uma outra, no meio do sprint.
Todas as equipes podem trabalhar com o mesmo objetivo num
sprint e fazer as reunies de planejamento juntas, o que promove
melhor colaborao entre as equipes.
Menos sobrecarga administrativa, p.ex., menos reunies de
planejamento, sprint demos e releases.
Por que criamos o papel de Lder de Equipe

Digamos que temos um nico produto e trs equipes.
O sujeito de vermelho (P) o product owner. Os caras de preto (S) so os

Scrum masters. Os outros so pees... quer dizer... respeitveis membros
da equipe.

Com tantas estrelas no projeto, a quem cabe decidir quem fica em qual
equipe? Ao product owner? Aos trs Scrum masters juntos? Todo mundo
escolhe em que equipe quer ficar? Mas e se todo mundo quiser ficar na
equipe 1(porque a Scrum master 1 to bonitinha...)?
E se mais tarde chega-se a concluso que impossvel ter mais do que
duas equipes trabalhando em paralelo no mesmo cdigo e precisarmos
transformar as trs equipes de seis pessoas em duas de nove. Ou seja,
apenas dois Scrum masters. Qual dos trs ser devidamente exonerado?
Em muitas empresas essas so questes delicadas.
extremamente tentador entregar a alocao e realocao dos recursos
nas mos do product owner. Mas isso no coisa de product owner,
certo? O product owner o especialista no domnio que d o norte a
equipe. Ele no deve se envolver nos pequenos detalhes. Especialmente
porque um frango (se voc no conhece a metfora dos porcos e frangos
digite chickens and pigs no Google).
Ns resolvemos essa questo criando um papel de Lder de Equipe.
Esse papel corresponde ao que chamamos de Scrum master dos Scrums
masters ou o chefo ou Scrum master senior etc. Ele no lidera
nenhuma equipe especfica mas responsvel por resolver problemas
entre as equipes, como quem ser o Scrum master da equipe, como as
pessoas devem ser divididas entre as equipes, etc.
No foi fcil achar um nome para esse papel, Lder de Equipe foi o
menos pior.
Essa soluo funcionou para ns e podemos recomend-la (independente
de como voc resolve chamar esse papel).
Como alocamos pessoas s equipes

Existem duas estratgias gerais para alocar pessoas s equipes, quando
voc tem vrias equipes trabalhando no mesmo produto.
Deixe uma pessoa designada para fazer a alocao. Por exemplo
o lder da equipe citado acima, o product owner, ou o gerente
funcional (se ele estiver envolvido o suficiente para tomar boas
decises a esse respeito)
Deixe as equipes fazerem a escolha por elas prprias.

Ns temos experimentado todas as trs opes. Trs?! Sim. Estratgia 1,
estratgia 2 e as duas combinadas.
Descobrimos que a combinao das duas tem melhor resultado.
Antes da reunio de planejamento do sprint, o lder da equipe convoca
uma reunio de alocao das equipes junto ao product owner e todos os
Scrum masters. Ns conversamos sobre o ltimo sprint e decidimos se as
realocaes da equipes esto garantidas. Entretanto, podemos decidir
combinar duas equipes, ou transferir algum de uma equipe para outra.
Ns tomamos uma deciso e anotamos como uma proposta de alocao
das equipes, que levamos reunio de planejamento do sprint.
A primeira coisa que ns fazemos na reunio de planejamento do sprint
atacar o product backlog na ordem das prioridades. O lder da equipe
ento diz algo como:
Ol pessoal. Ns sugerimos a seguinte alocao das equipes para o
prximo sprint.
Como podem ver, isso significaria uma reduo de 4 para 3 equipes. Ns

relacionamos os membros de cada equipe. Por favor, agora juntem-se e
arrumem uma seo na parede.
(o lder da equipe aguarda enquanto as pessoas ajeitam-se na sala. Depois
de algum tempo haver 3 grupos de pessoas, cada um deles perto de uma
parte vazia na parede).
Agora essa diviso das equipes uma prvia! s um ponta-p inicial
para ganharmos tempo. Durante o avano dessa reunio vocs so livres
para mudar de equipe, dividir sua equipe em duas, juntar com outra, o que
vocs quiserem. Usem o bom senso baseado nas prioridades do projeto.

Isto o que temos visto que melhor funciona. Um certo nvel de controle
centralizado no incio, seguido de um certo nvel de melhoria
descentralizada, depois.
Equipes especializadas ou no?

Digamos que sua tecnologia seja composta de 3 partes principais:
E digamos que voc tenha 15 pessoas trabalhando neste produto, e voc

no gostaria de execut-lo como uma nica equipe. Quais equipes voc
criaria?
Abordagem 1: Equipes especializadas em

componentes
Uma soluo criar equipes especializadas em componentes, como
equipe cliente, equipe servidor e o equipe BD.
Foi assim que comeamos a princpio. No funciona muito bem, pelo

menos no quando a maioria das estrias envolve mltiplas camadas.
Por exemplo, digamos que ns tenhamos uma estria denominada
quadro de avisos onde pessoas possam colocar recados/mensagens para
outras pessoas. Este quadro de avisos implicaria atualizar a interface
grfica no cliente, adicionar processamento lgico no servidor e adicionar
algumas tabelas no banco de dados.
Ou seja, as trs equipes cliente, servidor e banco de dados devem

interagir e colaborar para finalizar a estria. E isso no muito bom.
Abordagem 2: Equipes multifuncionais

Uma segunda abordagem criar equipes multifuncionais, isto , equipes
que no esto amarradas a nenhum componente especfico.
Se a maioria de nossas estrias envolvem mltiplos componentes, esta

estratgia de diviso de equipes ir funcionar melhor. Cada equipe pode
implementar uma estria completa, incluindo as partes do cliente, do
servidor e do BD. Cada equipe pode desse modo trabalhar mais
independente de cada outra, o que uma Boa Coisa.
Uma das primeiras coisas que fizemos quando introduzimos o Scrum foi
dissolver as equipes existentes especializadas em componentes
(abordagem 1) e criar equipes multifuncionais em seu lugar (abordagem
2). Isto diminuiu o nmero de casos de no pudemos completar este item
porque estvamos esperando pelos caras do servidor fazer o trabalho
deles.
Contudo, fazemos de vez em quando a criao de equipes temporrias
especializadas em componentes, sempre que surge uma forte necessidade.
Reorganizar as equipes entre os sprints ou

no?
Cada sprint geralmente bem diferente do outro., dependendo de quais
tipos de estrias possuem maior prioridade naquele momento especfico.
Como resultado, a definio da equipe ideal pode ser diferente para cada
sprint.

Na verdade, praticamente em todos os sprints nos vemos falando coisas
como este sprint realmente no um sprint normal porque (blablabla)
.... Aps um tempo ns desistimos da definio de sprints normais.
No existem sprints normais. Assim como no h famlias normais ou
pessoas normais.
Em um sprint pode ser uma boa idia ter uma equipe apenas de clientes,
consistindo apenas de pessoas que conhecem bem a base de cdigo do
cliente. No prximo sprint pode ser uma boa idia ter duas equipes e
dividir o pessoal cliente entre elas.
Um dos aspectos chave do Scrum o da cola da equipe, ou seja, se uma
equipe acaba trabalhando junta atravs de mltiplos sprints eles se
tornaro muito unidos. Eles aprendero a alcanar fluncia com o grupo e
atingiro um nvel de produtividade incrvel. Mas demora alguns sprints
para que chegue neste nvel. Se voc ficar mudando as equipes voc
nunca alcanar uma forte cola da equipe.
Logo, se voc pretende reorganizar as equipes, certifique-se de ter
levando em considerao todas as consequncias. Esta uma mudana de
curto ou longo prazo? Se esta for uma mudana de curto prazo, ignore-a.
Se for uma mudana de longo prazo, faa isso.
Uma exceo quando voc comea a praticar Scrum com uma equipe
grande pela primeira vez. Neste caso, provavelmente vale pena
experimentar um pouco com a subdiviso da equipe at que voc encontre
algo com que todos se sintam confortveis. Tenha certeza de que todos
entendo de no h problema algum se tudo der errado nas primeiras
vezes, desde que voc se mantenha sempre melhorando.
Membros de equipe em tempo parcial

Eu tenho que confirmar o que os livros de Scrum dizem ter membros em
tempo parcial em uma equipe Scrum geralmente no uma boa idia.
Digamos que voc est pretendendo incluir o Joe como um membro em
tempo parcial na sua equipe Scrum. Primeiro pense nisso com cuidado.
Voc realmente precisa do Joe na sua equipe? Voc tem certeza de que
no pode incluir o Joe em tempo integral? Quais so seus outros
compromissos? Ser que algum pode assumir estes outros compromissos
do Joe e fazer com que ele assuma uma funo um pouco mais passiva ou
de apoio em relao a este compromisso? Ser que o Joe pode passar a

integrar sua equipe em tempo integral no prximo sprint, e neste intervalo
transferir suas outras responsabilidades para outra pessoa?
Algumas vezes simplesmente no h soluo. Voc precisa
desesperadamente do Joe porque ele o nico DBA no prdio, mas as
outras equipes tambm precisam dele tanto quanto, logo ele nunca ser
alocado em tempo integral na sua equipe e a empresa no pode contratar
mais DBAs. Tudo bem. Este um caso vlido para t-lo por tempo parcial
(o que a propsito exatamente o que nos aconteceu). Mas tenha certeza
que voc est sempre fazendo essa avaliao.
De modo geral, eu prefiro ter uma equipe com 3 membros em tempo
integral do um equipe com 8 membros em tempo parcial.
Se voc tem uma pessoa que ir dividir seu tempo entre multiplas equipes,
como o DBA citado anteriormente, ainda assim uma boa idia t-lo
como membro primrio em uma nica equipe. Descubra qual a equipe que
mais ir precisar dele e faa esta sua equipe casa. Quando mais
ningum estiver precisando dele, ele estar presente nas reunies dirias,
reunies de planejamento de sprint, retrospectivas e etc desta equipe.
Como fazemos Scrum-de-Scrums

Scrum-de-Scrums so basicamente reunies regulares onde todos Scrum
masters se encontram para conversar.
Em um ponto no tempo ns tnhamos quatro produtos, onde trs dos
produtos tinham apenas uma equipe cada, e o ltimo produto tinha 25
pessoas divididas em vrias equipes. Algo assim:
Isso significa que tnhamos dois nveis de Scrum-de-Scrums. Ns

tnhamos um Scrum-de-Scrums de nvel de produto consistindo de
todas as equipes dentro do Produto D, e um Scrum-de-Scrums de nvel
corporativo consistindo de todos produtos.
Scrum-de-Scrums de nvel de produto

Esta reunio foi muito importante. Ns a fazamos uma vez por semana,
algumas vezes mais do que isso. Discutamos problemas de integrao, de
balanceamento de equipes, preparaes para a prxima reunio de
planejamento de sprint, etc. Ns alocvamos 30 minutos, mas
freqentemente passvamos disso. Uma alternativa seria termos tido
Scrum-de-Scrums todos os dias, mas nunca chegamos a tentar isso.
Nosso planejamento de Scrum-de-Scrums era
1) Ao redor da mesa, todos descrevem o que sua equipe realizou na ltima
semana, o que planeja alcanar nessa semana, e que impedimentos eles
tm.
2) Quaisquer outras preocupaes inter-equipes que precisem ser
levantadas, como problemas de integrao, por exemplo.
O planejamento de Scrum-de-Scrums no realmente importante para
mim, o importante que voc faa reunies Scrum-de-Scrums
regularmente.
Nvel corporativo Scrum-de-Scrums

Ns chamamos esta reunio de "O Pulso". Ns temos feito essa reunio
numa variedade de formatos, com uma variedade de participantes.

Ultimamente temos suprimido todo o conceito e, ao invs disso,
substitudo por uma reunio com todas as pessoas (bem, todas as pessoas
envolvidas no desenvolvimento). 15 minutos
O qu? 15 minutos? Com todos? Todos os membros de todas as equipes
de todos os produtos? Isto funciona?
Sim, isto funciona se voc (ou quem conduz a reunio) for rigoroso
quanto a mant-la curta.
O formato da reunio :
1) Notcias e atualizaes do chefe de desenvolvimento. Informaes
sobre prximos eventos, por exemplo.
2) Round-robin. Uma pessoa de cada grupo de produtos relata o que eles
fizeram na semana passada, o que eles planejam fazer essa semana e
qualquer problema. Algumas outras pessoas tambm reportam (lder do
gerenciameto de configurao, lder do controle de qualidade, etc)
3) Todos os outros so livres para adicionar qualquer informao ou fazer
perguntas
Esse um frum para informaes rpidas, no discusses ou reflexes.
Deixando-a assim, 15 minutos normalmente funciona. Algumas vezes ns
extrapolamos, mas muito raramente mais que 30 minutos. Se discusses
interessantes comeam, eu fao uma pausa e convido todos os
interessados para ficar depois do reunio e continu-la.
Por que ns fazendo uma reunio de pulso -todas-mos? Porque ns
notamos que o nvel corporativo Scrum-de-Scrums mais para
comunicao. Ns raramente temos discusses nesse grupo. Alm disso,
muitas outras pessoas fora do grupo esto famintos por esse tipo de
informao. Basicamente, equipes querem saber o que outras equipes
esto fazendo. Ento ns notamos que, se estamos indo reunio e
gastando tempo informando cada um sobre o que cada equipe est
fazendo, por que no simplesmente deixar todos freqentarem?
Intercalando as reunies dirias

Se voc tem muitas equipes Scrum para um mesmo produto, e todos
fazem a reunio diria ao mesmo tempo, voc tem um problema. O
product owner (e pessoas intrometidas como eu) s podem atender a
reunio diria de uma equipe por dia.

Por isso pedimos que s equipes evitem ter reunies dirias simultneas.
A agenda de exemplo acima de um perodo em que ns tnhamos

reunies dirias em salas separadas, ao invs de ser na sala da prpria
equipe. As reunies duravam 15 minutos normalmente, mas cada equipe
tem um perodo reservado de 30 minutos caso eles precisem estourar o
tempo um pouquinho.
Isto extremamente importante por dois motivos:
1. Pessoas como eu e o product owner podem ir a todas as reunies
dirias de uma manh. No h maneira melhor de se ter uma foto
precisa de como a sprint est se saindo e quais so as potenciais
ameaas.
2. As equipes podem visitar as reunies dirias umas das outras.
No acontece com muita freqncia, mas de vez em quando as
equipes estaro trabalhando em reas semelhantes, ento alguns
membros da equipe atendem s reunies umas das outras para
que haja sincronia.
A parte ruim que isso reduz a liberdade da equipe eles no podem
escolher o horrio que quiserem para fazer suas reunies dirias. Mas isto
no tem sido realmente um problema para ns.
Equipes de bombeiros
Tivemos uma situao onde no era possvel adotar Scrum em um grande
produto porque gastvamos muito tempo apagando incndios, ex:
corrigindo exaustivamente falhas de uma verso prematura do sistema.
Este era um verdadeiro ciclo vicioso. Ficvamos to ocupados corrigindo
falhas que no tnhamos tempo hbil para trabalhar proativamente na
preveno de novas falhas (exemplo: melhorias no desenvolvimento,
automao de testes, criao de ferramentas de monitoramento,
ferramentas de suporte, etc).
Ns resolvemos este problema criando uma equipe de bombeiros e outra

equipe Scrum dedicada.
A funo da equipe Scrum era (com as bnos do product owner) tentar
estabilizar o sistema e efetivamente prevenir os incndios.
J a equipe de bombeiros (chamvamos de suporte, na verdade) tinha
duas funes:
1) Apagar incndios;
2) Proteger a equipe Scrum de todos os tipos de perturbao,
incluindo coisas de como requisies ad-hoc vindas de lugar
algum.
A equipe de bombeiros ficava disposta prxima porta; a equipe Scrum
ficava ao fundo da sala. Desta forma, os bombeiros poderiam proteger
fisicamente a equipe Scrum de interferncias tais como vendedores
vorazes ou clientes raivosos.
Desenvolvedores experientes eram distribudos nas duas equipes, desta
forma uma equipe no seria to dependente da outra.
Basicamente, esta foi uma tentativa de resolver este impasse. Como
poderamos comear a usar Scrum se a equipe no tinha sequer a chance
de planejar mais que um dia de trabalho por vez? Nossa estratgia foi,
como mencionado, dividir o grupo.
Esta soluo funcionou muito bem. Quando a equipe Scrum teve uma sala
para trabalhar proativamente, eles finalmente estabilizaram o sistema.
Enquanto isso, a equipe de suporte desistiu completamente da ideia de
planejar atividades futuras. Trabalhando reativamente, eles simplesmente
consertavam qualquer defeito que aparecia.
Claro que a equipe Scrum no era totalmente intocvel. Freqentemente a
equipe de suporte tinha que envolver pessoas-chave da equipe Scrum, ou
pior, a equipe toda.
De qualquer forma, aps alguns meses, o sistema estava suficientemente
estvel e conseguimos desfazer a equipe de suporte e criar equipes
adicionais. Os membros da equipe de suporte (bombeiros) ficaram felizes
em aposentar seus capacetes de batalha e juntar-se s equipes Scrum.
Dividir o product backlog ou no?

Digamos que voc tem um produto e duas equipes Scrum. Quantos
product backlogs voc deve ter? Quantos product owners? Ns
analisamos trs modelos para esse tipo de situao. A escolha tem um
efeito realmente grande em como as reunies de planejamento de sprint
so conduzidas.
Estratgia 1: Um product owner, um backlog
Este o modelo S Pode Haver Um. Nosso modelo predileto.

O bom deste modelo que voc pode deixar as equipes praticamente por
conta prpria, baseado nas prioridades do product owner. O product
owner pode focar no que ele precisa e deixar as equipes decidirem como
dividir o trabalho.
Para ser mais concreto, aqui est o modo como a reunio de planejamento
de sprint funciona para esta equipe:
A reunio de planejamento de sprint ocorre em um centro de conferncias
externo.
Logo antes da reunio, o product owner define um quadro para ser o
quadro do product backlog e coloca estrias ali (cartes), ordenadas por
prioridade relativa. Ele continua colocando-as at que o quadro esteja
cheio. Normalmente estes so itens mais do que suficientes para um
sprint.
Cada equipe seleciona uma parte vazia do quadro e coloca seu nome ali.
Este o seu quadro de equipe. Cada equipe ento pega algumas estrias
do quadro do product backlog, comeando pelas estrias com maior
prioridade e coloca os cartes em seu prprio quadro de equipe.
Isso est ilustrado na imagem a seguir, com setas amarelas simbolizando o
fluxo dos cartes do quadro de product backlog para os quadros de
equipe.
Conforme a reunio progride, o product owner e a equipe debatem sobre

os cartes, movendo-os para cima e para baixo para alterar sua prioridade,
quebrando-os em itens menores, etc. Aps mais ou menos uma hora, cada
equipe tem uma verso candidata para sprint backlog em seu quadro de
equipe. Aps isso as equipes trabalham independentemente, realizando
estimativas de prazo e dividindo as tarefas.

bagunado, catico e exaustivo, mas tambm efetivo, divertido e social.
Quando o tempo acaba, normalmente todas as equipes tm informao
suficiente para iniciar seu sprint.
Estratgia 2: Um product owner, mltiplos backlogs

Nesta abordagem, o product owner mantm mltiplos product backlogs,
um por equipe. Ns no tentamos esta abordagem, mas chegamos perto.
Este basicamente nosso plano B no caso da primeira abordagem falhar.
A fraqueza desta estratgia que o product owner quem aloca estrias
para as equipes, tarefa esta que provavelmente seria melhor realizada
pelas prprias equipes.
Estratgia 3: Mltiplos product owners, um backlog

por dono.
Esta estratgia semelhante a segunda estratgia, um product backlog por
equipe, mas com um product owner por equipe tambm!
Ns no chegamos a execut-la, e provavelmente nunca iremos.

Se dois product backlogs compartilham o mesmo cdigo-fonte, isso ir
provavelmente causar srios conflitos de interesse entre os dois product
owners.
Se dois product backlogs implicarem na construo de cdigo-fonte
separados, essencialmente seria o mesmo que separar o produto como um
todo em sub-produtos e execut-los independentemente. O que significa
que estaramos de volta a situao uma-equipe-por-produto, a qual a
melhor e mais fcil.
Fazendo Branching de cdigo

Com mltiplos times trabalhando no mesmo cdigo-fonte, ns
inevitavelmente tivemos que trabalhar com branches (ramificaes) no
sistema de gerenciamento de configurao de software (ou SCM
software configuration management). Existem inmeros livros e artigos
que explicam como lidar com vrias pessoas trabalhando no mesmo
cdigo-fonte, ento eu no vou entrar em detalhes aqui. Eu no tenho
nada novo ou revolucionrio a adicionar. Irei, entretanto, resumir algumas
das mais importantes lies aprendidas at ento por nossas equipes.
Seja rigoroso ao manter a linha principal (trunk) num estado

consistente. Isso significa, que em todos os casos, tudo deve estar
compilando com todos os testes unitrios passando. Deve ser
possvel gerar uma entrega a qualquer momento.
Preferencialmente o sistema de compilao contnuo deve
compilar e auto executar testes durante a noite.
Gere uma tag (rtulo) para cada liberao ou entrega do cdigo.

No importa se uma entrega para testes de aceitao ou para
produo, tenha certeza que existe uma tag no seu ramo principal
para identificar exatamente cada entrega feita. Desta forma voc
poder em qualquer momento no futuro voltar e criar branches de
manuteno a partir daquele ponto especfico.
Crie novos branches somente quando necessrio. Uma boa

prtica fazer o branch de uma nova verso do cdigo somente
quando no possvel usar uma verso de cdigo j existente
sem quebrar sua poltica. Se estiver em dvidas, no crie o
branch. Por que? Porque cada branch ativo gera um custo de
administrao e complexidade.
Use branches principalmente para separar ciclos de vida

diferentes. Voc pode optar ou no por ter o cdigo de cada
equipe Scrum no seu prprio ramo de cdigo. Porm se voc
misturar pequenas correes com grandes alteraes na mesma
linha de cdigo, voc encontrar dificuldades para entregar as
pequenas correes!
Faa a sincronizao freqentemente. Se voc estiver trabalhando

numa branch, sincronize-se ao ramo principal (trunk) sempre que
tiver algo que esteja compilando. Todos os dias quando chegar
para trabalhar, faa a sincronia do ramo principal para o seu
branch, desta forma voc estar garantindo que seu branch esteja
atualizado respeitando tambm as alteraes das demais equipes.
Se isso te levar a problemas com o merge, simplesmente aceite o
fato que seria muito pior esperar para fazer a atualizao.
Retrospectivas com vrias equipes

Como fazemos retrospectivas de sprint quando h mltiplas equipes
trabalhando no mesmo produto?
Imediatamente aps a apresentao do sprint, depois do aplauso e da
mistura, cada equipe volta pra sua sala prpria, ou para alguma
localizao confortvel fora do escritrio. Elas fazem retrospectivas mais
ou menos como descrito na pg. 71 Como fazemos retrospectivas de
sprint.

Durante a reunio de planejamento de sprint ( qual todas as equipes vo,
j que fazemos sprints sincronizados a cada produto), a primeira coisa que
fazemos deixar um porta-voz de cada equipe resumir pontos chaves de
sua retrospectiva. Leva em torno de 5 minutos por equipe. Ento temos
uma discusso aberta em torno de 10 a 20 minutos. Depois fazemos uma
pausa. Finalmente, comeamos o planejamento de sprint mesmo.
Ns nunca tentamos outra maneira para mltiplas equipes, isso funciona
bem o suficiente. A maior desvantagem que no h intervalo entre a
retrospectiva e o planejamento do sprint. (Veja pg. 78 Intervalo entre
sprints ).
Para produtos de uma s equipe, ns no fazemos resumo retrospectivo
durante a reunio de planejamento do sprint. No h necessidade, j que
todos estavam presentes na verdadeira reunio de retrospectiva.
16
Como lidamos com equipes distribudas
geograficamente
O que acontece quando as equipes esto em locais geogrficos diferentes?
A maior parte da mgica do Scrum e do XP baseada em equipes
localizadas juntas e membros de equipe fortemente colaborativos que
programam em pares e encontram-se cara-a-cara todos os dias.
Ns temos algumas equipes geograficamente separadas e tambm alguns
membros trabalhando em casa de vez em quando.
Nossa estratgia para essa situao bem simples. Ns usamos todos os
truques possveis para aumentar a largura de banda de comunicao entre
os membros separados fisicamente. Eu no falo simplesmente sobre a
largura de banda em Mbits/segundo (apesar disso tambm ser importante).
Eu me refiro largura de banda de comunicao em um sentido mais
amplo:

A habilidade de programar juntos em pares.

A habilidade de participar cara-a-cara na reunio diria.
A habilidade de haver discusses cara-a-cara a qualquer
momento.
A habilidade de encontrar-se fisicamente para uma social.
A habilidade de ter reunies espontneas com a equipe inteira.
A habilidade de ter a mesma viso do sprint backlog, sprint
burndown, product backlog e outros termmetros de informao.
Algumas mtricas que ns implementamos (ou estamos implementando.

Ns no fizemos tudo ainda) so:
Webcam e fone de ouvido em cada estao de trabalho.
Salas de conferncia habilitadas para encontros remotos com
webcams, microfones p/ conferncia, computadores sempre
prontos, software de compartilhamento de desktop, etc.
Janelas remotas. Telas grandes em cada local, mostrando o que
est acontecendo nos outros locais. uma espcie de janela
virtual entre dois departamentos. Voc pode ficar l e navegar.

Voc pode ver quem est nas mesas e quem est conversando
com quem. Isso para criar um sentimento de ei, ns estamos
juntos nisso.
Programas de intercmbio, quando pessoas de um lugar viajam e
visitam outras regularmente.
Usando essas tcnicas e mais algumas, ns estamos lentamente mas

certamente comeando a pegar o jeito de como fazer reunies de
planejamento, demonstraes, retrospectivas, reunies dirias, etc. com
membros da equipe distribudos geograficamente.
Como normal, isso tudo um teste. Testar => adaptar => testar =>
adaptar => testar =>
adaptar
Equipes em outro pas

Ns temos vrias equipes em outros pases e temos experimentado como
lidar eficientemente com elas usando Scrum.
Existem duas estratgias principais aqui: equipes separadas ou membros
separados das equipes.
A primeira estratgia, equipes separadas, uma escolha instigante.

Entretanto, ns comeamos com a segunda estratgia, membros separados
das equipes. Existem vrias razes para isso.
1. Ns queremos que os membros das equipes conheam-se bem.
2. Ns queremos uma excelente infra-estrutura de comunicao
entre os dois locais, e tambm queremos dar um forte incentivo
s equipes para mant-las.
3. No princpio, a equipe em outro pas muito pequena para
formar uma equipe autnoma.
4. Ns queremos um perodo de intenso compartilhamento de
conhecimento antes que as equipes em outro pas independentes
sejam uma alternativa vivel.

Ao longo do tempo, ns poderemos andar na direo da estratgia de
equipes separadas
Membros da equipe trabalhando em casa.

Trabalhar em casa pode ser muito bom algumas vezes. As vezes voc
consegue programar mais em um dia em casa do que conseguiria a
semana toda na empresa. Isso se no tiver filhos :o)
Mas um dos fundamentos do Scrum diz que a equipe toda deve estar
fisicamente no mesmo lugar. Ento o que fazemos?
Basicamente deixamos a equipe decidir quando e com que frequencia
adequado trabalhar de casa. Alguns membros da equipe trabalham
regularmente de casa devido a viagens. Entretanto, ns encorajamos as
equipes a estarem no mesmo local a maior parte do tempo.
Quando os membros da equipe trabalham de casa eles participam das
reunies dirias atravs da chamada de voz do skype (as vezes por vdeo).
Eles ficam disponveis em mensageiros on-line o dia todo. No to bom
quanto estarem na mesma sala, mas o suficiente.
Ns tentamos uma vez o conceito de ter as quartas-feiras como o dia do
foco. Isto significava que basicamente se voc quisesse trabalhar em
casa, tudo bem, mas faa isso nas quartas-feiras. E cheque antes com sua
equipe. Isto funcionou muito bem com a equipe na qual tentamos.
Geralmente toda a equipe ficava em casa na quarta-feira e conseguiam
render bem, sem deixar de colaborarem uns com os outros
satisfatoriamente. O fato de que era apenas um dia na semana no deixa
que a equipe ficasse muito fora-de-sincronia. Mas por algum motivo a
idia no pegou com as outras equipes.
Em geral, pessoal trabalhando em casa no foi realmente um problema
para ns.
17
Checklist do scrum master
No final deste captulo eu irei mostrar a vocs o checklist do nosso
scrum master, listando suas rotinas administrativas mais comuns. Coisa
fcil de se esquecer. Ns cortamos as coisas bvias como remova os
impedimentos da equipe.
Comeando o sprint

Depois da reunio de planejamento do sprint, Crie uma pgina de

informaes.
o Adicione um link para sua pgina do dashboard no wiki.
o Imprima a pgina e coloque num muro onde as pessoas
passam.
Mande um email para todo mundo avisando que um novo sprint
comeou. Inclua o objetivo do sprint e um link para a pgina de
informaes do sprint.
Atualize o documento de estatsticas do sprint. Adicione a
velocidade real, o tamanho da equipe, o comprimento do sprint,
etc.
Todo dia

Garanta que a reunio diria comece e termine pontualmente.

Garanta que estrias sejam adicionadas e removidas do sprint
backlog conforme a necessidade de manter o sprint dentro do
planejamento.
CHECKLIST DO SCRUM MASTER | 125

Garanta que o product owner seja notificado dessas
mudanas.
Garanta que o sprint backlog e burndown sejam mantidos
atualizados pela equipe.
Garanta que problemas e impedimentos foram resolvidos ou
reportados ao product owner e/ou chefe de desenvolvimento.
o

Fim do Sprint

Faa uma demonstrao aberta do sprint.

Todos devem ser avisados sobre a demonstrao dois dias antes.
Faa uma retrospectiva do sprint com a equipe inteira e o
product owner. Convide o chefe de desenvolvimento tambm,
da ele pode ajudar a espalhar os conhecimentos que aprendeu.
Atualize o documento de estatsticas do sprint. Adicione a
velocidade real e os pontos chave da retrospectiva.
18
ltimas palavras
Ufa! Nunca pensei que seria to demorado.
Espero que este livro tenha lhe fornecido algumas idias teis, seja voc
um iniciante em Scrum ou um veterano.
Como o Scrum deve ser adaptado s necessidades especficas de cada
ambiente, difcil discutir de forma construtiva sobre as melhores prticas
de forma genrica. Apesar disso estou interessado em receber seu
feedback. Diga-me como a sua abordagem difere da minha. Envie suas
idias sobre como podemos melhorar!
Sinta-se a vontade para me contatar em henrik.kniberg@crisp.se
Ou ento em scrumdevelopment@yahoogroups.com.
Se voc gostou deste livro pode dar uma olhada tambm em meu blog.
Espero ir adicionando alguns posts sobre Java e desenvolvimento gil.
http://blog.crisp.se/henrikkniberg/
Ah, e no esquea
Isto s um trabalho, certo?
Leituras recomendadas
Aqui esto alguns livros que me deram muita inspirao e idias. So
altamente recomendados!
Sobre o autor
Henrik Kniberg (henrik.kniberg@crisp.se) consultor na Crisp em
Estocolmo (www.crisp.se), especializando em Java e desenvolvimento
gil de software.
Desde que apareceram os primeiros livros de XP e o manifesto gil,
Henrik abraou os princpios geis e tentou aprender como aplic-los
eficientemente em diferentes tipos de organizaes. Como co-fundador a
CTO (chief technology officer) de Goyada 1998-2003, ele teve ampla
oportunidade de experimentar o TDD (test-driven development) e outras
prticas geis bem como montar e gerenciar uma plataforma tcnica e
uma equipe de desenvolvimento com 30 pessoas.
No final de 2005 Henrik foi contratado como chefe de desenvolvimento
em uma companhia Sueca da industria de jogos eletrnicos. A companhia
estava em crise com problemas tcnicos e organizacionais urgentes.
Usando Scrum e XP como uma ferramenta, Henrik ajudou a companhia
sair da crise atravs da implementao de princpios geis e leves em
todos os nveis da empresa.
Em uma Sexta-feira de Novembro de 2006, Henrik estava em casa na
cama, com febre e decidiu tomar algumas notas para ele mesmo do que
ele aprendeu atravs do ltimo ano. Uma vez que comeou a escrever, no
conseguiu parar aps trs dias frenticos; escrevendo e desenhando as
notas iniciais se tornaram um artigo de 80 pginas intitulado Scrum e XP
direto das Trincheiras, que veio se tornar este livro.
Henrik usa uma abordagem holstica e divertida na adoo de diferentes
perfis como gerente, desenvolvedor, Scrum master, professor e coach. Ele
apaixonado em ajudar as companhias a construir excelentes softwares,
excelentes equipes, participando em qualquer perfil que seja necessrio
para isto.
Henrik cresceu em Tokyo e agora vive em Estocolmo com sua esposa
Sophia e dois filhos. Ele um msico ativo em seu tempo livre,
compondo e tocando baixo e teclado com sua banda local.
Para mais informaes, acesse: http://www.crisp.se/henrik.kniberg
Sobre a Traduo
Este livro foi traduzido voluntariamente por brasileiros, nas mais diversas
funes, com os mais diversos conhecimentos das lnguas cujo nico
interesse foi o de disseminar e popularizar as metodologias geis
Coordenao
Bruno Pedroso
Renato Willi
brunopedroso@gmail.com
renato.willi@gmail.com
Reviso
Verso 1.0
Renato Willi
Verso 1.1
Marcos Vincius Guimares
Ian Gallina
Verso 1.2
Leonardo Siqueira Rodrigues
Verso 1.3
Andr Delorme
Verso 1.4
Paulo Victor Gama Gross de Souza
pvggds@gmail.com
Ilustrao
Eduardo Bobsin Machado
eduardo.bobsin@gmail.com
Traduo
Vincius Assef
Cssio Marques
lvaro Maia
Jos Incio Serafini
Rafael Benevides
Rafael Recalde Caceres
Fernanda Stringassi de Oliveira
Renato Willi
Rodrigo Palhano
Daniel Wildt
Francisco M. Soares Nt.
Eduardo Bobsin Machado
Juliana Berossa Steffen
Mauricio Vieira
Rodrigo Russo
viniciusban@gmail.com
cassiommc@gmail.com
serafini@sr.cefetes.br
rafabene@gmail.com
rafael.r.caceres@gmail.com
fernandasoliveira@yahoo.com
dwildt@gmail.com
xfrancisco.soares@gmail.com
eduardo.bobsin@gmail.com
julianaberossa@gmail.com
mauricio@mauriciovieira.net
Adam Victor Brandizzi

Alexandre Gomes
Bruno Pedroso
Marcos Machado
Victor Hugo Germano
Acyr Jos Tedeschi
Emanoel Tadeu da Silva Freitas
Gustavo Grillo
Israel Rodrigo Faria
Marcos Vincius Guimares
Pablo Nunes Alves
Taiza Sousa
brandizzi@gmail.com
alegomes@gmail.com
brunopedroso@gmail.com
victorhg@gmail.com
emanoeltadeu@gmail.com
gustavogrillo@gmail.com
israel.faria@gmail.com
pablotj@gmail.com
Apoio
SEA Tecnologia
www.seatecnologia.com.br

Scrume XP

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Scrume XP

Enviado por

Direitos autorais:

Formatos disponíveis

FREE ONLINE EDITION

(non-printable free online version)

Trazido para voc como

Este livro distribudo gratuitamente no portal

Visite a pgina deste livro em:

Scrum e XP direto das

2007 C4Media Inc

PREFCIO EI, SCRUM FUNCIONOU!

COMO FAZEMOS PRODUCT BACKLOGS

COMO NS MANTEMOS O PRODUCT BACKLOG A NVEL DE

COMO NOS PREPARAMOS PARA O PLANEJAMENTO DO

COMO PLANEJAMOS SPRINT

POR QUE O PRODUCT OWNER DEVE PARTICIPAR

POR QUE QUALIDADE NO NEGOCIVEL

Onde traar a linha

COMO COMUNICAMOS SPRINTS

COMO FAZEMOS OS SPRINT BACKLOGS

COMO ARRUMAMOS A SALA DA EQUIPE

COMO FAZEMOS AS REUNIES DIRIAS

COMO FAZEMOS APRESENTAES DE SPRINT

COMO FAZEMOS RETROSPECTIVAS DE SPRINTS

INTERVALO ENTRE SPRINTS

COMO FAZEMOS O PLANEJAMENTO DE RELEASE E

Faa estimativas de tempo para os itens mais importantes

COMO COMBINAMOS SCRUM E XP

COMO LIDAMOS COM EQUIPES DISTRIBUDAS

CHECKLIST DO SCRUM MASTER

Prefcio por Jeff Sutherland

ii | SCRUM E XP DIRETO DAS TRINCHEIRAS

Prefcio por Mike Cohn

iv | SCRUM E XP DIRETO DAS TRINCHEIRAS

Prefcio Ei, Scrum funcionou!

apresentaes de sprint, diferentes formas de sincronizao de mltiplas

Porque eu escrevi isso

Mas o que Scrum?

8 | SCRUM E XP DIRETO DAS TRINCHEIRAS

10 | SCRUM E XP DIRETO DAS TRINCHEIRAS

Ns experimentamos com muitos outros campos, mas ao final do dia os

Campos adicionais da estria

12 | SCRUM E XP DIRETO DAS TRINCHEIRAS

Como ns mantemos o product backlog

14 | SCRUM E XP DIRETO DAS TRINCHEIRAS

invs de 20,5. Assim, deixe os espaos. bem mais

Nota: Outras pessoas alm do product owner podem adicionar estrias ao

Por que o product owner deve participar

16 | SCRUM E XP DIRETO DAS TRINCHEIRAS

Escopo e importncia so definidos pelo product owner. Estimativa

Tento ajudar o product owner a entender por que a sua

COMO PLANEJAMOS SPRINT | 17

que possa se juntar a ns durante toda a durao da reunio.

Por que qualidade no negocivel

Qualidade externa o que percebido pelos usurios do sistema.

18 | SCRUM E XP DIRETO DAS TRINCHEIRAS

Reunies de planejamento do sprint que se

COMO PLANEJAMOS SPRINT | 19

Agenda da reunio de planejamento do sprint

20 | SCRUM E XP DIRETO DAS TRINCHEIRAS

Definindo o tamanho do sprint

COMO PLANEJAMOS SPRINT | 21

Definindo o objetivo do sprint

22 | SCRUM E XP DIRETO DAS TRINCHEIRAS

Decidindo quais estrias incluir no sprint

Observe a figura acima. Cada retngulo representa uma estria, ordenado

COMO PLANEJAMOS SPRINT | 23