Como Criar, Estimar, Priorizar e Manter o Product Backlog

Como
criar,
Como criar, estimar, priorizar e manter o Product Backlog

estimar,
priorizar e
manter o
Product
Backlog

www.etcnologia.com.br
Rildo F Santos

rildo.santos@etecnologia.com.br
(11) 9123-5358 twitter: @rildosan
(11) 9962-4260 http://rildosan.blogspot.com

Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com

O Conteúdo do workshop:

1 2 3 4

Criar Estimar Priorizar 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

Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com 2

Como criar, estimar, priorizar e manter o Product Backlog Objetivo:

Objetivo:
Compartilhar conhecimento, trocar experiência e prover aprendizado de Como criar,
estimar, priorizar e manter o Product Backlog utilizando as melhores práticas, técnicas e
ferramentas.

Pré-requisito:
Conhecimento do Scrum. Se você não conhece o Scrum recomendamos fazer o Workshop
SCRUM (http://etecnologia.ning.com/group/scrum ) primeiro e depois esse treinamento.

Como criar, estimar, priorizar e manter o Product Backlog 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 herança para as próximas gerações.

Nossa missão: É buscar pelo equilibro do homem, da tecnologia e do meio ambiente.

Para cumprir esta missão é necessário: conscientizar, comprometer e AGIR.

O programa Menos Papel, Mais Árvores®, é uma ação, com objetivo de
estimular o consumo sustentável de papel dentro das organizações.

Quer participar ?
- Reduza o uso de papel (e de madeira) o máximo possível.
- Só imprima se for extremamente necessário.
- Evite comprar produtos com excesso de embalagem.
- Ao imprimir ou escrever, utilize os dois lados do papel.
- Use papel reciclado.
Este material não deve ser impresso..

Facilitador: Rildo F. Santos (@rildosan)
Coach , Instrutor, Consultor e Palestrante de Métodos Ágeis, Gestão de Negócios, Inovação , Processos e
Tecnologia .

Minha Experiência:
Tenho mais de 10.000 horas de experiência em Gestão de Negócios, Gestão de Inovação, Governança e Engenharia de
Software. Sou formado em Administração de Empresas, Pós-Graduado em Didática do Ensino Superior e Mestre em

Engenharia de Software pela Universidade Mackenzie.

Fui instrutor de Tecnologia de Orientação a Objetos, UML e Linguagem Java (Sun MicroSystems e IBM).

Conheço Métodos Ágeis (SCRUM, XP, FDD, Lean e OpenUP), Arquitetura de Software, SOA (Arquitetura Orientado a
Serviço), Processo Unificado, Business Intelligence, Gestão de Risco de TI entre outras tecnologias.

Sou professor de curso de MBA da Fiap e fui professor de pós-graduação da Fasp e IBTA.

Tenho conhecimento de Gestão de Negócio (Inteligência de Negócio, Gestão por Processo, Inovação, Gestão de Projetos e
GRC - Governance, Risk ando Compliance), SOX, Basel II e PCI;
Experiência na implementação de Governança de TI e Gerenciamento de Serviços de TI. Fluência nos principais frameworks
e padrões: ITIL, Cobit, ISO 20000, ISO 27001 e ISO 15999;

Participei de diversos projetos nos segmentos: Financeiro, Telecomunicações, Seguro, Saúde, Comunicação, Segurança
Pública, Fazenda, Tecnologia, Varejo, Distribuição, Energia e Petróleo e Gás.

Possuo as certificações: 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


Conteúdo do Workshop:

1 2 3 4








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.

Como criar, estimar, priorizar e manter o Product Backlog Parte 1:

Como Criar o Product Backlog

Framework SCRUM:
O Framework Scrum é composto por uma Equipe (Time) Scrum e seus papéis: Product Owner
(PO), Scrum Master (SM) e Equipe de desenvolvedores, Eventos com duração fixa (Time-Boxes),
Artefatos e Regras.

Planejamento Planejamento Reunião Revisão
diária Retrospectiva
da Release da Sprint da Sprint da Sprint

O foco 24 horas
desse
workshop Product Sprint
Backlog Backlog
Produto
Sprint
(2-4 Semanas)
Visão
Legenda:
Reuniões
Artefatos

Eventos (Reuniões)
Papéis Artefatos
 Planejamento da Release
• Product Owner (PO)  Planejamento da Sprint • Product Backlog
• ScrumMaster (SM)  Diária • Sprint Backlog
• Equipe (time)  Revisão da Sprint • Sprint Burndown
 Retrospectiva da Sprint • Release Burndown Sprint Burndown
Release Burndown

Framework Scrum: As Regras
As Regras fazem o elo entre os eventos com duração fixa (time-boxes), os papéis 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 responsável pelo gerenciamento do Product Backlog e
por garantir o valor do trabalho realizado pelo Time.
- Essa pessoa mantém o Product Backlog e garante que ele está visível para todos. Todos
sabem quais itens têm a maior prioridade, de forma que todos sabem em que se irá trabalhar.


Framework Scrum: Product Owner (PO)
O Product Owner (PO) é a única pessoa responsável pelo gerenciamento do
Product Backlog e por garantir o valor do trabalho realizado pela Equipe.
O PO mantém o Product Backlog (PB) e assegura que ele está visível para todos.
Todos sabem quais itens têm a maior prioridade, de forma que todos sabem em que
se irá trabalhar.

O Product Owner deve ser uma pessoa, e não um comitê. Podem existir comitês
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 métodos para definir prioridades e requisitos ao longo do tempo.
Para que o PO obtenha sucesso, todos na organização precisam respeitar suas
decisões. Somente o PO pode definir a prioridade dos itens que a equipe irá trabalhar.
As decisões do Product Owner são visíveis no conteúdo e na priorização do Product
Backlog. Essa visibilidade requer que o Product Owner faça 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 é responsável direto pelo
Product Backlog.

O ScrumMaster, que é responsável por garantir que o processo (as práticas do SCRUM) seja compreendido e
seguido. É responsável ainda por:
- Remover impedimentos;
- Proteger a equipe;
- Ajudar o PO (quando necessário);
- Ser o facilitador da equipe.

A equipe (ou time), é responsável pelo desenvolvimento do produto, é formada por desenvolvedores que devem ter as
habilidades necessárias para transformar os itens do Product Backlog em Produto. A Equipe ainda é responsável por:
- Fazer estimativa;
- Definir as tarefas;
- Garantir a qualidade do produto;
- Apresentar o produto ao cliente


Como criar, estimar, priorizar e manter o Product Backlog Framework Scrum: Artefatos

Scrum tem quatro artefatos principais:

- Product Backlog: é uma lista priorizada de tudo que pode ser necessário 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 entregável. 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
primário é o Product Backlog.

Questões sobre o Product Backlog:
O que é o Product Backlog ?
Product Backlog: é uma lista priorizada de tudo que pode ser necessário no produto.
O Product Backlog representa tudo que é necessário para desenvolver e lançar um produto de
sucesso. É uma lista de todas as características, funções, tecnologias, melhorias e correções de
defeitos que constituem as mudanças que serão efetuadas no produto para releases futuras. Os

itens do Product Backlog possuem os atributos de descrição, prioridade e estimativa. A prioridade é
determinada por risco, valor e necessidade. Há diversas técnicas para dar valor a esses atributos
(veremos isso mais tarde).

Quem é responsável pelo Product Backlog ?
O Product Owner (PO) é o responsável pelo Product Backlog , por sua criação, por seu conteúdo, por
sua disponibilidade e por sua priorização.

Até quando o Product Backlog existirá ?
O Product Backlog nunca está completo. A seleção 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 é dinâmico, 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 também existirá.
Resumo: O clico de vida do Product Backlog está ligado ao ciclo de vida do Produto

Qual é a ordenação 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
informações e detalhes do que os itens do Backlog de menor prioridade. É mais fácil de fazer a
estimativa quando existem mais informações e mais detalhes.

Questões sobre o Product Backlog:
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 frenquência e outros com menor frequência). O Product Backlog é um
documento vivo. Mudanças nos requisitos de negócios, condições do mercado, tecnologia e
equipe causam mudanças no Product Backlog. Para reduzir o retrabalho, apenas os itens de
maior prioridade precisam ser mais detalhados. Os itens do Product Backlog que ocuparão a
Equipe Scrum pelas várias Sprints seguintes deverão ter granularidade mais fina (mais detalhados),
tendo sido decompostos de forma tal que cada um dos itens possa ser feito dentro da duração da
Sprint.

Quando existe diversas equipes trabalhando para construir um produto quantos Product
Backlog devemos ter ?
Se múltiplas 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 características, por tecnologia ou por arquitetura,
e ele é frequentemente utilizado como uma forma de se organizar o trabalho por equipe.


Como criar o Product Backlog:
Para definir a visão do Produto, primeiro é necessário entender qual é a real necessidade do cliente:

A necessidade:
Um hotel, quer incrementar um novo canal de consultas e vendas de reservas de
apartamentos. A sugestão foi criar um Portal de Reservas para vender os serviços.

Após entender a necessidade do cliente, é hora de definir a Visão do Produto:

Declaração da Visão do Produto:

Para o Hotel que necessita de um Sistema o Portal de Reservas On-Line é um
software baseado na web, intuitivo e fácil 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.


Definindo a Visão do Produto:
Introdução:
Qualquer produto está necessariamente associada a uma visão, pois, a visão deve descrever o
produto em relação a necessidade do usuário (cliente).
A visão do produto somente será significativa se apresentada e compartilhada pela equipe SCRUM.

A definição da visão do produto é uma responsabilidade Product Owner. Mas, ele poderá
desenvolver a visão do produto em colaboração com a equipe de desenvolvimento de software e o
cliente final

A Declaração da Visão do Produto:
A declaração de Visão do Produto deve ser simples,
consistente, objetiva e de fácil entendimento, e que tenha
informações sobre a necessidade do cliente, o que é
produto esperado e quais sãos os seus principais
benefícios.
A declaração ainda deve descrever a motivação e o
diferencial do produto em relação aos outros concorretes.

Duas técnicas que ajudam no desenvolvimento da
da Visão do Produto:
- A Declaração do Elevador (que também pode ser
chamada de Visão Sintética)
- Product Vision Box. (Visão da Caixa do Produto)


Declaração do Elevador ou “Visão sintética" (essencial)
Segundo Moore (1991). É também chamada Elevator Pitch, mas podemos chamar "visão sintética“.
A Visão Sintética é estruturada em 6 partes que resumem em menos de dois minutos a Visão do Produto.

Primeira Técnica: Declaração do Elevador (Elevator Statement)

• For (target customer) O nome desta técnica é uma
• Who (statement of the need or opportunity) alusão ao seguinte desafio: você
tem que influenciar ou passar um
• The (product name) is a (product category)
mensagem para um pessoa em
• That (key benefit, compelling reason to buy) curto espaço de tempo uma
• Unlike (primary competitive alternative) viagem de elevador.
• Our product (statement of primary differentiation) Com o tempo é curto a mensagem
tem que ser objetiva e clara.

Exemplo de Visão do Produto utilizando a Declaração do Elevador:

Para empresas médias de marketing e departamento de vendas que necessitam de um sistema de
CRM, o EeaseCRM é um software baseado na web, intuitivo e fácil de usar que fornece a
possibilidade fazer a rastreabilidade de vendas, geração de leads e possibilita o estreitamento do
relacionamento com o cliente.
Diferente de outros serviços ou produtos, nosso produto oferece a melhor relação custo beneficio.

Product Owner (PO), é responsável por definir, manter e comunicar a
Visão do Produto para todos os stakeholders.
A equipe pode colaborar com o desenvolvimento da Visão do Produto.
Product Owner

Visão do Produto:
Segunda Técnica: Product Vision Box (Visão da Caixa do Produto)

Segundo Highsmith (2004). O Produto Vision Box é uma técnica altamente relevante para iniciar um

projeto para construir a visão e compartilhá-lo com todas as partes interessadas no produto.
O resultado de um projeto de desenvolvimento de software é o “produto”. O produto pode ser
representado por uma caixa (“a caixa” do produto).

“Product Vision Box“ é uma técnica que ajuda no entendimento da Visão do Produto, pois, quando
fazemos uma representação visual do produto (“caixa”, por exemplo) isto ajuda na redução do nível de
abstração (ou seja, melhora o entendimento do que ser feito).

A caixa final, é construída coletivamente, com base no que precede, no
consenso e colaboração. Esta "Visão da Caixa do Produto" é a visão
compartilhada, e irá incorporar os seguintes elementos:
• Parte da frente da caixa: Nome - Imagem (se possível) - divisão -
argumentos que ajudam a vender o produto
• Parte de trás da caixa: Colocar de forma mais detalhada as principais
funcionalidade, os pré-requisitos e etc...

Este exercício ajuda a melhorar o entendimento, identificar possíveis
conflitos e reduz a abstração. O formato desse exercício exige que os
as pessoas tenham uma participação intensa e as vezes até exaustiva.

Mas, a visão da caixa do produto é definida sempre em consenso.

Visão do Produto:

Exemplo: Product Vision Box

Informações sobre o produto:

- Nome do Produto:
- Logotipo ou desenho que
represente o produto
- Principais benefícios que ajuda a
“vender” o produto
- Principais características e/ou
funcionalidades do produto
- Principais requisitos técnicos

http://www.qualitystreet.fr/2009/07/29/la-vision-du-produit/

Product Owner (PO), pode utilizar esta técnica para exercitar o
Product Owner desenvolvimento da visão 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


Como criar o Product Backlog
Após a definição da Visão do Produto, devemos definir a primeira “versão” do Product Backlog:

agrupamento Funcionalidades do produto

O Product Backlog, inicialmente é uma lista que representa tudo que é necessário para desenvolver e
lançar um produto. A lista deve conter todas as características, funções, tecnologias, melhorias e
correções de defeitos que constituem as mudanças que serão efetuadas no produto para futuras
releases . O Product Backlog é dinâmico, no sentido de que ele está constantemente mudando
para identificar o que o produto necessita.

Como criar, estimar, priorizar e manter o Product Backlog Estudo de Caso: Visão do Produto



1 2 3 4








Apresentar e discutir como “Estimar” o Product Backlog.

Pré-requisito:
SCRUM (http://etecnologia.ning.com/group/scrum) primeiro e depois esse treinamento.


Como Estimar o Product Backlog

Framework SCRUM:
Artefatos e Regras.


O foco 24 horas
desse
Backlog Backlog
Produto
Sprint
(2-4 Semanas)
Visão
Legenda:
Reuniões
Artefatos

Eventos (Reuniões)
Papéis Artefatos
Release Burndown

Introdução, a Reunião de Planejamento da Release:
Na reunião de Planejamento da Release o Product Backlog é estimado e priorizado.
O PO é responsável por priorizar os itens do Product Backlog (isto será visto na próxima aula). A equipe
é responsável por estimar os itens do Product Backlog.


24 horas

Produto Sprint
Backlog Backlog
Produto
Sprint
2-4 Semanas
Visão


Equipe (Responsável por fazer a estimativa):
A equipe (ou time), é responsável pelo desenvolvimento do produto, é formada por
desenvolvedores que devem ter as habilidades necessárias para transformar os itens
do Product Backlog em Produto. A Equipe ainda é responsável 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 responsável pelo gerenciamento do Product Backlog e
por garantir o valor do trabalho realizado pela Equipe.
O PO mantém o Product Backlog (PB) e assegura que ele está visível para todos. Todos sabem
quais itens têm a maior prioridade, de forma que todos sabem em que se irá trabalhar.
O Product Owner deve ser uma pessoa, e não um comitê. Podem existir comitês 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 métodos para definir prioridades e requisitos
ao longo do tempo.
Para que o PO obtenha sucesso, todos na organização precisam respeitar suas decisões.
Somente o PO pode definir a prioridade dos itens que a equipe irá trabalhar.
As decisões do Product Owner são visíveis no conteúdo e na priorização do Product Backlog. Essa
visibilidade requer que o Product Owner faça 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 é responsável por garantir que o processo (as práticas do SCRUM) seja compreendido e
seguido. É responsável ainda por:
- Remover impedimentos;
- Proteger a equipe;
- Ajudar o PO (quando necessário);
- Ser o facilitador da equipe.


Versão inicial do Product Backlog:
Após a definição da Visão do Produto, devemos definir a primeira “versão” do Product Backlog,
note que ele não foi estimado nem priorizado.



Reunião de Planejamento da Release:
A estimativa e a priorização devem ser feitas na Reunião de Planejamento da Release.

O propósito do planejamento da release é o de estabelecer um plano e
metas que a Equipe Scrum e o resto da organização possam entender e
comunicar.

O planejamento da release responde às questões:
- Como podemos transformar a visão em um produto da melhor maneira
possível?
- Como podemos alcançar ou exceder a satisfação do cliente ?
- Como podemos alcançar 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 características
gerais e funcionalidades que estarão contidas na release.
Ele estabelece também uma data de entrega e custo prováveis que
devem se manter se nada mudar. A organização pode então inspecionar
o progresso e fazer mudanças nesse plano da release a cada Sprint.

Contudo, O planejamento da release é inteiramente opcional. Se uma
Equipe Scrum iniciar o trabalho sem essa reunião, a ausência 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 são construídos iterativamente, de
modo que cada Sprint cria um incremento do produto, iniciando pelo de
maior valor e maior risco. Mais e mais Sprints vão adicionando
incrementos ao produto.


Reunião de Planejamento da Release:

Cada incremento é um pedaço potencialmente entregável 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 organizações já tem um processo de Planejamento de
Release, e na maior parte desses processos o planejamento é feito no
início do trabalho da release e não é modificado com o passar do
tempo.
No Planejamento de Release do Scrum, são definidos uma meta geral e
resultados prováveis. Esse planejamento geralmente não requer mais do que
15-20% do tempo que uma organização costumava utilizar para produzir um
plano de release tradicional. No entanto, uma release com Scrum realiza
planejamento no momento da execução de cada reunião de Revisão de
Sprint e de Planejamento de Sprint, da mesma forma que realiza um
planejamento diário no momento da execução de cada Reunião Diária.

De forma geral, os esforços para uma release com Scrum provavelmente
consomem ligeiramente mais esforço do que os esforços para um
planejamento de release tradicional.

O planejamento da release requer estimar e priorizar o Product Backlog
para a release. Existem diversas técnicas para fazê-lo, mas o SCRUM é um
framework, não indica nenhuma técnica.
Contudo, nessa aula abordaremos algumas técnicas para estimar o Product
Backlog


Visão Geral da Reunião de Planejamento da Release:

Entradas Saídas

Release

Burndown
(artefato)

Visão do Produto

Reunião de
Planejamento
da Release

Product Backlog (visão inicial)
Product Backlog (priorizado e estimado)

Os participantes:
Equipe SCRUM
Plano de Release

Reunião de Planejamento da Release: Fazendo estimativas
Visão inicial do Product Backlog, antes da reunião de Planejamento da
1 Release, ele tem somente as funcionalidades do produto, agrupadas
por tema (este agrupamento é opcional).
Uma das atividades da reunião de Planejamento da Release é definir
o Plano de Release, nesse plano estabelece-se o prazo de entrega

(estimado) do produto e nível 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 é responsável por fazer a estimativa dos itens do Product
Backlog.

2


Por que estimar é difícil ?
Em um projeto desenvolvimento de software quase todas as variáveis são incertas...
O Cone da Incerteza:
No início de um projeto, detalhes específicos sobre a natureza do software a ser construído, os detalhes
dos requisitos específicos, os detalhes da solução, plano de projeto, equipe e outras variáveis do projeto
são claras. A variabilidade desses fatores contribui para a variabilidade de estimativas do projeto - uma

estimativa exata de um fenômeno variável deve incluir a variabilidade do fenômeno em si. Como estas
fontes de variabilidades são investigados e tratadas, a variabilidade no projeto diminui ao longo do tempo
(no decorrer do projeto), e assim a variabilidade no projeto estimada também pode diminuir. Este
fenômeno é conhecido como o "Cone da Incerteza", que é ilustrado na figura a seguir. Como a figura
sugere, a redução significativa do Cone ocorrem durante os primeiros 20-30% do tempo total de
calendário para o projeto.

O eixo horizontal contém etapas do projeto comum, como
conceito inicial, definição do produto aprovado, requisitos
completos, e assim por diante. "Definição do produto"
refere-se apenas ao acordado visão para o software, ou
"conceito de software", e é igualmente aplicável aos
serviços de web, sistemas internos de negócios, e a
maioria dos outros tipos de projetos de software.
O eixo vertical contém o grau de erro que foi encontrado
nas estimativas criado por estimadores qualificados em
vários pontos do projeto. As estimativas poderiam ser para
o quanto um conjunto de características particulares vai
custar e quanto esforço será necessário para entregar esse
conjunto de recursos, ou poderia ser de quantos recursos
podem ser entregues para uma determinada quantidade de
esforço ou programação.
Como você pode ver na figura, as estimativas criadas logo
no início do projeto estão sujeitos a um elevado grau de
erro. Estimativas iniciais são mais imprecisas do que as
Cone da Incerteza outras variáveis que foram criadas ao longo do projeto.

Fonte: http://www.construx.com/Page.aspx?hid=1648


O Cone da Incerteza: (continuação)
Quando trabalhamos com Métodos ágeis, o SCRUM por exemplo, é que podemos observar este
fenômeno invertido, explicando melhor, se perguntarmos a um desenvolvedor que já esta trabalhando em
um projeto o que ele consegue entregar nas próximas 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, não há como ter plena certeza do que irá
acontecer.
A única certeza que podemos ter em qualquer projeto de software é de que as coisas vão 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 mudanças.
E em projetos ágeis, não faz o Clone da Incerteza desaparecer, mas temos sempre mais certeza sobre
as estórias do usuário que estão priorizadas para o próxima Sprint ou estamos trabalhando neste
momento e vamos melhorando nossas estimativas e aumentando a precisão delas conforme os itens do
Product Backlog vai sendo entregues, mas, com uma visão muito clara do curto prazo e menos clara
para o que esta no fim do Product Backlog.
Importante: As estórias do usuário que estão sendo desenvolvidas no Sprint são 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/


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 visão equivocada.
- Estimativa (Mundo real) = Valor aproximado
- Estimativa (Desenvolvimento de Software) = Valor exato

Cena 1 – Sprint Review Cena 2 – Planejamento da Sprint
???? ????
Vocês erraram Preciso de uma
a estimativa ... data estimada
???? exata..
????

PO Equipe PO Equipe

Pontos de Estória (Story Points): Dias ideias (Ideal Days):
◦ Valores relativos ◦ Mais fácil para iniciantes
◦ Mais abstrato ◦ Fácil de explicar

Estimando Product Backlog:
Quando trabalhamos com métodos ágeis temos pelo menos duas formas para estimar a velocidade da
equipe: Ideal Days e Pontos de Estória. Recomendamos utilizar os Pontos de Estória.

Ideal Days: Dias Ideais (Ideal Days)
◦ Mais fácil para iniciantes Baseado na duração de tarefas.

◦ Fácil de explicar - Dias ou horas é unidade bem definida, contudo o “tempo ideal”
quase nunca é igual ao “tempo real”...
- É mais fácil de estimar, mas pode ser tornar difícil de estimar se
consideramos todas as interrupções e variações

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 necessário para concluir uma estória do usuário
“sem interrupções ou reuniões” Esta ideia ressalta que os desenvolvedores
eventualmente executam outras atividades durante o dia, além de programar.

Pontos de Estória: Pontos de Estória (Story Points)
◦ Valores relativos Baseia-se no tamanho da estória influenciado pela:
◦ Mais abstrato - Nível de dificuldade, complexidade e experiência (é empírico);
Foco nas funcionalidades;
O importante são os valores relativos;
Pontos são medidas sem unidade;
Equipe diferentes podem ter pontos diferentes para a mesma
estórias.
Principais técnicas:
◦ Opinião de especialista (alguém que está ajuda a implementar o
Scrum na empresa – as vezes um Coach);
◦ Analogia;
◦ Decomposição (Dividir para conquistar) ou Desagregação.

Técnicas que ajudam a Estimar:
Existem 3 técnicas que podem ajudar a fazer estimativas:
Estimativa por analogia:
- Comparando a estória do usuário com outra estória:
"Esta estória é muito parecida com aquela de Cadastro de Cliente, nós estimamos aquela estória

com 11 pontos...”
- Não utilize um único padrão (técnica). Procure utilizar pelo dois ou mais padrões.
- Triangulação:
“Comparar a estória que está sendo estimada em com várias outras estórias”

Desagregação:
- Quebrar uma estória do usuário “grande” em estória “menores” ou tarefas
É mais fácil estimar com base em tarefas
- Cuidado, a desagregação em excesso pode caurar problemas:
Como esquecimento de algumas tarefas

Triangulação:
- Certifique que estimativa será feita, comparando
a estória do usuário com várias outras estórias Estória A
- Grupo de estória do usuário com tamanho
próximos estão em uma tabela ou quadro branco,
isto facilita o trabalho.
Estória B Estória D Estória F

Estória C Estória E

Fonte: Agile Estimating and Planning – Mike Cohn


Estimando os itens do Product Backlog:
Detalhando os itens do Produto Backlog em estórias do usuário:
Para facilitar o entendimento dos
itens do Product Backlog ele são
descritos em estórias do usuário
elas auxiliam no entendimento do
que deve ser feito, permite fazer a

estimativa de velocidade da equipe
e também é, utilizada como
lembrete e para as atividades de
planejamento. Geralmente a
estimativa é feita em pontos
(pontos de estória)

Como escrever uma Estória do Usuário ?
Conversações sobre a estória, entre os usuários e desenvolvedores, de modo a detalhar o item do
Product Backlog e esclarecer todas as dúvidas sobre do que deve ser feito.
Estória do Usuário Cartão: Estória do Usuário são tradicionalmente
Titulo: “Fazer Reserva de Apartamentos” escritas em um cartão. Cartão podem ter notas,
estimativas, comentário observações e etc
Como cliente de negócio, eu quero fazer reserva de

apartamentos pela web para facilitar o meu
Conversas: Detalhes que podem surgir durante as
conversas com PO (Product Owner) e/ou cliente.
planejamento.
Confirmação: Testes de aceitação “confirmam” se
a Estória do Usuário foi codificada da forma correta.
Pontos: ? Prioridade: Alta Testes de aceitação são tipo Caixa Preta.

Boa Prática: A Estória do Usuário deve prover o entendimento do que deve ser feito e deve facilitar a estimativa
de velocidade da equipe.

Estimativa* e o Planning Poker:
Para fazer estimativa de velocidade da equipe ou de duração da Sprint, antes é preciso o escrever as
estórias do usuário.
O Planning Poker é uma “prática” que ajuda na estimativa de uma estória ou de uma tarefa e é baseada

no consenso de toda a equipe.

Geralmente o Planning Poker usa um conjunto de cartas com valores específicos que
podem representar pontos relativos e é praticado como se fosse um jogo de cartas. Os
pontos devem estar em uma escala não 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 começar o jogo é necessário definir um valor de referência. Por exemplo: Identificar a estória
que pode ser atribuído a menor quantidade pontos, esta estória será utilizada como referência para
pontuação das demais estórias.
O PO apresenta uma estória e pede para os membros da equipe fazer a estimativa de velocidade...

1ª. Rodada Quando todas as cartas Nª. Rodada
40
100 estiverem lançadas, elas 40 40
são viradas e caso não
Pessoal, qual é haja consenso nos
estimativa para
essa estória... pontos, as diferenças são
discutidas de forma
breve, e uma nova
40 40
40 rodada acontece até que 40

haja concesso.

Product Owner Equipe Equipe

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 reunião..

Escrevendo as Estórias do Usuário

Product Backlog

Planning Poker
20
20

Pessoal, qual é
estimativa para
essa estória...

40
20

Product Owner Equipe

Estimando

Product Backlog Estimado:
Após a estimativa de todos os itens do Product Backlog, o próximo passo é fazer a priorização
dos itens. Veja o Product Backlog com as estimativas.

Os itens do Product Backlog possuem os atributos de descrição, estimativa e prioridade. A prioridade
é determinada por risco, valor e necessidade.

O Product Backlog nunca está completo. A seleção 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 é dinâmico, 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 também
existirá.
Resumo: O clico de vida do Product Backlog está ligado ao ciclo de vida do Produto

Reunião de Planejamento da Release: PB estimado

1
2

Definição da estimativa do Product Backlog

Versão inicial do Product Backlog,
sem estimativa e nem priorização.

Após a equipe concluir a estimativa do Product Backlog é necessário fazer

Plano de Release
3 a priorização dos itens. Isto é responsabilidade do PO.

Relacionamento Programa de
Sprints# Reserva Promoções Tour Virtual 5 Sprints
ao cliente Fidelidade

Nível de
? ? ? ? ?
Prioridade
Prazo
30 dias 15 dias 7 dias 15 dias 15 dias 82 dias
(estimado)

Como criar, estimar, priorizar e manter o Product Backlog Reunião de Planejamento da Release. Check List parcial

Falta priorizar, mas isso é assunto para próxima aula



1 2 3 4








Como Priorizar o Product Backlog


Apresentar e discutir como “Priorizar” o Product Backlog.

Pré-requisito:

Framework SCRUM:
Artefatos e Regras.


O foco 24 horas
desse
Backlog Backlog
Produto
Sprint
(2-4 Semanas)
Visão
Legenda:
Reuniões
Artefatos

Eventos (Reuniões)
Papéis Artefatos
Release Burndown

Introdução, a Reunião de Planejamento da Release:
Na reunião de Planejamento da Release o Product Backlog é estimado e priorizado.
A equipe é responsável 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.


24 horas

Produto Sprint
Backlog Backlog
Produto
Sprint
2-4 Semanas
Visão


Versão inicial do Product Backlog:
Após a definição da Visão do Produto, devemos definir a primeira “versão” do Product Backlog,
note que ele não foi estimado nem priorizado.



{Review} Reunião de Planejamento da Release:

O propósito do planejamento da release é o de estabelecer um plano e
metas que a Equipe Scrum e o resto da organização possam entender e
comunicar.

O planejamento da release responde às questões:
- Como podemos transformar a visão em um produto da melhor maneira
possível?
- Como podemos alcançar ou exceder a satisfação do cliente ?
- Como podemos alcançar 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 características
gerais e funcionalidades que estarão contidas na release.
Ele estabelece também uma data de entrega e custo prováveis que
devem se manter se nada mudar. A organização pode então inspecionar
o progresso e fazer mudanças nesse plano da release a cada Sprint.

Contudo, O planejamento da release é inteiramente opcional. Se uma
Equipe Scrum iniciar o trabalho sem essa reunião, a ausência 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 são construídos iterativamente, de
modo que cada Sprint cria um incremento do produto, iniciando pelo de
maior valor e maior risco. Mais e mais Sprints vão adicionando
incrementos ao produto.


{Review} Reunião de Planejamento da Release:

Cada incremento é um pedaço potencialmente entregável 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 organizações já tem um processo de Planejamento de
Release, e na maior parte desses processos o planejamento é feito no
início do trabalho da release e não é modificado com o passar do
tempo.
No Planejamento de Release do Scrum, são definidos uma meta geral e
resultados prováveis. Esse planejamento geralmente não requer mais do que
15-20% do tempo que uma organização costumava utilizar para produzir um
plano de release tradicional. No entanto, uma release com Scrum realiza
planejamento no momento da execução de cada reunião de Revisão de
Sprint e de Planejamento de Sprint, da mesma forma que realiza um
planejamento diário no momento da execução de cada Reunião Diária.

De forma geral, os esforços para uma release com Scrum provavelmente
consomem ligeiramente mais esforço do que os esforços para um
planejamento de release tradicional.

O planejamento da release requer estimar e priorizar o Product Backlog
para a release. Existem diversas técnicas para fazê-lo, mas o SCRUM é um
framework, não indica nenhuma técnica.
Contudo, nessa aula abordaremos algumas técnicas para priorizar o
Product Backlog


Visão Geral da Reunião de Planejamento da Release:

Entradas Saídas

Release

Burndown
(artefato)

Visão do Produto

Reunião de
Planejamento
da Release

Product Backlog (visão inicial)
Product Backlog (priorizado e estimado)

Os participantes:
Equipe SCRUM
Plano de Release

Reunião de Planejamento da Release: Priorizando
Visão inicial do Product Backlog, antes da reunião de Planejamento da
1 Release, ele tem somente as funcionalidades do produto, agrupadas
por tema (este agrupamento é opcional).
Uma das atividades da reunião de Planejamento da Release é definir
o Plano de Release, nesse plano estabelece-se o prazo de entrega

(estimado) do produto e nível de prioridade dos itens do Product
Backlog.

A equipe é responsável por fazer a estimativa dos itens
2 do Product Backlog.

Após a estimava dos itens do Product Backlog é necessário definir
3 os níveis de prioridades dos itens Product Backlog.


Reunião 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 características gerais e funcionalidades que estarão contidas na release.

Ele estabelece também uma data de entrega e custo prováveis que devem se manter se nada mudar.

A organização pode então inspecionar o progresso e fazer mudanças nesse plano da release a cada
Sprint, se necessário.

Plano de Release

Nível de
? ? ? ? ?
Prioridade



Product Backlog sem priorização
Questões chaves:
1 - Qual item retorna maior valor ao negócio ?
2 - Quais itens devemos entregar primeiro ?
3 - Como priorizar os itens ?

?

?

?

?

?

Objetivo da priorização em métodos á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 serão entregues mais tarde).


Priorização do Product Backlog:
As melhores práticas recomendam que a priorização do Product Backlog deve ser por tema (ou por
categoria), já que a priorizar por estória, nem sempre é possível, pois, poderá existir grau de
dependências entre estórias do usuário.
Fatores de Priorização:
- Valor

- Custo
- Risco

Priorização Baseada em Valor, Custo e Risco:
Existem diversas técnicas 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
fração do valor total do produto ao menor fração do custo total. Em essência, estamos tentando identificar
item (ou funcionalidade) que irá maximizar o valor do produto, dentro das limitações de custo existentes.

Principais Técnicas:

- Kano: Composta por entrevistas com os usuários e opiniões de especialistas.

- Theme Screening: Composta por opiniões de especialistas baseadas em comparação realizadas
com um tema importante.

-Theme Scoring: Baseado em comparações realizadas em um “tem”’ de referência

- Outras:
. Opinião de Especialista
. Técnicas financeiras


Técnicas que ajudam na priorização do Product Backlog:
Modelo Kano:
É um modelo desenvolvido por Noriaki Kano que é usado para compreender as preferências dos
clientes (ou usuários).

O modelo Kano tem 3 tipos de funcionalidades:
- Desejadas: São aquelas funcionalidades que o usuário deseja, mas não tem plena certeza
- Linear: Quantas mais destas tiver melhor
- Mandatório: 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 máximo 20 clientes ou usuários com perfis
diferentes;

- Realizar uma pergunta funcional:
Se na próxima release incluir a emissão da Ordem de Serviço (OS), como você se sentira?
[ X ] Eu vou gostar
[ ] Eu acho que deveria incluir
[ ] Indiferente
[ ] Posso tolerar
[ ] Eu não gostaria disto

- Fazer uma pergunta disfuncional:
Se na próxima release NÃO incluir a emissão da Ordem de Serviço (OS), como você se sentira?
[ ] Eu vou gostar
[ X ] Eu acho que deveria incluir
[ ] Indiferente
[ ] Posso tolerar
[ ] Eu não gostaria disto

Modelo Kano:
Categorizando as respostas:

Agregando resultados:
O que incluir na Sprint ?

- Todas as funcionalidades
Mandatórias
- Algumas funcionalidades
Lineares
- Mas deixe um espaço para as
funcionalidades desejadas


Theme Screening
Theme Screening é uma técnica poderosa e fácil de priorização que pode ser usada para priorizar os
temas e/ou épicos. Também pode ser usado para priorizar projetos ou produtos.
Passos:

1 - identificar os fatores que são significantes (importantes) na priorização dos temas (ou dos épicos).

2 - Selecione um tema como "baseline" (que será utilizado como referência)

3 – Defina a tabela de pesos:
+ - Melhor que a referência
0 - Igual a referência
- - Pior que referência

4 – Faça a avaliação (comparação):
Fazer avaliação/comparação: do Critério x Tema x Tema de Referência. Perguntar: Qual é grau de importância do critério em
relação ao Tema ?

5 – Faça a classificação baseado no score (quando maior for o score maior será o nível de prioridade)

Temas
Baseline
Critério de Seleção Reserva Progr de Fidelidade Promoções Rel com Clientes Tour Virtual
Reserva para próximo verão + + 0 - -
Promoções para baixa temporada + - 0 0 -
0
0
0
Score 2 0 0 -1 -2
Classificação 1 2 3 4 5


Theme Scoring
É uma técnica de priorização que pode ser usada para priorizar os temas (grupos de estórias do usuário)
e/ou épicos (estórias do usuário grandes). Também pode ser usado para priorizar projetos ou produtos.
Passos:

1 - identificar os fatores que são significantes (importantes) na priorização dos temas (ou dos épicos).

2 – Defina o peso para cada critério

3 - Selecione um tema como "baseline" (que será utilizado como referência)

4 – Defina a tabela de pesos:
5 – Muito Melhor que a referência
4 – Melhor que a referência
3 – Igual a referência
2 - Pior que a referência
1 - Muito pior que a referência

5 – Faça a avaliação:
Fazer avaliação de cada tema em relação ao candidato tema de referência.

6 – Faça a classificação baseado no score (quando maior for o score maior será o nível de prioridade)

Reserva (referência) Progr de Fidelidade Promoções Rel com Clientes Tour Virtual
Critério de Seleção Peso Pontos Score Pontos Score Pontos Score Pontos Score Pontos Score
Reserva para próximo verão 5 3 15 2 10 1 5 2 10 1 5
Promoções para baixa temporada 2 3 6 1 2 3 6 2 4 1 2

Score 21 12 11 14 7
Classificação 1 3 4 2 5


Outras técnicas

Opinião de Especialista:
Um especialista ajuda na definição do nível de prioridade dos itens do Product Backlog..

Foco: Dever ser na “entrega de valor para cliente”.

Considerar 4 fatores:
- Entrega novas capacidades
- Desenvolvimento novos conhecimentos
- Mitigação do Risco
- Mudanças no custo relativo

Técnicas Financeiras
Utilização de técnicas financeira para ajudar na priorização dos itens do Product Backlog.

TIR - Taxa interna de retorno

ROI – Taxa de Retorno sobre investimento

Payback

Valor Presente Liquido (VPL)


Reunião de Planejamento da Release: PB estimado

1

2

Product Backlog estimado e priorizado

Alta

Médio
Versão inicial do Product Backlog,
sem estimativa e nem priorização. Médio

Baixo

Baixo

Plano de Release
3 Plano de Release, como status de “Pronto”

Nível de
Alto Médio Médio Baixo Baixo
Prioridade
Prazo
(estimado)

Reunião 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 esforços restantes do Product Backlog ao longo do
tempo. O esforço estimado deve estar em qualquer unidade de medida de trabalho que a equipe e a
organização tenham decidido usar. As unidades de tempo geralmente são Sprints.

Release Burndown
120
O Product Owner é responsável
por manter o Product Backlog e
o Release Burndown atualizados
108 e publicados todo o tempo.
Uma linha de tendência pode ser
80
traçada baseada na mudança do
Pontos (estimados)

trabalho restante.

68

40
48 40

20

0
Release #1 Release #2 Release #3 Release #4 Release #5
Releases


Como criar, estimar, priorizar e manter o Product Backlog Reunião de Planejamento da Release. Check List final



1 2 3 4








Apresentar e discutir como “Manter” o Product Backlog.

Pré-requisito:


Como Manter o Product Backlog

Framework SCRUM:
Artefatos e Regras.


O foco 24 horas
desse
Backlog Backlog
Produto
Sprint
(2-4 Semanas)
Visão
Legenda:
Reuniões
Artefatos

Eventos (Reuniões)
Papéis Artefatos
Release Burndown

Review: Product Backlog:
Visão do Product Backlog:

Alta

Médio

Médio

Baixo

Baixo

O Product Backlog é dinâmico, 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
é necessário para desenvolver e lançar um produto. A lista deve
conter todas as características, funções, tecnologias, melhorias e
correções de defeitos que constituem as mudanças que serão
efetuadas no produto para futuras releases .


Quem é Responsável por Manter o Product Backlog ?
O Product Owner (PO) é a única pessoa responsável pelo gerenciamento do Product Backlog e
por garantir o valor do trabalho realizado pela Equipe.
O PO mantém o Product Backlog (PB) e assegura que ele está visível para todos. Todos sabem
quais itens têm a maior prioridade, de forma que todos sabem em que se irá trabalhar.
O Product Owner deve ser uma pessoa, e não um comitê. Podem existir comitês 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 métodos para definir prioridades e requisitos
ao longo do tempo.
Para que o PO obtenha sucesso, todos na organização precisam respeitar suas decisões.
Somente o PO pode definir a prioridade dos itens que a equipe irá trabalhar.
As decisões do Product Owner são visíveis no conteúdo e na priorização do Product Backlog. Essa
visibilidade requer que o Product Owner faça 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.


Manter o Produto “Backlog” atualizado:
O Product Backlog poderá sofrer atualizações no decorrer de uma reunião de Planejamento de
uma Sprint.
Exemplo: Quando uma estória do usuário é considerada “épico”, ele será dividida em outras estórias e
isto deverá ser refletido no Product Backlog.


24 horas

Produto Sprint
Backlog Backlog
Produto
Sprint
2-4 Semanas
Visão


Na Reunião de Revisão da Sprint o Product Backlog poderá sofrer alterações.
Exemplo: Uma Sprint onde não foi atingido a meta ou o que foi entrega não estava em conformidade
coma definição de pronto, neste as estórias de usuário da Sprint devem voltar ao Product Backlog.


24 horas

Produto Sprint
Backlog Backlog
Produto
Sprint
2-4 Semanas
Visão


O Product Backlog também poderá ser alterado
quando o cliente solicita novas funcionalidades
e quando deseja retirar alguma funcionalidade
do Product Backlog.


Quer mais ?
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 missão da comunidade é compartilhar conhecimento, trocar experiências e prover
aprendizado.

Como criar, estimar, priorizar e manter o Product Backlog Licença:


Notas:
Marcas Registradas:

Todos os termos mencionados que são reconhecidos como Marca Registrada e/ou comercial são de
responsabilidades de seus proprietários. O autor informa não 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, não visando ao lucro, favorecimento ou desmerecimento da marca ou produto.

Melhoria e Revisão:

Este material esta em processo constante de revisão e melhoria, se você encontrou algum problema
ou erro envie um e-mail nós.

Criticas e Sugestões:

Nós estamos abertos para receber criticas e sugestões que possam melhorar o material, por favor
envie um e-mail para nós.

Imagens:
Google, Flickr e Banco de Imagem.

Rildo F dos Santos (rildo.santos@etecnologia.com.br)

Como
criar,

estimar,
priorizar e
manter o
Product
Backlog

www.etcnologia.com.br

Rildo F Santos
rildo.santos@etecnologia.com.br
twitter: @rildosan
(11) 9123-5358 skype: rildo.f.santos
(11) 9962-4260 http://rildosan.blogspot.com/
Versão 2.0 Mar/2011 | Rildo F Santos | (@rildosan) | rildo.santos@etecnologia.com.br | www.etecnologia.com.br | http://etecnologia.ning.com

Como Criar, Estimar, Priorizar e Manter o Product Backlog

Mais conteúdo relacionado

Mais procurados

Semelhante a Como Criar, Estimar, Priorizar e Manter o Product Backlog

Mais de Rildo (@rildosan) Santos

Como Criar, Estimar, Priorizar e Manter o Product Backlog