Backlog

Workshop SCRUM
Como
criar,
estimar,
priorizar e
manter o
Product
Backlog
www.etcnologia.com.br
Rildo F Santos
(11) 9123-5358
(11) 9962-4260
rildo.santos@etecnologia.com.br
twitter: @rildosan
skype: rildo.f.santos
http://rildosan.blogspot.com/
Verso 1 Ago 2010 | RFS
Todos os direitos reservados e protegidos 2006 e 2010
O Contedo do workshop:
Workshop SCRUM
1
Criar
2
Estimar
3
Priorizar
4
Manter
1 Como Criar o Product Backlog

2 Como Estimar o Product Backlog
3 Como Priorizar o Product Backlog
4 Como Manter o Product Backlog
Workshop SCRUM
Objetivo:
Objetivo:
Compartilhar conhecimento, trocar experincia e prover aprendizado de Como criar,
estimar, priorizar e manter o Product Backlog utilizando as melhores prticas, tcnicas e
ferramentas.
Pr-requisito:
Conhecimento do Scrum. Se voc no conhece o Scrum recomendamos fazer o Workshop
SCRUM (http://etecnologia.ning.com/group/scrum ) primeiro e depois esse treinamento.
Workshop SCRUM
Programa: Menos Papel, Mais rvores
Qual o mundo que queremos ?

O primeiro passo para criar um mundo melhor, saber qual tipo de mundo que queremos
ter e qual tipo que deixaremos de herana para as prximas geraes.
Nossa misso: buscar pelo equilibro do homem, da tecnologia e do meio ambiente.
Para cumprir esta misso necessrio: conscientizar, comprometer e AGIR.
O programa Menos Papel, Mais rvores, uma ao, com objetivo de

estimular o consumo sustentvel de papel dentro das organizaes.
Quer participar ?
- Reduza o uso de papel (e de madeira) o mximo possvel.
- S imprima se for extremamente necessrio.
- Evite comprar produtos com excesso de embalagem.
- Ao imprimir ou escrever, utilize os dois lados do papel.
- Use papel reciclado.
Este material no deve ser impresso..
Facilitador: Rildo F. Santos (@rildosan)

Coach , Instrutor, Consultor e Palestrante de Mtodos geis, Gesto de Negcios, Inovao , Processos e
Tecnologia .
Minha Experincia:
Tenho mais de 10.000 horas de experincia em Gesto de Negcios, Gesto de Inovao, Governana e Engenharia de
Software. Sou formado em Administrao de Empresas, Ps-Graduado em Didtica do Ensino Superior e Mestre em
Engenharia de Software pela Universidade Mackenzie.
Workshop SCRUM
Fui instrutor de Tecnologia de Orientao a Objetos, UML e Linguagem Java (Sun MicroSystems e IBM).
Conheo Mtodos geis (SCRUM, XP, FDD, Lean e OpenUP), Arquitetura de Software, SOA (Arquitetura Orientado a
Servio), Processo Unificado, Business Intelligence, Gesto de Risco de TI entre outras tecnologias.
Sou professor de curso de MBA da Fiap e fui professor de ps-graduao da Fasp e IBTA.
Tenho conhecimento de Gesto de Negcio (Inteligncia de Negcio, Gesto por Processo, Inovao, Gesto de Projetos e
GRC - Governance, Risk ando Compliance), SOX, Basel II e PCI;
Experincia na implementao de Governana de TI e Gerenciamento de Servios de TI. Fluncia nos principais frameworks
e padres: ITIL, Cobit, ISO 20000, ISO 27001 e ISO 15999;
Participei de diversos projetos nos segmentos: Financeiro, Telecomunicaes, Seguro, Sade, Comunicao, Segurana
Pblica, Fazenda, Tecnologia, Varejo, Distribuio, Energia e Petrleo e Gs.
Possuo as certificaes: CSM - Certified SCRUM Master, CSPO - Certified SCRUM Product Owner , SUN Java Certified
Instrutor, ITIL Foundation e sou Instrutor Oficial de Cobit Foundation e Cobit Games;
Sou membro do IIBA-International Institute of Business Analysis (Canada)
Onde estou:
Twitter: @rildosan
Blog: http://rildosan.blogspot.com/
Comunidade: http://etecnologia.ning.com
Contedo do Workshop:
Workshop SCRUM
1
Criar
2
Estimar
3
Priorizar
4
Manter

Workshop SCRUM
Objetivo:
Objetivo dessa parte:

Apresentar e discutir como Criar o Product Backlog.
Pr-requisito:
SCRUM (http://etecnologia.ning.com/group/scrum ) primeiro e depois esse treinamento.
Workshop SCRUM
Parte 1:
Como Criar o Product Backlog

Framework SCRUM:
O Framework Scrum composto por uma Equipe (Time) Scrum e seus papis: Product Owner
(PO), Scrum Master (SM) e Equipe de desenvolvedores, Eventos com durao fixa (Time-Boxes),
Artefatos e Regras.
Workshop SCRUM
Planejamento
da Release
O foco
desse
workshop
Reunio
diria
Planejamento
da Sprint
Reviso
da Sprint
Retrospectiva
da Sprint
24 horas
Product
Backlog
Sprint
Backlog
Produto
Sprint
(2-4 Semanas)
Viso
Legenda:
Reunies
Artefatos
Eventos (Reunies)
Artefatos
Papis
Product Owner (PO)
ScrumMaster (SM)
Equipe (time)
Planejamento da Release
Planejamento da Sprint
Diria
Reviso da Sprint
Retrospectiva da Sprint
Product Backlog
Sprint Backlog
Sprint Burndown
Release Burndown
Sprint Burndown
Release Burndown
Framework Scrum: As Regras
Workshop SCRUM
As Regras fazem o elo entre os eventos com durao fixa (time-boxes), os papis e os
artefatos do Scrum. Veja as regras aplicadas ao Product Backlog e ao Product Owner:
Regras:
- Somente o PO (Product Owner) definir e alterar a prioridade dos itens do Product Backlog.
- O Product Owner a nica pessoa responsvel pelo gerenciamento do Product Backlog e
por garantir o valor do trabalho realizado pelo Time.
- Essa pessoa mantm o Product Backlog e garante que ele est visvel para todos. Todos
sabem quais itens tm a maior prioridade, de forma que todos sabem em que se ir trabalhar.
10
Workshop SCRUM
Framework Scrum: Product Owner (PO)

O Product Owner (PO) a nica pessoa responsvel pelo gerenciamento do
Product Backlog e por garantir o valor do trabalho realizado pela Equipe.
O PO mantm o Product Backlog (PB) e assegura que ele est visvel para todos.
Todos sabem quais itens tm a maior prioridade, de forma que todos sabem em que
se ir trabalhar.
O Product Owner deve ser uma pessoa, e no um comit. Podem existir comits
que aconselhem ou influenciem , mas somente o PO poder mudar a prioridade de
um item do PB. Empresas que adotam Scrum podem perceber que isso influencia
seus mtodos para definir prioridades e requisitos ao longo do tempo.
Para que o PO obtenha sucesso, todos na organizao precisam respeitar suas
decises. Somente o PO pode definir a prioridade dos itens que a equipe ir trabalhar.
As decises do Product Owner so visveis no contedo e na priorizao do Product
Backlog. Essa visibilidade requer que o Product Owner faa seu melhor, o que faz o
papel de Product Owner exigente e recompensador ao mesmo tempo.
Product Backlog e as responsabilidades do PO: Criar , Priorizar e Manter o Product
Backlog.
Somente detalhamos papel do Product Onwer, pois, ele responsvel direto pelo
Product Backlog.
O ScrumMaster, que responsvel por garantir que o processo (as prticas do SCRUM) seja compreendido e
seguido. responsvel ainda por:
- Remover impedimentos;
- Proteger a equipe;
- Ajudar o PO (quando necessrio);
- Ser o facilitador da equipe.
A equipe (ou time), responsvel pelo desenvolvimento do produto, formada por desenvolvedores que devem ter as
habilidades necessrias para transformar os itens do Product Backlog em Produto. A Equipe ainda responsvel por:
- Fazer estimativa;
- Definir as tarefas;
- Garantir a qualidade do produto;
- Apresentar o produto ao cliente
11
Workshop SCRUM
Framework Scrum: Artefatos
Scrum tem quatro artefatos principais:

- Product Backlog: uma lista priorizada de tudo que pode ser necessrio no produto.
- Release Burndown: Mede o Product Backlog restante ao longo do tempo de um Plano de
Release do Produto.
- Sprint Backlog: uma lista de tarefas para transformar o Product Backlog , por uma Sprint, em
um incremento do produto potencialmente entregvel. Um burndown uma medida do
backlog restante pelo tempo.
- Sprint Burndown: Mede os itens da Sprint Backlog restantes ao longo do tempo de uma Sprint.
Nessa aula ser discutido os artefatos: Product Backlog (PB) e Release Burndown. Mas, nosso foco
primrio o Product Backlog.
12
Questes sobre o Product Backlog:
Workshop SCRUM
O que o Product Backlog ?

Product Backlog: uma lista priorizada de tudo que pode ser necessrio no produto.
O Product Backlog representa tudo que necessrio para desenvolver e lanar um produto de
sucesso. uma lista de todas as caractersticas, funes, tecnologias, melhorias e correes de
defeitos que constituem as mudanas que sero efetuadas no produto para releases futuras. Os
itens do Product Backlog possuem os atributos de descrio, prioridade e estimativa. A prioridade
determinada por risco, valor e necessidade. H diversas tcnicas para dar valor a esses atributos
(veremos isso mais tarde).
Quem responsvel pelo Product Backlog ?
O Product Owner (PO) o responsvel pelo Product Backlog , por sua criao, por seu contedo, por
sua disponibilidade e por sua priorizao.
At quando o Product Backlog existir ?
O Product Backlog nunca est completo. A seleo inicial para o seu desenvolvimento somente
mostra os requisitos inicialmente conhecidos e melhor entendidos. O Product Backlog evolui medida
que o produto e o ambiente em que ele ser usado evoluem. O Backlog dinmico, no sentido de
que ele est constantemente mudando para identificar o que o produto necessita para ser
apropriado, competitivo e til. Enquanto existir um produto, o Product Backlog tambm existir.
Resumo: O clico de vida do Product Backlog est ligado ao ciclo de vida do Produto
Qual a ordenao do Product Backlog ?
O Product Backlog ordenado por prioridade, os itens com as maiores prioridades devem ter o
desenvolvimento imediato.
Quanto mais alta sua prioridade, mais urgente ele , mais se pensou sobre ele e h mais
consenso no que diz respeito ao seu valor. Os itens do Backlog de maior prioridade, possuem mais
informaes e detalhes do que os itens do Backlog de menor prioridade. mais fcil de fazer a
estimativa quando existem mais informaes e mais detalhes.
13
Questes sobre o Product Backlog:
Workshop SCRUM
Por que o Product Backlog pode mudar ?
Porque quando um produto utilizado, e seu valor aumenta e o cliente pode fornecer feedback, o
Product Backlog poder se tornar uma lista maior e mais aprofundada. Os requisitos geralmente
mudam (alguns com maior frenquncia e outros com menor frequncia). O Product Backlog um
documento vivo. Mudanas nos requisitos de negcios, condies do mercado, tecnologia e
equipe causam mudanas no Product Backlog. Para reduzir o retrabalho, apenas os itens de
maior prioridade precisam ser mais detalhados. Os itens do Product Backlog que ocuparo a
Equipe Scrum pelas vrias Sprints seguintes devero ter granularidade mais fina (mais detalhados),
tendo sido decompostos de forma tal que cada um dos itens possa ser feito dentro da durao da
Sprint.
Quando existe diversas equipes trabalhando para construir um produto quantos Product
Backlog devemos ter ?
Se mltiplas equipes trabalham juntas no mesmo produto, devemos ter um nico Product Backlog
usado para descrever o trabalho a ser realizado no produto.
Como agrupar os itens do Product Backlog ?
O agrupamento pode ocorrer por conjuntos de caractersticas, por tecnologia ou por arquitetura,
e ele frequentemente utilizado como uma forma de se organizar o trabalho por equipe.
14
Como criar o Product Backlog:

Para definir a viso do Produto, primeiro necessrio entender qual a real necessidade do cliente:
Workshop SCRUM
A necessidade:
Um hotel, quer incrementar um novo canal de consultas e vendas de reservas de
apartamentos. A sugesto foi criar um Portal de Reservas para vender os servios.
Aps entender a necessidade do cliente, hora de definir a Viso do Produto:

Declarao da Viso do Produto:
Para o Hotel que necessita de um Sistema o Portal de Reservas On-Line um

software baseado na web, intuitivo e fcil de usar que fornece a possibilidade fazer a
consultas e reservas de apartamentos.
Diferente de outros sistemas, o produto oferece um canal direto de acesso ao cliente.
15
Definindo a Viso do Produto:

Introduo:
Qualquer produto est necessariamente associada a uma viso, pois, a viso deve descrever o o
produto em relao a necessidade do usurio (cliente).
A viso do produto somente ser significativa se apresentada e compartilhada pela equipe SCRUM.
Workshop SCRUM
A definio da viso do produto uma responsabilidade Product Owner. Mas, ele poder
desenvolver a viso do produto em colaborao com a equipe de desenvolvimento de software e o
cliente final
A Declarao da Viso do Produto:

A declarao de Viso do Produto deve ser simples,
consistente, objetiva e fcil entendimento, que tem
informaes sobre a necessidade do cliente, o que
produto esperado e quais sos os seus principais
benefcios.
A declarao ainda deve descrever a motivao e o
diferencial do produto em relao aos outros.
Apresentaremos duas tcnicas:

- A Declarao do Elevador (que tambm pode ser
chamada de Viso Sinttica)
- Product Vision Box.
16

Declarao do Elevador ou Viso sinttica" (essencial)
Segundo Moore (1991). tambm chamada Elevator Pitch, mas podemos chamar "viso sinttica.
A viso sinttica estruturado em 6 partes que resumem em menos de dois minutos a Viso do Produto.
Workshop SCRUM
Primeira Tcnica: Declarao do Elevador (Elevator Statement)

For (target customer)
Who (statement of the need or opportunity)
The (product name) is a (product category)
That (key benefit, compelling reason to buy)
Unlike (primary competitive alternative)
Our product (statement of primary differentiation)
O nome desta tcnica uma

aluso ao seguinte desafio: voc
tem que influenciar ou passar um
mensagem para um pessoa em
curto espao de tempo uma
viagem de elevador.
Com o tempo curto a mensagem
tem que ser objetiva e clara.
Exemplo de Viso do Produto utilizando a Declarao do Elevador:

Para empresas mdias de marketing e departamento de vendas que necessitam de um sistema de
CRM, o EeaseCRM um software baseado na web, intuitivo e fcil de usar que fornece a
possibilidade fazer a rastreabilidade de vendas, gerao de leads e possibilita o estreitamento do
relacionamento com o cliente.
Diferente de outros servios ou produtos, nosso produto oferece a melhor relao custo beneficio.
Product Owner
Product Owner (PO), responsvel por definir, manter e comunicar a

Viso do Produto para todos os stakeholders.
A equipe pode colaborar com o desenvolvimento da Viso do Produto.
17

Viso do Produto:
Segunda Tcnica: Product Vision Box
Workshop SCRUM
Segundo Highsmith (2004). O Produto Vision Box uma tcnica altamente relevantes para iniciar um
projeto para construir a viso e compartilh-lo com a equipe responsvel pelo desenvolvimento do
produto.
O resultado de um projeto de desenvolvimento de software produto. O produto pode ser representado
por uma caixa (a caixa do produto).
Product Vision Box uma tcnica que ajuda no entendimento da Viso do Produto, pois, quando
fazemos uma representao visual do produto (embalagem, por exemplo) isto auxilia na reduo do
nvel de abstrao (ou seja, melhora o entendimento do que ser feito).
A caixa final, construda coletivamente, com base no que precede, no

consenso e colaborao. Esta "Viso da Caixa do produto" a viso
compartilhada, e ir incorporar os seguintes elementos:
Parte da frente da caixa: Nome - Imagem (se possvel) - diviso argumentos que ajudam a vender o produto
Parte de trs da caixa: Colocar de forma mais detalhada as principais
funcionalidade, os pr-requisitos e etc...
Este exerccio ajuda a melhorar o entendimento, identificar possveis
conflitos e reduz a abstrao. O formato desse exerccio exige que os
as pessoas tenham uma participao intensa e as vezes at exaustiva.
Mas, a viso da caixa do produto definida sempre em consenso.
18

Viso do Produto:
Exemplo: Product Vision Box
Informaes sobre o produto:
Workshop SCRUM
- Nome do Produto:
- Logotipo ou desenho que
represente o produto
- Principais benefcios que ajuda a
vender o produto
- Principais caractersticas e/ou
funcionalidades do produto
- Principais requisitos tcnicos
http://www.qualitystreet.fr/2009/07/29/la-vision-du-produit/
Product Owner
Product Owner (PO), pode utilizar esta tcnica para exercitar o

desenvolvimento da viso do produto junto com a equipe.
Fonte:
Agile Project Management: Creating Innovative Products - Jim Highsmith
Cap. 5 - Practice: Product Vision Box and Elevator Test - Pg. 93
19
Como criar o Product Backlog
Workshop SCRUM
Aps a definio da Viso do Produto, devemos definir a primeira verso do Product Backlog:
agrupamento
Funcionalidades do produto
O Product Backlog, inicialmente uma lista que representa tudo que necessrio para desenvolver e
lanar um produto. A lista deve conter todas as caractersticas, funes, tecnologias, melhorias e
correes de defeitos que constituem as mudanas que sero efetuadas no produto para futuras
releases . O Product Backlog dinmico, no sentido de que ele est constantemente mudando
para identificar o que o produto necessita.
20
Workshop SCRUM
Estudo de Caso: Viso do Produto
21
Workshop SCRUM
1
Criar
2
Estimar
3
Priorizar
4
Manter

22
Workshop SCRUM
Objetivo:

Apresentar e discutir como Estimar o Product Backlog.
Pr-requisito:
SCRUM (http://etecnologia.ning.com/group/scrum) primeiro e depois esse treinamento.
23
Workshop SCRUM
Parte 2:
Como Estimar o Product Backlog

24
Framework SCRUM:
Artefatos e Regras.
Workshop SCRUM
Planejamento
da Release
O foco
desse
workshop
Reunio
diria
Planejamento
da Sprint
Reviso
da Sprint
Retrospectiva
da Sprint
24 horas
Product
Backlog
Sprint
Backlog
Produto
Sprint
(2-4 Semanas)
Viso
Legenda:
Reunies
Artefatos
Eventos (Reunies)
Artefatos
Papis
Product Owner (PO)
ScrumMaster (SM)
Equipe (time)
Diria
Reviso da Sprint
Product Backlog
Sprint Backlog
Sprint Burndown
Release Burndown
Sprint Burndown
Release Burndown
25
Introduo, a Reunio de Planejamento da Release:

Na reunio de Planejamento da Release o Product Backlog estimado e priorizado.
O PO responsvel por priorizar os itens do Product Backlog (isto ser visto na prxima aula). A equipe
responsvel por estimar os itens do Product Backlog.
Workshop SCRUM
Planejamento
da Release
Planejamento
da Sprint
Reunio
diria
Reviso
da Sprint
Retrospectiva
da Sprint
24 horas
Produto
Backlog
Sprint
Backlog
Sprint
2-4 Semanas
Produto
Viso
26
Equipe (Responsvel por fazer a estimativa):
Workshop SCRUM
A equipe (ou time), responsvel pelo desenvolvimento do produto, formada por

desenvolvedores que devem ter as habilidades necessrias para transformar os itens
do Product Backlog em Produto. A Equipe ainda responsvel por:
- Fazer estimativa;
- Definir as tarefas;
- Garantir a qualidade do produto;
- Apresentar o produto ao cliente
Destacamos: a tarefa Fazer Estimativa que uma responsabilidade da equipe (time)
O Product Owner (PO) a nica pessoa responsvel pelo gerenciamento do Product Backlog e
por garantir o valor do trabalho realizado pela Equipe.
O PO mantm o Product Backlog (PB) e assegura que ele est visvel para todos. Todos sabem
quais itens tm a maior prioridade, de forma que todos sabem em que se ir trabalhar.
O Product Owner deve ser uma pessoa, e no um comit. Podem existir comits que aconselhem
ou influenciem , mas somente o PO poder mudar a prioridade de um item do PB. Empresas que
adotam Scrum podem perceber que isso influencia seus mtodos para definir prioridades e requisitos
ao longo do tempo.
Para que o PO obtenha sucesso, todos na organizao precisam respeitar suas decises.
Somente o PO pode definir a prioridade dos itens que a equipe ir trabalhar.
As decises do Product Owner so visveis no contedo e na priorizao do Product Backlog. Essa
visibilidade requer que o Product Owner faa seu melhor, o que faz o papel de Product Owner
exigente e recompensador ao mesmo tempo.
Product Backlog e as responsabilidades do PO: Criar , Priorizar e Manter o Product Backlog.
O ScrumMaster, que responsvel por garantir que o processo (as prticas do SCRUM) seja compreendido e
seguido. responsvel ainda por:
- Remover impedimentos;
- Proteger a equipe;
- Ajudar o PO (quando necessrio);
- Ser o facilitador da equipe.
27
Verso inicial do Product Backlog:
Workshop SCRUM
Aps a definio da Viso do Produto, devemos definir a primeira verso do Product Backlog,
note que ele no foi estimado nem priorizado.
agrupamento
28
Reunio de Planejamento da Release:
Workshop SCRUM
A estimativa e a priorizao devem ser feitas na Reunio de Planejamento da Release.

O propsito do planejamento da release o de estabelecer um plano e
metas que a Equipe Scrum e o resto da organizao possam entender e
comunicar.
O planejamento da release responde s questes:
- Como podemos transformar a viso em um produto da melhor maneira
possvel?
- Como podemos alcanar ou exceder a satisfao do cliente ?
- Como podemos alcanar o ROI (retorno sobre investimento) ?
O Plano da Release estabelece a meta da release, as maiores
prioridades do Product Backlog, os principais riscos e as caractersticas
gerais e funcionalidades que estaro contidas na release.
Ele estabelece tambm uma data de entrega e custo provveis que
devem se manter se nada mudar. A organizao pode ento inspecionar
o progresso e fazer mudanas nesse plano da release a cada Sprint.
Contudo, O planejamento da release inteiramente opcional. Se uma

Equipe Scrum iniciar o trabalho sem essa reunio, a ausncia de seus
artefatos
aparecer como um impedimento que dever ser resolvido.
O trabalho para resolver o impedimento se tornar um item no Product
Backlog.
Ao se utilizar Scrum, os produtos so construdos iterativamente, de
modo que cada Sprint cria um incremento do produto, iniciando pelo de
maior valor e maior risco. Mais e mais Sprints vo adicionando
incrementos ao produto.
29
Reunio de Planejamento da Release:

Workshop SCRUM
Cada incremento um pedao potencialmente entregvel do produto

completo. Quando j tiverem sido criados incrementos suficientes
para que o produto tenha valor e uso para seus investidores, o produto
entregue
Muitas organizaes j tem um processo de Planejamento de
Release, e na maior parte desses processos o planejamento feito no
incio do trabalho da release e no modificado com o passar do
tempo.
No Planejamento de Release do Scrum, so definidos uma meta geral e
resultados provveis. Esse planejamento geralmente no requer mais do que
15-20% do tempo que uma organizao costumava utilizar para produzir um
plano de release tradicional. No entanto, uma release com Scrum realiza
planejamento no momento da execuo de cada reunio de Reviso de
Sprint e de Planejamento de Sprint, da mesma forma que realiza um
planejamento dirio no momento da execuo de cada Reunio Diria.
De forma geral, os esforos para uma release com Scrum provavelmente
consomem ligeiramente mais esforo do que os esforos para um
planejamento de release tradicional.
O planejamento da release requer estimar e priorizar o Product Backlog
para a release. Existem diversas tcnicas para faz-lo, mas o SCRUM um
framework, no indica nenhuma tcnica.
Contudo, nessa aula abordaremos algumas tcnicas para estimar o Product
Backlog
30
Viso Geral da Reunio de Planejamento da Release:

Sadas
Entradas
Release
Burndown
(artefato)
Workshop SCRUM
Viso do Produto
Reunio de
Planejamento
da Release
Product Backlog (viso inicial)
Product Backlog (priorizado e estimado)
Os participantes:
Equipe SCRUM
Plano de Release
31
Reunio de Planejamento da Release: Fazendo estimativas
Workshop SCRUM
Viso inicial do Product Backlog, antes da reunio de Planejamento da

Release, ele tem somente as funcionalidades do produto, agrupadas
por tema (este agrupamento opcional).
Uma das atividades da reunio de Planejamento da Release definir
o Plano de Release, nesse plano estabelece-se o prazo de entrega
(estimado) do produto e nvel de prioridade dos itens do Product
Backlog.
Para chegarmos na data de entrega do produto esperada, o PO deve
perguntar diretamente ao cliente.
A equipe responsvel por fazer a estimativa dos itens do Product
Backlog.
32
Workshop SCRUM
Por que estimar difcil ?

Em um projeto desenvolvimento de software quase todas as variveis so incertas...
O Cone da Incerteza:
No incio de um projeto, detalhes especficos sobre a natureza do software a ser construdo, os detalhes
dos requisitos especficos, os detalhes da soluo, plano de projeto, equipe e outras variveis do projeto
so claras. A variabilidade desses fatores contribui para a variabilidade de estimativas do projeto - uma
estimativa exata de um fenmeno varivel deve incluir a variabilidade do fenmeno em si. Como estas
fontes de variabilidades so investigados e tratadas, a variabilidade no projeto diminui ao longo do tempo
(no decorrer do projeto), e assim a variabilidade no projeto estimada tambm pode diminuir. Este
fenmeno conhecido como o "Cone da Incerteza", que ilustrado na figura a seguir. Como a figura
sugere, a reduo significativa do Cone ocorrem durante os primeiros 20-30% do tempo total de
calendrio para o projeto.
Cone da Incerteza
O eixo horizontal contm etapas do projeto comum, como

conceito inicial, definio do produto aprovado, requisitos
completos, e assim por diante. "Definio do produto"
refere-se apenas ao acordado viso para o software, ou
"conceito de software", e igualmente aplicvel aos
servios de web, sistemas internos de negcios, e a
maioria dos outros tipos de projetos de software.
O eixo vertical contm o grau de erro que foi encontrado
nas estimativas criado por estimadores qualificados em
vrios pontos do projeto. As estimativas poderiam ser para
o quanto um conjunto de caractersticas particulares vai
custar e quanto esforo ser necessrio para entregar esse
conjunto de recursos, ou poderia ser de quantos recursos
podem ser entregues para uma determinada quantidade de
esforo ou programao.
Como voc pode ver na figura, as estimativas criadas logo
no incio do projeto esto sujeitos a um elevado grau de
erro. Estimativas iniciais so mais imprecisas do que as
outras variveis que foram criadas ao longo do projeto.
Fonte: http://www.construx.com/Page.aspx?hid=1648
33
Workshop SCRUM

O Cone da Incerteza: (continuao)
Quando trabalhamos com Mtodos geis, o SCRUM por exemplo, que podemos observar este
fenmeno invertido, explicando melhor, se perguntarmos a um desenvolvedor que j esta trabalhando em
um projeto o que ele consegue entregar nas prximas duas semanas a estimativa com certeza ser bem
precisa, mas se perguntarmos o que ele consegue entregar daqui a 4 meses, dificilmente ele ter uma
ideia claro e vai chutar uma estimativa qualquer, pois, no h como ter plena certeza do que ir
acontecer.
A nica certeza que podemos ter em qualquer projeto de software de que as coisas vo mudar, os
requisitos, o design, as funcionalidades e etc. Mas, como SCRUM faz de entregas de software
funcionando em ciclos constantes e curtos e com isso se adaptar as constantes mudanas.
E em projetos geis, no faz o Clone da Incerteza desaparecer, mas temos sempre mais certeza sobre
as estrias do usurio que esto priorizadas para o prxima Sprint ou estamos trabalhando neste
momento e vamos melhorando nossas estimativas e aumentando a preciso delas conforme os itens do
Product Backlog vai sendo entregues, mas, com uma viso muito clara do curto prazo e menos clara
para o que esta no fim do Product Backlog.
Importante: As estrias do usurio que esto sendo desenvolvidas no Sprint so as de maior ROI para o
projeto. Sendo assim o Cone de Incerteza aplicado a uma equipe que utiliza Scrum teria este formato:
Cone da Incerteza para projetos que utilizam Scrum

Fontes: http://www.implementingscrum.com/2008/02/19/vegas-hangover-enlightenment/ e http://www.acarlos.com.br/blog/category/scrum/page/3/
34

No mundo real fazer estimativa ter uma valor aproximado, mas em desenvolvimento de software o
entendimento outro, estimativa tida como uma valor exato, claro que esta viso equivocada.
- Estimativa (Mundo real) = Valor aproximado
- Estimativa (Desenvolvimento de Software) = Valor exato
Cena 1 Sprint Review
Cena 2 Planejamento da Sprint
Workshop SCRUM
????
Vocs erraram
a estimativa ...
PO
Equipe
Pontos de Estria (Story Points):

Valores relativos
Mais abstrato
????
Preciso de uma
data estimada
exata..
????
PO
????
Equipe
Dias ideias (Ideal Days):

Mais fcil para iniciantes
Fcil de explicar
35
Estimando Product Backlog:

Quando trabalhamos com mtodos geis temos pelo menos duas formas para estimar a velocidade da
equipe: Ideal Days e Pontos de Estria. Recomendamos utilizar os Pontos de Estria.
Workshop SCRUM
Ideal Days:
Mais fcil para iniciantes
Fcil de explicar
Dias Ideais (Ideal Days)

Baseado na durao de tarefas.
- Dias ou horas unidade bem definida, contudo o tempo ideal
quase nunca igual ao tempo real...
- mais fcil de estimar, mas pode ser tornar difcil de estimar se
consideramos todas as interrupes e variaes
Ideal Days foi definido por Kent Beck para referenciar um dia totalmente livre de
impedimentos para o desenvolvedor. No seu livro, Extreme Programming Explained,
Beck descreveu o dia ideal, como o tempo necessrio para concluir uma estria do usurio
sem interrupes ou reunies Esta ideia ressalta que os desenvolvedores
eventualmente executam outras atividades durante o dia, alm de programar.
Pontos de Estria:
Valores relativos
Mais abstrato
Pontos de Estria (Story Points)

Baseia-se no tamanho da estria influenciado pela:
- Nvel de dificuldade, complexidade e experincia ( emprico);
Foco nas funcionalidades;
O importante so os valores relativos;
Pontos so medidas sem unidade;
Equipe diferentes podem ter pontos diferentes para a mesma
estrias.
Principais tcnicas:
Opinio de especialista (algum que est ajuda a implementar o
Scrum na empresa as vezes um Coach);
Analogia;
Decomposio (Dividir para conquistar) ou Desagregao.
36
Tcnicas que ajudam a Estimar:

Existem 3 tcnicas que podem ajudar a fazer estimativas:
Workshop SCRUM
Estimativa por analogia:

- Comparando a estria do usurio com outra estria:
"Esta estria muito parecida com aquela de Cadastro de Cliente, ns estimamos aquela estria
com 11 pontos...
- No utilize um nico padro (tcnica). Procure utilizar pelo dois ou mais padres.
- Triangulao:
Comparar a estria que est sendo estimada em com vrias outras estrias
Desagregao:
- Quebrar uma estria do usurio grande em estria menores ou tarefas
mais fcil estimar com base em tarefas
- Cuidado, a desagregao em excesso pode caurar problemas:
Como esquecimento de algumas tarefas
Triangulao:
- Certifique que estimativa ser feita, comparando
a estria do usurio com vrias outras estrias
- Grupo de estria do usurio com tamanho
prximos esto em uma tabela ou quadro branco,
isto facilita o trabalho.
Estria A
Estria B
Estria D
Estria C
Estria E
Estria F
Fonte: Agile Estimating and Planning Mike Cohn
37
Estimando os itens do Product Backlog:
Workshop SCRUM
Detalhando os itens do Produto Backlog em estrias do usurio:
Para facilitar o entendimento dos

itens do Product Backlog ele so
descritos em estrias do usurio
elas auxiliam no entendimento do
que deve ser feito, permite fazer a
estimativa de velocidade da equipe
e tambm , utilizada como
lembrete e para as atividades de
planejamento. Geralmente a
estimativa feita em pontos
(pontos de estria)
Como escrever uma Estria do Usurio ?

Conversaes sobre a estria, entre os usurios e desenvolvedores, de modo a detalhar o item do
Product Backlog e esclarecer todas as dvidas sobre do que deve ser feito.
Estria do Usurio
Titulo: Fazer Reserva de Apartamentos
Como cliente de negcio, eu quero fazer reserva de
apartamentos pela web para facilitar o meu
planejamento.
Pontos: ?
Prioridade: Alta
Carto: Estria do Usurio so tradicionalmente

escritas em um carto. Carto podem ter notas,
estimativas, comentrio observaes e etc
Conversas: Detalhes que podem surgir durante as
conversas com PO (Product Owner) e/ou cliente.
Confirmao: Testes de aceitao confirmam se

a Estria do Usurio foi codificada da forma correta.
Testes de aceitao so tipo Caixa Preta.
Boa Prtica: A Estria do Usurio deve prover o entendimento do que deve ser feito e deve facilitar a estimativa
de velocidade da equipe.
38

Estimativa* e o Planning Poker:
Workshop SCRUM
Para fazer estimativa de velocidade da equipe ou de durao da Sprint, antes preciso o escrever as
estrias do usurio.
O Planning Poker uma prtica que ajuda na estimativa de uma estria ou de uma tarefa e baseada
no consenso de toda a equipe.
Geralmente o Planning Poker usa um conjunto de cartas com valores especficos que
podem representar pontos relativos e praticado como se fosse um jogo de cartas. Os
pontos devem estar em uma escala no linear, por e exemplo a Fibonacci:
(1,2,3,5,8,13,...) + 20, 40, 100 ou em outra escala.
Jogando o Planning Poker:
Antes de comear o jogo necessrio definir um valor de referncia. Por exemplo: Identificar a estria
que pode ser atribudo a menor quantidade pontos, esta estria ser utilizada como referncia para
pontuao das demais estrias.
O PO apresenta uma estria e pede para os membros da equipe fazer a estimativa de velocidade...
1. Rodada
40
100
Pessoal, qual
estimativa para
essa estria...
40
40
Product Owner
Quando todas as cartas

estiverem lanadas, elas
so viradas e caso no
haja consenso nos
pontos, as diferenas so
discutidas de forma
breve, e uma nova
rodada acontece at que
haja concesso.
Equipe
N. Rodada
40
40
40
40
Equipe
39

Todos os itens do Product Backlog devem ser estimados, pois, assim PO poder construir o Plano de
Release e Release Burndown, que um dos artefatos produzidos nessa reunio..
Workshop SCRUM
Escrevendo as Estrias do Usurio
Product Backlog
Planning Poker
20
20
Pessoal, qual
estimativa para
essa estria...
40
20
Product Owner
Equipe
Estimando
40
Product Backlog Estimado:
Workshop SCRUM
Aps a estimativa de todos os itens do Product Backlog, o prximo passo fazer a priorizao
dos itens. Veja o Product Backlog com as estimativas.
Os itens do Product Backlog possuem os atributos de descrio, estimativa e prioridade. A prioridade

determinada por risco, valor e necessidade.
O Product Backlog nunca est completo. A seleo inicial para o seu desenvolvimento somente
mostra os requisitos inicialmente conhecidos e melhor entendidos. O Product Backlog evolui
medida que o produto e o ambiente em que ele ser usado evoluem. O Backlog dinmico, no
sentido de que ele est constantemente mudando para identificar o que o produto necessita
para ser apropriado, competitivo e til. Enquanto existir um produto, o Product Backlog tambm
existir.
Resumo: O clico de vida do Product Backlog est ligado ao ciclo de vida do Produto
41
Reunio de Planejamento da Release: PB estimado
1
2
Workshop SCRUM
Definio da estimativa do Product Backlog
Verso inicial do Product Backlog,

sem estimativa e nem priorizao.
Plano de Release
Aps a equipe concluir a estimativa do Product Backlog necessrio fazer

a priorizao dos itens. Isto responsabilidade do PO.
Reserva
Promoes
Relacionamento
ao cliente
Programa de
Fidelidade
Tour Virtual
Nvel de
Prioridade
Prazo
(estimado)
30 dias
15 dias
7 dias
15 dias
15 dias
Sprints#
5 Sprints
82 dias
42
Workshop SCRUM
Reunio de Planejamento da Release. Check List parcial
Falta priorizar, mas isso assunto para prxima aula
43
Workshop SCRUM
1
Criar
2
Estimar
3
Priorizar
4
Manter

44
Workshop SCRUM
Parte 3:
Como Priorizar o Product Backlog

45
Workshop SCRUM
Objetivo:

Apresentar e discutir como Priorizar o Product Backlog.
Pr-requisito:
46
Framework SCRUM:
Artefatos e Regras.
Workshop SCRUM
Planejamento
da Release
O foco
desse
workshop
Reunio
diria
Planejamento
da Sprint
Reviso
da Sprint
Retrospectiva
da Sprint
24 horas
Product
Backlog
Sprint
Backlog
Produto
Sprint
(2-4 Semanas)
Viso
Legenda:
Reunies
Artefatos
Eventos (Reunies)
Artefatos
Papis
Product Owner (PO)
ScrumMaster (SM)
Equipe (time)
Diria
Reviso da Sprint
Product Backlog
Sprint Backlog
Sprint Burndown
Release Burndown
Sprint Burndown
Release Burndown
47
Introduo, a Reunio de Planejamento da Release:

Na reunio de Planejamento da Release o Product Backlog estimado e priorizado.
A equipe responsvel por estimar os itens do Product Backlog, mais isto foi apresentado na aula
anterior. Nessa aula vamos apresentar como priorizar os itens do Product Backlog , essa tarefa de
responsabilidade do PO.
Workshop SCRUM
Planejamento
da Release
Planejamento
da Sprint
Reunio
diria
Reviso
da Sprint
Retrospectiva
da Sprint
24 horas
Produto
Backlog
Sprint
Backlog
Sprint
2-4 Semanas
Produto
Viso
48
Verso inicial do Product Backlog:
Workshop SCRUM
Aps a definio da Viso do Produto, devemos definir a primeira verso do Product Backlog,
note que ele no foi estimado nem priorizado.
agrupamento
49
{Review} Reunio de Planejamento da Release:
Workshop SCRUM

O propsito do planejamento da release o de estabelecer um plano e
metas que a Equipe Scrum e o resto da organizao possam entender e
comunicar.
O planejamento da release responde s questes:
- Como podemos transformar a viso em um produto da melhor maneira
possvel?
- Como podemos alcanar ou exceder a satisfao do cliente ?
- Como podemos alcanar o ROI (retorno sobre investimento) ?
O Plano da Release estabelece a meta da release, as maiores
prioridades do Product Backlog, os principais riscos e as caractersticas
gerais e funcionalidades que estaro contidas na release.
Ele estabelece tambm uma data de entrega e custo provveis que
devem se manter se nada mudar. A organizao pode ento inspecionar
o progresso e fazer mudanas nesse plano da release a cada Sprint.
Contudo, O planejamento da release inteiramente opcional. Se uma

Equipe Scrum iniciar o trabalho sem essa reunio, a ausncia de seus
artefatos aparecer como um impedimento que dever ser resolvido.
O trabalho para resolver o impedimento se tornar um item no Product
Backlog.
Ao se utilizar Scrum, os produtos so construdos iterativamente, de
modo que cada Sprint cria um incremento do produto, iniciando pelo de
maior valor e maior risco. Mais e mais Sprints vo adicionando
incrementos ao produto.
50
{Review} Reunio de Planejamento da Release:

Workshop SCRUM
Cada incremento um pedao potencialmente entregvel do produto

completo. Quando j tiverem sido criados incrementos suficientes
para que o produto tenha valor e uso para seus investidores, o produto
entregue
Muitas organizaes j tem um processo de Planejamento de
Release, e na maior parte desses processos o planejamento feito no
incio do trabalho da release e no modificado com o passar do
tempo.
No Planejamento de Release do Scrum, so definidos uma meta geral e
resultados provveis. Esse planejamento geralmente no requer mais do que
15-20% do tempo que uma organizao costumava utilizar para produzir um
plano de release tradicional. No entanto, uma release com Scrum realiza
planejamento no momento da execuo de cada reunio de Reviso de
Sprint e de Planejamento de Sprint, da mesma forma que realiza um
planejamento dirio no momento da execuo de cada Reunio Diria.
De forma geral, os esforos para uma release com Scrum provavelmente
consomem ligeiramente mais esforo do que os esforos para um
planejamento de release tradicional.
O planejamento da release requer estimar e priorizar o Product Backlog
para a release. Existem diversas tcnicas para faz-lo, mas o SCRUM um
framework, no indica nenhuma tcnica.
Contudo, nessa aula abordaremos algumas tcnicas para priorizar o
Product Backlog
51
Viso Geral da Reunio de Planejamento da Release:

Sadas
Entradas
Release
Burndown
(artefato)
Workshop SCRUM
Viso do Produto
Reunio de
Planejamento
da Release
Product Backlog (viso inicial)
Product Backlog (priorizado e estimado)
Os participantes:
Equipe SCRUM
Plano de Release
52
Reunio de Planejamento da Release: Priorizando
Workshop SCRUM
Viso inicial do Product Backlog, antes da reunio de Planejamento da

Release, ele tem somente as funcionalidades do produto, agrupadas
por tema (este agrupamento opcional).
Uma das atividades da reunio de Planejamento da Release definir
o Plano de Release, nesse plano estabelece-se o prazo de entrega
(estimado) do produto e nvel de prioridade dos itens do Product
Backlog.
2
3
A equipe responsvel por fazer a estimativa dos itens

do Product Backlog.
Aps a estimava dos itens do Product Backlog necessrio definir

os nveis de prioridades dos itens Product Backlog.
53
Reunio de Planejamento da Release: Plano de Release

{Review}
O Plano da Release estabelece a meta da release, as maiores prioridades do Product Backlog, os
principais riscos e as caractersticas gerais e funcionalidades que estaro contidas na release.
Workshop SCRUM
Ele estabelece tambm uma data de entrega e custo provveis que devem se manter se nada mudar.
A organizao pode ento inspecionar o progresso e fazer mudanas nesse plano da release a cada
Sprint, se necessrio.
Plano de Release
Sprints#
Nvel de
Prioridade
Reserva
Promoes
30 dias
15 dias
Programa de
Fidelidade
Tour Virtual
7 dias
15 dias
15 dias
Relacionamento
ao cliente
5 Sprints
82 dias
54
Product Backlog sem priorizao
Workshop SCRUM
Questes chaves:
1 - Qual item retorna maior valor ao negcio ?
2 - Quais itens devemos entregar primeiro ?
3 - Como priorizar os itens ?
?
?
?
Objetivo da priorizao em mtodos geis:
Entregar os itens de maior valor ao cliente ao menor custo (entregar primeiro os requisitos de maior
valor fazem que eles custem menos do que os itens que sero entregues mais tarde).
55
Priorizao do Product Backlog:
Workshop SCRUM
As melhores prticas recomendam que a priorizao do Product Backlog deve ser por tema (ou por
categoria), j que a priorizar por estria, nem sempre possvel, pois, poder existir grau de
dependncias entre estrias do usurio.
Fatores de Priorizao:
- Valor
- Custo
- Risco
Priorizao Baseada em Valor, Custo e Risco:
Existem diversas tcnicas que envolvem a estimativa do valor relativo e custo relativo de cada item
(funcionalidade) do Product Backlog, de tal forma que os itens de alta prioridade deve fornecer a maior
frao do valor total do produto ao menor frao do custo total. Em essncia, estamos tentando identificar
item (ou funcionalidade) que ir maximizar o valor do produto, dentro das limitaes de custo existentes.
Principais Tcnicas:
- Kano: Composta por entrevistas com os usurios e opinies de especialistas.
- Theme Screening: Composta por opinies de especialistas baseadas em comparao realizadas
com um tema importante.
-Theme Scoring: Baseado em comparaes realizadas em um tem de referncia
- Outras:
. Opinio de Especialista
. Tcnicas financeiras
56
Tcnicas que ajudam na priorizao do Product Backlog:

Modelo Kano:
um modelo desenvolvido por Noriaki Kano que usado para compreender as preferncias dos
clientes (ou usurios).
Workshop SCRUM
O modelo Kano tem 3 tipos de funcionalidades:

- Desejadas: So aquelas funcionalidades que o usurio deseja, mas no tem plena certeza
- Linear: Quantas mais destas tiver melhor
- Mandatrio: Deve estar presente para que o cliente esteja satisfeito.
Para saber qual o tipo de cada funcionalidade, podemos fazer o seguinte:

- Fazer as perguntas direcionadas para um grupo de no mximo 20 clientes ou usurios com perfis
diferentes;
- Realizar uma pergunta funcional:
Se na prxima release incluir a emisso da Ordem de Servio (OS), como voc se sentira?
[ X ] Eu vou gostar
[ ] Eu acho que deveria incluir
[ ] Indiferente
[ ] Posso tolerar
[ ] Eu no gostaria disto
- Fazer uma pergunta disfuncional:
Se na prxima release NO incluir a emisso da Ordem de Servio (OS), como voc se sentira?
[ ] Eu vou gostar
[ X ] Eu acho que deveria incluir
[ ] Indiferente
[ ] Posso tolerar
[ ] Eu no gostaria disto
57

Modelo Kano:
Workshop SCRUM
Categorizando as respostas:
Agregando resultados:
O que incluir na Sprint ?
- Todas as funcionalidades
Mandatrias
- Algumas funcionalidades
Lineares
- Mas deixe um espao para as
funcionalidades desejadas
58

Theme Screening
Theme Screening uma tcnica poderosa e fcil de priorizao que pode ser usada para priorizar os
temas e/ou picos. Tambm pode ser usado para priorizar projetos ou produtos.
Passos:
1 - identificar os fatores que so significantes (importantes) na priorizao dos temas (ou dos picos).
Workshop SCRUM
2 - Selecione um tema como "baseline" (que ser utilizado como referncia)

3 Defina a tabela de pesos:
+ - Melhor que a referncia
0 - Igual a referncia
- - Pior que referncia
4 Faa a avaliao (comparao):

Fazer avaliao/comparao: do Critrio x Tema x Tema de Referncia. Perguntar: Qual grau de importncia do critrio em
relao ao Tema ?
5 Faa a classificao baseado no score (quando maior for o score maior ser o nvel de prioridade)
Temas
Baseline
Critrio de Seleo
Reserva
Progr de Fidelidade
Promoes
Rel com Clientes
Tour Virtual
Reserva para prximo vero
Promoes para baixa temporada
0
0
0
Score
-1
-2
Classificao
59

Theme Scoring
uma tcnica de priorizao que pode ser usada para priorizar os temas (grupos de estrias do usurio)
e/ou picos (estrias do usurio grandes). Tambm pode ser usado para priorizar projetos ou produtos.
Passos:
1 - identificar os fatores que so significantes (importantes) na priorizao dos temas (ou dos picos).
Workshop SCRUM
2 Defina o peso para cada critrio

3 - Selecione um tema como "baseline" (que ser utilizado como referncia)
4 Defina a tabela de pesos:
5 Muito Melhor que a referncia
4 Melhor que a referncia
3 Igual a referncia
2 - Pior que a referncia
1 - Muito pior que a referncia
5 Faa a avaliao:
Fazer avaliao de cada tema em relao ao candidato tema de referncia.
6 Faa a classificao baseado no score (quando maior for o score maior ser o nvel de prioridade)
Reserva (referncia) Progr de Fidelidade

Critrio de Seleo
Peso Pontos
Reserva para prximo vero
5
3
Promoes para baixa temporada
2
3
Score
Classificao
Score
Pontos
15
6
21
1
Score
2
1
Promoes
Pontos
10
1
2
3
12
3
Score
Rel com Clientes

Pontos
5
2
6
2
11
4
Score
Tour Virtual
Pontos Score
10
1
5
4
1
2
14
2
7
5
60

Outras tcnicas
Opinio de Especialista:
Um especialista ajuda na definio do nvel de prioridade dos itens do Product Backlog..
Workshop SCRUM
Foco: Dever ser na entrega de valor para cliente.

Considerar 4 fatores:
- Entrega novas capacidades
- Desenvolvimento novos conhecimentos
- Mitigao do Risco
- Mudanas no custo relativo
Tcnicas Financeiras
Utilizao de tcnicas financeira para ajudar na priorizao dos itens do Product Backlog.
TIR - Taxa interna de retorno
ROI Taxa de Retorno sobre investimento
Payback
Valor Presente Liquido (VPL)
61
Reunio de Planejamento da Release: PB estimado
Workshop SCRUM
Product Backlog estimado e priorizado
Alta
Verso inicial do Product Backlog,

sem estimativa e nem priorizao.
Mdio
Mdio
Baixo
Baixo
Plano de Release
Plano de Release, como status de Pronto
Reserva
Promoes
Relacionamento
ao cliente
Programa de
Fidelidade
Tour Virtual
Nvel de
Prioridade
Alto
Mdio
Mdio
Baixo
Baixo
Prazo
(estimado)
30 dias
15 dias
7 dias
15 dias
15 dias
Sprints#
5 Sprints
82 dias
62
Reunio de Planejamento da Release. Release Burndown:

Com Product Backlog atualizado e o Plano de Release, o PO poder construir o Release Burndown, que um
dos artefatos do SCRUM.
O Release Burndown registra a soma das estimativas dos esforos restantes do Product Backlog ao longo do
tempo. O esforo estimado deve estar em qualquer unidade de medida de trabalho que a equipe e a
organizao tenham decidido usar. As unidades de tempo geralmente so Sprints.
120
O Product Owner responsvel

por manter o Product Backlog e
o Release Burndown atualizados
e publicados todo o tempo.
Uma linha de tendncia pode ser
traada baseada na mudana do
trabalho restante.
108
80
Pontos (estimados)
Workshop SCRUM
Release Burndown
68
40
48
40
20
0
Release #1
Release #2
Release #3
Release #4
Release #5
Releases
63
Workshop SCRUM
Reunio de Planejamento da Release. Check List final
64
Workshop SCRUM
1
Criar
2
Estimar
3
Priorizar
4
Manter

65
Workshop SCRUM
Objetivo:

Apresentar e discutir como Manter o Product Backlog.
Pr-requisito:
66
Workshop SCRUM
Parte 4:
Como Manter o Product Backlog

67
Framework SCRUM:
Artefatos e Regras.
Workshop SCRUM
Planejamento
da Release
O foco
desse
workshop
Reunio
diria
Planejamento
da Sprint
Reviso
da Sprint
Retrospectiva
da Sprint
24 horas
Product
Backlog
Sprint
Backlog
Produto
Sprint
(2-4 Semanas)
Viso
Legenda:
Reunies
Artefatos
Eventos (Reunies)
Artefatos
Papis
Product Owner (PO)
ScrumMaster (SM)
Equipe (time)
Diria
Reviso da Sprint
Product Backlog
Sprint Backlog
Sprint Burndown
Release Burndown
Sprint Burndown
Release Burndown
68
Review: Product Backlog:

Viso do Product Backlog:
Alta
Workshop SCRUM
Mdio
Mdio
Baixo
Baixo
O Product Backlog dinmico, no sentido de que ele est

constantemente mudando para identificar o que o produto
necessita.
O Product Backlog, inicialmente uma lista que representa tudo que
necessrio para desenvolver e lanar um produto. A lista deve
conter todas as caractersticas, funes, tecnologias, melhorias e
correes de defeitos que constituem as mudanas que sero
efetuadas no produto para futuras releases .
69
Workshop SCRUM
Quem Responsvel por Manter o Product Backlog ?

O Product Owner (PO) a nica pessoa responsvel pelo gerenciamento do Product Backlog e
por garantir o valor do trabalho realizado pela Equipe.
O PO mantm o Product Backlog (PB) e assegura que ele est visvel para todos. Todos sabem
quais itens tm a maior prioridade, de forma que todos sabem em que se ir trabalhar.
O Product Owner deve ser uma pessoa, e no um comit. Podem existir comits que aconselhem
ou influenciem , mas somente o PO poder mudar a prioridade de um item do PB. Empresas que
adotam Scrum podem perceber que isso influencia seus mtodos para definir prioridades e requisitos
ao longo do tempo.
Para que o PO obtenha sucesso, todos na organizao precisam respeitar suas decises.
Somente o PO pode definir a prioridade dos itens que a equipe ir trabalhar.
As decises do Product Owner so visveis no contedo e na priorizao do Product Backlog. Essa
visibilidade requer que o Product Owner faa seu melhor, o que faz o papel de Product Owner
exigente e recompensador ao mesmo tempo.
Product Backlog e as responsabilidades do PO: Criar ,

Priorizar e Manter o Product Backlog.
70
Manter o Produto Backlog atualizado:

O Product Backlog poder sofrer atualizaes no decorrer de uma reunio de Planejamento de
uma Sprint.
Exemplo: Quando uma estria do usurio considerada pico, ele ser dividida em outras estrias e
isto dever ser refletido no Product Backlog.
Workshop SCRUM
Planejamento
da Release
Planejamento
da Sprint
Reunio
diria
Reviso
da Sprint
Retrospectiva
da Sprint
24 horas
Produto
Backlog
Sprint
Backlog
Sprint
2-4 Semanas
Produto
Viso
71

Na Reunio de Reviso da Sprint o Product Backlog poder sofrer alteraes.
Exemplo: Uma Sprint onde no foi atingido a meta ou o que foi entrega no estava em conformidade
coma definio de pronto, neste as estrias de usurio da Sprint devem voltar ao Product Backlog.
Workshop SCRUM
Planejamento
da Release
Planejamento
da Sprint
Reunio
diria
Reviso
da Sprint
Retrospectiva
da Sprint
24 horas
Produto
Backlog
Sprint
Backlog
Sprint
2-4 Semanas
Produto
Viso
72
Workshop SCRUM
O Product Backlog tambm poder ser alterado

quando o cliente solicita novas funcionalidades
e quando deseja retirar alguma funcionalidade
do Product Backlog.
73
Quer mais ?
Workshop SCRUM
Os membros da comunidade podem participar dos eventos, treinamentos e cursos gratuitos.

Comunidade: http://etecnologia.ning.com/
Para participar da comunidade basta se cadastrar: http://bit.ly/czZlez

A misso da comunidade compartilhar conhecimento, trocar experincias e prover
aprendizado.
74
Workshop SCRUM
Licena:
75
Notas:
Marcas Registradas:
Workshop SCRUM
Todos os termos mencionados que so reconhecidos como Marca Registrada e/ou comercial so de
responsabilidades de seus proprietrios. O autor informa no estar associada a nenhum produto e/ou
fornecedor que apresentado neste material. No decorrer deste, imagens, nomes de produtos e
fabricantes podem ter sido utilizados, e desde j o autor informa que o uso apenas ilustrativo para fins
educativo, no visando ao lucro, favorecimento ou desmerecimento da marca ou produto.
Melhoria e Reviso:
Este material esta em processo constante de reviso e melhoria, se voc encontrou algum problema
ou erro envie um e-mail ns.
Criticas e Sugestes:
Ns estamos abertos para receber criticas e sugestes que possam melhorar o material, por favor
envie um e-mail para ns.
Imagens:
Google, Flickr e Banco de Imagem.
Rildo F dos Santos (rildo.santos@etecnologia.com.br)

76
Workshop SCRUM
Como
criar,
estimar,
priorizar e
manter o
Product
Backlog
www.etcnologia.com.br
Rildo F Santos
(11) 9123-5358
(11) 9962-4260
twitter: @rildosan
skype: rildo.f.santos
http://rildosan.blogspot.com/

Backlog

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Backlog

Enviado por

Direitos autorais:

Formatos disponíveis

Workshop SCRUM

Verso 1 Ago 2010 | RFS

Todos os direitos reservados e protegidos 2006 e 2010

1 Como Criar o Product Backlog

Verso 1 Ago 2010 | RFS

Todos os direitos reservados e protegidos 2006 e 2010

Todos os direitos reservados e protegidos 2006 e 2010

Programa: Menos Papel, Mais rvores

Qual o mundo que queremos ?

Para cumprir esta misso necessrio: conscientizar, comprometer e AGIR.

O programa Menos Papel, Mais rvores, uma ao, com objetivo de

Todos os direitos reservados e protegidos 2006 e 2010

Facilitador: Rildo F. Santos (@rildosan)

Verso 1 Ago 2010 | RFS

Todos os direitos reservados e protegidos 2006 e 2010

1 Como Criar o Product Backlog

Verso 1 Ago 2010 | RFS

Todos os direitos reservados e protegidos 2006 e 2010

Objetivo dessa parte:

Todos os direitos reservados e protegidos 2006 e 2010

Como Criar o Product Backlog

Todos os direitos reservados e protegidos 2006 e 2010

Verso 1 Ago 2010 | RFS

Todos os direitos reservados e protegidos 2006 e 2010

Framework Scrum: As Regras

Verso 1 Ago 2010 | RFS

Todos os direitos reservados e protegidos 2006 e 2010

Framework Scrum: Product Owner (PO)

Todos os direitos reservados e protegidos 2006 e 2010

Framework Scrum: Artefatos

Scrum tem quatro artefatos principais:

Todos os direitos reservados e protegidos 2006 e 2010

Questes sobre o Product Backlog:

O que o Product Backlog ?

Todos os direitos reservados e protegidos 2006 e 2010

Questes sobre o Product Backlog:

Por que o Product Backlog pode mudar ?

Verso 1 Ago 2010 | RFS

Todos os direitos reservados e protegidos 2006 e 2010

Como criar o Product Backlog:

Aps entender a necessidade do cliente, hora de definir a Viso do Produto:

Para o Hotel que necessita de um Sistema o Portal de Reservas On-Line um

Verso 1 Ago 2010 | RFS

Todos os direitos reservados e protegidos 2006 e 2010

Definindo a Viso do Produto:

A Declarao da Viso do Produto:

Apresentaremos duas tcnicas:

Verso 1 Ago 2010 | RFS

Todos os direitos reservados e protegidos 2006 e 2010

Definindo a Viso do Produto:

Primeira Tcnica: Declarao do Elevador (Elevator Statement)

O nome desta tcnica uma

Exemplo de Viso do Produto utilizando a Declarao do Elevador:

Product Owner (PO), responsvel por definir, manter e comunicar a

Todos os direitos reservados e protegidos 2006 e 2010

Definindo a Viso do Produto:

A caixa final, construda coletivamente, com base no que precede, no

Todos os direitos reservados e protegidos 2006 e 2010

Definindo a Viso do Produto:

Product Owner (PO), pode utilizar esta tcnica para exercitar o

Verso 1 Ago 2010 | RFS

Todos os direitos reservados e protegidos 2006 e 2010

Como criar o Product Backlog

Todos os direitos reservados e protegidos 2006 e 2010