Escolar Documentos
Profissional Documentos
Cultura Documentos
criar,
estimar,
priorizar e
Workshop SCRUM
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 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010
O Conteúdo do workshop:
1 2 3 4
Criar Estimar Priorizar Manter
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 2
Workshop SCRUM 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.
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 3
Programa: “Menos Papel, Mais Árvores ®”
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..
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 4
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
Workshop SCRUM
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;
Onde estou:
Twitter: @rildosan
Blog: http://rildosan.blogspot.com/
Comunidade: http://etecnologia.ning.com
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 5
Conteúdo do Workshop:
1 2 3 4
Criar Estimar Priorizar Manter
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 6
Workshop SCRUM Objetivo:
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.
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 7
Workshop SCRUM Parte 1:
O foco 24 horas
Workshop SCRUM
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
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010
9
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.
Workshop SCRUM
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 10
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.
Workshop SCRUM
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
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 11
Workshop SCRUM Framework Scrum: Artefatos
- 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.
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 12
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).
Workshop SCRUM
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
Workshop SCRUM
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.
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 14
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.
Workshop SCRUM
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 15
Definindo a Visão do Produto:
Introdução:
Qualquer produto está necessariamente associada a uma visão, pois, a visão deve descrever o 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
Workshop SCRUM
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 16
Definindo a Visão 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 é estruturado em 6 partes que resumem em menos de dois minutos a Visão do Produto.
• 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.
Segundo Highsmith (2004). O Produto Vision Box é uma técnica altamente relevantes para iniciar um
projeto para construir a visão e compartilhá-lo com a equipe responsável 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).
Workshop SCRUM
“Product Vision Box “ é uma técnica que ajuda no entendimento da Visão do Produto, pois, quando
fazemos uma representação visual do produto (embalagem, por exemplo) isto auxilia na redução do
nível de abstração (ou seja, melhora o entendimento do que ser feito).
- Nome do Produto:
- Logotipo ou desenho que
represente o produto
Workshop SCRUM
http://www.qualitystreet.fr/2009/07/29/la-vision-du-produit/
Fonte:
Agile Project Management: Creating Innovative Products - Jim Highsmith
Cap. 5 - Practice: Product Vision Box and Elevator Test - Pg. 93
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 19
Como criar o Product Backlog
Após a definição da Visão do Produto, devemos definir a primeira “versão” do Product Backlog:
Workshop SCRUM
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.
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 20
Workshop SCRUM Estudo de Caso: Visão do Produto
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 21
Conteúdo do Workshop:
1 2 3 4
Criar Estimar Priorizar Manter
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 22
Workshop SCRUM Objetivo:
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.
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 23
Workshop SCRUM Parte 2:
O foco 24 horas
Workshop SCRUM
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
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010
25
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
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 26
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
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 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 27
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.
Workshop SCRUM
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.
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 28
Reunião de Planejamento da Release:
A estimativa e a priorização devem ser feitas na Reunião de Planejamento da Release.
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 29
Reunião de Planejamento da Release:
A estimativa e a priorização devem ser feitas na Reunião de Planejamento da Release.
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 30
Visão Geral da Reunião de Planejamento da Release:
Entradas Saídas
Release
Burndown
(artefato)
Visão do Produto
Workshop SCRUM
Reunião de
Planejamento
da Release
Os participantes:
Equipe SCRUM
Plano de Release
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 31
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.
Workshop SCRUM
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 32
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
Workshop SCRUM
sugere, a redução significativa do Cone ocorrem durante os primeiros 20-30% do tempo total de
calendário para o projeto.
Fonte: http://www.construx.com/Page.aspx?hid=1648
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 33
Por que estimar é difícil ?
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
Workshop SCRUM
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 34
Por que estimar é difícil ?
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
PO Equipe PO Equipe
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.
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
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 37
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)
Workshop SCRUM
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.
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 38
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:
Workshop SCRUM
haja concesso.
Product Backlog
Planning Poker
20
20
Pessoal, qual é
estimativa para
essa estória...
40
20
Estimando
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 40
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.
Workshop SCRUM
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
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 41
Reunião de Planejamento da Release: PB estimado
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)
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 42
Workshop SCRUM Reunião de Planejamento da Release. Check List parcial
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 43
Conteúdo do Workshop:
1 2 3 4
Criar Estimar Priorizar Manter
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 44
Workshop SCRUM Parte 3:
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.
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 46
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
Workshop SCRUM
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
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010
47
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 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 48
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.
Workshop SCRUM
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.
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 49
{Review} Reunião de Planejamento da Release:
A estimativa e a priorização devem ser feitas na Reunião de Planejamento da Release.
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 50
{Review} Reunião de Planejamento da Release:
A estimativa e a priorização devem ser feitas na Reunião de Planejamento da Release.
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 51
Visão Geral da Reunião de Planejamento da Release:
Entradas Saídas
Release
Burndown
(artefato)
Visão do Produto
Workshop SCRUM
Reunião de
Planejamento
da Release
Os participantes:
Equipe SCRUM
Plano de Release
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 52
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.
Workshop SCRUM
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 53
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.
Workshop SCRUM
Plano de Release
Relacionamento Programa de
Sprints# Reserva Promoções Tour Virtual 5 Sprints
ao cliente Fidelidade
Nível de
? ? ? ? ?
Prioridade
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 54
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 ?
Workshop SCRUM
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).
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 55
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
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:
- Outras:
. Opinião de Especialista
. Técnicas financeiras
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 56
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).
Agregando resultados:
O que incluir na Sprint ?
- Todas as funcionalidades
Mandatórias
- Algumas funcionalidades
Lineares
- Mas deixe um espaço para as
funcionalidades desejadas
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 58
Técnicas que ajudam na priorização do Product Backlog:
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).
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
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 59
Técnicas que ajudam na priorização do Product Backlog:
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).
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
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 60
Técnicas que ajudam na priorização do Product Backlog:
Outras técnicas
Opinião de Especialista:
Um especialista ajuda na definição do nível de prioridade dos itens do Product Backlog..
Considerar 4 fatores:
Workshop SCRUM
Técnicas Financeiras
Utilização de técnicas financeira para ajudar na priorização dos itens do Product Backlog.
Payback
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 61
Reunião de Planejamento da Release: PB estimado
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”
Relacionamento Programa de
Sprints# Reserva Promoções Tour Virtual 5 Sprints
ao cliente Fidelidade
Nível de
Alto Médio Médio Baixo Baixo
Prioridade
Prazo
30 dias 15 dias 7 dias 15 dias 15 dias 82 dias
(estimado)
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 62
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
Workshop SCRUM
trabalho restante.
68
40
48 40
20
0
Release #1 Release #2 Release #3 Release #4 Release #5
Releases
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 63
Workshop SCRUM Reunião de Planejamento da Release. Check List final
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 64
Conteúdo do Workshop:
1 2 3 4
Criar Estimar Priorizar Manter
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 65
Workshop SCRUM Objetivo:
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.
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 66
Workshop SCRUM Parte 4:
O foco 24 horas
Workshop SCRUM
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
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010
68
Review: Product Backlog:
Visão do Product Backlog:
Alta
Médio
Workshop SCRUM
Médio
Baixo
Baixo
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 69
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.
Workshop SCRUM
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.
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 70
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
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 71
Manter o Produto “Backlog” atualizado:
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
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 72
Manter o Produto “Backlog” atualizado:
O Product Backlog também poderá ser alterado
quando o cliente solicita novas funcionalidades
e quando deseja retirar alguma funcionalidade
do Product Backlog.
Workshop SCRUM
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 73
Quer mais ?
Os membros da comunidade podem participar dos eventos, treinamentos e cursos gratuitos.
Comunidade: http://etecnologia.ning.com/
Workshop SCRUM
Versão 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010 75
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.
Workshop SCRUM
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.
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 1 Ago 2010 | RFS rildo.santos@etecnologia.com.br Todos os direitos reservados e protegidos © 2006 e 2010