1.
1
APOSTILA INTRODUTÓRIA
AOSCRUM

2.
2
Desafio do desenvolvimento de software___________________________________ 4
Introdução ao Manifesto Ágil ____________________________________________ 5
Os princípios 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
Papéis no SCRUM ________________________________________________________________ 12
Product Owner ________________________________________________________________ 12
Scrummaster__________________________________________________________________ 12
Time ________________________________________________________________________ 12
O ciclo do SCRUM _________________________________________________________ 14
Reunião de Planejamento da Release _________________________________________ 14
Artefatos do Release Planning ______________________________________________________ 14
Backlog do Produto ____________________________________________________________ 14
Release Burndown _____________________________________________________________ 16
Dicas além do SCRUM_____________________________________________________________ 17
Definição de "Pronto" ______________________________________________________ 18
A Sprint _________________________________________________________________ 19
Planejamento da Sprint_____________________________________________________ 19
Dicas além do SCRUM_____________________________________________________________ 20
Execução da Sprint ________________________________________________________ 22
Artefatos da Sprint _______________________________________________________________ 22
Backlog da Sprint ______________________________________________________________ 22
Sprint Burndown_______________________________________________________________ 24
Dicas além do SCRUM_____________________________________________________________ 25
Reunião Diária ____________________________________________________________ 26
Dicas além do SCRUM_____________________________________________________________ 26
Revisão da Sprint__________________________________________________________ 27
Dicas além do SCRUM_____________________________________________________________ 27
Retrospectiva da Sprint_____________________________________________________ 28
Dicas além do SCRUM_____________________________________________________________ 28

3.
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.
4
Desafio do desenvolvimento de software
Os desafios de se desenvolver softwares vão muito mais além do que problemas de processos
e procedimentos. Trabalhar com expectativas, transferir e compartilhar conhecimento,
motivação e um bom ambiente são 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 contínua 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 Ciência de Software é considerada uma
área Exata, sua aplicabilidade se demonstra cada vez mais uma área Humana.
A evolução de uma prática, processo ou produto somente se dá através da evolução de
Pessoas. Esta evolução está cada vez mais presente nas necessidades do desenvolvimento de
software atual. Evoluirmos como Pessoa, como um Time unido, através de colaboração,
confiança e comprometimento são 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 interação 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.
5
Introdução ao Manifesto Ágil
Em fevereiro de 2001, vários profissionais da área de desenvolvimento de software se
reuniram em uma Estação de Esqui em Utah, Estados Unidos, para uma discussão sobre o
desenvolvimento de software. Em tal discussão, foram abordados os desafios, necessidades e
desejos que todos tinham em relação a tal assunto. Através desta reunião, foram extraídas
algumas conclusões que pautaram a geração 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 cenário geral de desenvolvimento de
software.
O Manifesto Ágil:
Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e
ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:
Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o Cliente mais que negociação de contratos
Responder a mudanças 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 citação complexa, que requer estudo, prática e reflexão.
O primeiro axioma nos mostra que o valor dos indivíduos e a interação entre eles geram mais
valor do que a simples utilização de ferramentas ou padrões. Pessoas reagem através de
emoções. Tais emoções geram ações que tornam os processos imprevisíveis. Logo, a
adaptação de processos e procedimentos em relação á interação entre as pessoas se tornar
uma melhor ferramenta do que a padronização do comportamento humano a processos
genéricos.
O segundo axioma nos exibe um dos principais focos de um projeto: “Software funcionando”.
Não é difícil encontrar projetos onde o software esteja “90%” concluído, porém ainda não

6.
6
esteja em funcionamento. Tal questão se dá muito pelo fato das documentações abrangentes
geradas. A finalidade desta documentação é representar um desejo e fixá-lo quase como um
“contrato”. Porém o esforço 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 não aconselha a
geração de documentação, mas sim, que incentiva a documentação com real valor, gerada no
tempo certo e por motivos que tragam valor.
O terceiro axioma exibe uma mudança profunda de atitude. O processo de desenvolvimento
de um software é algo colaborativo e dinâmico. Os contratos de desenvolvimento de software
hoje em dia são meramente “artefatos para segurança” ou “negociação de risco”. Estes
contratos são firmados muitas vezes apenas com a designação de “definir um culpado” caso o
projeto falhe e/ou uma “definição rígida” de prazo, custo e escopo. Os contratos muitas vezes
são usados para gerar pressão, seja por parte do cliente cobrando o todo ou mesmo pelo
fornecedor, se eximindo em relação a qualquer mudança daquilo que foi combinado. Logo, o
Manifesto Ágil nos exibe a faceta da colaboração real. Tal colaboração deve visar um real valor
agregado para o cliente e para tal, deve ser pautada em confiança e transparência.
O último axioma é tão 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 colaboração e confiança, são firmados contratos com valores, custos, prazos e
escopos definidos. Para se ter certeza (certeza totalmente irreal esta!) gera-se toda a
documentação abrangente para se levantar as funcionalidades a serem desenvolvidas. O
levantamento de requisitos é custoso e demorado e quando se começa o desenvolvimento do
sistema, acontecem às mudanças. Essas mudanças se tornam traumáticas mediante ao tanto
de tempo que já foi gasto analisando e documentando requisitos. Inicia-se todo um trabalho
para ver o quanto esta mudança 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 mudanças para maximizar o valor do produto,
ao invés de seguir um plano pré-definido. Muitas vezes as mudanças trazem imenso valor e
não puderam ser vistas no início do projeto pelo simples fato de que naquele momento, não se
fazia sentido pedir o que se pede agora. O mundo é dinâmico e o desenvolvimento de
software também tem está característica. Cabe a nós tirar proveito desta mudança como um
diferencial de valor agregado e buscar colaborar para atingir um sucesso completo.

7.
7
Os princípios do Manifesto Ágil
Complementares ao ideal do Manifesto criaram-se princípios que auxiliam na empreitada de
desenvolver softwares:
Nossa maior prioridade é satisfazer o cliente, através de entregas rápidas e
contínuas gerando valor ao software
Devemos receber bem as mudanças nos requisitos, mesmo em estágios tardios do
desenvolvimento. Processos ágeis devem admitir mudanças em prol de vantagens
competitivas para o cliente
Trabalhar para entregar software em intervalos de duas semanas até dois meses,
com preferência para que tenha uma curta escala de tempo
As pessoas de negócio e os desenvolvedores devem trabalhar juntos diariamente
durante todo o projeto
Construir projetos baseados em indivíduos motivados. Dar-lhes o ambiente e o
suporte que precisam e confiar que irão realizar o trabalho
O método mais eficiente e efetivo de transmitir informações em uma equipe de
desenvolvimento é conversa face-a-face
Software funcionando é a principal medida para o progresso.
Processos ágeis promovem o desenvolvimento sustentável. Os patrocinadores, os
desenvolvedores e os usuários devem ser capazes de manter um ritmo constante
indefinidamente
Atenção contínua a excelência técnica e um bom design aumentam a agilidade
Simplicidade – a arte de maximizar o valor do trabalho não 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
então, ajustar-se de acordo com seu comportamento

8.
8
Metodologias Ágeis
Com base nos valores e princípios do Manifesto Ágil, algumas metodologias foram
enquadradas ou nasceram e levam a alcunha de Metodologias Ágeis.
Metodologias Ágeis mais conhecidas:
Crystal
Extreme Programming (XP)
FeatureDrivenDevelpoment (FDD)
LEAN Software Development
OpenUP
RUP (a partir da versão 7.0)
SCRUM
Repare que o Manifesto Ágil fora criado em 2001 e algumas destas metodologias são
anteriores a esta data. Isso se dá pelo fato que o conceito e a prática destas metodologias
pautaram a criação do Manifesto.
Conceitos como “Empirismo”, “PDCA”, “LEAN” estão por trás destas metodologias e logo, por
trás do Manifesto Ágil. É importante ter em mente que o Manifesto Ágil não definiu tais
conceitos, mas sim, explicita os ganhos que tais aplicações geraram.

9.
9
SCRUM
A origem do SCRUM
De início, o SCRUM foi concebido como uma forma de gerenciamento de projetos de produtos
complexo por IkujiroNonaka e HirotakaTakeuchi, no livro “The New NewProductDevelopment
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 também o implementaram e trabalharam em sua formação.
Em 1995 o SCRUM foi formalizado por Ken Schwaber, Mike Beedle e Jeff Sutherland e
apresentado oficialmente na OOPLSA (Object-OrientedProgramming, Systems,
LanguagesandApplications).
Conceitos do SCRUM
O SCRUM tem em sua base os conceitos de:
LEAN
Desenvolvimento iterativo e incremental
Team Process
Micro enterprisedevelopment
Empirismo
PDCA
Time Boxe
Definição de Pronto
Team Velocity
O que é SCRUM?
SCRUM é um framework para desenvolvimento de produtos complexos, fundamentado na
teoria de controle de processos empíricos, utilizando da abordagem iterativa e incremental,
visando maximizar valor de negócio, otimizar a previsibilidade e controlar risco.
Outras definições 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
técnicas, 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.
10
Pilares do SCRUM
Três pilares sustentam o SCRUM:
Transparência: Visibilidade e entendimento
Os pontos do processo devem estar visíveis para todos aqueles que participam ou são afetados
pelo processo. Além da visibilidade, todos os aspectos devem estar passíveis de entendimento
por todos.
Inspeção: Verificação e sentimento
Os pontos do processo devem ser passíveis de verificação com freqüência. A freqüência deve
ser suficiente para que ruídos inaceitáveis sejam detectados.
Adaptação: Mudar parar melhor, tentar
Dado a visibilidade e o entendimento. O processo de inspeção tem como resultado algumas
adaptações que visam à melhoria do sistema. As ações de mudança são então ajustadas e
realizadas e um novo ciclo se inicia.
Em uma aplicação de SCRUM é fundamental estar atento a estes pilares, logo, ao se buscar
incrementar ou alterar um processo ou procedimento, busque visualizar se esta ação está de
acordo com os pilares do SCRUM. Tal verificação será valida também para os valores e
princípios do Manifesto Ágil.

11.
11
O SCRUM
Figura 1 – Fluxo do SCRUM
O SCRUM é formado papéis, eventos com duração fixa, artefatos e regras.
Os papéis são:
Scrummaster: responsável por garantir que o processo seja compreendido e
seguido
ProductOwner: responsável por maximizar o valor de trabalho que o Time gera
Time: Executa o trabalho. Formado com todas as habilidades necessárias para
gerar o produto
O SCRUM utiliza de eventos com duração fixa para gerar uma regularidade. As cerimônias com
duração fixa são:
Reunião de Planejamento da Release
Reunião de Planejamento da Sprint
Sprint
Reunião diária
Revisão 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.
12
Papéis no SCRUM
O Time SCRUM é composto por um Scrummaster, ProductOwner e pelo Time.
ProductOwner
O ProductOwner é o responsável por maximizar o ROI (ReturnonInvestiment) do Projeto. Seu
papel é fundamental e suas atribuições são de grandes responsabilidades. O ProductOwner
deve manter vivo o ProductBacklog, com as informações das necessidades que deseja realizar.
É de sua responsabilidade priorizar o trabalho a ser realizar pelo Time, bem como, dar
visibilidade a está priorização. O ProductOwner é uma única pessoa, porém, esta pessoa pode
ser auxiliada por um grupo de pessoas. Contudo, deve-se ressaltar que a decisão da prioridade
é realizada pelo ProductOwner.
Dentre as atribuições do ProductOwner, ressalta-se:
Definir as funcionalidades do produto
Maximizar o ROI
Apresentar ao Time os requisitos necessários para o desenvolvimento do produto
Planejar as entregas do produto
Gerenciar alterações do produto
Scrummaster
O Scrummaster é o responsável por garantir e ajudar o Time SCRUM esteja aderindo e
aplicando os valores do SCRUM, as práticas e as regras. Mais do que garantir a adesão e
aplicação, o Scrummaster educa o Time SCRUM, treinando-os e estimulando-os a melhoria
contínua. O Scrummaster tem uma atuação de “Facilitador”, removendo os impedimentos que
o Time SCRUM venha a ter, para poder maximizar a produtividade do Time.
As responsabilidades do Scrummaster são:
Remover impedimentos no desenvolvimento do produto
Ensinar o cliente na maximização do valor agregado
Facilitar a rotina do Time SCRUM, estimulando a criatividade e motivando-os
Auxiliar o ProductOwner na manutenção do ProductBacklog
Proteger o time de interferências externas
Promover práticas e procedimentos que auxiliem o Time no desenvolvimento do
Produto
Time
O Time tem a responsabilidade de realizar e entregar o produto solicitado pelo ProductOwner.
O Time é um grupo de pessoas que têm as formações necessárias para gerar o produto
solicitado. Todos os integrantes do Time devem contribuir para a geração do produto, mesmo
que isto implique em que um membro do Time tenha de aprender uma nova habilidade. Os
Times não contêmsubtimes dedicados a áreas particulares do produto. Os Times SCRUM
devem ter tais características:
Auto organizado
Interdisciplinar

13.
13
Ser formador por cinco até nove membros
Ser auto organizado implica que ninguém deve dizer ao Timecomo transformar as solicitações
do ProductOwner 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 necessário dentro dos valores e diretrizes para alcançar os objetivos da
Sprint
Demonstrar o resultado do desenvolvimento em uma Sprint para o ProductOwner
Comprometidos com o trabalho
Organizar o espaço físico (ambiente)
Os papéis no SCRUM são bem definidos, porém, existe ainda uma gama de skills que cada
pessoa que ocupar estes papéis deve desenvolver.
A interação entre os membros do Time SCRUM é crucial para o sucesso de um projeto. Um
ambiente de confiança e transparência deve ser gerado e mantido.

14.
14
O ciclo do SCRUM
Reunião de Planejamento da Release
A Reunião 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 à
discussão as questões 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 através de uma Visão. O SCRUM não explicita
como esta visão pode ser declarada, porém, indica que as metas a serem obtidas devem estar
bem expressas e visíveis a todos, assim como as maiores prioridades do Backlog do Produto, os
principais riscos e as características 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 provável custo. Para a estimativa de entrega, requer-se que o Backlog do Produto
tinha sido priorizado pelo ProductOwner e estimado pelo Time. O SCRUM não define uma
técnica de estimativa, mas existem várias técnicas úteis que podem ser utilizadas.
Artefatos do Release Planning
Backlog do Produto
O ProductOwneré responsável por gerar e manter oBacklog do Produto. O Backlog do Produto
é uma lista com as necessidades para lançar 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 não define uma técnica de priorização, porém 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, serão os itens a ser primeiramente desenvolvidos
pelo Time. Para os itens de maior prioridade, o ProductOwner e o Time já podem avançar,
estudando requisitos mais definidos, critérios de aceitação ou detalhes técnicos.
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 também devem ser revistos.

15.
15
Exemplo:
Item Valor de Negócio Critérios de Aceite Estimativa Data
estimada
Inserção de novos
materiais do
Almoxarifado
100 Inserir dados da descrição
do produto, quantidade
de produtos e código. O
código 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.
Não permitir que um
produto tenha
quantidade negativa.
2 09/05
Remover material
do cadastro do
Almoxarifado
80 Poder excluir um material
do Almoxarifado. A
exclusão 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 vários materiais de
uma única vez.
8 16/05
Alteração em lote
de materiais do
Almoxarifado
60 Alteração de vários
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
Exclusão em lote
de Materiais
30 5 06/06
TOTAL 39 Entrega
em 13/06
Tabela 1 – Backlog do Produto

16.
16
Release Burndown
O gráfico de Burndown da Release exibe a somatória 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 são as Sprints, conforme
o tamanho definido pelo Time SCRUM.
No início, somasse todas as estimativas do Backlog do Produto e gera-se o total de trabalho a
ser realizado. À medida que o projeto avança, os esforços já realizados são diminuídos da
estimativa de esforço inicial. A intenção do Burndown da Release é exibir o quanto de trabalho
ainda falta ser realizado e não 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 tendência é traçada baseada na mudança do trabalho restante para
indicar o avanço 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.
17
Dicas além do SCRUM
Definições de Visão podem ser feitas através de Modelos de Mapa Mental.
Para uma Visão, você pode levantar:
Objetivos
Publico Alvo
Metas
Definições tecnológicas
Funcionalidades Macro
Para priorizar seu Backlog do Produto, você pode usar pontuação através de Valor de Negócio
e assim ordenar seus itens. Existem outras técnicas como MoSCoW que podem lhe auxiliar. O
Backlog do Produto tende a ter os itens mais prioritários na parte superior. Os itens prioritários
devem ser os itens melhores trabalhados e especificados. Sempre deve-se orientar o trabalho
através da priorização.
Para estimar seu Backlog do Produto você pode utilizar Story Points, T ShirtSize e outras
técnicas.
Você pode utilizar de tamanhos como "Épico" e "Histórias" para manter seu Backlog do
Produto. Épicos seriam itens que ainda estão muito grandes e indefinidos, logo, menos
priorizados. Os itens com maior prioridade podem estar no formato de Histórias (UserStories),
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 média 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
sustentável. A velocidade geralmente é medida através de pontos estimados sobre UserStories
ou outras medidas abstratas.

18.
18
Definição de "Pronto"
O SCRUM define que o Time e o ProductOwner devem alinhar-se para o conceito de "Pronto".
Cada incremento de software construído deve obedecer a definição de "Pronto" para poder
ser entregue. O ideal é que um incremento considerado "Pronto" esteja realmente pronto, a
ponto de ser possível subir o mesmo para Produção, caso o ProductOwner assim solicite. Esta
definição deve estar clara e difundida entre o Time SCRUM e os interessados no produto. Um
incremento "Pronto" idealmente não deve estar apenas desenvolvido e testado. O incremento
deve estar aceito pelo ProductOwner e deve estar pronto para subir em um ambiente de
Produção.
Está definição é importante, pois, para avaliar se o Time está concluindo suas Tarefas e
atingindo o objetivo, não deve-se levar em conta uma tarefa "50% realizada". No SCRUM, um
item está realmente pronto quando satisfaz a definição de "Pronto" e assim pode ser
considerado como entregue.

19.
19
A Sprint
Uma Sprint é um espaço de tempo fixado, com o tamanho médio de uma semana a quatro
semanas, onde se busca entregar um incremento de produto potencialmente pronto. As
Sprints são formadas pelo Planejamento da Sprint, a execução da Sprint, a Revisão da Sprint e
a Retrospectiva da Sprint.
Um projeto SCRUM é composto por várias Sprint sequênciais onde se espera que não existam
intervalos entre elas. Ao final de uma Sprint, se inicia outra. O ideal é que as Sprint tenham um
período de tempo que não varie. Logo, se foi definido que as Sprints tenham 2 semanas, que
procure se manter assim e não mude ao longo da Release.
Planejamento da Sprint
O Planejamento da Sprint é o momento onde se planeja o trabalho do próximo período de
tempo fixado. A Reunião é divida em duas partes:
O que? (discovery)
Nesta parte, o ProductOwner apresenta o Backlog do Produto ao Time e destaca os itens de
maior prioridade. O ProductOwner explica ao Time o que espera que seja realizado, o valor de
negócio 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. Através da parte selecionada
do Backlog do Produto, cria-se uma Meta para a Sprint. A Meta deixa claro o objetivo de
negócio a ser atingido ao final da Sprint. Ela é uma descrição sucinta que expressa ao Time
uma orientação sobre a razão que eles estão desenvolvendo os itens selecionados.
Como? (delivery)
Nesta parte da Reunião, o Time estima a porção de maior prioridade do Backlog do Produto, e
irá definir como é a melhor maneira de implementar o desejo do ProductOwner. Para tal, o
Time cria Tarefas, nas quais descrevem pequenas porções de trabalho a ser feito. O ideal é que
uma tarefa não seja superior a mais de um dia útil de trabalho. Tais Tarefas auxiliam o Time
em sua organização durante a evolução da Sprint. Ao final, gera-se o Backlog da Sprint, que
contém os itens e Tarefas a serem trabalhados na Sprint. O foco da Sprint é gerar uma porção
de incremento de software potencialmente pronto para implantação/produção.
O ideal é que o Planejamento da Sprint dure cerca de 5% do tamanho da Sprint.

20.
20
Dicas além do SCRUM
É difundida a utilização de UserStories
[http://www.extremeprogramming.org/rules/userstories.html] para se popular o Backlog da
Sprint e Backlog do Produto. Uma UserStory descreve uma funcionalidade que deve conter
valor de negócio para o usuário ou cliente do projeto. A UserStory é composta pelos três "C":
Card (cartão):Descrição sucinta da história do usuário. Ela deve obedecer a três perguntas:
Quem? Papel do usuário que obterá o valor da funcionalidade
O que? O desejo expresso que se tem
Por quê? O valor de negócio que se espera obter com a história.
Exemplo:Como <papel> desejo <necessidade expressa> para <valor de negócio>
Como almoxarife desejo cadastrar os materiais recém chegados no almoxarifadopara
manter atualizada e correta minhas informações de materiais disponíveis.
Conversation (conversas):Toda história deve ser um convite a uma conversa entre o Time e o
ProductOwner. Uma história existe mais para representar os requisitos do cliente do que
documentá-los. Logo, a conversa face-a-face é uma ferramenta importantíssima e deve ser
fomentada pelas histórias.
Confirmation (confirmação):Histórias devem conter critérios de aceite que deixem claros
quando uma história pode ser dada como implementada. Tais critérios auxiliam o Time a saber
como devem implementar as necessidades e podem ser validadas ao longo da Sprint.
Como almoxarife desejo cadastrar os materiais recém chegados no almoxarifado para
manter atualizada e correta minhas informações de materiais disponíveis.
Incluir descrição do material
Incluir quantidade de material
Incluir código do material. O código deve ser um texto livre de até 5
caracteres
O ideal é que as histórias sejam escritas em conjunto, cliente, ProductOwner e Time. Alguns
times adotam o Story-Writing Workshop. Tal reunião é realizada entre cliente, ProductOwnere
Time onde os mesmos escrevem as histórias, os critérios de aceite e aprofundam no
conhecimento do produto.

21.
21
É difundida também a utilização do Planning Poker para se estimar uma UserStory. O Planning
Poker utiliza de cartas com a numeração de Fibonacci. Cada membro do Time tem um
conjunto de cartas com estes números a sua disposição. Geralmente, estimasse uma UserStory
com base no esforço e complexidade que se julga ter para implementá-la. Esta estimativa deve
levar em consideração o trabalho que o Time todo irá ter para transformar aquela UserStory
em um incremento pronto de produto.
Uma UserStory é apresentada e discutida e então, através de uma contagem regressiva, todos
os membros do Time devem mostrar uma carta que represente o tamanho que estimam para
a UserStory. Caso haja divergência de estimativa, o membro que apresentou a menor
estimativa deve falar primeiro e em seguida o membro que apresentou a maior estimativa.
Após isto, uma nova contagem regressiva é feita e cada membro do Time apresenta sua
estimativa. Se houver mais de três rodadas de estimativa, o Time pode fazer uma pausa e
buscar um consenso rápido, neste consenso o ProductOwner pode auxiliar.

22.
22
Execução da Sprint
Uma vez que o Backlog da Sprint foi definido, a Sprint tem início. O Time busca se auto
organizar da melhor maneira a implementar as Tarefas e Itens. O ideal é que uma Sprint não
tenha sua meta alterada ou mesmo seus itens. Caso as mudanças em uma Sprints sejam
frequentes, deve ser feita uma analise sobre o que pode estar acontecendo. Um volume
grande de mudanças na Sprint causa incertezas e dificuldades na execução das Tarefas o que
pode prejudicar a entrega do incremento do produto.
Artefatos da Sprint
Backlog da Sprint
O Backlog da Sprint contém as tarefas que o Time irá realizar para gerar um incremento
“pronto” do produto. Ele deve conter todas as Tarefas necessárias para se atingir a Meta da
Sprint e idealmente estas Tarefas devem ser decomposta de maneira que as mudanças
ocorridas ao longo dia possam ser entendidas durante a Reunião diária. O Backlog da Sprint
também é 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 responsável por alterar e atualizar o Backlog da Sprint.
O Time pode estimar em horas cada Tarefa do Backlog da Sprinte gerar um Total de Horas de
trabalho da Sprint, atualizando o total de horas restantes a serem trabalhadas. Cada Tarefa
realizada, excluída ou adicionada deve gerar uma atualização no total de horas.

23.
23
Exemplo: Com base no Backlog do Produto estimado e priorizado, e na Reunião de
Planejamento da Sprint, temos o seguinte Backlog da Sprint.
Item Tarefa Estimativa
Inserção de novos materiais do Almoxarifado
– 3 pontos
Refinar requisitos 2 horas
Tela de inserção de
dados
4 horas
Validação do código
do material
3 horas
Testes de aceite 2 horas
Alterar quantidade de materiais existentes no
Almoxarifado – 2 pontos
Refinar requisitos 2 horas
Seleção de material 1 hora
Alteração da
descrição 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.
24
Sprint Burndown
O Sprint Burndown é um gráfico 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 visível 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.
25
Dicas além do SCRUM
Para ajudar na visibilidade do fluxo do SCRUM, alguns times utilizam de Quadros SCRUM (ou
kanban). Estes quadros são 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
Inserção de
novos
materiais do
Almoxarifado
Tela de
inserção de
dados
Validação do
código do
material
Testes de
aceite
Refinar
requisitos
Alterar
quantidade
de materiais
existentes no
Almoxarifado
Seleção de
material
Alteração da
descrição 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 mudança necessária, o quadro possa ser alterado com
facilidade. São também muito utilizado os post-its para se incluir itens e tarefas no Quadro.

26.
26
Reunião Diária
A Reunião diária busca oferecer ao Time SCRUM e a qualquer pessoa interessada um feedback
sobre o andamento da Sprint naquele exato momento. A Reunião diária 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 também que a Reunião Diária ocorra sempre no
mesmo horário. Nesta reunião apenas os membros do Time falam, o ProductOwner,
Scrummaster e outras pessoas que acompanham a reunião devem permanecer como ouvintes.
Cada membro do Time deve ser sucinto e responder a três perguntas:
• O que fiz desde a última reunião diária?
• O que pretendo fazer até a próxima reunião diária?
• Estou tendo (tive) impedimentos?
Impedimentos são geralmente quaisquer tipos de problemas que um membro do Time
encontre na tentativa de realizar uma tarefa.
A Reunião diária não deve durar mais do que 15 minutos.
Dicas além do SCRUM
Ao final da Reunião diária o Time pode colaborar com o ProductOwner para validar o quão
distante estão da Meta da Sprint e o que podem fazer para atingi-la. Isto pode implicar em
alterações no Backlog da Sprint. O Time SCRUM deve estar atento para estas deliberações.

27.
27
Revisão da Sprint
No fim da Sprint, é realizada a reunião de Revisão da Sprint. Esta reunião tem por objetivo
realizar a inspeção no incremente de produto pronto que o Time entrega ao ProductOwner. O
Time SCRUM e pessoas interessadas se juntam para conversar sobre o que foi realizado. O
Time apresenta para o ProductOwner os itens prontos e o ProductOwner identifica o que foi
feito e o que não 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
ProductOwneratualiza o Backlog do Produto e pode realizar alterações nas projeções de
entrega do produto conforme a velocidade do Time. Por fim o Time SCRUM faz uma projeção
do que pode ser realizado na próxima Sprint.
O ideal é que a Revisão da Sprint tenha a duração de cerca de 5% do tamanho da Sprint.
Dicas além do SCRUM
O Time pode ter um ambiente preparado para apresentar os itens. Se o Time utiliza post it,
pode levá-los a reunião e entregá-los ao ProductOwner e através deles, orientar a
apresentação. Itens que forem rejeitados pelo ProductOwner devem voltar para o Backlog do
Produto para serem analisados novamente. O ideal é que o ProductOwner possa interagir com
o sistema durante a apresentação. Isto aguça os sentimentos do ProductOwner em relação ao
produto. Sempre se deve buscar apresentar produto funcionado.

28.
28
Retrospectiva da Sprint
Logo após a Revisão da Sprint e antes da próxima Reunião de Planejamento da Sprint é
realizada a reunião de Retrospectiva da Sprint. Nesta reunião, o Time é estimulado a realizar
uma avaliação de seu processo de trabalho com o objetivo de melhorá-lo cada vez mais. O
foco desta reunião é 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 identificação e priorização dos principais itens que aconteceram de forma
boa e também dos itens que ocorreram de uma forma que poderia ter sido feita melhor. Esta
reflexão inclui a formação do time, ambiente de trabalho, comunicação, preparativos e
processos realizados para se gerar um incremento pronto de produto.
Ao final o Time deve ter levantado ações claras de melhoria e formas de dar visibilidade a elas.
Essas mudanças se transformam na adaptação para a inspeção empírica.
Esta reunião tem duração de três horas.
Dicas além do SCRUM
Existem várias técnicas 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 anotações e juntos todos podem priorizar as ações de
melhorias mais prioritárias e definir ações concretas.
É difundido o uso de Analise de Causa-Raiz na forma de Diagrama de Causa e Efeito, os “5
porquês” [Sistema Toyota de Produção] ou Árvore da Realidade Atual, com base na Teoria das
Restrições para realizar sua Retrospectiva.
Busque manter suas reuniões com um ambiente colaborativo e animado.