Gestão Ágil de Produtos

Prévia do material em texto

Gestão Ágil de Produtos Rafael Sabbagh 
Certified Scrum Product Owner
Certified Scrum Trainer (CST), Scrum Alliance!
ScrumMaster, Agile Coach & Agile Trainer!
Palestrante em eventos e congressos:
@rsabbagh
Rafael Sabbagh
Participante:
Organizador:
Uso de Funcionalidades pelo Cliente
Sempre
Frequentemente
Às vezes
Raramente
Nunca
Fonte: Standish Group, 2002
Entrega de Valor: Agile x Waterfall
Tempo
releases Ágeis
release 
Waterfall
0
Plan Driven x Value Driven
Fixo
Estimado
Plan 
Driven
Value 
Driven
Requisitos
RequisitosCusto Tempo
Custo Tempo
Waterfall Agile
Agilidade
Agilidade
2001: representantes de processos 
leves de desenvolvimento de software 
se reuniram para discutirem sobre o 
que seus processos possuíam em 
comum
Os 12 Princípios Ágeis
1. Nossa maior prioridade é satisfazer o cliente através da entrega 
contínua e adiantada de software com valor agregado. 
!
2. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no 
desenvolvimento. Processos ágeis tiram vantagem das mudanças 
visando vantagem competitiva para o cliente. 
!
3. Entregar frequentemente software funcionando, de poucas semanas a 
poucos meses, com preferência à menor escala de tempo. 
!
4. Pessoas de negócio e desenvolvedores devem trabalhar diariamente 
em conjunto por todo o projeto. 
!
5. Construa projetos em torno de indivíduos motivados. Dê a eles o 
ambiente e o suporte necessário e confie neles para fazer o trabalho. 
!
6. O método mais eficiente e eficaz de transmitir informações para e entre 
uma equipe de desenvolvimento é através de conversa face a face.
Os 12 Princípios Ágeis
7. Software funcionando é a medida primária de progresso. 
!
8. Os processos ágeis promovem desenvolvimento sustentável. Os 
patrocinadores, desenvolvedores e usuários devem ser capazes de 
manter um ritmo constante indefinidamente. 
!
9. Contínua atenção à excelência técnica e bom design aumenta a 
agilidade. 
!
10.Simplicidade--a arte de maximizar a quantidade de trabalho não 
realizado--é essencial. 
!
11. As melhores arquiteturas, requisitos e designs emergem de equipes 
auto-organizáveis. 
!
12.Em intervalos regulares, a equipe reflete sobre como se tornar mais 
eficaz e então refina e ajusta seu comportamento de acordo. 
O que é Scrum
Scrum...
• . . . é um f ramework ág i l s imp les pa ra 
desenvolvimento de produtos complexos em 
ambientes complexos; 
!
• ...não é um processo ou técnica: dentro de Scrum 
podem-se empregar diversos processos e 
técnicas;
• ...utiliza a abordagem iterativa e 
incremental para melhorar a 

previsibilidade e o controle de 
riscos;
Scrum...
• . . . to rna os prob lemas das prá t icas de 
desenvolvimento transparentes, para que se 
possa melhorá-las;
• ...gera entrega frequente de valor para 
o cliente;
• . . . u t i l i z a i n s p e ç ã o e 
adaptação para melhoria 
contínua do produto e dos 
p r o c e s s o s d e 
desenvolvimento;
Scrum...
• ...é orientado a valor, e não a planos
• ...utiliza times auto-organizados, que 
definem as melhores formas de 
desenvolverem as funcionalidades de 
maior valor
...é focado na ordenação do 
trabalho baseada no maior 
valor de negócio para o cliente;
As Origens do Scrum
Scrum: Origens
• Ken Schwaber, início dos anos 90: desenvolvimento em sua 
empresa do que se tornaria o Scrum 
!
• Jeff Suttherland, 1993: desenvolvimento 
 do Scrum na Easel Corporation 
!
• Ken Schwaber : formalização do Scrum na OOPSLA’95 
!
• Anos seguintes: Schwaber e Sutherland 

colaboram para unificar seus trabalhos 
!
• Publicação do livro “Agile Software 

Development with Scrum”, por Ken 

Schwaber e Mike Beedle 
Scrum: Origens
• “The New New Product Development 
Game”, de Takeuchi e Nonaka (1986)
• Equipes de desenvolvimento de novos 
produtos de empresas americanas e 
japonesas 
!
• Instabilidade embutida 
• Equipes auto-organizadas 
• Fases sobrepostas de desenvolvimento 
• Múltiplo aprendizado 
• Controle sutil 
• Transferência organizacional de 
aprendizado
Scrum: Origens
O nome Scrum vem do Rugby!
• “The New New Product Development 
Game”, de Takeuchi e Nonaka (1986)
Scrum: Origens
• Sistema Toyota de Produção

e Produção Enxuta 
!
– Produção “puxada” pelo cliente 
– Produção de valor em fluxo estável e contínuo, sem paradas, 
lotes, filas ou departamentos 
– Qualidade embutida no processo: jidoka 
– Melhoria contínua: kaizen 
– Combate ao desperdício: 
• muda: etapas sem valor 
• muri: sobrecarga nas pessoas e equipamentos 
• mura: desbalanços nos ritmos de produção
Os Papéis do Scrum
Time de Scrum
• Product Owner 
– Garante e maximiza o ROI do cliente a partir do 
trabalho do Time 
!
• Time de Desenvolvimento (o Time) 
– Gera valor para o cliente construindo incrementos do 
produto com alta qualidade 
!
• ScrumMaster 
– Garante que aos valores do Scrum, práticas e regras 
estão sendo compreendidos e seguidos
Product Owner: Atribuições
!
!
!
• Gerencia o Product Backlog: garante a visibilidade, insere, 
remove, modifica e ordena os itens 
!
• Gerencia os stakeholders do projeto 
– identifica os stakeholders e seu nível de apoio 
– comunica-se com eles para entender suas necessidades 
– balanceia as diferentes necessidades dos stakeholders 
– influencia os stakeholders 
!
• Gerencia a Visão do Produto: estabelece, mantém e comunica 
!
• Gerencia os Releases do produto para o cliente
Responsável por garantir e maximizar o ROI do 
cliente a partir do trabalho do Time
Product Owner: Atribuições
!
!
!
• Participa ativamente das Sprints 
– Disponível para o Time 
– Sprint Planning / Sprint Review (e Release Planning) 
!
• Aceita ou rejeita na Sprint Review o trabalho realizado pelo Time 
!
• Gerencia o orçamento: garante que há orçamento suficiente para o 
projeto durante todo seu desenvolvimento
Responsável por garantir e maximizar o ROI do 
cliente a partir do trabalho do Time
Product Owner: Características
• Único (só pode haver um!) 
– Não é comitê, não há substitutos 
– Influenciado por outros (Time, stakeholders e até mesmo um time de negócios) 
– Tem a voz final sobre o Product Backlog 
!
• Disponível 
– para tirar dúvidas do Time e tomar decisões sobre o produto 
– para falar com os stakeholders e atualizar o Product Backlog frequentemente 
!
• Representativo 
– com suficiente poder e conhecimento necessário para tomar decisões rápidas e corretas 
sobre o produto
Time de Desenvolvimento: Atribuições
!
!
!
• Trabalha sobre o Product Backlog, em direção à visão do produto 
!
• Entrega valor frequentemente para o cliente 
!
• Auto-organiza-se para realizar o trabalho 
– com poder para gerenciar seu trabalho de desenvolvimento, responsável por seus 
resultados 
– comunicação: melhores Times são pequenos (7 ± 2 membros) e co-localizados 
!
• Comunica-se frequentemente com o P.O. – dúvidas e decisões 
sobre o produto 
!
• Informa os impedimentos ao ScrumMaster

assim que detectados
Gera valor para o cliente construindo incrementos do 
produto com alta qualidade
Time de Desenvolvimento: Características
• Multidisciplinar 
– todo conhecimento e habilidades necessárias para gerar o trabalho pronto (DoD), 
incluindo qualidade 
– os melhores Times são Feature Teams 
– não há títulos no Time 
– fertilização cruzada: um aprendendo do outro 
!
• Suficientemente pequeno (7 ± 2) para garantir comunicação 
!
• Motivado, com a confiança e apoio necessários 
!
• Tecnicamente excelente 
!
• Comprometido a alcançar as metas da Sprint/Release – os 
melhores Times são 100% dedicados ao projeto (sem multitasking)ScrumMaster: Atribuições
!
!
!
• Remove os impedimentos que atrapalham o trabalho do Time 
!
• Facilita as reuniões do Scrum 
!
• Facilita o trabalho do Time e sua relação com o P.O. 
!
• Ensina (ou garante que aprenda) e encoraja o Time a melhorar seu 
trabalho, com qualidade e produtividade, e a se auto-organizar 
!
• Alinha as necessidades do Time e as da organização 
!
• Ajuda a escolher e ensina o P.O. (ou garante

que aprenda)
Garante que aos valores do Scrum, práticas e regras 
estão sendo seguidos
ScrumMaster: Características
• Competente em soft skills: facilitador, negociador, comunicador, 
gerência de conflitos etc. 
!
• Corajoso para realizar as mudanças necessárias e remover os 
impedimentos 
!
• presente durante todo o trabalho do Time 
!
• isento o suficiente para garantir que não haja desvios no processo, 
para facilitar o consenso, para não interferir nas decisões do Time e 
para ajudar o Time a melhorar seu trabalho
Ciclo do Scrum
A VISÃO DO PRODUTO e o 
PRODUCT ROADMAP 
devem ser criados antes do 
início do desenvolvimento
Resumo do Ciclo do Scrum
O representante do cliente, chamado de 
PRODUCT OWNER, levanta com os 
stakeholders os requisitos de maior prioridade 
no momento
Resumo do Ciclo do Scrum
Ele então insere esses 
requisitos em uma lista 
ordenada, chamada 
PRODUCT BACKLOG
Resumo do Ciclo do Scrum
Resumo do Ciclo do Scrum
O Product Owner e o Time se reúnem na 
SPRINT PLANNING MEETING e geram o 
SPRINT BACKLOG: o que será feito e como 
será feito neste ciclo de desenvolvimento 
(SPRINT)
O Time faz o trabalho de 
desenvolvimento do incremento do 
produto que foi planejado, buscando 
atingir a Meta da Sprint
Resumo do Ciclo do Scrum
Em cada dia, o Time faz a DAILY SCRUM, uma 
reunião de 15 minutos para promover 
visibilidade e comunicação entre os membros 
do Time
Resumo do Ciclo do Scrum
O que fiz !
O que farei !
Quais foram os 
impedimentos
Ao final do ciclo de desenvolvimento, o 
Time terá produzido um incremento no 
produto pronto, que significa valor para 
o cliente
Resumo do Ciclo do Scrum
DEFINIÇÃO DE 
DONE 
__ ____ ____ 
________ __ 
_____ ___ __
O Time então se reúne com o Product 
Owner e stakeholders na SPRINT 
REVIEW e apresenta o que foi feito na 
Sprint
Resumo do Ciclo do Scrum
E, em seguida, o Time se reúne para a SPRINT 
RETROSPECTIVE, onde verifica o que 
funcionou bem e o que pode melhorar nas 
próximas Sprints
Resumo do Ciclo do Scrum
...e o ciclo recomeça.
Resumo do Ciclo do Scrum
Gerenciamento de Stakeholders
Gerenciamento de Stakeholders
• Essencial para o sucesso do projeto 
!
• Fatores-chave: 
– Correta identificação dos stakeholders 
– Mapeamento dos stakeholders para entender seu 
potencial de ameaça e de cooperação (nível de apoio) 
– Entender as necessidades de cada um dos 
stakeholders 
– Desenvolver e implementar um plano de ação para 
influenciar e conseguir o apoio necessário dos 
stakeholders
adaptado do material de Ian Wilson
Gerenciamento de Stakeholders
• Estratégias e Ações
Baixo Alto
Baixo
Tipo: Marginal 
Estratégia: 
Monitorar
Tipo: Não Apoiador 
Estratégias: 
Defesa ou 
Discordar e se 
Alto
Tipo: Apoiador 
Estratégia: 
Envolver
Tipo: Vantagens e 
Desvantagens 
Estratégia: 
Colaborar
Potencial de Ameaça ao Projeto
Ma
xim
iza
r
Savage et al., 1991
Gerenciamento de Stakeholders
Tipo 1: Stakeholder Apoiador 
!
• Baixo potencial de ameaça ao projeto, alto 
potencial de cooperação 
!
• Estratégia: envolvê-los em decisões relevantes 
para encorajar potencial de cooperação 
– esforço constante 
– aumentar sua participação no processo decisório 
sobre o produto
Savage et al., 1991
Gerenciamento de Stakeholders
Tipo 2: Stakeholder Marginal 
!
• Baixo potencial de ameaça ao projeto, baixo 
potencial de cooperação 
!
• Estratégia: monitorá-los 
– Ao reconhecer que seus interesses são limitados e 
específicos, evita-se desperdício de esforços. 
– Deve-se atuar para aumentar seu apoio ou rechaçar 
sua oposição apenas se as questões envolvidas nas 
decisões parecerem importantes para esses 
stakeholders.
Savage et al., 1991
Tipo 3: Stakeholder Não Apoiador 
!
• Alto potencial de ameaça ao projeto, baixo potencial 
de cooperação 
!
• Estratégias: 
• Defesa: reduzir as dependências que formam a base 
dos interesses do stakeholder no projeto 
• Discordar e se comprometer: mantê-lo satisfeito todo 
o tempo
Savage et al., 1991
Gerenciamento de Stakeholders
Tipo 4: Vantagens e Desvantagens 
!
• Alto potencial de ameaça ao projeto, alto potencial 
de cooperação 
!
• Estratégia: colaborar para maximizar sua 
cooperação, tornando mais difícil possíveis 
oposições 
– Se cooperativo: pode ter forte impacto positivo 
– Se não cooperativo: pode ter impacto negativo 
significativo
Savage et al., 1991
Gerenciamento de Stakeholders
Scrum e o Produto
Visão do Produto
PRODUCT 
ROADMAP
O que é a Visão do Produto?
• “Uma visão é uma imagem clara que evoca um 
atração emocional” – Boris Gloger 
!
• “A visão do produto pinta um quadro do futuro 
que atrai as pessoas” – Roman Pichler 
!
• “Um enunciado de visão do produto ajuda times a 
se manterem focados nos aspectos críticos do 
produto, mesmo quando os detalhes estão 
mudando rapidamente” – Jim Highsmith
• É um objetivo compartilhado, fornecendo contexto e 
orientação para o trabalho do projeto 
!
• Deve ser compreendido por todos os stakeholders do 
projeto, clientes e Time de Scrum – alinhamento 
!
• Estabelecido antes que o desenvolvimento comece e 
deve permanecer relativamente estável durante todo o 
desenvolvimento do projeto 
– Product Backlog deve estar alinhado com a visão 
!
• Criada, gerenciada e compartilhada pelo Product 
Owner
O que é a Visão do Produto?
• Uma visão efetiva do produto deve responder às 
perguntas de uma forma concisa: 
!
1. Quem irá comprar o produto? Quem é o cliente-alvo? 
2. Que necessidades de cliente o produto atenderá? 
3. Que atributos de produto são críticos para satisfazer às 
necessidades selecionadas, e consequentemente para o sucesso 
do produto? 
4. Como o produto compara com relação a produtos existentes, dos 
concorrentes e da mesma companhia? Que são as vantagens 
únicas do produto? 
5. Qual o prazo e orçamento para desenvolver e lançar o produto?
por Roman Pichler
O que é a Visão do Produto?
O que é a Visão do Produto?
• Ninguém pode prever o futuro! 
!
• Assim, não desperdice tempo

construindo uma Visão detalhada! 
!
• Apenas o suficiente para dar 

uma direção! 
!
• Algumas técnicas: Teste do Elevador, Desenhe-
a-Caixa e Remember the Future
Visão do Produto: Teste do Elevador
• Enunciado do Teste do Elevador – habilidade de explicar 
o produto para qualquer pessoa em dois minutos, na 
forma: 
!
– Para (cliente-alvo) 
– Que (enunciado da necessidade ou oportunidade) 
– O (nome do produto) é um (categoria do produto) 
– Que (benefício-chave, razão convincente para comprar) 
– Ao contrário de (alternativa primária que compete) 
– Nosso produto (enunciado de diferenciação primária)
de “Crossing the Chasm”, por Geoffrey Moore
Visão do Produto: Desenhe-a-Caixa
• Participação do Time e de usuários – quebrar em grupos 
de quatro a seis 
!
• Suposição: produto será vendido em uma caixa 
!
• Tarefa: desenhe frente e de trás da caixa 
– Frente: “atrair” 
• Nome do produto 
• Desenho 
• Três a quatro pontos para “vender” o produto 
!
– Trás: “decisão de compra” 
• Descrição detalhada dos atributos do produto 
• Requisitos de operação
por Bill ShakelfordProduct Roadmap
PRODUCT 
ROADMAP
O que é Product Roadmap?
• Plano em alto nível de como o produto poderá evoluir ao 
longo das próximas releases 
!
• Para cada release: 
– Data de release 
– Funcionalidades principais x clientes-alvo 
!
• Ferramenta de comunicação: facilita diálogo entre Time 
Scrum e stakeholders sobre evolução do produto 
!
• Ajuda a organização a coordenar o desenvolvimento e 
release de produtos relacionados
Product Roadmap: Remember the Future
• Reúna seus clientes e entregue a cada um deles 
algumas folhas de papel 
!
• Peça que imaginem que estamos em algum momento no 
futuro e que eles vêm usando o produto continuamente 
entre agora e esse futuro 
!
• Peça que escrevam, com o máximo de

detalhes, exatamente o que o produto

deverá ter feito para fazê-los se sentirem

felizes/bem sucedidos/satisfeitos nesse

futuro 
!
• Isso ajudará a entender a definição de

sucesso dos clientes
por Luke Hohmann, “Innovation Games”
Product Roadmap: Remember the Future
Adaptado para definir o Product Roadmap: 
!
• Peça aos clientes que desenhem uma linha do tempo 
para o produto em um período no futuro (ex. 1 ano) 
!
• Peça que se coloquem, do futuro ao presente, em cada 
um dos pontos no tempo, e escrevam o que o produto 
terá feito para fazê-los se sentirem felizes/bem 
sucedidos/satisfeitos nesse futuro 
!
• Tenha em mente que é um roadmap de expecativa muito 
alta – significado de sucesso para os clientes.
Product Backlog
O que é o Product Backlog?
• Lista de requisitos do produto – itens com desejos de 
negócios do cliente, melhorias no produto, correções de 
bugs, tarefas técnicas etc. 
!
• Meio para se alcançar a visão do produto 
!
• Itens ordenados por prioridade de desenvolvimento 
– itens do alto: < granularidade, > detalhe 
– itens de baixo: > granularidade, < detalhe 
!
• Lista incompleta e dinâmica em constante evolução – 
ambiente evolui e clientes e Time aprendem sobre o 
produto
O que é o Product Backlog?
• Product Owner é o único responsável por gerenciar o 
Product Backlog – atualizar, ordenar e dar visibilidade 
!
• Seus itens possuem descrição e estimativa 
!
• A ordenação é determinada por: valor que gerará ao 
cliente, risco e necessidade
O que é o Product Backlog?
Product Backlog é...
• Ordenado: itens são ordenados de acordo com a 
prioridade de sua implementação – de forma a maximizar 
o ROI do cliente 
!
• Estimável: julgar e formar uma opinião sobre o tamanho 
do Product Backlog ou de uma parte relevante dele (ex. 
próxima Sprint ou Release) 
!
• Emergente: incompleto, dinâmico, em constante 
evolução – mudança no ambiente e no produto 
!
• Gradualmente refinado: de acordo com a ordenação
Product Backlog é Ordenado
Sprint
Release
Futuras Releases
Desenvolvidos 
mais cedo
• Técnicas para ordenar 
!
• Análise Kano 
!
• Theme Screening 
!
• Relative Weighting 
!
• Buy a Feature
Product Backlog é Ordenado
Ordenando: Análise Kano
• Tipos de funcionalidades: 
!
• Funcionalidades de Entusiasmo – usuário não 
sabe que as quer até vê-las 
!
• Funcionalidades de Performance / Lineares – 
quanto mais, melhor 
!
• Funcionalidades Obrigatórias / Básicas – 
devem estar presentes para satisfazer os 
usuários
por Prof. Noriaki Kano (1984), Tokio Rika University
Ordenando: Análise Kano
Entrevistando Usuários 
!
• Verifica tipo da funcionalidade entrevistando um 
pequeno grupo de usuários (uns 20-30) 
!
• Duas perguntas devem ser perguntadas: 
!
– Funcional: “como você se sentirá se a funcionalidade 
estiver presente?” 
!
– Disfunc iona l : “ como você se sen te se a 
funcionalidade estiver ausente?” 
Entrevistando Usuários 
!
• Pergunta funcional:
“Se a loja online aceitar PayPal, como 
você se sentirá?”
[X] Gosto dessa forma
[ ] Espero que seja assim
[ ] Sou neutro
[ ] Posso viver dessa forma
[ ] Não gosto dessa forma
Ordenando: Análise Kano
Entrevistando Usuários 
!
• Pergunta disfuncional:
“Se a loja online não aceitar PayPal, 
como você se sentirá?”
[ ] Gosto dessa forma
[ ] Espero que seja assim
[ ] Sou neutro
[X] Posso viver dessa forma
[ ] Não gosto dessa forma
Ordenando: Análise Kano
Tabela de Avaliação Kano
O Obrigatório Q Questionável 
L Linear R Contrário 
E Entusiasmo I Indiferente
Ordenando: Análise Kano
O Obrigatório Q Questionável 
L Linear R Reverso 
E Entusiasmo I Indiferente
“Usar PayPal para pagamento” tipo de funcionalidade para esse usuário: Entusiasmo
Tabela de Avaliação Kano
Ordenando: Análise Kano
Resultados possíveis da Tabela de 
Avaliação Kano 
!
• Funcionalidade de Entusiasmo 
• Funcionalidade de Performance / Linear 
• Funcionalidade Obrigatória/ Básica 
• Questionável – resultados não confiáveis 
• Reverso – usuário não quer essa funcionalidade 
(outros podem querer!) 
• Indiferente – usuário não se importa cm essa 
funcionalidade
Ordenando: Análise Kano
Exemplos Includir: 1. Obrigatórios: todos 
2. Lineares: o máximo possível 
3. Empolgantes: algumas
Ordenando: Análise Kano
Ordenando: Theme Screening
• Identifique alguns critérios sobre o que é 
importante para o próximo release 
!
• Selecione um tema de referência 
– Mais provável de ser incluído na próxima release 
– Bem compreendido por membros do Time 
!
• Verificar cada tema candidato com relação ao 
tema de referência 
– +: significa melhor que a referência 
– –: significa pior que a referência 
– 0: significa o mesmo que a referência
Adaptado de uma 
apresentação de Mike Cohn
Ordenando: Theme Screening
Veja Theme Scoring para uma alternativa mais elaborada
Exemplo:
• Valor relativo do item 
– Benefício relativo de fazer o item – para cada item do backlog, 
pontue de 1-9 o impacto relativo de ter o item 
– Penalidade relativa por não fazer o item – para cada item do 
backlog, pontue de 1-9 o impacto relativo por NÃO ter o item 
– Benefício relativo + penalidade relativa = valor relativo do item 
!
• Custo relativo do item 
– Avalie o custo de cada item em story points ou outra unidade 
relativa = Custo relativo do item 
!
• Ordem = (Valor Relativo / Custo Relativo) 
– ordene pela “ordem”
Ordenando: Peso Relativo
1. Crie uma lista de funcionalidades

potenciais (itens) 
!
2. Determine um preço para cada item 
– custo de desenvolvimento, valor para o cliente etc. 
(geralmente não é o custo real) 
– Alguns itens devem ter preço alto suficiente para que 
ninguém possa comprá-las individualmente 
!
3. Junte de quatro a 7 clientes e/ou stakehoders e 
lhes dê “notas de dinheiro”
por Luke Hohmann, “Innovation Games”
Ordenando: Buy a Feature
4. Participantes compra os itens para o próximo 
release do produto 
!
5. Encorage os participantes a juntar seu dinheiro 
para comprar itens importantes e/ou caros – 
motivar negociação 
!
6. Os itens comprados são os escolhidos para a 
próxima realease
por Luke Hohmann, “Innovation Games”
Ordenando: Buy a Feature
Product Backlog é Estimável
• Estimar ajuda o Time a conhecer sua 
velocidade e ser capaz de se compromenter com 
itens de acordo 
!
• Estimar ajuda o Product Owner a criar o Plano de 
Release, baseado na velocidade do Time 
!
• Estimar ajuda a medir o progresso em uma 
release usando o Release Burndown 
!
• Estimativas feitas pelo Time!
Product Backlog é Estimável
• Acurácia é mais importante que precisão!
Estimando o Product Backlog
• Story Points 
!
– Unidade de medida para determinar o tamanho do 
item do Product Backlog (geralmente User Stories) 
!
– Story points significam o tamanho do esforço relativo 
necessário para desenvolver o item!
– É uma medida relativa (entre os itens) 
!
– Fibonacci: 0, 1, 2, 3, 5, 8, 13, 21, 34...

(ou, adaptado: 0, 1, 2, 3, 5, 8, 13, 20, 40...)
13
Estimando o Product Backlog
• Uma das técnicas para realizar a estimativa do Product 
Backlog é o PLANNING POKER
1 2 3 5
8 13 2140
• Inicialmente, o Time escolhe o item de menor esforço e atribui o 
tamanho de 2 
!
• O Time escolhe um item e joga o Planning Poker para estimá-lo, 
tendo como base o item de tamanho 2 
!
• O Time escolhe mais um item e joga o Planning Poker para estimá-
lo, tendo como base os itens já estimados - triangulação
STORY POINTS
Estimando o Product Backlog
Jogando o PLANNING POKER
2
5
13
5
• Para um item, todos os membros do Time 
escolhem uma estimativa nas cartas – não 
mostrar até que todos tenham escolhido !
• Todos mostram as cartas ao mesmo tempo !
• Os membros com a maior e a menor estimativa 
devem justificar !
• Jogam-se novamente as cartas, até o consenso 
– ScrumMaster facilita!
Estimando o Product Backlog
• T-Shirt Sizing
P M G
GG
Definição de Pronto
• Ao final da Sprint, o trabalho desenvolvido deve estar 
pronto 
!
• Mas o que significa “pronto”? 
!
• O Time e o Product Owner devem definir o que significa 
pronto 
!
• Quando alguém diz que algo está pronto, todos devem 
entender o que isso significa 
!
• Ex. de software: codificado, testado e documentado
Product Backlog Grooming
• Product Backlog necessita atenção e cuidados constantes 
!
• Grooming é um processo que assegura que o Product 
Backlog seja Ordenado, Estimável, Emergente e 
Gradualmente Refinado 
– pré-requisito para uma Sprint Planning bem-sucedida 
!
• Feito colaborativamente pelo Product Owner e pelo Time 
(Time geralmente dedica 10% de seu tempo) 
!
• Cada Time Scrum tem seu próprio processo de grooming: 
sessões diárias curtas, sessões semanais, workshop etc.
por Roman Pichler
Product Backlog Grooming
Passos para Grooming: 
!
• Descobrir e descrever novos itens; modificar ou remover os 
existentes 
!
• Ordenar – alto: mais importente à baixo: menos importente; 
quais itens na próxima release, ordem de implementação 
!
• Itens de alta prioridade preparados (DoR): decompostos e 
refinados; claros: entendimento comum; factíveis: pequenos o 
suficiente para a sprint; testáveis: podem ser validados 
!
• Time estima novos itens e corrige os antigos
por Roman Pichler
Definição de Preparado (ready, DoR)
• Preparado = item do Product Backlog está disponível e 
preparado para discussão pelo Product Owner na Sprint 
Planning 
!
• DoR descreve um estado em que os itens do Product 
Backlog devem estar para estarem qualificados para 
discussão na Sprint Planning 
!
• Objetivo claro para o Time, previne “estragar” a Sprint 
!
• O quê, Como, estimado, pequeno o suficiente
por Jeff Sutherland / Serge Beaumont
User Stories
Quem?
O quê?
Por quê?
Eu, enquanto <PERSONA>, 
eu posso/gostaria/devo 
<FUNCIONALIDADE> para/
tal que <VALOR>
Eu, enquanto COMPRADOR 
DE LIVROS, eu posso 
PESQUISAR LIVROS para 
que EU ESCOLHA O QUE 
VOU COMPRAR
User Stories
CARD 
(cartão)
CONVERSATION 
(conversas)
CONFIRMATION 
(confirmação)
Descrição da story 
s u f i c i e n t e p a r a 
identificar o requisito e 
para lembrar do que 
se trata a story
Conversas sobre a 
story, por onde de fato 
o r e q u i s i t o é 
comunicado do cliente 
aos programadores Testes que documentam 
os detalhes da story e 
podem ser usados para 
determinar quando ela 
está completa
User Stories: os três C’s
Independent
Negotiable
Valuable
Estimable
Small
Testable
Independente das 
outras stories
Negociável, detalhes 
serão negociados
Valiosa para o cliente
Estimável pelos 
desenvolvedores
Pequena em esforço 
de implementação
Testável para permitir 
a confirmação
Uma 
User 
Story 
deve 
ser:
User Stories: INVEST
ÉPICO
STORY
STORY
STORY
STORY
STORY
STORY
TEMA
STORY STORY
STORY
STORY STORY
STORY STORY STORY
User Stories: Stories, Temas e Epics
Como um usuário,eu posso exportar 
dados em XML para poder integrar 
minhas informações com outros 
sistemas 
•Abrir no Excel o arquivo XML 
exportado 
•Confrontar campo a campo com o 
modelo estabelecido
Testes de Aceitação 
!
•Servem para verificar que as user 
stories implementadas funcionam como 
o cliente pediu 
!
•São escritos pelo cliente, antes da 
codificação, com a ajuda dos 
desenvolvedores
3 C’s:
 Conf
irmaç
ão
User Stories: Testes de Aceitação
• Reunião que inclui desenvolvedores, usuários, cliente e 
qualquer pessoa que possa contribuir na descoberta 
de stories 
!
• Os part ic ipantes escrevem quantas stories 
conseguirem, sem se preocupar com priorização 
!
• Uso de brainstorming e prototipação rápida, de baixa 
fidelidade
User Stories: Story-Writing Workshop
• Product Owner escreve os critérios de aceitação para 
cada item desejado antes da Sprint Planning 
!
• Durante a Sprint Planning, os critérios de aceitação são 
discutidos e negociados com o Time 
!
• Enunciados pequenos e 

fáceis de se entender 
!
• Definem os limites para um item
Adaptado de um artigo de Sandy Mamoli
Critérios de Aceitação
• Ajudam o P.O. a responder o que ele precisa para que 
essa funcionalidade propicie valor 
!
• Ajuda o Time a ganhar uma compreensão compartilhada 
sobre a Story/funcionalidade 
!
• Ajudam programadores/testers a gerar os testes 
!
• Ajudam programadores a saber quando devem parar de 
adicionar mais funcionalidades a uma story
Critérios de Aceitação
Adaptado de um artigo de Sandy Mamoli
• Exemplo: “como um aluno, quero me registrar 
online, para não me deslocar ou enfrentar filas” 
!
– Os campos obrigatórios do formulário devem estar 
claramente indicados 
!
– Caso o usuário submeta o formulário sem completar 
todos os campos obrigatórios, esses campos devem 
ser indicados e o formulário não é submetido 
!
– Um email de confirmação deve ser enviado após 
submeter o formulário
Critérios de Aceitação
Gestão de Releases
O que é uma Release?
• É a entrega para o cliente de um incremento no produto 
!
• Deve ser decidida pelo Product Owner, de acordo com as 
necessidades do cliente 
!
• A Release só pode ser feita quando incrementos no produto 
suficientes tiverem sido feitos para gerar valor para o cliente
Sprint 1 Sprint 2 Sprint 3 Sprint 4
Release 1
Sprint 5 Sprint 6
Release 2…
Sprint 7 Sprint 8
Reunião de Release Planning
• Reunião (não obrigatória) realizada para cada 
release para criar o Plano de Release: 
!
– Meta da Release: caminho para a Visão do Produto 
– data da entrega 
– Itens ordenados do Product Backlog que, a princípio, 
serão entregues nas Sprints da Release 
• Não é um compromisso !
• Veja que itens cabem na Release usando o número calculado 
de Sprints, estimativas não refinadas do Time para os itens e 
a velocidade do Time !
• Geralmente, distribua os itens apenas pelas duas primeiras 
Sprints
Traçando o Release Burndown
• Release Burndown é um gráfico que mostra a soma dos 
pontos de esforços estimados restantes dos itens da 
Release pelo tempo 
!
– Y: pontos de esforços estimados restantes 
– X: iterações (Sprints) 
!
• Serve para acompanhar o progresso em direção a uma 
entrega 
!
• É feito inicialmente no Release Planning Meeting e deve 
ser atualizado no final de cada Sprint
Traçando o Release Burndown
Scrum Alliance
http://www.scrumalliance.org
Scrum Alliance
Certificações da Scrum Alliance