Gerencie seu 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


Conteúdo do Workshop:

1 2 3 4








Objetivo dessa parte:
Apresentar e discutir como “Estimar” 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 2:

Como Estimar 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.


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

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.

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.

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:
A estimativa e a priorização devem ser feitas na 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.

Estimando os itens do Product Backlog:
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

Gerencie seu Product Backlog

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Gerencie seu Product Backlog

Similar to Gerencie seu Product Backlog (20)

More from Rildo (@rildosan) Santos

More from Rildo (@rildosan) Santos (20)

Gerencie seu Product Backlog