A verdade
sobre projetos
Scrum – Visão
Geral
Sprints
O papel de
ScrumMaster
O papel de
Time
Escalando
Scrum
Scrum na sua
empresa
Workshop Scrum
O papel de
Product Owner
Product
Backlog
Reuniões
Sprint Planning
Release
Planning
Visibilidade
Workshop Scrum
Agenda
• O que colaborou para que seus projetos tenham sido
bem sucedidos?
Exercício
• O que colaborou para que seus projetos tenham sido
mal sucedidos?
•
O Standish Group vem, há mais de uma década,
realizando estudos em volta dos resultados dos
projetos de software ao redor do mundo. O resultado
destes estudos é um relatório batizado de Chaos
Report;
• Segundo o Standish Group quais foram os principais
fatores para esta melhora?
• Segundo o Standish Group quais os principais fatores
para um número ainda tão alto de projetos que não
alcançam seu objetivo?
• A vasta maioria dos projetos de software falha por
Chaos Report
• A vasta maioria dos projetos de software falha por
falta de clareza – sobre responsabilidades e requisitos
– e também por inabilidade para acompanhar o que
ocorre em cada um dos diferentes passos do ciclo de
vida da aplicação.
7%
13%
16%
45%
Média de uso de funcionalidades de sistemas
Uso de funcionalidades
19%
Sempre
Frequentemente
Às vezes
Raramente
Nunca
Standish Group, 2010
• A comunicação entre as partes envolvidas nos
projetos é muito fraca;
• A visibilidade do andamento real e dos problemas
existentes nos projetos é muito fraca;
• Clientes pedem sempre mais do que realmente
Resumindo . . .
• Clientes pedem sempre mais do que realmente
precisam;
• Os projetos são caros e, ainda em sua maioria, não
alcançam sucesso;
• Os conflitos existentes entre TI e negócios durante
os projetos são muitos;
A verdade
sobre projetos
Scrum – Visão
Geral
Sprints
O papel de
ScrumMaster
O papel de
Time
Escalando
Scrum
Scrum na sua
empresa
Workshop Scrum
O papel de
Product Owner
Product
Backlog
Reuniões
Sprint Planning
Release
Planning
Visibilidade
Workshop Scrum
Agenda
Nova versão do Scrum?
Mais de 100
Ferramenta
“Scrum+
Management
2.0”
O que é Scrum?
Vídeos “How
to Sell Scrum”
por Ken
Schwaber
Mais de 100
modelos de
relatórios
50 horas de
suporte
técnico
Check-lists para
avaliar o seu nível
de maturidade
com Scrum
•
É um processo interativo e
incremental para o
desenvolvimento de qualquer
produto e gerenciamento de
qualquer projeto;
O que é Scrum?
•
É mais um framework que uma
metodologia, mais atitute que
um processo;
•
Processo empírico de
gerenciamento e controle;
•
Inspeção e adaptação em loops
de feedback;
•
Entrega frequente de
Scrum é...
•
Entrega frequente de
funcionalidades com valor para o
cliente;
•
Escalável a projetos distribuídos e
SCRUM,but ...
Atividade: O melhor Plano
Tabela de Valores
Passo Curto
R$ 20,00
Passo Longo
R$ 40,00
Virada
R$ 10,00
“Estamos descobrindo maneiras melhores de desenvolver software
fazendo-o nós mesmos e ajudando outros a fazê-lo. Através desse
trabalho, passamos a valorizar:
Indivíduos e interação entre eles mais que processos e ferramentas
Produto em funcionamento mais que documentação abrangente
O Manifesto Ágil
Produto em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os
itens à esquerda."
•
Product Owner
Responsável por garantir o ROI (Retorno de Investimento);
Responsável por conhecer as necessidades do(s) cliente(s);
Proxy em ambientes com mais de um cliente;
•
ScrumMaster
Responsável por remover os impedimentos do time;
Papéis no Scrum
Responsável por remover os impedimentos do time;
Responsável por garantir o uso de Scrum;
Protege o time de interferências externas;
•
Time
Definir metas das iterações;
Auto-gerenciamento;
Responsabilidades de cada papel
Atividade
Responsável
Responsabilidades
Gerenciar a Visão
Product Owner
O Product Owner estabelece, nutre e comunica a visão do produto. Ele consegue o investimento inicial e de andamento para o projeto através da criação de um Plano de Releases e de um Product Backlog inicialGerenciar o ROI
Product Owner
O Product Owner monitora o projeto através das metas de ROI e da visão de investimento. Ele atualiza e prioriza o Product Backlog para assegurar que a funcionalidade mais valioza seja desenvolvida primeiro. Ele prioriza e refina o Product Backlog e mede sucesso vs. despesas.mede sucesso vs. despesas.
Gerenciar a Sprint de
desenvolvimento
Time
Durante uma Sprint o time seleciona e desenvolve as funcionalidaes de maior prioridade no Product Backlog.Coletivamente, o time expande os itens do Product Backlog em pequenas tarefas, criando assim o Sprint Backlog., e depois gerencia o seu próprio trabalho .
Gerenciar o processo
ScrumMaster
O ScrumMaster é responsável por direcionar o time para o sucesso assegurando-se que o projeto e a cultura organizacional estão otimizadas para atender os objetos do ROI. Isto envolve a organização de uma reunião de planejamento e de uma reunião de revisão, a proteção do time de influências externas, aotimização das reuniões diárias e a remoção de impedimentos.
Gerenciar a entrega
Product Owner
O Product Owner toma a decisão sobre quando criar uma entrega oficial. Por uma série de razões pode não ser desejável entregar o produto na conclusão de cada incremento.Estrutura do Scrum
Estrutura do Scrum
• O Product Owner define a Visão do Produto. Esta Visão é o que representa sua necessidade, é o que deve ser satisfeito ao fim do projeto;
• Para definir esta Visão o PO colhe informações junto a clientes, usuários final, time, gerentes, stakeholders, executivos, etc.;
Estrutura do Scrum
• O PO cria uma lista inicial de necessidades que precisam ser produzidas para que a Visão do projeto seja bem sucedida;
• Esta lista de necessidades é chamada de Product Backlog.
Estrutura do Scrum
• O PO cria uma lista inicial de necessidades que precisam ser produzidas para que a Visão do projeto seja bem sucedida;
• Esta lista de necessidades é chamada de Product Backlog;
• O ScrumMaster deve auxiliar o PO na elaboração desta lista.
Estrutura do Scrum
• No início de cada iteração (Sprint) o time deve se reunir para realizar a Planning Meeting;
• Nesta reunião o time realizará o planejamento do que será entregue ao final do ciclo da Sprint (que deve ser de 2 a 4 semanas).
Estrutura do Scrum
• Na primeira parte da Planning Meeting o PO deverá: definir a meta da Sprint e falar para o time sobre os Itens mais prioritários do Product Backlog;
• O time deve estimar os Itens em tamanho (caso ainda não estejam estimados) e selecionar o que acredita que possa ser feito durante a Sprint. Essa lista selecionada chama-se Selected Product Backlog;
Estrutura do Scrum
• Na segunda parte da Planning Meeting o time deverá colher mais detalhes dos Itens do Selected Product Backlog e decompô-los em tarefas, gerando assim o Sprint Backlog;
• Para isso pode ser necessária a ajuda de Especilistas de Domínio;
• Após a decomposição, cada membro do time deve selecionar as tarefas que deseja executar durante a Sprint (sempre negociando com o time) e estimá-las em horas;
• O facilitador desta reunião é o ScrumMaster.
Estrutura do Scrum
• Durante a execução da Sprint, valem as práticas de engenharia definidas para o projeto;
• O ScrumMaster, através da sua capacidade de liderança e colaboração, facilita o trabalho do time removendo os impedimentos encontrados e garantindo a boa aplicação do Scrum;
• Durante a Sprint o time pode sentir necessidade de consultar Especistas de Domínio, ou mesmo o Product Owner;.
Estrutura do Scrum
• Diariamente o time realiza uma reunião de 15 minutos (Daily Meeting) na qual cada membro deve responder:
• O que fiz desde a última reunião? • O que pretendo fazer até a próxima? • Tive (estou tendo) algum impedimento? • Através desta reunião o time ganha visibilidade de como está o caminho para a meta e planeja o dia seguinte de trabalho;
• O ScrumMaster novamente é o facilitador, e deve lembrar-se que a reunião é para o time e não para ele.
Estrutura do Scrum
• Ao final da execução da Sprint deve ser realizada a Review Meeting, reunião que tem como propósito apresentar o que foi feito para o Product Owner e convidados;
• O time é quem realiza a apresentação, que deve ser feita no formato de demo;
• Product Owner avalia se a Meta da Sprint foi alcançada;
• Product Owner faz anotações que poderão se tranformar em novos Itens para o Product Backlog.
Estrutura do Scrum
• A última cerimônia de um Sprint Scrum é a Retrospectiva;
• Reunião de lições aprendidas, facilitada pelo ScrumMaster, na qual o time deve avaliar: o que foi bom na última Sprint? O que deve ser melhorado? Quem está no controle?
• Esta reunião representa o espírito de Inspeção-Adaptação dentro do Scrum;
• É uma reunião do time, mas – caso seja de acordo de todos seus membros – o PO também pode participar.
A verdade
sobre projetos
Scrum – Visão
Geral
Sprints
O papel de
ScrumMaster
O papel de
Time
Escalando
Scrum
Scrum na sua
empresa
Workshop Scrum
O papel de
Product Owner
Product
Backlog
Reuniões
Sprint Planning
Release
Planning
Visibilidade
Workshop Scrum
Agenda
• A Sprint é um time-box de 2 a 4 semanas no qual o
time do projeto irá produzir uma parte do produto
definida pelo cliente
• O conceito de Sprint nos remete à necessidade de
estarmos frequentemente entregando algo de
valor para o cliente.
Conceito de Sprint
valor para o cliente.
• Uma Sprint deve ser empreendida por um time
multi-disciplinar com não mais que 9 membros
• Cada Sprint deve ter uma meta específica que
represente o desejo do cliente para aquele time-box
específico
• O que significa “pronto” para você em um
projeto ?
• Você concorda com essa definição? Por que?
Diálogo: Definindo “pronto”
• Quais problemas você percebe com essa definição
de “pronto”?
• Ao final de cada Sprint, o time deve ter produzido um
incremento potencialmente entregável do produto
• Com alta qualidade, testado, completo e pronto
• Potencialmente entregável ≠ entregável
Incremento do produto
R1
S1
S2
S3
S4
S1, S2, S3 e S4 são produtos potencialmente entregáveis
• Specific – Específico
• Measurable – Mensurável
• Achivable – Atingível
Uma Sprint deve ser SMART
• Achivable – Atingível
• Realistic – Realista
• Timed – Datado
• Sempre entregar valor para o cliente ao final de
cada Sprint
• Nunca esquecer: o deadline é sagrado, as
funcionalidades é o que podem variar
Sempre entregar valor!
• Se houver necessidade de incluir tarefas técnicas,
arquiteturais, estudos, ou qualquer tipo de tarefa
que não forneça valor visível para o cliente: fazer
balanceamento entre estas tarefas e as com alto
ROI
S
e
m
p
re
e
n
tr
e
g
a
r v
a
lo
r!
Itens técnicos, arquitetura...
Ite
ns
co
m R
OI
vis
ív
el
S
1
S
6
S
5
S
4
S
3
S
2
Itens técnicos, arquitetura...
Ite
ns
co
m R
OI
vis
ív
el
• O tamanho ideal de uma Sprint é o tamanho que
seu time e cliente achar ideal. Encontre o seu!
• Observe:
• Mudança constante no topo do Product Backlog: ideal
Tamanho de Sprints
• Mudança constante no topo do Product Backlog: ideal
trabalhar com Sprints curtos
• Dificuldade de entregar valor para o cliente ao fim das
Sprints: ideal trabalhar com Sprints curtos
• Time e/ou cliente exaustos com loops tão curtos: ideal
trabalhar com Sprints longos
• O Product Owner é quem possui a visão
de qual o período ideal para distribuir
uma nova versão do produto
• Observe:
Tamanho do Release
• Observe:
• Não adianta entrega produto tão
rapidamente de forma a tornar impossível o
acompanhamento de atualização do cliente
• Um Release deve ser algo integrado e de
• O que o time se comprometeu a entregar – e o que
foi acordado com o Product Owner – é o que deve ser
entregue
• Quando mudar o conteúdo da Sprint se torna regra:
• Cliente deixa de sentir necessidade de fazer um
Sem mudanças durante a Sprint
• Cliente deixa de sentir necessidade de fazer um
planejamento de qualidade, bem como de estar atento a
uma boa composição e priorização do Product Backlog;
afinal, se pode mudar a qualquer momento, para que se
preocupar com isso?
• Time ignora meta, afinal “com certeza” ela mudará
• Time perde foco e motivação
• Umas Sprint pode ser terminada
antes da sua finalização nas
seguintes situações:
• O time sente que não conseguirá
atingir a meta
• O Product Owner percebe que
Parando a Sprint antes da sua finalização
• O Product Owner percebe que
mudanças em fatores externos
influenciarão diretamente no valor
da meta da Sprint
• Caso uma Sprint seja cancelada deve se iniciar
imediatamente o planejamento da próxima Sprint
A verdade
sobre projetos
Scrum – Visão
Geral
Sprints
O papel de
ScrumMaster
O papel de
Time
Escalando
Scrum
Scrum na sua
empresa
Workshop Scrum
O papel de
Product Owner
Product
Backlog
Reuniões
Sprint Planning
Release
Planning
Visibilidade
Workshop Scrum
Agenda
A maioria dos projetos entregam
software a cada 6 a 18 meses.
Scrum reduz isso a muitas entregas
mensais que incrementam o controle
via inspeção e adaptação.
ScrumMaster revela a realidade
Isto permite ao time e a organização, maior
visibilidade, expondo problemas e
limitações, ou seja, expondo o que está por trás da “janela suja”.
O trabalho do ScrumMaster é priorizar estes problemas e ajudar a
organização a superá-los, gerenciando investimentos e garantindo o
seu retorno.
Um ScrumMaster deve:
•
Remover a barreira entre desenvolvimento e cliente
•
Ensinar o cliente a maximir o ROI e atingir seus
objetivos através do Scrum
•
Melhorar o dia-a-dia dos membros do time facilitando
a criatividade e fortalecimento
• Priorizar os impedimentos e combatê-los
Responsabilidades do ScrumMaster
• Priorizar os impedimentos e combatê-los
• Auxiliar o Product Owner com o Product Backlog
• Garantir o uso do Scrum
• Quais seriam alguns dos desafios que um
ScrumMaster iria ter caso ele também fosse um
membro do time?
• O que poderia ajudar a superar estes desafios?
Diálogo: Como membro do time!
• Se assegure que todo mundo está fazendo o que
se comprometeu a fazer
• Determine onde Scrum está, comparado com
onde poderia estar e atualize seu próprio Product
Backlog
Um dia na vida de um ScrumMaster
Backlog
• Trabalhe no Product Backlog com o Product
Owner
• Um ScrumMaster inútil é um ScrumMaster
morto...você acha que pode ser feliz morto?
A verdade
sobre projetos
Scrum – Visão
Geral
Sprints
O papel de
ScrumMaster
O papel de
Time
Escalando
Scrum
Scrum na sua
empresa
Workshop Scrum
O papel de
Product Owner
Product
Backlog
Reuniões
Sprint Planning
Release
Planning
Visibilidade
Workshop Scrum
Agenda
Um Product Owner deve:
• Definir a visão do produto (product vision);
• Gerenciar o retorno de investimento (ROI);
• Apresentar ao time os requisitos necessários
para a entrega do produto;
• Priorizar cada requisito de acordo com seu
valor para o negócio/cliente;
Responsabilidades do Product Owner
valor para o negócio/cliente;
• Gerenciar a entrada de novos requisitos e suas
priorizações;
• Planejar entregas (releases);
• Atuar como facilitador quando mais de um cliente estiver
envolvido no projeto;
• Garantir que Especialistas de Domínio estejam disponíveis
para o time;
Product Vision Box:
• Materializar a idéia do produto/projeto a ser elaborado
Remember the Future:
• Mapear passos que serão necessários para chegar ao objetivo
A verdade
sobre projetos
Scrum – Visão
Geral
Sprints
O papel de
ScrumMaster
O papel de
Time
Escalando
Scrum
Scrum na sua
empresa
Workshop Scrum
O papel de
Product Owner
Product
Backlog
Reuniões
Sprint Planning
Release
Planning
Visibilidade
Workshop Scrum
Agenda
•
Assumimos que há um nível
avançado de conhecimento de tudo
•
Alto consumo de tempo para
escrever e ler; um tédio para
escrever
Por que não apenas especificar?
•
Trata o aprendizado do cliente
como “mudança de escopo”
•
Difíceis de se adequar ao
desenvolvimento iterativo e
incremental
Documentação substitui a comunicação?
Qual o propósito dos Backlog Itens?
“...representar os requisitos do cliente
mais que documentá-los.”
• O primeiro passo em um projeto Scrum é de responsabilidade do
Product Owner, que deve articular a visão do produto;
• O Product Backlog representa esta visão, ele deve ser apresentado
no formato de uma lista com itens priorizados e ordenados
de acordo com o valor que representam para o cliente e negócio;
Product Backlog
• O Product Backlog irá existir por todo o ciclo de vida do projeto e é regularmente
atualizado pelo Product Owner para refletir as necessidades do cliente, mudanças
estratégicas ou tecnológicas, novas idéias, enfim...mudanças;
• Um Product Backlog é composto de vários tipos de itens: funcionalidades, requisitos
de desenvolvimento, exploração técnica, estudo, documentação, bugs, etc.
User Stories
User Stories
Card ( Cartão)
Os três C’s da User Story
Conversation ( Conversas)
Alexandre Magno, CST
•
Story-Writing Workshops são reuniões que
incluem desenvolvedores, usuários, cliente
e product owner;
•
Durante este workshop os participantes
escrevem a quantidade de estórias que
conseguirem;
Story-Writing Workshop
•
Prioridades não são associadas;
•
Bons workshops combinam os melhores elementos de brainstorming
e prototipação de desenho;
Uma empresa de taxi aéreo deseja elaborar um site onde seja possível ao
seus clientes realizar a compra de bilhetes, pesquisar vôos, realizar Check-in
on-line e pesquisar serviços relacionados como hotéis e shows
Home-page
Pesquisa vôos
Check-in
Pesquisar
Story-Writing Workshop
Pesquisa vôos
Compra
bilhetes
Paga pela
compra
Reservar
lugares
Check-in
on-line
serviços
relacionados
Pesquisar
hotéis
Pesquisar
shows
Quem?
Quem?
O que?
O que?
Como um
<PERFIL>
eu
posso/gostaria/devo
<FUNCTION>
para
<VALOR AO NEGÓCIO>
O que?
O que?
Por que?
Por que?
Como um
INSTRUTOR
eu devo
APONTAR A LISTA DE PRESENÇA
DOS ALUNOS
para
MANTER AS
INFORMAÇÕES DO TREINAMENTO
ATUALIZADAS
Como um cliente de
negócios eu posso realizar
check-in on-line para
acelerar meu embarque
Como um cliente de turismo
Como um cliente eu posso
pesquisar vôos para
visualizar as informações
que necessito
Como um agente de viagens
Story-Writing Workshop
Como um cliente de turismo
eu posso reservar hotel para
fazer uma compra conjunta
Como um cliente de turismo
eu posso comprar ingressos
para shows para fazer uma
compra conjunta
Como um agente de viagens
eu posso reservar lugares
para dar um diferencial no
atendimento a meus clientes
•
Em um projeto ideal nós devemos ter uma única pessoa
responsável pelo trabalho de priorização das estórias;
•
Uma característica marcante de projetos “stories-driven” é
que clientes e usuários estão comprometidos no projeto em
toda sua duração;
Observações
•
“User stories” devem ser compreensíveis por todos:
usuários, cliente e time de desenvolvimento;
•
Uma das melhores formas de se expressar em uma estória
alguns dos detalhes discutidos entre cliente (Product Owner,
Especialista de Domínio, ...) é a escrita de Testes de
Aceitação;
Teste de aceitação
Como um usuário eu posso
exportar dados em XML
para poder integrar minhas
informações com outros
sistemas
• Testar abrir no Microsoft
Excel o arquivo exportado;
• Testar com Visa,
MasterCard e Aura (passar)
• Testar com cartões
expirados (falhar)
Como um cliente
cadastrado eu posso
Teste de aceitação
expirados (falhar)
• Testa com valores acima
do limite (falhar)
• Testar com cartão de
pessoa física (falhar)
cadastrado eu posso
pagar meu
bilhete com cartão de
crédito para agilizar
•
Escrever Testes de Aceitação antes da
codificação;
•
O cliente é quem deve especificar Testes de
Aceitação;
•
Teste DEVEM fazer parte do processo;
Teste de aceitação - Prática
•
Teste DEVEM fazer parte do processo;
•
Automatização de Testes de Aceitação
•
Script de Testes
•
Alguns tipos de testes
•
Teste de Interface;
•
Teste de Usabilidade;
•
Teste de Performance;
•
Teste de Stress;
EPIC
STORY
STORY
STORY
STORY
STORY
STORY
Stories, Temas e Epics
STORY
TEMA
STORY
STORY
STORY
STORY
STORY
STORY
STORY
STORY
• As Estórias são apropriadas para o seu ambiente
de trabalho?
• Quais os desafios você visualiza para utilizá-las?
Diálogo: User Stories ( Estórias)
• Quais as vantagens que você visualiza em
utilizá-las?
A verdade
sobre projetos
Scrum – Visão
Geral
Sprints
O papel de
ScrumMaster
O papel de
Time
Escalando
Scrum
Scrum na sua
empresa
Workshop Scrum
O papel de
Product Owner
Product
Backlog
Reuniões
Sprint Planning
Release
Planning
Visibilidade
Workshop Scrum
Agenda
• O que fiz desde a última
reunião?
• O que pretendo fazer até
a próxima;
Estou tendo
Daily Meeting (Reunião Diária)
• Estou tendo
impedimentos?
• Você acredita que uma reunião diária de 15
minutos pode atrapalhar seu time? Por que?
• Quais os ganhos que seu time pode obter
realizando uma reunião diária?
Diálogo: Daily Meeting
realizando uma reunião diária?
• Que ações você, como ScrumMaster, poderia
tomar para fazer com que seu time tivesse
• Reunião diária não é coffee-break
• Reunião diária não é bate-papo
• Reunião diária não é “conversa sobre a
As armadilhas das reuniões diárias
• Reunião diária não é “conversa sobre a
relação”
•
Apresentação do resultado
da iteração para os clientes
•
Todos os envolvidos no
projeto participam
Review Meeting
• Devolver ao Product Backlog funcionalidades não
terminadas e repriorizá-las
• Remover do Product Backlog funcionalidades que foram
finalizadas antecipadamente
• Repriorização do Product Backlog
• Solicitar o fechamento de um Release com as
Consequências da Review Meeting
• Solicitar o fechamento de um Release com as
funcionalidades demonstradas, sozinhas ou com o
incremento de Sprints anteriores
• Escolher não avançar mais com o projeto e não autorizar
outra Sprint
• Solicitar que o progresso do projeto seja acelerado
autorizando a inclusão de times adicionais para trabalhar no
Product Backlog
•
Melhoria de processos no final
de cada Sprint
•
Falicitada pelo ScrumMaster
•
O que foi bom? O que deve ser
melhorado?
•
O ScrumMaster prioriza os itens
citados de acordo com a direção
Retrospectivas
citados de acordo com a direção
do time
•
O time propõe soluções para a
maioria dos problemas que a
atrapalham/irritam
•
Retrospectivas são a essência do
conceito de inspeção e adaptação
O que foi bom? O que deve melhorar?
Quem está no controle?
Time
Empresa
Time
Empresa
Impediments
Backlog
A verdade
sobre projetos
Scrum – Visão
Geral
Sprints
O papel de
ScrumMaster
O papel de
Time
Escalando
Scrum
Scrum na sua
empresa
Workshop Scrum
O papel de
Product Owner
Product
Backlog
Reuniões
Sprint Planning
Release
Planning
Visibilidade
Workshop Scrum
Agenda
•
A Sprint Planning Meeting ou Reunião de Planejamento, é dividida em
duas partes, e entra em cena no início de cada Sprint.
•
Além de todos os comprometidos (PO, SM e Time), alguns envolvidos
podem ser convidados a participar em determinados momentos da
reunião, desde que agreguem valor à mesma e tenham seu convite
aprovado pelo Product Owner.
•
Pela prática, percebemos que a duração desta reunião segue a
Sprint Planning Meeting
•
Pela prática, percebemos que a duração desta reunião segue a
seguinte tabela:
•
Velocidade é uma medida da
produtividade do Time;
•
Representa a taxa de trabalho que o Time
conseguiu completar durante um Sprint;
Velocidade
•
Serve de guia para o planejamento de Sprints.
•
Serve de guia para o planejamento de Releases e
progresso do projeto.
Atividade: Velocidade
Parte II
Parte I
Planejamento por velocidade
Ajuste de
prioridades
Identificar a
meta da
Selecionar
Itens do
Quebra Itens
Determinar
velocidade
meta da
Sprint
Itens do
Backlog
Quebra Itens
em tarefas
Estimar
tarefas
Planejamento por compromisso
Ajuste de
prioridades
Pergunte se
time se
compromete
Selecionar
um Item do
Backlog
Finaliza
Sprint
Planning
Se compromete; ainda pode fazer maisSe compromete; mas não consegue incluir mais nada
compromete
Identificar a
meta da
Sprint
Quebra Itens
em tarefas
Estimar
tarefas
Remove o
Item
Planning
Não seResultado do planejamento de Sprint
A verdade
sobre projetos
Scrum – Visão
Geral
Sprints
O papel de
ScrumMaster
O papel de
Time
Escalando
Scrum
Scrum na sua
empresa
Workshop Scrum
O papel de
Product Owner
Product
Backlog
Reuniões
Sprint Planning
Release
Planning
Visibilidade
Workshop Scrum
Agenda
Planejamento de Release
Selecionar
um tamanho
de Sprint
Continua planejando Releases até que a Visão do produto seja alcançada
