SCRUM

Gesto gil de
Projetos
Prefcio
Por que Scrum?

A primeira vez que entrei em contato com Gesto de Projetos foi em 2005, no meu estgio
num grande banco de investimentos. Eu fazia parte da rea de Projetos & Processos e um dos
meus desafios era cuidar da gesto de parte de desenvolvimento dos softwares do banco,
utilizando o mtodo tradicional, em cascata. Neste, um projeto era concludo em todos
estgios distintos e seguia, passo a passo, em direo ao lanamento para os usurios. O
processo era lento, imprevisvel e, em geral, nunca resultava num produto que as pessoas
queriam ou estavam dispostas a mudar para nossa instituio para obt-lo.

Algum tempo depois, durante o Mestrado, tive acesso ao Lean e aos ensinamentos de Deming
e pensei: por que no aplicar tais conceitos Gesto de Projetos? Foi a que fiquei sabendo do
trabalho de Jeff Sutherland, criador do Scrum.

Para mim, com o Scrum que os conceitos que adotei para minha vida profissional do Sistema
Toyota se liga Gesto de Projetos. O Scrum semelhante aos sistemas autocorretivos,
evolucionrios e adaptativos. mtodo cientfico e aprendizado no dia a dia, tornando o
projeto adequado ao que o cliente quer.

Um abrao,

Murilo F. M. Santos

Virgilio F. M. Santos

Equipe FM2S
Gesto gil de Projetos
SCRUM

www.fm2s.com.br
 Mtodo em Cascata

Teste

Desenvolvimento
Aprovao do
Planejamento cliente e
Codificao e lanamento
Descoberta testes
Planejamento
tcnico
Requisitos do
negcio
Incio do
Projeto

Diagramas de Gantt ou mtodo em cascata a maneira como as pessoas esto

acostumadas a trabalhar para gerenciar projetos. a maneira como as pessoas acham
que o trabalho precisa ser feito, porque assim que aprendem a faz-lo. As equipes de
projeto, com pessoas inteligente, trabalhando por meses a fio, planejando tudo como
faz-lo costumam utilizar este mtodo. Desenham lindos diagramas com todos os
detalhes do projeto e o tempo que levariam para atingir os objetivos. Ento, com uma
seleo cuidadosa de cores, apresentam um fluxo que mostra cada uma das fases do
projeto em cascata.

Esses fluxos so chamados de Diagrama de Gantt, em homenagem a Henry Gantt, que

os desenvolveu. Com o advento dos computadores pessoais na dcada de 1980,
tornou-se bem mais fcil desenvolver diagramas complicados e torna-los realmente
complexos -, e eles se tornaram verdadeiras obras de arte. Cada etapa do projeto est
detalhadamente definida; cada evento importante de se ver. O nico problema com
eles que esto sempre errados. Sempre.

Henry Gantt inventou esses famosos diagramas por volta de 1910. Eles comearam a
ser usados na Primeira Geurra Mundial pelo General William Crozier, que era o oficial
chefe do Armamento do exrcito americano. E por que tal ferramenta, criada l em
1900 para a guerra ainda hoje prtica comum no gerenciamento de projetos? No
est muito claro para ns, mas apesar das guerras de trincheiras no serem mais
praticadas, algumas ideias que as nortearam ainda so muito populares.

J visitei diversas empresas com funcionrios cujo nico trabalho atualizar

diariamente os diagramas de Gantt. O problema que quando aquele plano elegante
se depara com a realidade, ele cai por terra. S que, em vez de descartar o plano ou o
modo como pensam nele, os gerentes contratam pessoas para fazer com que parea
que o plano est funcionando.
 SCRUM

SCRUM: no rgbi o termo se refere maneira como um time trabalha junto para
avanar com a bola no campo. Alinhamento cuidadoso, unidade de propsito,
clareza de objetivo, tudo se unindo. Trata-se de uma metfora perfeita para o que
uma equipe deseja fazer. Jeff Sutherland

Ao comear um projeto, por que no fazer paradas regulares para verificar se o que
est sendo feito est seguindo na direo certa, e se, na verdade, os resultados so
os que as pessoas desejam? E verificar se existem maneiras de aprimorar a forma
como se est trabalhando para obter resultados melhores e executados mais
rapidamente, e quais seriam os obstculos que impedem as pessoas de obt-los.

Criado h vinte anos atrs, por Jeff Sutherland e Ken Schwaber, o SCRUM foi feito para
ser a forma mais rpida, eficaz e confivel de criar softwares para o setor de
tecnologia. A tcnica uma mudana radical das metodologias prescritivas e de cima
para baixo usadas na gerncia de projetos no passado; pois o SCRUM semelhante aos
sistemas autocorretivos, evolucionrios e adaptativos. Depois de ter ganhado
praticamente 100% do mercado de gesto de projetos de software, o SCRUM comea a
ganhar a gesto dos projetos tradicionais.

A tcnica acolhe a incerteza e a criatividade. Coloca uma estrutura em volta do

processo de aprendizagem, permitindo que as equipes avaliem o que j criaram e, o
mais importante, de que forma o criaram. A estrutura do SCRUM busca aproveitar a
maneira como as equipes realmente trabalham, dando a elas as ferramentas para se
auto-organizar e, o mais importante, aprimorar rapidamente a velocidade e a
qualidade de seu trabalho.

Os resultados finais do SCRUM so equipes que melhoraram drasticamente a

produtividade. Os resultados so to drsticos que grandes empresas de pesquisa e
anlise, como Gartner e Standish, agora afirmam que o antigo estilo de trabalho se
tornou obsoleto. As empresas que ainda insistem nas ideias j tentadas e malogradas
de comando e controle e que tentam impor um nvel rgido de previsibilidade esto
simplesmente fadadas ao fracasso se seus concorrentes usarem o SCRUM.
SCRUM: Gesto gil
Fluxo Continuo de Projetos
 Sprint

Pense nos diversos projetos que voc faz. Aposto que raramente voc recebe um
feedback at que eles estejam concludos e isso pode levar meses, at anos. Voc
pode estar seguindo na direo completamente errada durante muito tempo, sem
suspeitar de nada, e isso vai acabar subtraindo uma grande parte da sua vida. Nos
negcios, isso pode significar a diferena entre o sucesso e o fracasso. J viu-se esse
tipo de situao acontecer o tempo todo: uma empresa passa anos em um projeto que
parecia uma tima ideia quando os funcionrios comearam, mas, quando cruzam a
linha de chegada, o mercado j sofreu mudanas fundamentais. Quanto mais cedo
voc entregar o produto para os clientes, mais rpido eles sero capazes de dizer se
voc est fazendo algo de que se precisam.

Os Sprints s vezes so chamados de caixas de tempo, porque so definidos para ter

certa durao. Voc no pode fazer um Sprint de uma semana e, depois, um de trs
semanas. Voc precisa ser consistente: quer estabelecer o ritmo de trabalho no qual as
pessoas saibam o que pode ser feito em determinado perodo. Em geral, a quantidade
surpreende.

Um elemento crucial de um Sprint individual, porm, que uma vez que a equipe se
compromete com o objetivo, as tarefas so bloqueadas. Nada mais pode ser
acrescentado por ningum fora da equipe. Explicarei os motivos disse mais adiante,
mas, por ora, saiba apenas que interferir e distrair a equipe reduz drasticamente sua
velocidade.
 Dinmica
Reunio de
SPRINT SPRINT SPRINT SPRINT
Planejamento do 1 SEMANA 2 SEMANA 3 SEMANA 4 SEMANA
Reviso do Sprint
SPRINT

Proposta de desenvolvimento SCRUM

Reunio de Planejamento do Sprint (8 horas) - Todos
Reunies Semanais de Acompanhamento (1 hora) - Equipe
Reunies Dirias (15 minutos) - Equipe
Reunio de Reviso e Entrega (2 horas) - Todos
Papis
Dono do Produto: responsvel pelo projeto. Deve-se
preocupar com o macro, pois sabe o que o cliente precisa
Mestre Scrum: responsvel por fazer o Scrum funcionar.
Deve-se preocupar com o processo
Equipe: responsveis pelo desenvolvimento do projeto.
Preocupam-se com o micro
 Papis
Dono do Produto:
Ser a voz do cliente
Garantir o retorno
Definir as funcionalidades chave
Gerenciar stakeholders
Escrever as histrias dos usurios e os testes
Definir as metas

dele o papel que decide que trabalho deve ser feito. Ele o dono da lista de
pendncias (backlog), o que est ali e, o mais importante, em que ordem. A inspirao
para o dono do produto veio do papel do Engenheiro Chefe da Toyota. Esse profissional
responsvel por toda uma linha de produo. Para isso, eles tm de aproveitar o
talento dos grupos especializados em engenharia da carroceria, chassis, eltrica, etc.
Ele precisa escolher profissionais de todos esses grupos para criar uma equipe
interfuncional capaz de fazer um carro. E o mais interessante, que eles so lderes,
mas sem autoridade formal. Ningum se reporta a eles ao contrrio: so eles que se
reportam aos seus grupos. As pessoas podem dizer aos Engenheiros Chefes que eles
esto errados, e ento eles tm de se certificar que esto certos. Eles no fazem
avaliaes de desempenho, no promovem funcionrios e nem do aumentos. Mas
decidem sobre o carro e como ele ser feito, por consenso e no por imposio.

O Dono do Produto precisa ser capaz de dar equipe o feedback do cliente em cada
um dos Sprints. Eles precisam passar metade do tempo conversando com as pessoas
que estavam comprando o produto (coletando suas opinies sobre o ltimo
lanamento e como aquilo agrega valor) e a outra metade com a equipe, criando as
Pendncias (mostrando a eles o que os clientes valorizaram e o que no valorizaram).

Um Dono de Produto dever possuir quatro caractersticas essenciais:

Precisa ser bem-informado em relao ao setor. Com isso, devemos dizer duas
coisas: o Dono do Produto deve entender o processo que a equipe est executando
o suficiente para saber o que pode ser feito e, to importante quanto isso, o que
no pode. Mas ele tambm precisa entender bem o o qu o suficiente para saber
como traduzir o que pode ser feito em um valor verdadeiro e significativo. Esse
profissional precisa conhecer o mercado a ponto de saber o que far a diferena.

Deve ter o poder de tomar decises. Assim como a diretoria no deve interferir na
equipe, ele precisa ter autonomia para decidir sobre a viso de como o produto
ser, e o que precisa ser feito para chegar at l. Isso importante porque o Dono
 est sob presso de diversos stakeholders, tanto internos quanto externos, e
precisa ser capaz de se manter firme. Ele deve ser responsvel pelos resultados,
mas permitir que a equipe tome as prprias decises.

Ele tem que estar disponvel para a equipe, para explicar o que precisa ser feito e o
porqu. Embora o Dono do Produto seja basicamente o responsvel pela definio
das Pendncias, necessrio que haja um dilogo constante com a equipe. Em
geral, o especialista da equipe informa as decises que o Dono do Produto precisa
tomar. Ento, essa figura precisa ser confivel, consistente e estar disponvel. Sem
acesso a ele, a equipe no saber o que fazer, e muito menos em que ordem fazer.
Eles dependem do Dono do Produto para obter a viso e, tambm, para que a
inteligncia de mercado saiba o que importante.

Ele precisa ser responsvel pelo valor. A avaliao do Dono do Produto feita de
acordo com a receita que gera por ponto de esforo. Se a equipe est produzindo
quarenta pontos por semana, eu quero medir quanta receita gerada para cada
ponto. Mas a medida de valor poderia ser quantos sucessos a equipe obteve. O
importante decidir qual medida de valor ser usada, e cobrar do Dono do Produto
que ela seja entregue em maior quantidade. No Scrum, esse tipo de mtrica fcil
de observar, por causa da incrvel transparncia do mtodo.

Como a tarefa do Dono do Produto extensa, comum em grande projetos, haver

uma equipe de Donos.
 Papis
Mestre Scrum:
Garantir o processo Scrum
Remover os obstculos do time e da organizao
Ajudar o dono do produto na administrao
Facilitar reunies
Proteger o time das interferncias externas

dele o papel de ajudar a equipe a descobrir como trabalhar melhor, alm de ajudar a
eliminar quaisquer obstculos que os esteja deixando mais lentos.
 Reunio Planejamento do Sprint
Preparao para reunio:
Marketing: trar as tendncias de mercado e opinies dos potenciais clientes
CRM: trar principais reclamaes do clientes, principalmente aquelas que geraram ouvidoria
e cancelamentos
Suporte: trar as principais reclamaes, dvidas e sugestes recebidas no ms
Implantao: trar os problemas e sugestes enfrentados pela rea, ao visitar os clientes,
bem como razes da baixa aderncia em algum cliente
Comercial: trar motivos da no converso de leads, reclamaes e sugestes
Equipe SCRUM: trar as pendncias de ltima reunio, horas disponveis para o
desenvolvimento e a quantidade de trabalho que foi feito no ltimo SPRINT

Ao listar o que precisa ser feito, tentador fazer uma lista parecida com lista de
casamento: igreja, flores, celebrante, noivo, noiva, etc. A questo , se voc der cada
um desses itens para uma equipe separada que no esteja intimamente envolvida nos
resultados das decises tomadas entre rosas brancas e margaridas, talvez voc no
consiga o resultado que espera.

Quantas vezes no trabalho voc recebeu uma tarefa que no sabia exatamente por que
deveria cumpri-la? Algum pede a voc que determine a variao das vendas mensais
na Regio A, analisando lojas com mais de 55 m. Voc faz, mas no sabe por que isso
precisa ser feito. E, por causa disso, talvez fornea o tipo errado de dados, interprete a
questo erroneamente, ou talvez voc apenas se ressinta de ter recebido um monte de
trabalho extra.

O problema que voc no est conseguindo e nem fornecendo informaes

suficientes para que o trabalho seja feito da maneira correta. As pessoas pensam em
narrativas, histrias. desse modo que compreendemos o mundo. Ento, a primeira
coisa em que voc deve pensar ao considerar uma tarefa em um personagem ou em
um papel por exemplo, um cliente, uma noiva, um leitor. Para quem a tarefa ser
realizada? Por meio de quais lentes precisamos olhar quando estamos construindo
isso, tomando aquela deciso, ou entregando uma pea?

Ento, voc precisa pensar no qu no que quer que seja feito primeiro. aqui que
costumamos comear e parar. Mas apenas o meio do processo que deveramos estar
seguindo. Depois, voc precisa pensar em motivao. Por que esse personagem quer
isso? Como isso vai ajudar e maravilhar esse cliente especfico? E, de certo modo, essa
a parte principal. A motivao colore tudo.

E antes de priorizar o que precisa ser feito em sua empresa, voc precisa definir o
personagem, o usurio, o cliente a pessoa que vai usar o que voc vai produzir. Voc
precisa saber do que gostam, do que no gostam, suas paixes, entusiasmos,
frustraes e alegrias. Logo, precisa compreender as suas motivaes. Como esses
tipos de personagens informam o que desejam? Por que eles precisam do que est
propondo? O que eles vo fazer com isto?

Isto tambm influenciar o modo como voc faz estimativas das coisas. Eles querem
uma funo simples de calendrio; isso fcil. Um selo inaltervel de tempo para
objetivos legais isso um pouco mais complexo.

Traga para reunies histrias curtas. Elas devem ser curtas o suficiente para voc
estima-las. Imagine a histria da Amazon.com: como cliente, eu quero a maior livraria
virtual do mundo para que eu possa comprar qualquer livro no instante que eu
desejar. Agora, essa histria certamente engloba a Amazon, mas, na verdade,
grande demais para que possamos fazer qualquer coisa com ela.

Escreva histrias que a equipes consigam compreender. Para isto, devem ser
especficas o suficiente para serem prticas, mas no prescrevem como sero feitas.
Lembre-se: a equipe decide de que forma o trabalho ser realizado, mas o que ser
realizado decidido pelo valor que traz aos negcios. Depois, faa duas perguntas: a
histria est pronta? Como voc vai saber disso?
 INVEST: a histria correta
Como escrever histrias
Independente. A histria precisa ser prtica e passvel de ser feita por si s.
Ela no deve ser inerentemente dependente de outra histria.
Negocivel. At que esteja sendo realizada, ela precisa poder ser reescrita. A
permisso para alteraes est embutida nela.
Valiosa. Ela realmente deve acrescentar valor ao cliente, usurio ou
stakeholder.
Estimvel. Voc deve ser capaz de mensur-la.
Small (pequena). A histria precisa ser pequena o suficiente para que voc
possa estimar e planejar facilmente. Se ela for grande demais, reescreva-a ou
divida-a em histrias menores.
Testvel. A histria precisa ter um teste no qual deve passar para ser
completa. Escreva o teste antes de fazer a sua histria.

Para cada histria que se deseja fazer, deve haver uma definio de Pronto (ou seja,
ela atende aos critrios INVEST?) e, por fim, uma definio de Feito (ou seja, quais
condies precisam ser atendidas, que testes precisam ser feitos para considera-la
feita?). Encontrarmos em projetos verdadeiros que, se as histria esto realmente
pronta, a equipe vai dobrar a velocidade da sua implementao. E, se as histrias
estiverem concludas no final de um Sprint, as equipes dobram novamente a
velocidade. Esse um dos truques necessrios para conseguir fazer o dobro do
trabalho na metade do tempo.

No Scrum, esse tipo de planejamento acontece em cada um dos Sprints e chama-se

reunio de planejamento do Sprint. Todos se renem e analisam a lista de histrias que
precisam ser feitas, e dizem: tudo bem, o que podemos fazer nesse Sprint? Essas
histrias esto prontas? Elas podem ser concludas ao final desta iterao? Poderemos
demonstr-las para o cliente e mostrar-lhe valor real?

A chave para responder a essas perguntas est na velocidade que a equipe est
atingindo.
 E como estimar?
Poker do Desenvolvimento
Cada membro, tem um baralho de cartas com os nmeros: 1, 3, 5, 8,
13 e assim por diante.
Ao analisar o esforo necessrio para concluir uma tarefa, todos
puxam a carta que julgam definir melhor
Se as cartas puxadas foram 5, 8 e 13, por exemplo, a equipe considera
o esforo como a mdia entre as 3 cartas
Se a diferena superior a 3, ento abre-se para a discusso sobre os
motivos da diferena. Aps a discusso, vota-se novamente

No estime as Pendncias em horas, porque as pessoas so pssimas nesse tipo de

previso. Faa isso usando uma classificao relativa por tamanho: Pequeno, Mdio ou
Grande. Ou, melhor ainda, use a sequncia de Fibonacci e faa estimativas de pontos
para cada item: 1, 2, 3, 5, 8, 13, 21, etc.
Dinmica
Dinmica
O que ser entregue no SPRINT Mensal? O time Scrum ir prever quais funcionalidades,
solicitadas pelas reas, podem ser desenvolvidas durante o SPRINT. Para isto, as demais reas
iro apresentar uma lista com as histrias dos itens solicitados pelos clientes e , junto do time
Scrum, iro colaborar para entender o que deve ser feito para atender as sugestes
levantadas. Depois, define-se a meta, que o objetivo a ser alcanado, por meio do
desenvolvimento das mudanas. Isto funcionar como guia para a equipe durante o SPRINT.
Como ns iremos escolher o que deve ser feito? Depois de definido o que deve ser
entregue, o time de desenvolvimento escolho como ir entregar as funcionalidades
solicitadas. Este trabalho poder variar em tamanho ou no esforo estimado. Entretanto,
deve-se planejar o trabalho para um ms, mas as atividades planejadas para a primeira
semana, devem ser decompostas em tarefas que durem no mximo um dia.
Meta Sprint: qual a meta do Sprint? d ao time de desenvolvimento alguma flexibilidade
quanto a funcionalidade a ser implementada dentro do sprint. A medida que o time Scrum
trabalha, ele mantm a meta na mente.
 SCRUM Dirio
SCRUM Dirio (Desenvolvimento)
O scrum dirio uma reunio de 15 minutos para o time sincronizar suas atividades e criar um
plano para as prximas 24 horas. Isto feito por meio da avaliao do trabalho realizado versus o
planejado na ltima reunio. O scrum dirio deve ocorrer sempre na mesma hora e lugar todos os
dias, para reduzir a complexidade. Durante a reunio, todo desenvolvimento ir explicar:
O que foi feito desde a ltima reunio?
O que ser feito at a prxima reunio?
Quais os obstculos esto no caminho?
O time de desenvolvimento utiliza o scrum dirio para avaliar o progresso no caminho da meta e a
velocidade que cada tarefa pendente vai sendo executada. O time de desenvolvimento
frequentemente se encontra imediatamente aps o scrum dirio para replanejar o resto do
trabalho daquele Sprint.

Quando se trata de verificar o trabalho da equipe, uma vez por dia o suficiente.
Rena-se por 15 minutos na reunio diria, veja o que pode ser feito para aumentar a
velocidade e faa isso. O Mestre Scrum, a pessoa responsvel por dirigir o processo, faz
trs perguntas para cada um dos membros da equipe:

O que voc fez ontem para ajudar a equipe a concluir o Sprint?

O que voc vai fazer hoje para ajudar a equipe a concluir o Sprint?

Que obstculos a equipe est enfrentando?

S isso. Essa a reunio. Se ela levar mais que 15 minutos, voc est fazendo algo
errado. O objetivo dessa reunio ajudar todos na equipe a saberem exatamente em
que ponto do Sprint eles esto. Todas as tarefas sero concludas no prazo? Existem
oportunidades para ajudar outros membros da equipe a superar obstculos? No h
tarefas definidas por algum superior a equipe autnoma; eles fazem isso. No h
relatrios detalhados para a diretoria. Qualquer um da diretoria ou de outra equipe
pode passar e olhar para o quadro Scrum que vai saber exatamente em que ponto o
projeto est.

Para a sua reunio funcionar bem, sugerimos algumas regras.

Os encontros devem acontecer no mesmo horrio e lugar todos os dias, no

importando em qual, e todos devem estar presentes. Se a equipe inteira no
estiver presente, a comunicao simplesmente no acontece. A questo chave aqui
dar equipe um ritmo regular.

A reunio no pode durar mais que 15 minutos. Ela tem que ser rpida, clara e
direto ao ponto. Se algo precisar ser discutido mais a fundo, deve ser anotado para
 uma reunio posterior. A ideia obter as informaes mais valiosas e prticas no
menor tempo possvel.

Todos devem participar de forma efetiva. Para isto, faa com que todos fiquem de
p. Desse modo, haver conversas ativas, onde todos falam e ouvem, e as reunies
sero curtas.

No trate as reunies dirias como relatrio individual Eu fiz isso, Eu vou fazer
aquilo..... A equipe deve conversar de forma rpida sobre como poder seguir em
direo concluso do Sprint. A passividade no apenas algo indolente, mas
tambm algo que afeta o desempenho do restante da equipe. Assim que
detectada, deve ser eliminada, imediatamente.

Uma equipe Scrum deve ser agressiva e por isto, sair da reunio sabendo a coisa mais
importante que precisam atingir naquele dia. Chame sua equipe para o ataque e
pergunte se eles desejam ser horrveis ou lembrados como timos.
 Reviso do Sprint ou Demonstrao do Sprint
Durao de 4 horas. Tem como funo avaliar as funcionalidades criadas e adapt-las ao backlog do
produto, se necessrio. Esta uma reunio informal, e a apresentao das funcionalidades criadas tem
como objetivo coletar feedbacks e estimular a colaborao. A reunio dever incluir:
O dono do produto:
Identificando o que foi feito durante o Sprint;
Discutindo o backlog do produto conforme ele apresentado. Depois, projetando quando as prximas
funcionalidades sero entregues, de acordo com o progresso da equipe
A equipe de desenvolvimento:
Discutindo o que foi bem durante o Sprint, quais problemas ocorreram e como eles foram solucionados;
Demostrando as funcionalidades criadas e respondendo as questes feitas;
O grupo inteiro colabora sobre o que fazer no prximo Sprint, e assim, esta reunio j prepara
valiosos inputs para a reunio de planejamento mensal
Resultado: backlog de produto revisado. Isto define a lista das provveis necessidades para o prximo
Sprint. Alm deste input, o backlog do produto poder ser ajudado para acomodar s novas
oportunidades levantadas.

Trata-se da reunio na qual a equipe mostra o que conseguiu fazer durante o Sprint.
Qualquer pessoa pode participar, no apenas o Dono do Produto, o Mestre Scrum e a
equipe, mas tambm os stakeholders, os gestores, os clientes, e qualquer outra pessoa.
Esta uma reunio aberta na qual a equipe demonstra o que conseguiu colocar na
coluna Feito.

A equipe s deve demonstrar o que satisfaz a Definio de Feito. O que est total e
completamente concludo e pode ser entregue sem qualquer trabalho adicional. Pode
no ser o produto completo, mas deve ser um atributo concludo do produto.
 Retrospectiva do Sprint
A retrospectiva do Sprint uma oportunidade para a equipe Scrum se auto avaliar e criar um plano de
melhorias que poder ser executado durante o prximo. Este encontro ocorre depois da reviso do Sprint e
antes da prxima reunio de planejamento do prximo. Sua durao deve ser de 3 horas para cada ms de
Sprint. Seu propsito :
Avaliar o ltimo ciclo em relao s pessoas, relacionamentos, processos e ferramentas;
Identificar e organizar os principais itens que foram bem e o potencial para melhora;
Criar um plano para a implementao das melhorias na maneira como o time realiza seu trabalho.
O mestre Scrum ir estimular o time a melhorar, dentro do modelo Scrum, por meio do desenvolvimento
dos processos e prticas para tornar isto mais efetivo e prazeroso para o prximo Sprint. Durante cada
retrospectiva, o time planeja maneiras para melhorar a qualidade, adaptando o que ser classificado como
pronto.
Ao final da retrospectiva do Sprint, o time dever ter identificado melhorias que sero implementadas no
prximo ciclo. Vale lembrar que as melhorias podero ser implantada a qualquer hora, mas que esta
reunio fornece uma oportunidade formal para a equipe focar na sua auto avaliao e melhor-la.

Depois que a equipe mostrou o que conseguiu fazer no Sprint anterior aquilo que
est Feito e pode ser entregue para clientes para obteno de feedback - , eles se
renem e pensam no que deu certo e o que poderia ter sido melhor, e o que podem
melhorar no prximo Sprint. Qual o aprimoramento no processo que eles, como uma
equipe, podem implementar de forma imediata?

Para ser eficaz, essa reunio requer certa dose de maturidade emocional e atmosfera
de confiana. O importante lembrar-se sempre de que voc no est procurando
culpados; est olhando para o processo. Por que aquilo aconteceu assim? Por que voc
no percebeu aquilo? O que poderia ter acontecido para sermos mais geis?
essencial que as pessoas na equipe assumam a responsabilidade pelo processo e seus
respectivos resultados, e que busquem solues como uma equipe. Ao mesmo tempo,
elas tm de ter coragem de levantar as questes que realmente as incomodam, de
forma que a soluo seja orientada, em vez de acusadora. E o restante da equipe
precisa ter maturidade para ouvir o feedback, absorv-lo e procurar uma soluo, em
vez de assumir uma postura defensiva.

No final da reunio, a equipe e o Mestre Scrum devem chegar a um acordo sobre um

aprimoramento no processo, s vezes, chamado de kaizen, e deve ser colocado nas
pendncias do prximo Sprint, acompanhado de testes de aceitao. Desse modo, ser
fcil para a equipe verificar se o aprimoramento realmente foi implementado, e que
efeito ele teve sobre a velocidade.
 Backlog List

O backlog do produto tem listadas

todas as caractersticas, funes,
necessidades, melhorias e ajustes
que constituem as mudanas para
serem feitas nas verses futura do
produto

uma lista ordenada de tudo que pode ser necessrio no produto e a fonte nica dos
requisitos para quaisquer mudanas a ser feita no produto. O dono do produto o
responsvel pelo Back Log, incluindo seu contedo, anlise de viabilidade e a ordem de
prioridade.

O backlog do produto nunca est completo. Sua primeira verso, possui somente o que
conhecido como requisitos necessrios. O backlog do produto avana de acordo com
a evoluo do produto e do ambiente em que ele est inserido. A lista dinmica;
mudando constantemente para identificar quais as necessidades de alterao no
produto so apropriadas, competitivas e teis. Enquanto o produto existir, existir
tambm o seu backlog.

O backlog do produto tem listadas todas as caractersticas, funes, necessidades,

melhorias a ajustes que constituem as mudanas para serem feitas nas verses futura
do produto. Cada atributo listado no backlog possui sua descrio, prioridade e
estimativa.

O backlog do produto frequentemente ordenado pelo valor, risco, prioridade e

necessidade. Os itens listados no backlog do produto direcionam as atividades de
desenvolvimento. Quanto mais alta a pontuao do item, maior o consenso do seu
valor. Quanto maior a prioridade de item, mais detalhes ele dever possuir. Os itens do
backlog do produto que sero trabalhados pelo time de desenvolvimento no prximo
Sprint, so decompostos para que possam ser feitos no prximo ciclo. Depois disto,
eles so classificados como prontos para serem levados reunio de planejamento
mensal.

A medida que o produto utilizado e vai ganhando valor, o cliente comea a dar
feedback e a lista comea ficar maior e mais exaustiva. Os requisitos nunca param de
mudar, ento o backlog do produto uma lista viva. Mudanas nos requisitos de
negcios, condies de mercado ou na tecnologia, podem gerar mudanas no backlog
do produto.
Outros Documentos

www.fm2s.com.br
 Sprint Backlog
Tarefas Seg Ter Qua Qui Sex
Codificar a interface do usurio
uma lista de tarefas que
Codificar a mudana na rvore
do PCP a equipe se compromete
Testar a interface a fazer no Sprint
Escrever a ajuda online
Quadro de Monitoramento
Slide 21

Quadro de Monitoramento