GERENCIAMENTO DE PROJETOS COM

SCRUM
Rodrigo Yoshima
Aspercom Serviços de Informática Ltda.
CNPJ 02.942.579/00001-37
Autores: Rodrigo Yoshima

GERENCIAMENTO DE PROJETOS COM SCRUM

Abril de 2007

Copyright 2007, Aspercom. Todos os direitos reservados.

http://www.aspercom.com.br

O conteúdo deste texto é de propriedade da Aspercom Serviços de Informática Ltda.

Qualquer reprodução total ou parcial deste conteúdo é proibida.
Índice

1. O Manifesto Ágil do Desenvolvimento de Software ........................................ 5

1.1. O que são metodologias ágeis?.............................................................. 5
1.2. Pessoas, Processos e Tecnologia .......................................................... 6
2. Conceitos do SCRUM .................................................................................... 8
2.1. O que é o SCRUM? ................................................................................ 8
2.2. Controle do Processo: Empírico x Definido............................................. 8
2.3. Papéis do SCRUM................................................................................ 10
2.4. Iniciando um Projeto Ágil ...................................................................... 11
2.5. Estrutura do Processo SCRUM ............................................................ 13
2.6. Por dentro do SPRINT .......................................................................... 14
2.7. Planejamento do Sprint......................................................................... 15
2.8. Como é um dia de trabalho do Sprint?.................................................. 18
2.9. Sprint Review........................................................................................ 21
2.10. Sprint Retrospective.............................................................................. 22
3. Estimativas e Métricas Ágeis........................................................................ 23
3.1. Fundamentos........................................................................................ 23
3.2. Estimando em Story Points................................................................... 23
3.3. Pontos, Velocidade e Prazo.................................................................. 24
3.4. Planning Poker ..................................................................................... 26
3.5. Estimando a velocidade........................................................................ 27
3.6. Inspeção e Adaptação das Estimativas................................................. 29
Índice de figuras

Figura 1 - Adoção de Metodologias Ágeis - Fonte: VersionOne Agile Global Survey.................. 6

Figura 2 - Triângulo Pessoas, Processo e Tecnologia ................................................................ 6
Figura 3 - Adoção do SCRUM - Fonte: VersionOne Agile Global Survey....................................8
Figura 4 - Processo de Desenvolvimento em Cascata.............................................................. 11
Figura 5 Macro-estrutura do SCRUM........................................................................................ 12
Figura 6 - Processo Iterativo ..................................................................................................... 13
Figura 7 - Estrutura de um SPRINT .......................................................................................... 14
Figura 8 - Planejamento - Parte 1 ............................................................................................. 15
Figura 9 – Project Backlog – Primeiro Sprint............................................................................. 16
Figura 10 - Planejamento - Parte 2 ........................................................................................... 17
Figura 11 - Sprint Backlog ........................................................................................................ 17
Figura 12 - Sprint Backlog Atualizado ....................................................................................... 18
Figura 13 - Sprint Backlog - Definição de "Pronto".................................................................... 20
Figura 14 - Sprint Review ......................................................................................................... 21
Figura 15 - Retrospectiva do Sprint........................................................................................... 22
Figura 16 Métricas: Acerto x Tempo Investido .......................................................................... 23
Figura 17 Equipe e o Product Backlog...................................................................................... 24
Figura 18 Product Backlog Pontuado........................................................................................ 25
Figura 19 Impacto da opinião em métricas da equipe ............................................................... 26
Figura 20 Planning Poker ......................................................................................................... 26
Figura 21 Poker, consenso e participação do Product Owner................................................... 27
Figura 22 Estimando a Velocidade no Primeiro Sprint .............................................................. 27
Figura 23 Quebrando item do Product Backlog ........................................................................ 28
Figura 24 Product Backlog Final do Sprint 1 ............................................................................. 29
Figura 25 Product Backlog Replanejado................................................................................... 29
2. Conceitos do SCRUM
2.1. O que é o SCRUM?
SCRUM é um processo ágil e leve que pode ser utilizado para gerenciar e controlar o
desenvolvimento de software utilizando práticas iterativas e incrementais. Baseado em práticas de
gerenciamento já fundamentadas no Extreme Programming e no RUP, o SCRUM produz os
benefícios do desenvolvimento ágil com a vantagem de ser uma implementação bem simples.
O SCRUM aumenta significativamente a produtividade e reduz o tempo para obter
resultados, pois facilita a adaptação a processos empíricos de desenvolvimento de sistemas.
O SCRUM também foi adotado como ferramenta padrão de gerência de projetos nas
metodologias MSF for Agile e OpenUP e atende aos padrões CMMI e PMBOK.

Outras
15%
DSDM
8% SCRUM
40%

Híbrida
14%
XP
23%

Figura 3 - Adoção do SCRUM - Fonte: VersionOne Agile Global Survey

2.2. Controle do Processo: Empírico x Definido

Muito dos processos do nosso dia a dia só são aceitos como válidos porque aceitamos o
nível de introspecção que o processo nos oferece, isto é, aceitamos o nível de qualidade que o
produto final nos proporciona. Você aceita o processo de construção de um carro mesmo com um
pequeno ruído no freio. Você aceita aguardar até 3 minutos para ser atendido no SAC. O trânsito é
violento e mesmo assim não deixamos de usar o carro. Processo e Qualidade são intimamente
relacionados.
Quando um determinado processo não atende o nível de qualidade que esperamos podemos
dizer que o processo não funciona. Se você não aceita aguardar 3 minutos até ser atendido no SAC
automaticamente você torna o processo de atendimento inválido.
Com relação a essa qualidade, determinados processos são prescritivos, isto é, possuem
pontos observáveis que a cada passo podem ser verificáveis como válidos. A construção de uma
ponte segue um processo prescritivo. Uma linha de montagem de um produto é um processo
prescritivo. A forma que um cartório funciona é um processo prescritivo. Nesses processos, a cada
passo que você avança no ciclo MENOR é a sua incerteza, pois você pode avaliar aquele passo
como válido. Você consegue avaliar a qualidade das fundações de uma ponte e ter certeza que está
caminhando na direção correta.

8
 Uma característica importante dos processos prescritivos é que se caso o produto final não
atenda o nível de qualidade que você espera o custo é muito alto para reconstruir esse produto
novamente ou para reparar a falha. Como exemplo, se um carro ao final da linha de produção foi
montado de maneira errada é praticamente impossível colocá-lo novamente na linha para que seja
produzido da maneira certa. É mais barato jogar o carro no lixo e corrigir a linha de produção.
O software não possui passos intermediários que possam ser verificáveis como válidos
durante o seu ciclo de vida. Quando você captura requisitos você não tem certeza que eles
solucionarão as necessidades do negócio, quando você elege uma arquitetura não tem certeza se
ela será suficiente, quando você codifica soma-se a essas incertezas aspectos técnicos e também
com relação ao futuro (como o software será mantido). Testes são efetuados sobre requisitos
incertos e também nunca sabemos se os testes são suficientes. Nós só conseguimos reduzir essa
incerteza quando o usuário olha a aplicação. Em determinadas aplicações, a incerteza só reduz
depois que ela está em produção a mais de dois anos! Por conta disso, chegamos à declaração
abaixo:

DESENVOLVIMENTO DE SOFTWARE = GERENCIAMENTO DE INCERTEZA

Quando desenvolvemos produtos de processos empíricos, como o Software, maneiras

empíricas de gerenciamento de projeto devem ser aplicadas. O software é um produto que evolui
constantemente até que os objetivos de negócio sejam atingidos. Muitas vezes, simplesmente
atender a requisitos não é suficiente.
Uma confusão constante no desenvolvimento de software é a definição de “retrabalho”.
Imagine que você capturou requisitos com relação a uma determinada tela de pedidos e com a
entidade de pedidos. Você modelou e implementou de acordo com o que você definiu como
objetivos do seu Sprint. Você mostra a tela para o usuário, ele gostou do que viu, mas ainda faltam
algumas coisas (que podem fazer parte da próxima entrega). O fato de você ter que mexer na tela
novamente ou na entidade não significa necessariamente retrabalho e sim refinamentos. O que
mostra o andamento do projeto é o cumprimento desses objetivos e não o número de telas
implementadas. Se depois, na vigésima entrega, algum conceito de negócio necessitar de mais
ajustes na entidade “pedido” também não será retrabalho, simplesmente é o software
amadurecendo. Não considere ter que mexer em coisas já implementadas como retrabalho,
principalmente se o processo é ágil.
Essa dinâmica é possível porque o PRODUTO SOFTWARE nos permite que o tratemos
dessa forma. O custo para ajustar os conceitos no SOFTWARE não segue o padrão de um produto
de processo prescritivo. A tecnologia nos permite construir o software dessa maneira. Isso nos leva
a outro conceito:

SOFTWARE = IDÉIA

Idéias são coisas que amadurecem. É bem raro uma maçã cair na sua cabeça e de uma hora
para outra você ter a idéia completa de como resolver um problema complexo. O software assim
como uma campanha publicitária, ou uma ação de marketing, ou um novo produto, é algo que
floresce com a participação de muitas pessoas e chega à maturidade em constante inspeção e
adaptação. O SCRUM é uma das maneiras empíricas de se controlar o gerenciamento da produção
de um software baseado em alta produtividade e satisfação dos envolvidos.

9
2.3. Papéis do SCRUM
O SCRUM como qualquer outra metodologia é baseada em papéis e responsabilidades,
porém, os papéis do SCRUM são bem abrangentes e direcionados para um propósito comum: O
SUCESSO DO PROJETO.

Product Owner

O Product Owner pode ser o financiador ou um importante interessado no projeto. Suas

principais responsabilidades são:
• Define as funcionalidades do produto
• Concentra as informações vindas de usuários, stakeholders ou do mercado de
maneira que se obtenha uma visão única dos requisitos do sistema
• Sua maior responsabilidade é o ROI do projeto
• Prioriza o Product Backlog
• Pode alterar as prioridades fora do Sprint
• Aceita ou rejeita os resultados dos trabalhos

O Time (Team)

O Time é mais bem definido como um grupo de pessoas do que um papel. O Time é o grupo
de pessoas diretamente ligadas ao trabalho a ser feito que garantirá que o projeto seja entregue com
todas as funcionalidades necessárias. Suas características são:

• Multi-functional
• Formado por até 7 pessoas
• Define o objetivo do Sprint e especifica os resultados dos trabalhos
• Faz aquilo que é necessário dentro das diretrizes do projeto para alcançar o objetivo
do Sprint
• Auto-organizável
• Demonstram o resultado do Sprint para o Product Owner e outros Stakeholders

A idéia por trás dos conceitos MULTI-FUNCIONAL e AUTO-ORGANIZÁVEL é que o time

deve ter a capacidade e o conhecimento técnico sobre TODO o processo de desenvolvimento do
produto. No caso de um projeto de desenvolvimento de software, o time deve ter pessoas capazes
de analisar a solução, codificá-la e testá-la sem necessitar de outros times ou outras pessoas.

10
 SCRUM Master

O SCRUM Master desempenha um papel de liderança, gerenciando os interesses do Product

Owner mediante o Time. Numa abordagem tradicional de gerenciamento de projetos, o SCRUM
Master seria um Gerente de Projetos, porém, essa nomenclatura foi substituída para diferenciar o
foco de liderança necessário para que um processo empírico funcione. Um SCRUM Master eficiente
deve:

• Melhorar a vida e a produtividade do time de desenvolvimento promovendo a

criatividade e o conhecimento
• Estimular uma comunicação e cooperação muito próxima entre todas as pessoas do
time
• Proteger o time de interferências externas
• Remover Impedimentos ("Impediments")
• Garantir que o processo está sendo respeitado
• Convidar pessoas apropriadas para as reuniões de acompanhamento (Daily SCRUM,
Sprint Review e Sprint Retrospective)
• Remover barreiras entre o desenvolvimento e o cliente para garantir que realmente é
o cliente que está direcionando as funcionalidades desenvolvidas
• Auxiliar o Product Owner a maximizar o ROI atingindo os seus objetivos com o
SCRUM
• Promover práticas de engenharia para que cada pedaço de funcionalidade seja
potencialmente implantável.

2.4. Iniciando um Projeto Ágil

É comum que processos ágeis sejam contra atividades que seguem o processo tradicional
em cascata. O processo tradicional define que todas as tarefas são encadeadas e seguem um
padrão linear. Esse modelo provadamente é a maneira menos produtiva e mais arriscada de se
desenvolver um projeto de software.

Figura 4 - Processo de Desenvolvimento em Cascata

11
 Neste modelo temos uma divisão onde há precedência e grande parte do projeto é analisado,
depois projetada, depois implementada e depois testada. Essa linha do tempo pode ser um prazo de
dois anos.
Um dos grandes problemas dessa abordagem é o grande risco de não entregar software
continuamente para reduzir as incertezas. Nessa abordagem, o software só fica funcional para os
usuários depois de dois anos! Em dois anos os usuários já mudaram, o mercado já mudou, a
concorrência aumentou. Desenvolvimento em cascata é uma abordagem arriscada para projetos de
software. Em projetos de software a iteratividade é primordial.
De qualquer forma, todo projeto (de software ou não) necessita de uma fase inicial ou de
concepção para definir exatamente o que o projeto deve resolver. Essas informações são
importantes para:

1. Definir os problemas a serem resolvidos

2. Estabelecer a visão e um escopo de alto nível
3. Investigar a viabilidade do projeto
4. Fornecer esforço e prazo preliminares
5. Conseguir recursos como financiamento

Um problema corriqueiro em empresas de software é o tempo investido para conseguir obter

o esforço e o prazo. É importante ressaltar que no inicio do projeto as incertezas são grandes,
porém, durante o projeto os riscos vão sendo resolvidos sempre através de software funcionando.
Investir duramente na fase de requisitos com o objetivo de refinar estimativas não funciona, pois
requisitos são abstrações com grande incerteza! Mesmo que todos os requisitos sejam levantados
nada garante que eles não vão mudar durante o processo. Adicionando iterações é a maneira mais
indicada para refinar o esforço e o prazo, de qualquer forma, segundo recomendação do PMBOK,
projetos de desenvolvimento devem ter escopo flutuante.
O SCRUM também possui fases para definição da visão do projeto e também para um
estudo de viabilidade. A figura a seguir demonstra a macro-estrutura do SCRUM:

Nível Estratégico 1.Definir os problemas a serem resolvidos

2.Estabelecer a visão e um escopo de alto nível
3.Investigar a viabilidade do projeto
Visão 4.Fornecer esforço e prazo preliminares
Backlog 5.Conseguir recursos como financiamento
Inicial

Nível Tático 1.Planejar Objetivos dos Sprints

2.Resolver Impedimentos
3.Liderar a Equipe
4.Promover a Comunicação
Backlog

Nível Operacional
1.Realizar Objetivos dos Sprints
2.Aplicar Boas Práticas de Engenharia
3.Adequar mudanças
Sprint 4.Garantir a Qualidade
Software
Backlog Funcionando

Figura 5 Macro-estrutura do SCRUM

12
2.5. Estrutura do Processo SCRUM
O SCRUM define conceitos importantes referentes à aplicação do processo no período do
projeto. Esses conceitos fundamentam práticas importantes para definir a estratégia de inspeção e
adaptação do projeto, fornecendo uma excelente visibilidade do andamento dos trabalhos,
juntamente com uma importante previsibilidade do que acontecerá no futuro.

SPRINT: ITERATIVO e INCREMENTAL

O processo iterativo é um dos conceitos básicos para qualquer metodologia de
desenvolvimento de software cuja estratégia é minimizar riscos oferecendo uma rápida avaliação
dos usuários a respeito daquilo que está sendo construído.
Uma iteração é um período de tempo fixo onde o time está trabalhando para que, ao final
desse período, algo de valor para os usuários ou interessados seja demonstrado. Essa
demonstração é importante para avaliar o andamento do projeto e também para inspecionar se o
time está realmente compreendendo o que o produto deve fazer.
No SCRUM, a iteração é chamada de SPRINT. Durante esse período o TIME trabalha nos
objetivos determinados para o SPRINT. Esse período de tempo pode variar, mas geralmente é um
período de 30 dias.

Sprint 1 Sprint = Iteração

30 dias

Sprint 2

Sprint 3

Sprint 4

Sprint 5

Tempo

Figura 6 - Processo Iterativo

Um projeto SCRUM é composto por vários SPRINTs do mesmo tamanho. Não é
aconselhável que o tamanho dos SPRINTs varie, pois um período de tempo fechado é a melhor
maneira para observar resultados, principalmente para avaliar a produtividade da equipe (veja o
conceito “velocidade” no capítulo 3).

13
 TIME-BOXING: Período Fechado de Tempo
Outro conceito importante para as práticas do SCRUM é o TIME-BOXING. Um SPRINT de 30
dias é um TIME-BOX. O planejamento que ocorre no primeiro dia do SPRINT ocorre num TIME-BOX
de 1 dia. As reuniões diárias com a equipe devem demorar no máximo 15 minutos. Tudo que
acontece dentro da metodologia SCRUM tem o espaço de tempo definido e cronometrado.
O TIME-BOX, como já citado, é um artifício importante para o acompanhamento. Além disso,
quando você define um objetivo e um período de tempo fechado, isso força sua equipe a se
concentrar naquilo que é mais importante, sem gastar tempo com coisas desnecessárias para o
objetivo.
O Time-boxing é um pilar importante da metodologia SCRUM, pois a filosofia é agregar valor
de negócio num curto período de tempo. O Time-boxing garante que o tempo seja investido onde
realmente é importante para o projeto.

2.6. Por dentro do SPRINT

Para facilitar o entendimento da dinâmica do SPRINT, vamos padronizar o período do
SPRINT em 30 dias. Um SPRINT é um período de trabalho planejado e observável. Nesse período a
equipe faz tudo ao seu alcance para que os objetivos que agregam valor ao negócio do cliente
sejam alcançados. Vamos verificar com mais detalhes o que ocorre durante um SPRINT.

e v
2

cti
spe
1&

....

tro
28
3
1
2

Re
.....
ng

Di a
Dia
Di a

Sprint
Dia

Dia
w
nni

Dia

vie
Pla

Re

Tempo 30 dias
Figura 7 - Estrutura de um SPRINT
A figura acima representa os dias no sentido vertical, evoluindo dentro do período de 30 dias.
A estrutura do processo SCRUM dentro do tempo é bem simples. O SPRINT inicia com um dia de

14
 planejamento que ocorre em duas partes. Neste dia, todos os envolvidos planejam quais serão os
objetivos a serem finalizados nos próximos 28 dias. Nesses 28 dias a equipe está trabalhando e
colaborando entre si em constante comunicação. No 30º dia do Sprint todo o trabalho da equipe é
avaliado juntamente ao Product Owner que pode dar novos direcionamentos ao projeto. Por último,
temos um momento de retrospectiva, onde a equipe discute as lições aprendidas e quais ajustes são
necessários no processo. Logo em seguida, um novo planejamento do próximo Sprint é realizado,
dando continuidade e fluidez à construção do Software.
Todos os Sprints possuem uma estrutura exatamente igual, o primeiro dia você planeja,
durante o Sprint você cumpre o planejamento, no último dia você avalia o resultado e ajusta o
processo buscando uma melhoria contínua. A simplicidade do modelo de papéis, artefatos e
estrutura do processo SCRUM é uma das razões da sua eficácia.
Para que cada um desses pontos fique ainda mais claro, vamos comentar cada um deles
com mais detalhes.

2.7. Planejamento do Sprint

O planejamento do projeto como um todo ocorre a cada planejamento de Sprint na
metodologia SCRUM. Este planejamento ocorre em duas partes, cada uma delas com TIME-BOX de
4 horas.

Parte 1 Parte 2

Product Backlog Sprint Backlog

Priorizado

4 horas 4 horas

Tempo 1 dia
Figura 8 - Planejamento - Parte 1

15
 Na primeira parte da reunião de planejamento o SCRUM Master reúne-se com o Product
Owner para verificar qual é o Product Backlog. O Product Backlog é um artefato do SCRUM que
nada mais é um documento ou planilha onde constam todas as funcionalidades de alto nível do
sistema. Lá estão todas as funcionalidades desejadas pelos Stakeholders ordenadas pela
prioridade. Aquilo que é mais prioritário está no topo da lista, e aquilo que é menos prioritário vai
para o fim da lista.

ID Descrição Sprint Esforço Conclusão

1 Emitir Pedido 1
2 Faturar Pedido 1
3 Aprovar Pedido 1
4 Integração com ERP
5 Cadastrar Cliente
6 Aprovar Crédito do Cliente
7 Cadastrar Produtos
8 Estoque – Entrada de Mercadorias
9 Estoque – Saída de Mercadorias
10
11
Figura 9 – Project Backlog – Primeiro Sprint
Nesta primeira parte da reunião a conversa deve focar no ROI (Retorno sobre Investimento)
do projeto. O trabalho de ordenar o Product Backlog é uma importante tarefa, pois o Product Owner
decidirá aquilo que agregará mais valor ao software para ser entregue ao final do Sprint que se
iniciará amanhã.
Os itens que aparecem no Product Backlog são qualquer tipo de funcionalidade ou tarefa que
possua um valor para o Product Owner ou ao grupo de Stakeholders que este Product Owner
representa. Esses itens seguem um conceito do SCRUM chamado “incremento de funcionalidade
potencialmente implantável”. Uma funcionalidade potencialmente implantável significa que quando
esse item do Product Backlog for finalizado ele estará completamente funcional e resolvendo algum
problema de negócio dos Stakeholders. O planejamento dos Sprints é feito através de conjuntos de
funcionalidades potencialmente implantáveis, sendo que ao final do Sprint, algo funcional SEMPRE
esteja sendo entregue. É inadimissível para a filosofia do SCRUM que ao final do Sprint sua equipe
só entregue documentos para o Product Owner (veja o segundo princípio do Manifesto Ágil).
Software funcionando ao final do Sprint é mandatório!

16
 Parte 1 Parte 2

Product Backlog Sprint Backlog

Priorizado

4 horas 4 horas

Tempo 1 dia

Figura 10 - Planejamento - Parte 2

Na segunda parte do dia do planejamento, o SCRUM Master se reúne com o time e com o
Product Owner (opcionalmente) para planejar o Sprint baseado no Product Backlog criado ou
atualizado. O trabalho nessa segunda parte é estabelecer e firmar os objetivos do Sprint,
selecionando quais itens prioritários do Backlog serão implantados completamente até o fim dos 28
dias. Para isso, métricas são adotadas para quantificar o esforço de cada item do Backlog a fim de
estimar a velocidade da equipe (veja capítulo 3).
Note que é importante ressaltar que o Product Owner e o SCRUM Master somente definiram
a ordem das coisas, mas não cabe a eles definir os prazos. Os prazos, como boa prática de todas as
metodologias de gerenciamento de projeto, são dados pelo Time que é responsável pela parte
produtiva do projeto.
Após ter selecionado quais itens potencialmente implantáveis serão resolvidos neste Sprint, o
Time quebra cada item selecionado em tarefas menores que podem ser cumpridas em um dia
(desejável). Esta quebra de cada item é chamado SPRINT BACKLOG e o time define que cada uma
dessas tarefas menores esclarece tudo que é necessário ser feito para implantar os itens do
PRODUCT BACKLOG selecionados para esse Sprint. Uma das ferramentas que podem ser
utilizadas para controlar o SPRINT BACKLOG é um quadro em cartolina com 4 colunas conforme o
descrito à seguir:

Item Pendente Alocado Pronto

Refinar Modelo de Tela de

Requisitos Dados Pedidos
Emitir Pedido
Carga de Tela de Testes /
Produtos Busca Prd. Homolog

Refinar Tela de Regras de

Requisitos Faturam. Validação
Faturar Pedido
Impressão Testes /
NF Homolog

Modelo de Tela Aprovação

Dados Aprovação Automática
Aprovar Pedido
Tela de Teste de Testes /
Param. Carga Homolog

Definir Testes API Escrever

Interface Comm Docum.
Integração
ERP Dados para Testes /
Teste Homolog

Figura 11 - Sprint Backlog

17
 Este quadro é montado a cada Sprint, e a idéia é que ele esteja visível a cada membro do
Time durante o período de trabalho. Neste quadro constam os itens potencialmente implantáveis do
Product Backlog em azul na primeira coluna “Item”. A coluna “Pendente” mostra a quebra deste item
em tarefas menores com duração média de um dia através de notas em amarelo (post-it’s).
Demonstraremos mais utilidades deste quadro durante este capítulo. O que você precisa ter
em mente neste momento é que itens do Product Backlog foram selecionados para serem resolvidos
neste Sprint e esses itens foram quebrados em tarefas menores no Sprint Backlog.
O Sprint Backlog é o produto do trabalho do dia de planejamento. Ao fim deste dia, o Time já
sabe exatamente aonde o esforço dos próximos 28 dias será empregado. Toda metodologia de
gerenciamento de projetos é baseada em: planejamento, execução, controle e avaliação. No
SCRUM isso não é diferente. O primeiro dia do Sprint é investido em planejar baseado em objetivos
aquilo que será entregue aos usuários ao final do período.

2.8. Como é um dia de trabalho do Sprint?

Com o Sprint Backlog definido a idéia é que os integrantes do Time peguem tarefas para
realizar. Isso consiste em retirar o post-it da coluna “Pendente” e colocá-lo na coluna “Alocado”,
conforme a figura a seguir:

Item Pendente Alocado Pronto

Tela de Refinar Modelo de

Pedidos Requisitos Dados
Emitir Pedido
Tela de Testes / Carga de
Busca Prd. Homolog Produtos

Refinar Tela de Regras de

Requisitos Faturam. Validação
Faturar Pedido
Impressão Testes /
NF Homolog

Modelo de Tela Aprovação

Dados Aprovação Automática
Aprovar Pedido
Tela de Teste de Testes /
Param. Carga Homolog

Definir Testes API Escrever

Interface Comm Docum.
Integração
ERP Dados para Testes /
Teste Homolog

Figura 12 - Sprint Backlog Atualizado

Como os itens estão ordenados de acordo com a prioridade do Product Backlog, é importante
que os itens no topo da lista sejam resolvidos primeiro. Se o foco é resolver os itens em ordem, seria
estranho que um post-it do item “Integração com ERP” estivesse alocado no início do Sprint.
Uma característica importante é que o membro do Time é quem seleciona a tarefa que ele
vai fazer. Isso permite que as pessoas tenham um maior controle e comprometimento sobre o
próprio trabalho, sem que alguém esteja delegando tarefas repetidamente de uma maneira
prescritiva. Um time multi-funcional e auto-organizável traz um ótimo ambiente de trabalho e uma
melhor performance no desenvolvimento.

18
Reunião Diária (Daily SCRUM)
Um evento importante que ocorre todos os dias durante o Sprint é a REUNIÃO DIÁRIA. A
reunião diária (Daily SCRUM) é um encontro entre o SCRUM Master, o Time e qualquer pessoa
interessada no projeto. As reuniões diárias ocorrem num TIME-BOX de 15 minutos no máximo. É
comum ocorrer algumas reuniões com menos de 5 minutos, porém, faça todos se concentrarem
naquilo que realmente é importante para que esse encontro não dure 2 ou 3 horas comprometendo
a produtividade da equipe.
A reunião diária são 15 minutos onde cada membro da equipe dará as suas impressões a
respeito do projeto, respondendo a três perguntas importantes:

1. O que eu fiz desde a última reunião diária?

2. O que eu pretendo fazer até amanhã?
3. Tem alguma coisa impedindo o meu trabalho?

É aconselhável que a reunião diária ocorra todo o dia no mesmo horário. Neste momento o
SCRUM Master verifica o andamento do trabalho, observando problemas, verificando a continuidade
do processo, resolvendo mal-entendidos e principalmente liderando as pessoas.
Esses 15 minutos diários são preciosos para manter a comunicação e a sincronização do
status do projeto entre os membros da equipe. A reunião diária promove a auto-organização, um
maior comprometimento das pessoas e um compartilhamento das responsabilidades.
Com relação à pergunta 3, o SCRUM define um conceito chamado IMPEDIMENTO.

IMPEDIMENTOS
Um impedimento é qualquer tipo de problema que um membro do Time está enfrentando que
impede o andamento dos trabalhos. Um impedimento pode ser um computador com defeito ou mal
dimensionado para o trabalho, interferências externas (recursos compartilhados com outros
projetos), dificuldades para se comunicar com Stakeholders, dependências com outras equipes ou
projetos, falhas no processo e etc... Os impedimentos são reportados diretamente ao SCRUM
Master, e o SCRUM Master é responsável por remover essas barreiras.

19
DEFINIÇÃO DE “PRONTO”
Um dos pontos de muita discussão a respeito da adoção do SCRUM é a definição da equipe
a respeito dos itens do Product Backlog finalizados. O SCRUM possui um conceito de valor
agregado (earned value do PMBOK) bem agressivo com relação aos riscos. Vamos analisar a
situação do Sprint Backlog abaixo:

Item Pendente Alocado Pronto

Refinar Modelo de Tela de

Requisitos Dados Pedidos
Emitir Pedido
Carga de Tela de Testes /
Produtos Busca Prd. Homolog

Regras de Refinar Tela de

Validação Requisitos Faturam.
Faturar Pedido
Testes / Impressão
Homolog NF

Tela Aprovação Modelo de

Aprovação Automática Dados
Aprovar Pedido
Teste de Testes / Tela de
Carga Homolog Param.

Definir Testes API Escrever

Interface Comm Docum.
Integração
ERP Dados para Testes /
Teste Homolog

Figura 13 - Sprint Backlog - Definição de "Pronto"

Como já foi dito, os itens mais importantes do Product Backlog são as principais
funcionalidades do sistema (podendo ser casos de uso, cenários, user stories ou outros). Se você
verificar o item “Emitir Pedido”, podemos chegar à conclusão que ele está pronto, pois não existem
mais tarefas a serem realizadas para este item.
O detalhe aqui é que o Time, juntamente com o SCRUM Master, em concordância com o
Product Owner, devem ter a sentença daquilo que o projeto define como “PRONTO”. Por exemplo, é
comum aos desenvolvedores acharem que ao terminar a codificação a funcionalidade está pronta,
porém, conceitualmente no SCRUM, uma determinada funcionalidade do Product Backlog só está
pronta quando é potencialmente implantável, isto é, a funcionalidade só está pronta quando tem o
potencial de entrar em produção assim que o Product Owner decidir. Alguns exemplos de definição
de “pronto”:

- Funcionalidade testada no ambiente de homologação;

- Funcionalidade avaliada por um Stakeholder;
- Funcionalidade homologada nos ambientes MySQL e Oracle;

A definição de “pronto” é um importante aspecto para avaliação no andamento do projeto,

isso porque a metodologia SCRUM não considera as funcionalidades 50% realizadas como é
comum nas abordagens tradicionais de gerenciamento de projeto. Para o SCRUM, um item só está
pronto quando atende à definição de “pronto” do time e o projeto só avança quando itens são dados
como completamente “prontos” no Product Backlog. No SCRUM, 20% da codificação feita não
significa nada para o andamento do projeto.

20
 Esta política é diretamente ligada à visão do SCRUM com relação a objetivos. O SCRUM é
direcionado por OBJETIVOS e não por TAREFAS. Esta abordagem fornece uma base concreta para
que o Product Owner realmente saiba onde o dinheiro dele está sendo investido de uma maneira
clara.
O foco em OBJETIVOS é um dos pilares importantes do SCRUM. Um time que realmente
segue a metodologia SCRUM planeja baseada em OBJETIVOS, executa as tarefas baseadas em
OBJETIVOS e principalmente, reporta o andamento do projeto baseada em OBJETIVOS e não em
porcentagens enganosas. 99% de uma funcionalidade pronta não agrega qualquer valor de negócio
ao software.

2.9. Sprint Review

O Sprint Review (Revisão) é um importante ponto de inspeção da metodologia SCRUM. Esta
reunião ocorre no último dia do Sprint e representa o momento que a equipe e o SCRUM Master
demonstram as funcionalidades potencialmente implantáveis executadas para o Product Owner.

Review
$ $
$

Product Backlog
Atualizado

Tempo 4 horas
Figura 14 - Sprint Review

Conforme dito anteriormente, o desenvolvimento de software é um gerenciamento de

incerteza. Muitos passos no processo de desenvolvimento devem ser seguidos, porém, a
funcionalidade potencialmente implantável é a única medida real a respeito do andamento do projeto
que pode reduzir essa incerteza.
Quando você demonstra a aplicação rodando para o Product Owner o sentimento de valor
agregado ao investimento é importante para manter a sustentabilidade do projeto e também para a
motivação da equipe onde objetivos claros foram definidos e muitos deles (senão todos) foram
implementados corretamente segundo o aval do Product Owner.

21
2.10. Sprint Retrospective
O SCRUM é um conjunto de práticas focadas em melhoria contínua do processo. O SCRUM,
como um controle empírico, não prega uma rigidez do processo, ao invés, o SCRUM promove a
constante adaptação das práticas mesmo durante o projeto. O processo pode mudar de um Sprint
para o outro sempre buscando uma melhoria na produtividade ou qualidade do produto final. A
retrospectiva do Sprint é uma reunião entre SCRUM Master e a equipe onde duas perguntas são
feitas:

1. O que foi bom durante o Sprint?

2. O que pode ser melhorado?

Retrospective

O que foi bom?

O que pode ser melhorado?

Lições Aprendidas

Tempo 4 horas
Figura 15 - Retrospectiva do Sprint

Nessa reunião o objetivo é a transparência interna da equipe. O SCRUM Master deve avaliar
friamente os pontos apresentados e prover os recursos necessários para que as mudanças ocorram.
Um dos problemas mais comuns é a equipe não buscar ou não se empenhar para que essas
mudanças no processo ocorram. A adaptação contínua é um fundamento importante para controlar
projetos críticos e esses pontos de melhorias devem ser valorizados.
As lições aprendidas é um fundamento em muitas metodologias de gerenciamento de
projeto. Elas representam a memória corporativa e promovem uma maneira para que os projetos
não sofram sempre dos mesmos problemas. Se sua empresa tem muitos projetos ou projetos
simultâneos essas lições aprendidas devem ser compartilhadas em toda a organização.

22