1

APOSTILA INTRODUTRIA
AO SCRUM
2

Desafio do desenvolvimento de software ___________________________________ 4
Introduo ao Manifesto gil ____________________________________________ 5
Os princpios do Manifesto gil___________________________________________ 7
Metodologias geis ____________________________________________________ 8
SCRUM ______________________________________________________________ 9
A origem do SCRUM ________________________________________________________ 9
Conceitos do SCRUM ______________________________________________________________ 9
O que SCRUM? __________________________________________________________________ 9
Pilares do SCRUM ________________________________________________________________ 10
O SCRUM ________________________________________________________________ 11
Papis no SCRUM ________________________________________________________________ 12
Product Owner ________________________________________________________________ 12
Scrummaster __________________________________________________________________ 12
Time ________________________________________________________________________ 12
O ciclo do SCRUM _________________________________________________________ 14
Reunio de Planejamento da Release _________________________________________ 14
Artefatos do Release Planning ______________________________________________________ 14
Backlog do Produto ____________________________________________________________ 14
Release Burndown _____________________________________________________________ 16
Dicas alm do SCRUM _____________________________________________________________ 17
Definio de "Pronto" ______________________________________________________ 18
A Sprint _________________________________________________________________ 19
Planejamento da Sprint _____________________________________________________ 19
Dicas alm do SCRUM _____________________________________________________________ 20
Execuo da Sprint ________________________________________________________ 22
Artefatos da Sprint _______________________________________________________________ 22
Backlog da Sprint ______________________________________________________________ 22
Sprint Burndown_______________________________________________________________ 24
Dicas alm do SCRUM _____________________________________________________________ 25
Reunio Diria ____________________________________________________________ 26
Dicas alm do SCRUM _____________________________________________________________ 26
Reviso da Sprint __________________________________________________________ 27
Dicas alm do SCRUM _____________________________________________________________ 27
Retrospectiva da Sprint _____________________________________________________ 28
Dicas alm do SCRUM _____________________________________________________________ 28


3

ndice de figuras e tabelas
Figura 1 Fluxo do Scrum .................................................................................................. 11
Figura 2 Burndown da Release ........................................................................................ 16
Figura 3 Burndown da Sprint ........................................................................................... 24
Tabela 1 Backlog do Produto ........................................................................................... 15
Tabela 2 Backlog da Sprint .............................................................................................. 23
Tabela 3 Quadro SCRUM ................................................................................................. 25

4

Desafio do desenvolvimento de software
Os desafios de se desenvolver softwares vo muito mais alm do que problemas de processos
e procedimentos. Trabalhar com expectativas, transferir e compartilhar conhecimento,
motivao e um bom ambiente so exemplos de aspectos que devem ser considerados muito
importantes no desenvolvimento de um software. Cada vez mais fica claro que o foco de
pontos a melhorar e a melhoria contnua provem e depende das pessoas comprometidas com
o desenvolvimento do software. Isto nos eleva a um novo patamar na cultura de
desenvolvimento de software, onde, tanto quanto a Cincia de Software considerada uma
rea Exata, sua aplicabilidade se demonstra cada vez mais uma rea Humana.
A evoluo de uma prtica, processo ou produto somente se d atravs da evoluo de
Pessoas. Esta evoluo est cada vez mais presente nas necessidades do desenvolvimento de
software atual. Evoluirmos como Pessoa, como um Time unido, atravs de colaborao,
confiana e comprometimento so atitudes que se mostram eficazes e eficientes para vencer
os desafios de desenvolver um software. Esta cultura que j nasceu e est sendo disseminada,
uma cultura voltada a Pessoas e a interao entre elas, voltada ao real valor agregado aos
clientes, simples e leve vem se fortificando, se adaptando as necessidades e dando novos ares
a forma que se desenvolve software.
Rafael Barbosa Camargo

5

Introduo ao Manifesto gil
Em fevereiro de 2001, vrios profissionais da rea de desenvolvimento de software se
reuniram em uma Estao de Esqui em Utah, Estados Unidos, para uma discusso sobre o
desenvolvimento de software. Em tal discusso, foram abordados os desafios, necessidades e
desejos que todos tinham em relao a tal assunto. Atravs desta reunio, foram extradas
algumas concluses que pautaram a gerao de um Manifesto.
O Manifesto gil foi gerado sobre os Valores que estes profissionais vislumbraram ser algo
bom, com a finalidade de impulsionar melhorias no cenrio geral de desenvolvimento de
software.
O Manifesto gil:
Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o ns mesmos e
ajudando outros a fazerem o mesmo. Atravs deste trabalho, passamos a valorizar:
Indivduos e interaes mais que processos e ferramentas
Software em funcionamento mais que documentao abrangente
Colaborao com o Cliente mais que negociao de contratos
Responder a mudanas mais que seguir um plano
Ou seja, mesmo havendo valor nos itens direita, valorizamos mais os itens esquerda.
http://agilemanifesto.org
O Manifesto gil foi gerado por muitos profissionais e estudiosos de Desenvolvimento de
Software, onde destes, os seguintes assinaram o Manifesto:
Kent Beck James Grenning Robert C. Martin
Mike Beedle Jim Highsmith Steve Mellor
Arien van Bennekum Andrew Hunt Ken Schwaber
Alistair Cockburn Ron Jeffries Jeff Sutherland
Ward Cunnigham Jon Kern Dave Thomas
Martin Fowler Brian Marick

O Manifesto gil uma citao complexa, que requer estudo, prtica e reflexo.
O primeiro axioma nos mostra que o valor dos indivduos e a interao entre eles geram mais
valor do que a simples utilizao de ferramentas ou padres. Pessoas reagem atravs de
emoes. Tais emoes geram aes que tornam os processos imprevisveis. Logo, a
adaptao de processos e procedimentos em relao interao entre as pessoas se tornar
uma melhor ferramenta do que a padronizao do comportamento humano a processos
genricos.
O segundo axioma nos exibe um dos principais focos de um projeto: Software funcionando.
No difcil encontrar projetos onde o software esteja 90% concludo, porm ainda no
6

esteja em funcionamento. Tal questo se d muito pelo fato das documentaes abrangentes
geradas. A finalidade desta documentao representar um desejo e fix-lo quase como um
contrato. Porm o esforo tomado para isto muito grande e gera pouco valor agregado
uma vez que os desejos e necessidades de um projeto mudam fatalmente conforme seu
andamento. Isto de forma alguma implica que o Manifesto gil discorda ou no aconselha a
gerao de documentao, mas sim, que incentiva a documentao com real valor, gerada no
tempo certo e por motivos que tragam valor.
O terceiro axioma exibe uma mudana profunda de atitude. O processo de desenvolvimento
de um software algo colaborativo e dinmico. Os contratos de desenvolvimento de software
hoje em dia so meramente artefatos para segurana ou negociao de risco. Estes
contratos so firmados muitas vezes apenas com a designao de definir um culpado caso o
projeto falhe e/ou uma definio rgida de prazo, custo e escopo. Os contratos muitas vezes
so usados para gerar presso, seja por parte do cliente cobrando o todo ou mesmo pelo
fornecedor, se eximindo em relao a qualquer mudana daquilo que foi combinado. Logo, o
Manifesto gil nos exibe a faceta da colaborao real. Tal colaborao deve visar um real valor
agregado para o cliente e para tal, deve ser pautada em confiana e transparncia.
O ltimo axioma to simples tanto quanto profundo. Em muitos projetos, busca-se tanto
seguir o Planejamento inicial definido, que ao longo de projeto, perde-se o foco no produto.
Torna-se mais importante seguir o plano do que entregar o software. Pelos motivos explicados
no terceiro axioma, gera-se o problema exemplificado no segundo axioma. Logo tudo impacta
no quarto axioma. Vamos explicar:
Pela falta de colaborao e confiana, so firmados contratos com valores, custos, prazos e
escopos definidos. Para se ter certeza (certeza totalmente irreal esta!) gera-se toda a
documentao abrangente para se levantar as funcionalidades a serem desenvolvidas. O
levantamento de requisitos custoso e demorado e quando se comea o desenvolvimento do
sistema, acontecem s mudanas. Essas mudanas se tornam traumticas mediante ao tanto
de tempo que j foi gasto analisando e documentando requisitos. Inicia-se todo um trabalho
para ver o quanto esta mudana altera no escopo, prazo e custo do projeto e aqui que o
cabo de guerra se intensifica.
O foco do Manifesto gil est em responder as mudanas para maximizar o valor do produto,
ao invs de seguir um plano pr-definido. Muitas vezes as mudanas trazem imenso valor e
no puderam ser vistas no incio do projeto pelo simples fato de que naquele momento, no se
fazia sentido pedir o que se pede agora. O mundo dinmico e o desenvolvimento de
software tambm tem est caracterstica. Cabe a ns tirar proveito desta mudana como um
diferencial de valor agregado e buscar colaborar para atingir um sucesso completo.


7

Os princpios do Manifesto gil
Complementares ao ideal do Manifesto criaram-se princpios que auxiliam na empreitada de
desenvolver softwares:
Nossa maior prioridade satisfazer o cliente, atravs de entregas rpidas e
contnuas gerando valor ao software
Devemos receber bem as mudanas nos requisitos, mesmo em estgios tardios do
desenvolvimento. Processos geis devem admitir mudanas em prol de vantagens
competitivas para o cliente
Trabalhar para entregar software em intervalos de duas semanas at dois meses,
com preferncia para que tenha uma curta escala de tempo
As pessoas de negcio e os desenvolvedores devem trabalhar juntos diariamente
durante todo o projeto
Construir projetos baseados em indivduos motivados. Dar-lhes o ambiente e o
suporte que precisam e confiar que iro realizar o trabalho
O mtodo mais eficiente e efetivo de transmitir informaes em uma equipe de
desenvolvimento conversa face-a-face
Software funcionando a principal medida para o progresso.
Processos geis promovem o desenvolvimento sustentvel. Os patrocinadores, os
desenvolvedores e os usurios devem ser capazes de manter um ritmo constante
indefinidamente
Ateno contnua a excelncia tcnica e um bom design aumentam a agilidade
Simplicidade a arte de maximizar o valor do trabalho no feito essencial
As melhores arquiteturas, requisitos e design surgem a partir de equipes auto-
organizadas
Em intervalos regulares, a equipe deve refletir sobre como tornar-se mais efetiva e
ento, ajustar-se de acordo com seu comportamento

8

Metodologias geis
Com base nos valores e princpios do Manifesto gil, algumas metodologias foram
enquadradas ou nasceram e levam a alcunha de Metodologias geis.
Metodologias geis mais conhecidas:
Crystal
Extreme Programming (XP)
Feature Driven Develpoment (FDD)
LEAN Software Development
OpenUP
RUP (a partir da verso 7.0)
SCRUM
Repare que o Manifesto gil fora criado em 2001 e algumas destas metodologias so
anteriores a esta data. Isso se d pelo fato que o conceito e a prtica destas metodologias
pautaram a criao do Manifesto.
Conceitos como Empirismo, PDCA, LEAN esto por trs destas metodologias e logo, por
trs do Manifesto gil. importante ter em mente que o Manifesto gil no definiu tais
conceitos, mas sim, explicita os ganhos que tais aplicaes geraram.


9

SCRUM
A origem do SCRUM
De incio, o SCRUM foi concebido como uma forma de gerenciamento de projetos de produtos
complexo por Ikujiro Nonaka e Hirotaka Takeuchi, no livro The New New Product
Development Game [Harvard Business Review, Janeiro-Fevereiro 1986].
Em 1993, Jeff Sutherland, John Scumniotales e Jeff MacKenna conceberam, documentaram e
implementaram o SCRUM na empresa Easel Corporation. Ken Schwaber, Mike Smith e Chris
Martin tambm o implementaram e trabalharam em sua formao.
Em 1995 o SCRUM foi formalizado por Ken Schwaber, Mike Beedle e Jeff Sutherland e
apresentado oficialmente na OOPLSA (Object-Oriented Programming, Systems, Languages and
Applications).
Conceitos do SCRUM
O SCRUM tem em sua base os conceitos de:
LEAN
Desenvolvimento iterativo e incremental
Team Process
Micro enterprise development
Empirismo
PDCA
Time Boxe
Definio de Pronto
Team Velocity
O que SCRUM?
SCRUM um framework para desenvolvimento de produtos complexos, fundamentado na
teoria de controle de processos empricos, utilizando da abordagem iterativa e incremental,
visando maximizar valor de negcio, otimizar a previsibilidade e controlar risco.
Outras definies encontradas de SCRUM:
Processo iterativo e incremental para o desenvolvimento de produtos e
gerenciamento de projetos
SCRUM um framework dentro do qual voc pode empregar diversos processos e
tcnicas, onde, produtos complexos podem ser desenvolvidos.
SCRUM um processo gil e leve que pode ser utilizado para gerenciar e controlar o
desenvolvimento de software

10

Pilares do SCRUM
Trs pilares sustentam o SCRUM:
Transparncia: Visibilidade e entendimento
Os pontos do processo devem estar visveis para todos aqueles que participam ou so afetados
pelo processo. Alm da visibilidade, todos os aspectos devem estar passveis de entendimento
por todos.
Inspeo: Verificao e sentimento
Os pontos do processo devem ser passveis de verificao com freqncia. A freqncia deve
ser suficiente para que rudos inaceitveis sejam detectados.
Adaptao: Mudar parar melhor, tentar
Dado a visibilidade e o entendimento. O processo de inspeo tem como resultado algumas
adaptaes que visam melhoria do sistema. As aes de mudana so ento ajustadas e
realizadas e um novo ciclo se inicia.
Em uma aplicao de SCRUM fundamental estar atento a estes pilares, logo, ao se buscar
incrementar ou alterar um processo ou procedimento, busque visualizar se esta ao est de
acordo com os pilares do SCRUM. Tal verificao ser valida tambm para os valores e
princpios do Manifesto gil.


11

O SCRUM

Figura 1 Fluxo do SCRUM
O SCRUM formado papis, eventos com durao fixa, artefatos e regras.
Os papis so:
Scrummaster: responsvel por garantir que o processo seja compreendido e
seguido
Product Owner: responsvel por maximizar o valor de trabalho que o Time gera
Time: Executa o trabalho. Formado com todas as habilidades necessrias para
gerar o produto
O SCRUM utiliza de eventos com durao fixa para gerar uma regularidade. As cerimnias com
durao fixa so:
Reunio de Planejamento da Release
Reunio de Planejamento da Sprint
Sprint
Reunio diria
Reviso da Sprint
Retrospectiva da Sprint
O SCRUM utiliza ainda os seguintes artefatos:
Backlog do Produto
Backlog da Sprint
Burndown da Release
Burndown da Sprint

12

Papis no SCRUM
O Time SCRUM composto por um Scrummaster, Product Owner e pelo Time.
Product Owner
O Product Owner o responsvel por maximizar o ROI (Return on Investiment) do Projeto. Seu
papel fundamental e suas atribuies so de grandes responsabilidades. O Product Owner
deve manter vivo o Product Backlog, com as informaes das necessidades que deseja realizar.
de sua responsabilidade priorizar o trabalho a ser realizar pelo Time, bem como, dar
visibilidade a est priorizao. O Product Owner uma nica pessoa, porm, esta pessoa pode
ser auxiliada por um grupo de pessoas. Contudo, deve-se ressaltar que a deciso da prioridade
realizada pelo Product Owner.
Dentre as atribuies do Product Owner, ressalta-se:
Definir as funcionalidades do produto
Maximizar o ROI
Apresentar ao Time os requisitos necessrios para o desenvolvimento do produto
Planejar as entregas do produto
Gerenciar alteraes do produto
Scrummaster
O Scrummaster o responsvel por garantir e ajudar o Time SCRUM esteja aderindo e
aplicando os valores do SCRUM, as prticas e as regras. Mais do que garantir a adeso e
aplicao, o Scrummaster educa o Time SCRUM, treinando-os e estimulando-os a melhoria
contnua. O Scrummaster tem uma atuao de Facilitador, removendo os impedimentos que
o Time SCRUM venha a ter, para poder maximizar a produtividade do Time.
As responsabilidades do Scrummaster so:
Remover impedimentos no desenvolvimento do produto
Ensinar o cliente na maximizao do valor agregado
Facilitar a rotina do Time SCRUM, estimulando a criatividade e motivando-os
Auxiliar o Product Owner na manuteno do Product Backlog
Proteger o time de interferncias externas
Promover prticas e procedimentos que auxiliem o Time no desenvolvimento do
Produto
Time
O Time tem a responsabilidade de realizar e entregar o produto solicitado pelo Product Owner.
O Time um grupo de pessoas que tm as formaes necessrias para gerar o produto
solicitado. Todos os integrantes do Time devem contribuir para a gerao do produto, mesmo
que isto implique em que um membro do Time tenha de aprender uma nova habilidade. Os
Times no contm subtimes dedicados a reas particulares do produto. Os Times SCRUM
devem ter tais caractersticas:
Auto organizado
Interdisciplinar
13

Ser formador por cinco at nove membros
Ser auto organizado implica que ningum deve dizer ao Time como transformar as solicitaes
do Product Owner em incrementos de funcionalidade. O Time descobre por si s como isto
deve ser feito. O Scrummaster deve auxili-los nesta descoberta.
O Time tem a responsabilidade de:
Fazer o necessrio dentro dos valores e diretrizes para alcanar os objetivos da
Sprint
Demonstrar o resultado do desenvolvimento em uma Sprint para o Product Owner
Comprometidos com o trabalho
Organizar o espao fsico (ambiente)
Os papis no SCRUM so bem definidos, porm, existe ainda uma gama de skills que cada
pessoa que ocupar estes papis deve desenvolver.
A interao entre os membros do Time SCRUM crucial para o sucesso de um projeto. Um
ambiente de confiana e transparncia deve ser gerado e mantido.


14

O ciclo do SCRUM
Reunio de Planejamento da Release
A Reunio do Planejamento da Release tem por finalidade estabelecer um plano de Metas que
o Time SCRUM possa entender comunicar e desenvolver. O Planejamento da Release eleva
discusso as questes como:
Como podemos transformar os desejos do Cliente em um produto vencedor?
Como podemos maximizar o Retorno sobre o Investimento desejado?
O Planejamento da Release pode ser definido atravs de uma Viso. O SCRUM no explicita
como esta viso pode ser declarada, porm, indica que as metas a serem obtidas devem estar
bem expressas e visveis a todos, assim como as maiores prioridades do Backlog do Produto, os
principais riscos e as caractersticas gerais da funcionalidade a ser desenvolvida. Ainda no
Planejamento da Release, procura-se obter-se uma data estimada de entrega do produto, bem
como um provvel custo. Para a estimativa de entrega, requer-se que o Backlog do Produto
tinha sido priorizado pelo Product Owner e estimado pelo Time. O SCRUM no define uma
tcnica de estimativa, mas existem vrias tcnicas teis que podem ser utilizadas.
Artefatos do Release Planning
Backlog do Produto
O Product Owner responsvel por gerar e manter o Backlog do Produto. O Backlog do
Produto uma lista com as necessidades para lanar o produto desejado. Esta lista deve ser
priorizada de forma que os itens com maior prioridade se mantenham na parte de cima do
Backlog do Produto. O SCRUM no define uma tcnica de priorizao, porm recomenda que a
mesma seja feita com base em risco, valor e necessidade. Os itens com maior prioridade
devem ser melhor detalhados e compreendidos, pois, sero os itens a ser primeiramente
desenvolvidos pelo Time. Para os itens de maior prioridade, o Product Owner e o Time j
podem avanar, estudando requisitos mais definidos, critrios de aceitao ou detalhes
tcnicos.
O Backlog do Produto evoluiu medida que o produto evolui e desta forma, ele nunca est
completo ou terminado. Ele um artefato vivo.
O Time pode estimar uma velocidade inicial para poder gerar estimar as datas de entrega. Esta
velocidade deve ser aferida constantemente. Uma vez atualizada, o Backlog do Produto e suas
datas de entrega tambm devem ser revistos.
15

Exemplo:
Item Valor de Negcio Critrios de Aceite Estimativa Data
estimada
Insero de novos
materiais do
Almoxarifado
100 Inserir dados da descrio
do produto, quantidade
de produtos e cdigo. O
cdigo deve ser um texto
com at 5 caracteres.
3 09/05
Alterar quantidade
de materiais
existentes no
Almoxarifado
90 Alterar o valor existente
do produto cadastrado.
No permitir que um
produto tenha
quantidade negativa.
2 09/05
Remover material
do cadastro do
Almoxarifado
80 Poder excluir um material
do Almoxarifado. A
excluso exclui o material
e toda a quantidade do
mesmo do cadastro do
Almoxarifado.
5 09/05
Entrada em lote de
materiais do
Almoxarifado
70 Inserir vrios materiais de
uma nica vez.
8 16/05
Alterao em lote
de materiais do
Almoxarifado
60 Alterao de vrios
materiais de uma nica
vez.
5 23/05
Pesquisa de
materiais com
quantidade igual a
0 no Almoxarifado
50 3 23/05
Mensagem de
alerta para
quantidade de
material menor
que 3
40 8 30/05
Excluso em lote
de Materiais
30 5 06/06
TOTAL 39 Entrega
em 13/06

Tabela 1 Backlog do Produto
16

Release Burndown
O grfico de Burndown da Release exibe a somatria das estimativas dos itens que faltam ser
realizados do Backlog do Produto ao longo da Release. O Time tem a liberdade de escolher a
sua unidade de medida de trabalho. A unidade de tempo geralmente so as Sprints, conforme
o tamanho definido pelo Time SCRUM.
No incio, somasse todas as estimativas do Backlog do Produto e gera-se o total de trabalho a
ser realizado. medida que o projeto avana, os esforos j realizados so diminudos da
estimativa de esforo inicial. A inteno do Burndown da Release exibir o quanto de trabalho
ainda falta ser realizado e no o quanto de trabalho j foi realizado. Logo, o Time deve sempre
estimar a quantidade de trabalho restante ao longo do projeto e manter o Backlog do Produto
atualizado. Uma linha de tendncia traada baseada na mudana do trabalho restante para
indicar o avano ideal do Time.
Exemplo:
Com base no nosso Backlog do Produto anterior, temos o seguinte Release Burndown.

Figura 2 Release Burndown
Neste caso temos Sprints semanais (cinco dias teis) A expectativa inicial de velocidade
considerada de 9 pontos aproximadamente.

17

Dicas alm do SCRUM
Definies de Viso podem ser feitas atravs de Modelos de Mapa Mental.
Para uma Viso, voc pode levantar:
Objetivos
Publico Alvo
Metas
Definies tecnolgicas
Funcionalidades Macro
Para priorizar seu Backlog do Produto, voc pode usar pontuao atravs de Valor de Negcio
e assim ordenar seus itens. Existem outras tcnicas como MoSCoW que podem lhe auxiliar. O
Backlog do Produto tende a ter os itens mais prioritrios na parte superior. Os itens prioritrios
devem ser os itens melhores trabalhados e especificados. Sempre deve-se orientar o trabalho
atravs da priorizao.
Para estimar seu Backlog do Produto voc pode utilizar Story Points, T Shirt Size e outras
tcnicas.
Voc pode utilizar de tamanhos como "pico" e "Histrias" para manter seu Backlog do
Produto. picos seriam itens que ainda esto muito grandes e indefinidos, logo, menos
priorizados. Os itens com maior prioridade podem estar no formato de Histrias (User Stories),
com uma analise j realizada.
Para realizar estimativas de data de entrega o Time SCRUM tem de definir uma Velocidade de
Time inicial. Esta velocidade traduz a mdia de produtividade do Time. Esta medida
representar a quantidade de trabalho que o Time capaz de realizar ao longo da Sprint. A
velocidade ser usada para guiar o Planejamento da Release ao longo do projeto e deve ser
verificada a cada Sprint. O Time pode demorar algumas Sprints para encontrar sua velocidade
sustentvel. A velocidade geralmente medida atravs de pontos estimados sobre User
Stories ou outras medidas abstratas.
18

Definio de "Pronto"
O SCRUM define que o Time e o Product Owner devem alinhar-se para o conceito de "Pronto".
Cada incremento de software construdo deve obedecer a definio de "Pronto" para poder
ser entregue. O ideal que um incremento considerado "Pronto" esteja realmente pronto, a
ponto de ser possvel subir o mesmo para Produo, caso o Product Owner assim solicite. Esta
definio deve estar clara e difundida entre o Time SCRUM e os interessados no produto. Um
incremento "Pronto" idealmente no deve estar apenas desenvolvido e testado. O incremento
deve estar aceito pelo Product Owner e deve estar pronto para subir em um ambiente de
Produo.
Est definio importante, pois, para avaliar se o Time est concluindo suas Tarefas e
atingindo o objetivo, no deve-se levar em conta uma tarefa "50% realizada". No SCRUM, um
item est realmente pronto quando satisfaz a definio de "Pronto" e assim pode ser
considerado como entregue.

19

A Sprint
Uma Sprint um espao de tempo fixado, com o tamanho mdio de uma semana a quatro
semanas, onde se busca entregar um incremento de produto potencialmente pronto. As
Sprints so formadas pelo Planejamento da Sprint, a execuo da Sprint, a Reviso da Sprint e
a Retrospectiva da Sprint.
Um projeto SCRUM composto por vrias Sprint sequnciais onde se espera que no existam
intervalos entre elas. Ao final de uma Sprint, se inicia outra. O ideal que as Sprint tenham um
perodo de tempo que no varie. Logo, se foi definido que as Sprints tenham 2 semanas, que
procure se manter assim e no mude ao longo da Release.
Planejamento da Sprint
O Planejamento da Sprint o momento onde se planeja o trabalho do prximo perodo de
tempo fixado. A Reunio divida em duas partes:
O que? (discovery)
Nesta parte, o Product Owner apresenta o Backlog do Produto ao Time e destaca os itens de
maior prioridade. O Product Owner explica ao Time o que espera que seja realizado, o valor de
negcio que isto proporcionar e como espera que isso funcione de maneira macro. Cabe ao
Time dizer a quantidade de itens do Backlog do Produto que deseja selecionar para conversar,
pois, apenas o Time capaz de dizer o quanto capaz de realizar. Atravs da parte selecionada
do Backlog do Produto, cria-se uma Meta para a Sprint. A Meta deixa claro o objetivo de
negcio a ser atingido ao final da Sprint. Ela uma descrio sucinta que expressa ao Time
uma orientao sobre a razo que eles esto desenvolvendo os itens selecionados.
Como? (delivery)
Nesta parte da Reunio, o Time estima a poro de maior prioridade do Backlog do Produto, e
ir definir como a melhor maneira de implementar o desejo do Product Owner. Para tal, o
Time cria Tarefas, nas quais descrevem pequenas pores de trabalho a ser feito. O ideal que
uma tarefa no seja superior a mais de um dia til de trabalho. Tais Tarefas auxiliam o Time
em sua organizao durante a evoluo da Sprint. Ao final, gera-se o Backlog da Sprint, que
contm os itens e Tarefas a serem trabalhados na Sprint. O foco da Sprint gerar uma poro
de incremento de software potencialmente pronto para implantao/produo.
O ideal que o Planejamento da Sprint dure cerca de 5% do tamanho da Sprint.

20

Dicas alm do SCRUM
difundida a utilizao de User Stories
[http://www.extremeprogramming.org/rules/userstories.html] para se popular o Backlog da
Sprint e Backlog do Produto. Uma User Story descreve uma funcionalidade que deve conter
valor de negcio para o usurio ou cliente do projeto. A User Story composta pelos trs "C":
Card (carto): Descrio sucinta da histria do usurio. Ela deve obedecer a trs perguntas:
Quem? Papel do usurio que obter o valor da funcionalidade
O que? O desejo expresso que se tem
Por qu? O valor de negcio que se espera obter com a histria.
Exemplo: Como <papel> desejo <necessidade expressa> para <valor de negcio>
Como almoxarife desejo cadastrar os materiais recm chegados no almoxarifado
para manter atualizada e correta minhas informaes de materiais disponveis.
Conversation (conversas): Toda histria deve ser um convite a uma conversa entre o Time e o
Product Owner. Uma histria existe mais para representar os requisitos do cliente do que
document-los. Logo, a conversa face-a-face uma ferramenta importantssima e deve ser
fomentada pelas histrias.
Confirmation (confirmao): Histrias devem conter critrios de aceite que deixem claros
quando uma histria pode ser dada como implementada. Tais critrios auxiliam o Time a saber
como devem implementar as necessidades e podem ser validadas ao longo da Sprint.
Como almoxarife desejo cadastrar os materiais recm chegados no almoxarifado para
manter atualizada e correta minhas informaes de materiais disponveis.
Incluir descrio do material
Incluir quantidade de material
Incluir cdigo do material. O cdigo deve ser um texto livre de at 5
caracteres
O ideal que as histrias sejam escritas em conjunto, cliente, Product Owner e Time. Alguns
times adotam o Story-Writing Workshop. Tal reunio realizada entre cliente, Product Owner
e Time onde os mesmos escrevem as histrias, os critrios de aceite e aprofundam no
conhecimento do produto.

21

difundida tambm a utilizao do Planning Poker para se estimar uma User Story. O Planning
Poker utiliza de cartas com a numerao de Fibonacci. Cada membro do Time tem um
conjunto de cartas com estes nmeros a sua disposio. Geralmente, estimasse uma User
Story com base no esforo e complexidade que se julga ter para implement-la. Esta
estimativa deve levar em considerao o trabalho que o Time todo ir ter para transformar
aquela User Story em um incremento pronto de produto.
Uma User Story apresentada e discutida e ento, atravs de uma contagem regressiva, todos
os membros do Time devem mostrar uma carta que represente o tamanho que estimam para
a User Story. Caso haja divergncia de estimativa, o membro que apresentou a menor
estimativa deve falar primeiro e em seguida o membro que apresentou a maior estimativa.
Aps isto, uma nova contagem regressiva feita e cada membro do Time apresenta sua
estimativa. Se houver mais de trs rodadas de estimativa, o Time pode fazer uma pausa e
buscar um consenso rpido, neste consenso o Product Owner pode auxiliar.

22

Execuo da Sprint
Uma vez que o Backlog da Sprint foi definido, a Sprint tem incio. O Time busca se auto
organizar da melhor maneira a implementar as Tarefas e Itens. O ideal que uma Sprint no
tenha sua meta alterada ou mesmo seus itens. Caso as mudanas em uma Sprints sejam
frequentes, deve ser feita uma analise sobre o que pode estar acontecendo. Um volume
grande de mudanas na Sprint causa incertezas e dificuldades na execuo das Tarefas o que
pode prejudicar a entrega do incremento do produto.
Artefatos da Sprint
Backlog da Sprint
O Backlog da Sprint contm as tarefas que o Time ir realizar para gerar um incremento
pronto do produto. Ele deve conter todas as Tarefas necessrias para se atingir a Meta da
Sprint e idealmente estas Tarefas devem ser decomposta de maneira que as mudanas
ocorridas ao longo dia possam ser entendidas durante a Reunio diria. O Backlog da Sprint
tambm um artefato vivo. Ele alterado constantemente ao longo da Sprint para dar a
visibilidade correta em tempo real do trabalho que o Time tem planejado para a Sprint. Novas
Tarefas podem surgir ao longo da Sprint e o Time deve manter o Backlog da Sprint atualizado.
Apenas o Time deve ser responsvel por alterar e atualizar o Backlog da Sprint.
O Time pode estimar em horas cada Tarefa do Backlog da Sprint e gerar um Total de Horas de
trabalho da Sprint, atualizando o total de horas restantes a serem trabalhadas. Cada Tarefa
realizada, excluda ou adicionada deve gerar uma atualizao no total de horas.

23

Exemplo: Com base no Backlog do Produto estimado e priorizado, e na Reunio de
Planejamento da Sprint, temos o seguinte Backlog da Sprint.
Item Tarefa Estimativa
Insero de novos materiais do Almoxarifado
3 pontos
Refinar requisitos 2 horas
Tela de insero de
dados
4 horas
Validao do cdigo
do material
3 horas
Testes de aceite 2 horas
Alterar quantidade de materiais existentes no
Almoxarifado 2 pontos
Refinar requisitos 2 horas
Seleo de material 1 hora
Alterao da
descrio e
quantidade do
material
3 horas
Teste de aceite 1 hora
Remover material do cadastro do
Almoxarifado 5 Pontos
Refinar requisito 1 hora
Excluir material 2 horas
Teste de aceite 3 horas
10 pontos 24 horas

Tabela 2 Backlog da Sprint
24


Sprint Burndown
O Sprint Burndown um grfico que tem por objetivo exibir a quantidade de trabalho restante
que se tem de um Backlog da Sprint. O Time soma a quantidade de trabalho de um Backlog da
Sprint e atualiza conforme for realizando as Tarefas da Sprint, deixando visvel e claro a
quantidade de trabalho restante da Sprint.
Exemplo:

Figura 3 Sprint Burndown
Neste caso, temos 24 horas de trabalho restante para serem realizadas em cinco dias teis.

25

Dicas alm do SCRUM
Para ajudar na visibilidade do fluxo do SCRUM, alguns times utilizam de Quadros SCRUM (ou
kanban). Estes quadros so gerados para expressar o fluxo de trabalho do Time e devem exibir
o estado atual de cada tarefa do Sprint:
Item
Pendente
Tarefa
Pendente
Tarefas em
Desenvolvimento
Tarefas
Prontas
Item em
Aceite Item Pronto



Refinar
requisitos

Insero de
novos
materiais do
Almoxarifado
Tela de
insero de
dados
Validao do
cdigo do
material
Testes de
aceite

Refinar
requisitos
Alterar
quantidade
de materiais
existentes no
Almoxarifado

Seleo de
material
Alterao da
descrio e
quantidade do
material
Teste de aceite
Remover
material do
cadastro do
Almoxarifado


Refinar
requisito

Excluir material
Teste de
aceite



Tabela 3 Quadro SCRUM
Neste exemplo, o primeiro item est pronto. O segundo item est em uma etapa de aceite
enquanto o terceiro item ainda est pendente, pois est sendo desenvolvido ainda.
Muitos Times utilizam de Quadros branco para desenhar seus quadros SCRUM ou kanban. Isto
interessante, pois permite que a cada mudana necessria, o quadro possa ser alterado com
facilidade. So tambm muito utilizado os post-its para se incluir itens e tarefas no Quadro.
26

Reunio Diria
A Reunio diria busca oferecer ao Time SCRUM e a qualquer pessoa interessada um feedback
sobre o andamento da Sprint naquele exato momento. A Reunio diria pode ser feita em
frente a um quadro de visibilidade de processo ou mesmo em um local afastado do ambiente
natural de trabalho do Time. recomendando tambm que a Reunio Diria ocorra sempre no
mesmo horrio. Nesta reunio apenas os membros do Time falam, o Product Owner,
Scrummaster e outras pessoas que acompanham a reunio devem permanecer como ouvintes.
Cada membro do Time deve ser sucinto e responder a trs perguntas:
O que fiz desde a ltima reunio diria?
O que pretendo fazer at a prxima reunio diria?
Estou tendo (tive) impedimentos?
Impedimentos so geralmente quaisquer tipos de problemas que um membro do Time
encontre na tentativa de realizar uma tarefa.
A Reunio diria no deve durar mais do que 15 minutos.
Dicas alm do SCRUM
Ao final da Reunio diria o Time pode colaborar com o Product Owner para validar o quo
distante esto da Meta da Sprint e o que podem fazer para atingi-la. Isto pode implicar em
alteraes no Backlog da Sprint. O Time SCRUM deve estar atento para estas deliberaes.
27

Reviso da Sprint
No fim da Sprint, realizada a reunio de Reviso da Sprint. Esta reunio tem por objetivo
realizar a inspeo no incremente de produto pronto que o Time entrega ao Product Owner. O
Time SCRUM e pessoas interessadas se juntam para conversar sobre o que foi realizado. O
Time apresenta para o Product Owner os itens prontos e o Product Owner identifica o que foi
feito e o que no foi feito. Feito isto o Time pondera sobre o que ocorreu bem e as dificuldades
que teve ao longo da Sprint e como estas foram superadas. Em seguida o Product Owner
atualiza o Backlog do Produto e pode realizar alteraes nas projees de entrega do produto
conforme a velocidade do Time. Por fim o Time SCRUM faz uma projeo do que pode ser
realizado na prxima Sprint.
O ideal que a Reviso da Sprint tenha a durao de cerca de 5% do tamanho da Sprint.
Dicas alm do SCRUM
O Time pode ter um ambiente preparado para apresentar os itens. Se o Time utiliza post it,
pode lev-los a reunio e entreg-los ao Product Owner e atravs deles, orientar a
apresentao. Itens que forem rejeitados pelo Product Owner devem voltar para o Backlog do
Produto para serem analisados novamente. O ideal que o Product Owner possa interagir
com o sistema durante a apresentao. Isto agua os sentimentos do Product Owner em
relao ao produto. Sempre se deve buscar apresentar produto funcionado.

28

Retrospectiva da Sprint
Logo aps a Reviso da Sprint e antes da prxima Reunio de Planejamento da Sprint
realizada a reunio de Retrospectiva da Sprint. Nesta reunio, o Time estimulado a realizar
uma avaliao de seu processo de trabalho com o objetivo de melhor-lo cada vez mais. O
foco desta reunio inspecionar o modo de trabalho realizado na ltima Sprint e buscar
formas de tornar o trabalho mais eficaz e gratificante. O Scrummaster colabora com o Time
para que juntos possam focar em pontos de melhoria e formas de realizar esta melhoria. Deve
ser realizada uma identificao e priorizao dos principais itens que aconteceram de forma
boa e tambm dos itens que ocorreram de uma forma que poderia ter sido feita melhor. Esta
reflexo inclui a formao do time, ambiente de trabalho, comunicao, preparativos e
processos realizados para se gerar um incremento pronto de produto.
Ao final o Time deve ter levantado aes claras de melhoria e formas de dar visibilidade a elas.
Essas mudanas se transformam na adaptao para a inspeo emprica.
Esta reunio tem durao de trs horas.
Dicas alm do SCRUM
Existem vrias tcnicas para se realizar uma Retrospectiva. Voc pode utilizar post its para que
cada pessoa do Time SCRUM escreva os pontos bons da Sprint e os pontos a melhorar. Cada
membro pode deliberar sobre suas anotaes e juntos todos podem priorizar as aes de
melhorias mais prioritrias e definir aes concretas.
difundido o uso de Analise de Causa-Raiz na forma de Diagrama de Causa e Efeito, os 5
porqus [Sistema Toyota de Produo] ou rvore da Realidade Atual, com base na Teoria das
Restries para realizar sua Retrospectiva.
Busque manter suas reunies com um ambiente colaborativo e animado.