1

2
3
4
5
6
7
8
9
10
11
12
13
Sucesso = no prazo, dentro do orçado reunindo todos os requisitos.

Motivadores para o aumento do sucesso de 1994 a 2007: melhor gerenciamento

de projetos, desenvolvimento iterativo (métodos ágeis), tecnologia Web.

14
15
16
17
Consiste em concentrar o esforço de um time em um curto período de tempo
para alcançar um pequeno objetivo estabelecido.

SCRUM usa a mesma idéia e divide o desenvolvimento de um software em

várias partes (Sprints) onde o principal objetivo é alcançar primeiro os 20% das
funcionalidades mais importantes de um sistema para entregar 80% do seu
valor.

É um framework iterativo e incremental para desenvolvimento de softwares

onde seu principal objetivo é entregar funcionalidades com o mais alto valor
de negócio para o cliente freqüentemente.

18
19
20
21
22
23
24
A maioria dos projetos entregam software a cada 6 a 18 meses. Scrum reduz
isso a muitas entregas mensais que incrementam o controle via inspeção e
adaptação. Isto estressa o time e a organização, expondo problemas
subjacentes e limitações, ou seja, expondo o que está por trás da “maquiagem”.

O trabalho do Scrum Master é priorizar estes problemas e ajudar a organização

a superá-los para ficar melhor no desenvolvimento de produto, gerenciando
investimentos e se transformando em uma comunidade.

25
Um SCRUM Master deve:

• Remover a barreira entre desenvolvimento e cliente

• Ensinar o cliente a maximizar o ROI e atingir seus objetivos através do Scrum
• Melhorar o dia-a-dia dos membros do time facilitando a criatividade e fortalecimento
• Combater a ilusão do comando-controle
• Priorizar os impedimentos e combatê-los
• Ser um catalisador de resultados para o time
• Determinar onde Scrum está, comparado com onde poderia estar
• Auxiliar o Product Owner com o Product Backlog
• Garantir o uso do Scrum
• Facilitar reuniões
• Garante a qualidade da entrega

Também deve ser responsável, comunicativo, humilde, comprometido, influente e conhecedor.

Deve adquirir um conjunto de novas habilidades e aptidões, que incluem: facilitação, educação,
coaching, liderança e dominar a arte de escutar e observar.

26
Características desejadas do PO:
•Entender as necessidades do cliente
•Ter habilidade para criar e comunicar a visão do produto
•Tomar decisões e saber quando dizer não
•Entender o valor do processo criativo
•Líder / Facilitador

Problemas comuns:
•PO sem poder de decisão
•PO com baixa disponibilidade
•PO não foi preparado/treinado para exercer o papel

27
Como um Product Owner você deve:
• Definir a visão do produto (product vision);
Qual o objetivo do negócio?
Qual o roadmap do projeto?
Ao final dos Sprints, o que eu quero do projeto?
Qual a expectativa do projeto?
• Gerenciar o retorno de investimento (ROI);
• Apresentar ao time os requisitos necessários para a entrega do produto;
• Priorizar cada requisito de acordo com seu valor para o negócio/cliente;
• Gerenciar a entrada de novos requisitos e suas priorizações;
• Planejar entregas (releases);
• Atuar como facilitador quando mais de um cliente estiver envolvido no projeto;
• Garantir que Especialistas de Domínio estejam disponíveis para o time;

28
29
Times Scrum são:
• Auto-organizados
• Multidisciplinares
• Compostos por no máximo 9 integrantes
• Comprometidos com o trabalho
• Responsáveis por fazer aquilo que for necessário para atingir a meta da Sprint
• Comunicativos (ferramentas de comunicação devem estar disponíveis para o
time com membros de diferentes sites)
• Organizadas em um espaço físico apropriado para o trabalho
• Responsáveis pela resolução de conflitos

30
31
Papéis que não colaboram frequentemente para atender o conceito de pronto do
Product Backlog podem ser organizados em times periféricos (times de suporte).
Os profissionais deste time (que não é um time Scrum) são alocados em times
Scrum quando for necessária a sua participação em tarefas específicas.

32
33
O Product Owner define a Visão do Produto. Esta Visão é o que representa
sua necessidade, é o que deve ser satisfeito ao fim do projeto. Para definir esta
Visão o PO colhe informações junto a clientes, usuários final, time, gerentes,
stakeholders, executivos, etc.;

O primeiro passo em um projeto Scrum é de responsabilidade do Product

Owner, que deve articular a visão do produto. O Product Backlog representa
esta visão, ele deve ser apresentado no formato de uma lista com itens
priorizados e ordenados de acordo com o valor que representam para o cliente e
negócio. Apenas um Product Backlog deve existir, e ele deve definir uma visão
de tudo que precisa ser feito.

O Product Backlog irá existir por todo o ciclo de vida do projeto (e não da Sprint),
e é regularmente atualizado pelo Product Owner para refletir as mudanças e
necessidades do cliente, mudanças estratégicas ou tecnológicas, novas idéias,
enfim, mudanças. Ele é composto de vários tipos de itens: funcionalidades,
requisitos de desenvolvimento, exploração técnica, estudo, documentação, bugs,
etc.

34
A visão do produto estimula os membros do time a focarem seus diferentes
pontos de vistas em uma visão mais concisa, visual e curta sobre o objetivo do
projeto e seu resultado. Na fase de planejamento do projeto ocorrem as reuniões
para definir a visão do produto. Neste momento o PO cria uma lista inicial de
necessidades que precisam ser produzidas para que a Visão do produto seja
atingida, para esta lista damos o nome de Product Backlog. Nestas reuniões
participam o Product Owner, Scrum Master, outros usuários de negócio,
especialistas em arquitetura de sistemas e infra, e até mesmo o time.

Quanto mais crítico for o cronograma de entrega e mais volátil o projeto, é muito
importante que o time tenha uma boa visão do resultado final desejado. Sem
esta visão, projetos de desenvolvimento iterativo (ágeis) se tornam mais
oscilantes, sem agregar muito valor às entregas, pois todo mundo está
enxergando uma miniatura do que deve ser feito (estória) ao invés de uma
grande visão. Para grandes projetos uma definição da visão pode se feita para
cada componente principal.

Uma boa visão de produto permanece relativamente constante, ao passo

que o caminho para implementação da visão é frequentemente adaptado.

35
Uma das melhores formas de se expressar em uma estória alguns dos detalhes
discutidos entre cliente (Product Owner, especialista do negócio, etc) é a escrita
de Critérios (ou testes) de Aceitação. O cliente (Product Owner, especialista do
negócio, etc) é quem deve escrever os Critérios de Aceitação, e o deve fazê-lo
antes da codificação. Testes devem fazer parte do processo e devem ser
automatizados sempre que possível. Testes de engenharia são extremamente
importantes para a garantia de qualidade dos entregáveis.

Basicamente um Critério de Aceitação é a descrição daquilo que será verificado

pelo Product Owner para dizer que a funcionalidade atingiu seu objetivo.

36
37
38
Uma boa estratégia para ser utilizada é um design simples que simula o fluxo de
possíveis funcionalidades a partir de um ponto do sistema.

39
O valor de negócio é definido pelo Product Owner levando em consideração os
benefícios imediatos que as funcionalidades desenvolvidas irão trazer para a
área de negócio. Este definição auxilia o PO no trabalho de priorizar a lista de
requisitos do Product Backlog.

40
O valor de negócio é definido pelo Product Owner levando em consideração os
benefícios imediatos que as funcionalidades desenvolvidas irão trazer para a
área de negócio. Este definição auxilia o PO no trabalho de priorizar a lista de
requisitos do Product Backlog.

41
Um Product Backlog é uma lista de funcionalidades priorizadas e estimadas,
compatível com a visão. É uma lista única para todo o projeto.

Se a priorização do Product Backlog está na mão do cliente e este sabe que não
precisará definir todas as funcionalidade no início do projeto, há uma
probabilidade muito grande de que no topo do Product Backlog residam as
funcionalidades que realmente importam (20% do gráfico do Uso das
Funcionalidades), as que irão gerar mais valor para o negócio em menor tempo.

O PO cria (com ajuda do time) e mantém o Product Backlog. Ele nunca vai
a uma Planning Meeting sem estar com o Product Backlog estimado e
priorizado (ready!).

42
43
44
45
Em SCRUM, como mudanças fazem parte do processo, o Product Owner pode
incluir novas funcionalidades ao Product Backlog conforme a necessidade do
negócio. Porém apenas uma regra deve ser considerada: se um grupo de
funcionalidades de tamanho 50 entrar no Product Backlog, outro grupo de
mesmo tamanho deve sair do seu final, afinal, elas tem pouco importância ao
negócio.

46
O Product Owner cria e mantém o Product Backlog. Ele nunca vai a uma
Planning Meeting sem estar com o Product Backlog estimado e priorizado.

47
Um Product Backlog é considerado pronto quando atende aos requisitos acima.
Nesse momento, o time é cliente do Product Owner que deve garantir que o
conceito de “READY” seja atendido para de fato poder iniciar uma Sprint
Planning Meeting.

48
49
50
O esforço estimado para os itens do Product Backlog deve ser negociado entre
o time e o Product Owner, sempre praticando o bom senso e não sendo
influenciados por alguma pressão exercida por nenhuma das partes. A técnica
mais popular para estimativas é o Planning Poker, onde através de cartas com
numeração seguindo a tabela de Fibonacci, os membros do time “sugerem” um
tamanho para os itens do Product Backlog. Ele funciona porque apresenta
múltiplas opiniões de especialistas quanto à estimativa de um item, e como
Scrum trabalha com times multi-funcionais, é sempre importante ter um
consenso quanto a este fator.

O Planning Poker estimula o diálogo durante os rounds, e cada membro do time

tem que explicar para todos os outros membros o porque estimou o item com
aquele tamanho. Todo este processo gera compartilhamento de conhecimento.
Além disso estudos mostram que estimas feitas em grupo vem sendo bem mais
bem sucedidas que estimativas individuais.

Todas as estimativas são feitas pelo time (se possível, todo o time!). Uma
abordagem clássica é identificar o item de backlog mais simples de desenvolver
(baseado em seu conhecimento, experiência anterior e complexidades técnica e
de negócio) e atribuir o valor 2 para ele. Os demais itens do backlog são
estimados com base nele.

51
52
53
54
55
O Release Planning foca em planejar o trabalho para a geração de um entregável, de acordo com uma
condição de satisfação real, clara e prioritária (uma data, uma condição de negócio, etc). Somente
após a finalização de um Release é que um novo deve ser planejado.

Ao final de uma Release Planning Meeting você deve ter uma visão do horizonte do projeto, e isso significa
ter visibilidade de quais Sprints farão parte da próxima Release e como elas estão preenchidas. Ao
final de cada Sprint, normalmente após a Sprint Review, o seu Plano de Release deve ser atualizado.

Processo da Release Planning:

1) Prefira trabalhar com releases pequenos, de 2 a 3 meses, pois assim é possível manter uma taxa
constante de entrega de valor para o cliente, tendo feedbacks constantes da qualidade e da ativação
do valor.
2) Defina as metas de negócio da release e o que deve conter no entregável (SEMPRE deve entregar
valor “ativo” ao cliente)
3) Identifique o número de Sprints necessários para consumir o Product Backlog (Tamanho estimado do
Product Backlog dividido pela Velocidade do time)
4) Defina as datas de entrega para as releases
5) Distribua as estórias priorizadas por valor nos Sprints de forma que atenda aos objetivos de cada
release
6) Revise com o time a lista final do Product Backlog para certificar que estarão entregando o valor
desejado em cada release

Durante a Release Planning Meeting o Product Owner deve fornecer uma visão clara dos objetivos de cada
release para o time entender e se comprometer com as datas e entregáveis esperados ao fim da
release. Durante esta reunião estão presentes o Product Owner, outros usuários de negócio que
agregam valor, o Scrum Master e o time.

56
57
A velocidade do time serve de guia para o planejamento de Sprints. Por
exemplo, se na Sprint anterior um time foi capaz de completar 16 pontos, esta
quantidade de trabalho realizado passa a ser a velocidade do time e contribuirá
bastante para o planejamento da próxima Sprint. A velocidade também pode
servir de guia para o planejamento de Releases e progresso do projeto. Por
exemplo, se na Sprint (de 4 semanas) o time foi capaz de completar 16 pontos,
provavelmente precisará de mais 3 Sprints para completar os 67 restante no
Product Backlog.

A velocidade de um time pode mudar de projeto a projeto quando as

características tecnológicas e de negócio são muito diferentes da arquitetura e
domínio convencionais.

58
59
Cada iteração é chamada de Sprint com período de 2 a 4 semanas, onde o
produto é projetado, codificado e testado. Cada Sprint é composto por Planning
Meeting, Daily Meetings, Retrospective Meeting (Lessons Learned) e Review
Meeting (ou Demo Meeting).

A Planning Meeting ocorre no início de cada Sprint e deve durar 8h. A Planning é
dividida em duas partes: a primeira para o Product Owner apresentar a visão do
produto, os detalhes das estórias, tirar dúvidas e concluir a estimativa junto com
o time de algum item do Product Backlog que ainda não foi estimado. A segunda
parte é para o time definir quais itens do Product Backlog irão fazer parte do
Selected Product Backlog e para detalhar em horas cada tarefa a ser executada
para cada item selecionado, formando assim o Sprint Backlog. Participam desta
reunião o Product Owner, o Scrum Master e o time. Outras pessoas também
podem ser envolvidas com a aprovação do Product Owner se agregarem valor a
reunião.

60
Durante esta reunião o PO deve solucionar todas as dúvidas do time referente
às estórias selecionadas que farão parte do Selected Product Backlog. O PO
pode inserir mais detalhes nas estórias para deixá-las mais claras e objetivas ao
time.

Responsabilidades do Scrum Master antes da Planning Meeting:

•Organizar a reunião e garantir que todos estarão presentes (usa-se conf para
casos onde os integrantes dos times ficam em sites diferentes)
•Certificar que o Product Backlog esteja priorizado e estimado
•Certificar que as estórias mais prioritárias estejam em um bom nível de detalhes
para discussão do time (Critérios de Aceitação)
•Garantir que as datas de início e término do Sprint estejam planejadas
•Ter em mãos anotações, pendências ou itens do Sprint passado
•Garantir que os próximos Sprints estejam com as datas planejadas

61
62
63
Nenhuma tarefa pode ter mais que 16h de duração. Se passar disso, ela deve
ser decomposta e implementada em partes. Isso facilita o controle da execução
do Sprint, evitando surpresas ao aproximar o término de uma tarefa.

64
65
66
Levando em consideração a definição de “pronto” para o Sprint, as tarefas definidas não devem
ultrapassar o total de horas disponíveis para o Sprint, que é baseado na quantidade de membros
que irão queimar o backlog e nas cerimônias programadas.

Exemplo:

Tamanho do Sprint = 4 semanas (20 dias)

Tamanho do time = 5 membros (não considera o Scrum Master pois ele não queima backlog,
apesas de ser o responsável pelo Sprint)
Horas de Trabalho = 8 horas por dia
Capacidade em horas do Sprint = 800 horas

Planning Meeting = 40 horas (5 pessoas x 8 horas)

Retrospective Meeting = 10 horas (5 pessoas x 2 horas)
Review Meeting = 10 horas (5 pessoas x 2 horas)
Daily Meetings = aproximadamente 25 horas (5 pessoas x ¼ hora x 18 dias)

Capacidade Total do Sprint para queima de backlog = 715 horas

Tempo não é negociável em SCRUM.

67
68
69
70
• O time executa as tarefas considerando a engenharia definida para o projeto
• O Scrum Master facilita o trabalho do time removendo impedimentos (blocks) encontrados e
garantindo a boa aplicação do SCRUM
• O PO deve estar sempre acessível para facilitar a remoção de impedimentos em uma estória,
sendo por ele mesmo ou através do contato direto do time com os usuários de negócio
• O tempo das tarefas são atualizados para refletir o andamento da Sprint no Burndown chart

Comprometimento do PO, Scrum Master e time é a chave para o sucesso da Sprint.

O tamanho ideal de uma Sprint é o tamanho que seu time e cliente achar ideal. Para isso,
considere:

• Mudança constante no topo do Product Backlog: ideal trabalhar com Sprints curtos
• Síndrome do estudante presente: ideal trabalhar com Sprints curtos
• Dificuldade de entregar valor para o cliente ao fim das Sprints: ideal trabalhar com Sprints
curtos
• Time e/ou cliente exaustos com loops tão curtos: ideal trabalhar com Sprints longos

71
Durante a Sprint, o que o time se comprometeu a entregar e o que foi acordado
com o Product Owner é o que deve ser entregue. O Product Owner também não
pode mudar o objetivo da Sprint e nem adicionar novas estórias.

Durante uma Sprint pode-se incluir, alterar ou excluir tarefas que não vão alterar
a meta da Sprint e que irão trazer valor à entrega.

Quando o conteúdo de uma Sprint é alterado, o cliente deixa de sentir

necessidade de fazer um planejamento de qualidade, bem como de estar atento
a uma boa composição e priorização do Product Backlog, afinal, se pode mudar
a qualquer momento, para que se preocupar com isso? O time ignora a meta,
afinal “com certeza” ela mudará novamente. O time perde foco e motivação e o
stress impera.

72
Umas Sprint pode ser terminada antes da sua finalização nas seguintes
situações:

• O time sente que não conseguirá atingir a meta.

• O Product Owner percebe que mudanças em fatores externos influenciarão
diretamente no valor da meta da Sprint.

Caso uma Sprint seja cancelada deve se iniciar imediatamente o planejamento

da próxima Sprint.

73
Reunião diária de 15 minutos onde cada membro do time deve responder:

1) O que foi feito desde o último Sprint Daily Meeting?

2) O que se pretende fazer até o próximo Sprint Daily Meeting
3) Há algum impedimento?

Através desta reunião o time ganha visibilidade de como está o caminho para a
meta e planeja o dia seguinte de trabalho. O Scrum Master novamente é o
facilitador, e deve se lembrar que a reunião é para o time e não para ele. O
Product Owner também pode participar, porém não é obrigatório.

74
O burndown é um gráfico que demonstra diariamente o andamento do Sprint. No eixo horizontal
(X) é exibido a quantidade de dias de uma Sprint, por exemplo 15 dias, e no eixo vertical (Y) a
quantidade de horas (capacidade do time) definido para a Sprint. Após a definição dos eixos X e
Y é traçado uma linha entre os dois extremos, que é por onde a Sprint “deve trilhar”. Essa linha
demonstra a velocidade do time, ou seja, quantas horas precisam ser “queimadas” por dia até o
término da Sprint.

Antes da Sprint Daily Meeting o time deve fazer a atualização desse gráfico. Ao atualizar uma
tarefa o membro do time pode dizer que ela está no prazo, ou que vai levar mais horas (atrasada)
ou que levará menos horas que o previsto (adiantada). Para ambos os casos deve-se refletir as
horas no burndown chart. Por exemplo, se uma tarefa de 4h irá atrasar mais 2h, então para
concluir toda a tarefa o membro do time irá levar 6h, sendo estas as horas a serem consideradas
para ela.

Se após um dia de trabalho sua equipe de 5 membros queimou 40hs (5 vezes 8h) e ainda restam
mais 12h para concluir as tarefas previstas para aquele dia (pois houve atraso), deve-se atualizar
o burndown chart demonstrando que houve um aumento de 12h de trabalho na Sprint.

Ao realizar este trabalho diariamente, logo é possível ver se o time irá ou não atingir sua meta,
dando tempo ao time, com auxílio do Scrum Master e Product Owner, avaliar o andamento do
projeto e executar ações corretivas para fazer a entrega planejada.

75
76
77
Ao final da execução da Sprint deve ser realizada a Review Meeting, reunião
que tem como propósito apresentar o que foi feito para o Product Owner e
convidados. O time é quem realiza a apresentação, que deve ser feita no
formato de demo. A apresentação do produto da Sprint não pode ultrapassar 2h
e deve ser informal. O Product Owner avalia se a Meta da Sprint foi alcançada e
faz anotações que poderão se transformar em novos itens para o Product
Backlog.

A Review Meeting é uma apresentação do resultado da iteração para os clientes

onde todos os envolvidos no projeto participam. As possíveis conseqüências
desta reunião são:
• Devolver ao Product Backlog funcionalidades não terminadas e repriorizá-las
• Remover do Product Backlog funcionalidades que foram finalizadas
antecipadamente
• Trabalhar com o ScrumMaster para reformular a equipe
• Repriorização do Product Backlog
• Solicitar o fechamento de um Release com as funcionalidades demonstradas,
sozinhas ou com o incremento de Sprints anteriores
• Escolher não avançar mais com o projeto e não autorizar outra Sprint
• Solicitar que o progresso do projeto seja acelerado autorizando a inclusão de
times adicionais para trabalhar no Product Backlog

78
Semelhante ao Sprint Burndown, este gráfico mantém no eixo horizontal a
quantidade Sprints previstas para o projeto, e no eixo vertical a quantidade de
pontos (Story Points). Sempre ao final de uma Sprint o gráfico deve ser
atualizado através da subtração da quantidade de pontos que foram entregues
naquela Sprint.

79
80
A Retrospective é a última cerimônia do Scrum. Realizada ao fim de uma Sprint
ou Release, esta é uma reunião de lições aprendidas, facilitada pelo
ScrumMaster, na qual o time deve avaliar:
•O que foi bom neste iteração?
•O que deve ser melhorado para a próxima iteração?
•O que melhoramos desde a última iteração?

Deste reunião participam todos os membros do time e o Scrum Master.

Dependendo de negociação podem participar todos os envolvidos no projeto.

81
Os membros do time são convidados a escrever post-its citando os pontos que
acreditam que foram bons nesta iteração, quais ainda devem ser melhorados e
quais foram melhorados desde a última iteração. Este trabalho deve ser feito
individualmente e não deve ser levado para o lado pessoal, ou seja, deve-se
citar o problema ou a qualidade, e não apontar um responsável por isso.

Ao fim desta etapa, o Scrum Master deve conduzir a discussão de cada item
citado, destacando os pontos positivos e os pontos melhorados desde a última
iteração. Para os pontos a melhorar, o Scrum Master juntamente com o time
devem elaborar um plano de ação para que na próxima iteração o item negativo
seja eliminado da melhor maneira possível. Para itens onde seja necessária a
ação direta da empresa, o Scrum Master deve liderar esta questão, procurando
retirar este impedimento do time.

No início da próxima iteração (Sprint ou Release) o Scrum Master deve lembrar

o time dos itens que deverão ser melhorados e as ações para alcançar isso.

Ter esse tipo de reunião sem gerar entrada de ações corretivas para a próxima
iteração vai contra o princípio de melhoria contínua do processo.

82
83
Scrum não é um framework engessado. Por ser baseado em princípios ágeis e
constantemente adaptado aos mais diversos ramos da indústria, o framework
está sempre em evolução, por isso devemos sempre buscar a melhor forma de
entregar software com rapidez, eliminando desperdícios, trazendo valor ao
cliente, dentro de um custo e risco aceitáveis ao negócio.

84
85
86
87
88
89
90
90