Gerenciamento de Projetos

LIVRO 23
SCRUMBOK Iniciar
Sumário
1. Processos da fase Iniciar 5. Desenvolver os Épicos
2. Criar a Visão do Projeto 6. Criar o Backlog Priorizado
3. Identificar o Scrum Master do Produto
e o Stakeholder(s) 7. Conduzir o Planejamento
4. Formar o Time Scrum da Release
8. Referências
Processos da fase Iniciar
8.1 Criar a Visão do Projeto — Neste processo, o Caso de Negócio do Projeto é revisado para criar
uma Declaração da Visão do Projeto que servirá de inspiração e orientação para todo o projeto.
8.2 Identificar o Scrum Master e o(s) Stakeholder(s) — Nesse processo, o Scrum Master e os
stakeholders são identificados, utilizando Critérios de Seleção específicos.
8.3 Formar o Time Scrum — Nesse processo, os membros do Time Scrum são identificados. Normalmente,
o Dono do Produto seleciona os membros do time, porém, muitas vezes com a ajuda do Scrum Master.
8.4 Desenvolver o(s) Épico(s) — Nesse processo, a Declaração da Visão do Projeto serve como base
para o desenvolvimento dos Épicos.
8.5 Criar o Backlog Priorizado do Produto — Nesse processo, os Épicos são refinados e elaborados, e
em seguida priorizados, para criar o Backlog Priorizado do Produto para o projeto.
8.6 Conduzir o Planejamento da Release — Nesse processo, o Time Central do Scrum analisa as
Estórias de Usuário no Backlog Priorizado do Produto para desenvolver um Cronograma de
Planejamento da Release, que é essencialmente, um cronograma de implantação por fases que pode ser
compartilhado com os Stakeholders.

1 2 3 4 5 6 7 8 9 10
Processos da fase Iniciar
Estes são as entradas,
ferramentas e saídas
obrigatórias para os
processos da fase
Iniciar.
Nas próximas páginas
veremos todos os
processos, não apenas
os obrigatórios.

1 2 3 4 5 6 7 8 9 10
Processos da fase Iniciar

1 2 3 4 5 6 7 8 9 10
Criar a Visão do Projeto Entradas
Caso de Negócio do Projeto, expressa a razão para iniciar o projeto. Ele pode incluir informações substanciais sobre o
background do projeto; a finalidade do negócio pretendido e os resultados desejados, uma lista de riscos identificados, e
estimativas de tempo, esforço e custo. Ele é apresentado aos stakeholders e patrocinadores. Os stakeholders compreendem
os benefícios do negócio, e os patrocinadores confirmam que irão fornecer os recursos.
O Dono do Produto do Programa é a pessoa responsável por
maximizar o valor do negócio, por articular as necessidades do
cliente e por manter a justificativa de negócio do programa.
O Scrum Master do Programa é um facilitador que garante
que todos os times no programa, sejam favorecidos com um
ambiente propício a conclusão do projeto com sucesso.
Stakeholder(s) do Programa é um termo coletivo que inclui os
clientes, usuários e patrocinadores (para um programa), que
influenciam todos os projetos do programa.
O Dono do Produto Chefe é responsável por coordenar o
trabalho de vários Donos do Produto. Ele prepara e mantém o
Backlog Priorizado do Produto completo para o projeto.

1 2 3 4 5 6 7 8 9 10
Criar a Visão do Projeto Entradas
Backlog do Produto do Programa contém uma lista de prioridades de negócios e de requisitos do projeto de alto
nível, preferencialmente escrito, sob a forma de grandes Itens do Backlog do Programa.
O Teste do Projeto, se possível, pode ser executado, como uma experiência para prever e avaliar a viabilidade,
tempo e custo, riscos, e possíveis efeitos do projeto real.
A Prova de Conceito demonstra e comprova que a ideia do projeto é potencialmente viável no ambiente do mundo
real. Um protótipo é projetado para determinar a viabilidade técnica e financeira, entender os requisitos e auxiliar na
avaliação de decisões de design, no início do processo.
Compreender a Visão da Empresa ajuda o projeto a manter seu foco em objetivos da organização e no potencial
futuro da empresa. O Dono do Produto pode utiliza essas informações para criar a Declaração da Visão do Projeto.
A Missão da Empresa orienta a formulação das estratégias da empresa, e em geral orienta a tomada de decisão. O
cumprimento da Visão do Projeto orienta ajuda a organização a cumprir sua missão.
O Estudo de Mercado refere­se à pesquisa, coleta, comparação e análise organizada de dados, relacionados com
as preferências dos clientes para com os produtos. Pode incluir dados extensos sobre as tendências de mercado.
O Scrum Guidance Body (SGB) é opcional. Pode ser um conjunto de documentos e/ou um grupo de especialistas que
estão envolvidos nos assuntos de qualidade, regulamentações governamentais, de segurança e outros.

1 2 3 4 5 6 7 8 9 10
Criar a Visão do Projeto Ferramentas
Reunião da Visão do Projeto reune o(s) Stakeholder(s) do Programa, Dono do Produto do Programa, Scrum Master do
Programa e com o Dono do Produto Chefe. Esta reunião ajuda a identificar o contexto e os requisitos do negócio e as
expectativas dos stakeholders, a fim de desenvolver uma Declaração da Visão do Projeto eficaz. O Scrum acredita em
envolvimento e em colaboração estreita com todos os representantes das empresas para oferecer um valor maior.
Uma sessão de Joint Application Design (JAD) é uma técnica de coleta de requisitos. É um workshop facilitador
altamente estruturado que acelera o processo de Criar a Visão do Projeto, uma vez que permite aos Stakeholders, e
outros tomadores de decisões, que cheguem a um consenso sobre o escopo, objetivo e outras especificações do
projeto.
A Análise SWOT é uma abordagem estruturada para o planejamento do projeto que ajuda a avaliar os pontos fortes
e fracos, as oportunidades e as ameaças relacionadas a um projeto. Este tipo de análise ajuda a identificar os fatores
internos e externos que possam afetar o projeto. Os pontos fortes e fracos são os fatores internos, enquanto que as
oportunidades e ameaças são os fatores externos.
A Análise de Gap é uma técnica usada para comparar o estado atual, real, com o estado desejado. Em uma
organização, isto envolve a determinação e a documentação da diferença entre a capacidade de negócio atual e o
conjunto final de capacidades desejado. Um projeto é normalmente iniciado para trazer uma organização para o
estado desejado, por isso, a realização de uma análise de GAP pode ajudar os tomadores de decisão a determinar a
necessidade de um projeto.

1 2 3 4 5 6 7 8 9 10
Criar a Visão do Projeto Saídas
Dono do Produto é Identificado O Dono do Produto é a pessoa
responsável por maximizar o valor de negócio para o projeto. Sendo a
pessoa responsável por articular as necessidades dos clientes e manter
a justificativa de negócio para o projeto. Ele é a Voz do Cliente.
Declaração da Visão do Projeto é o resultado principal deste
processo. Uma boa Visão do Projeto explica as necessidades do
negócio e o que o projeto se destina a atender.
O Termo de Abertura do Projeto é uma declaração oficial dos
objetivos e resultados desejados em um projeto. Ele é o documento
oficial que formalmente autoriza o início projeto. Fornecendo ao time
uma autorização por escrito para começar os trabalhos do projeto.
O Orçamento do Projeto é um documento financeiro que inclui os
custos de pessoas, materiais e outras despesas relacionadas em um
projeto. Ele é assinado pelo(s) patrocinador(es) para garantir que
existem fundos suficientes. Uma vez assinado, o Dono do Produto e o
Scrum Master estarão envolvidos no gerenciamento do Orçamento.

1 2 3 4 5 6 7 8 9 10
Identificar Scrum Master e Stakeholder
Entradas
Scrum Master Chefe ­ Os Grandes projetos requerem que Times trabalharem em paralelo. As informações coletadas por um
time deve ser devidamente comunicadas aos outros times. O Scrum Master Chefe é responsável por esta atividade.
A Identificação de Requisito de Pessoas é um dos passos
iniciais na seleção do Scrum Master e do(s) Stakeholder(s). É
importante documentar os papéis e as responsabilidades de
todos aqueles que vão estar envolvidos na realização das
tarefas no projeto.
A Comprometimento e Disponibilidade de Pessoas deve ser
confirmada. Somente os membros do time que estarão
disponíveis e que poderão se comprometer totalmente ao
projeto, devem ser selecionados.
A Matriz de Recurso Organizacional é uma representação
hierárquica que reune os membros de diferentes departamentos
funcionais para um projeto.
A Matriz de Requisito de Habilidades, é utilizada para
avaliar as lacunas de habilidades e requisitos de treinamento
para os membros do time.

1 2 3 4 5 6 7 8 9 10
Identificar
A disciplinaScrum Master e Stakeholder
Ferramentas
Critérios de Seleção ­ A Seleção do(s) Scrum Master(s) apropriado(s) e a identificação do(s) Stakeholder(s)
relevante(s) é crucial para o sucesso de qualquer projeto. Em alguns projetos, podem haver condições pré estipuladas
contendo os membros do time e as suas funções. Os seguintes Critérios de Seleção são importantes:
1. Capacidade de resolver problemas 2. Disponibilidade 3. Comprometimento 4. Estilo de Liderança Servidora
Os Conselhos de Especialistas de RH, podem ser valiosos na identificação do Scrum Master e do(s) Stakeholder(s). O
departamento de RH possui conhecimento especializado sobre os colaboradores de uma organização e sobre várias
técnicas que podem ajudar na identificação do Scrum Master e do(s) Stakeholder(s).
Treinamento e Custos de Treinamento adequado deve ser fornecido aos membros do Time Scrum, tanto antes do
início do trabalho, quanto durante a realização do mesmo. Os membros do Time Scrum também devem estar prontos
para aprender uns com os outros, e com as pessoas mais experientes no time.
Custos de Recurso ­ Ao selecionar pessoas tem que ter equilíbrio entre experiência versus salário. Existem outros
fatores relacionados a pessoas que impactam custos, e que às vezes também precisarão ser considerados. Idealmente,
o(s) Scrum Master(s), os membros do time e o(s) stakeholder(s) devem estar no mesmo local de trabalho, para que eles
possam se comunicar com frequência e com facilidade. Se isso não for possível e existirem times distribuídos, recursos
adicionais deverão ser dedicados para facilitar a comunicação, para entender as diferenças culturais, para
sincronizar o trabalho, e para manter o compartilhamento de conhecimento.

1 2 3 4 5 6 7 8 9 10
Identificar Scrum Master e Stackeholder
Saídas
O Scrum Master é Identificado
O Scrum Master é um facilitador e "líder servidor", que garante ao Time
Scrum o fornecimento de um ambiente propício para concluir com
sucesso o projeto. O Scrum Master guia, facilita e ensina as práticas
do Scrum para todos os envolvidos no projeto; remove os impedimentos
encontrados pelo time; e, assegura que os processos do Scrum estejam
sendo seguidos. O Dono do Produto é responsável pela identificação
do Scrum Master para um projeto do Scrum.
Stakeholder(s) é(são) Identificado(s)
Stakeholder(s), é um termo coletivo que inclui clientes, usuários e
patrocinadores, que muitas vezes interagem com o Time Central de
Scrum e que influenciam o projeto durante o processo de
desenvolvimento do produto. É para os stakeholders que o projeto
produz os benefícios colaborativos.Esta identificação é uma das saídas
deste processo.

1 2 3 4 5 6 7 8 9 10
Formar o Time Scrum Entradas
Os Requisitos de Recursos incluem todos os recursos (exceto recursos de pessoal), necessários para o funcionamento
eficaz do Time Scrum. Esses recursos incluem a infra­estrutura de escritório, o espaço para reuniões, os equipamentos de
trabalho, Scrumboards, etc. No caso de times virtuais, outros recursos adicionais devem ser considerados, tais como: as
ferramentas de colaboração; videoconferência, depósito de documentos compartilhados, serviços de tradução, etc.

1 2 3 4 5 6 7 8 9 10
Formar o Time Scrum Ferramentas
Seleção do Time Scrum ­ O Time Scrum é o centro de qualquer projeto Scrum, e é importante obter no time os membros
certos, para a entrega bem sucedida de projetos Scrum. Os membros do Time Scrum são generalistas/especialistas, no
sentido de que possuem conhecimento em várias áreas, e são especialistas em pelo menos uma delas.
Os membros ideias do Time Scrum são independentes, auto­motivados, focados no cliente, responsáveis e
colaborativos.
Os Conselhos de Especialistas do RH, podem ser valiosos na formação do Time Scrum. O departamento de RH possui
conhecimento especializado sobre os colaboradores de uma organização, e sobre várias técnicas que podem ajudar
os Donos do Produto, os Scrum Masters e os patrocinadores a identificarem os membros certos para o time.
Custos de Pessoal­ precisam ser avaliados, analisados, aprovados e orçados.
Treinamento e Custos de Treinamento
Os membros do time podem não possuir as habilidades e conhecimentos necessários para realizar as tarefas
especializadas. O Dono do Produto deve avaliar as necessidades potenciais de treinamento dos membros do time, e
fornecê­lo, quando qualquer gap de habilidade ou de conhecimento for encontrado.
Os custos de Recurso associados a todos os requisitos que não estão relacionados a pessoal, devem ser avaliados,
analisados, aprovados e orçados. Um recurso no ambiente do projeto é qualquer coisa utilizada para executar uma
tarefa ou atividade, incluindo, mas não limitando­se a: equipamento, material, serviços de terceiros, e espaço físico.

1 2 3 4 5 6 7 8 9 10
Formar o Time Scrum Saídas
O Time Scrum é Identificado, que é um grupo de pessoas que são
responsáveis por entender os requisitos de negócio especificados
pelo Dono do Produto, estimar as Estórias de Usuário e criar os
entregáveis finais do projeto.
Pessoal para Backup , para membro do Time Scrum, porque
problemas podem surgir; como uma doença, emergência familiar, ou
um membro do time deixando a organização.
Plano de Colaboração descreve como os vários tomadores de
decisão, stakeholders, e membros do time devem se envolver e
colaborar uns com os outros é vital.
Plano de Team Building ­ Considerando que um Time Scrum é
multifuncional, cada membro precisa participar ativamente de todos
os aspectos do projeto. O Scrum Master deve identificar problemas
potenciais que possam surgir com os membros do time, e tentar
resolvê­los de forma diligente utilizando o Plano de Team Building, a
fim de manter um time eficaz.

1 2 3 4 5 6 7 8 9 10
Desenvolver o(s) Épico(s) Entradas
O Time Central do Scrum é constituído pelo Time Scrum, Scrum Master e Dono do Produto.
Solicitações de Mudança Aprovadas provenientes do
programa ou portfólio, são entradas que devem ser
adicionadas à lista de mudanças do projeto aprovadas, para
implementação em Sprints futuros.
Solicitações de Mudança Não Aprovadas
Os pedidos de mudanças são geralmente apresentados na
forma de Solicitações de Mudança. As mesmas permanecem não
aprovadas até que sejam formalmente aprovadas.
Riscos de Programa e de Portfólio que também terão impacto
sobre projetos que fazem parte do respectivo portfolio ou
programa. Durante a avaliação de riscos, se for determinado
que um risco pode afetar um projeto, informações relevantes ao
risco devem ser comunicadas ao Dono do Produto e ao Time.
Dependendo do projeto, temos Leis e Regulamentos impostos
pelos órgãos do governo, o que impacta no planejamento e na
execução.

1 2 3 4 5 6 7 8 9 10
Desenvolver o(s) Épico(s) Entradas

Contratos Aplicáveis ­ Se o projeto está sendo cumprido por meio de um contrato, o contrato define o
escopo do trabalho e as condições específicas do projeto. Alguns dos tipos de contrato:
Contrato de Entrega Incremental — Este contrato inclui pontos de inspeções em intervalos regulares,
ajudando os stakeholders a tomarem decisões sobre o desenvolvimento do produto periodicamente.
Contrato Joint Venture — Este contrato é geralmente usado quando duas ou mais partes formam uma
parceria para a realização do trabalho de um projeto.
Contrato de Desenvolvimento em Fases — Esse contrato assegura a disponibilização de fundos a
cada mês ou a cada trimestre, após a conclusão de uma release com êxito.
Contrato de Incentivo e Penalidade — Se o fornecedor entrega o produto no tempo, será
recompensado com um incentivo financeiro, se a entrega for atrasada, incorrerá em sanções financeiras.
Informações sobre o Projeto Anterior são inputs valiosos para o desenvolvimento dos Épicos e para a
avaliação do risco. As Informações podem incluir observações de gerente de projetos, registros de
projeto e comentários por parte dos stakeholders.
As Recomendações do Scrum Guidance Body podem incluir informações sobre as regras, regulamentos,
padrões, e sobre as melhores práticas para o desenvolvimento de Épicos.

1 2 3 4 5 6 7 8 9 10
Desenvolver o(s) Épico(s) Ferramentas
As Reuniões do Grupo de Usuários envolvem o(s) Stakeholder(s) relevante(s), principais usuários ou clientes do
produto. Eles fornecem ao Time Central do Scrum informações de primeira mão sobre as expectativas do usuário.
Os Workshops da Estória de Usuário são realizados como parte do processo de Desenvolver Épico(s). O Scrum
Master é o facilitador dessas sessões. O Time Central do Scrum inteiro está envolvido e, por vezes, é desejável incluir
outros Stakeholders. Esses workshops ajudam o Dono do Produto a priorizar os requisitos, e permite que o Time Central
do Scrum tenha uma perspectiva compartilhada dos Critérios de Aceitação.
Reuniões dos Grupos de Foco reúnem indivíduos em uma sessão orientada para apresentar suas opiniões,
percepções ou avaliações com relação a um produto, serviço ou resultado desejado.
Entrevistas de Usuários ou Clientes são importantes para se adquirir o contexto necessário e o insight requerido
para o desenvolvimento dos Épicos. O tempo de qualidade gasto nas entrevistas de usuários e de clientes, irá resultar
na garantia de que os requisitos dos Épicos se alinham aos da Visão geral do Projeto.
Questionários são uma maneira econômica de se obter uma visão estatística quantitativa e qualitativa de um
grande número de usuários ou clientes, é através da utilização de pesquisas ou Questionários.
Expertise do Scrum Guidance Body pode ser relacionada às regras e aos regulamentos documentados, ou padrões
e melhores práticas, para a criação de Épicos. Também pode existir um time de especialistas no assunto.

1 2 3 4 5 6 7 8 9 10
Desenvolver o(s) Épico(s) Saídas

Os Épicos são escritos nas fases iniciais do projeto, quando a

maioria das Estórias de Usuário são funcionalidades de alto nível ou
quando as descrições de produtos e requisitos são amplamente
definidas. São Estórias de Usuário grandes e não refinadas no
Backlog Priorizado do Produto.
As Personas são personagens fictícios altamente detalhados,
representantes da maioria dos usuários, bem como outros stakeholders,
que podem não usar diretamente o produto final. As Personas são
criadas para identificar as necessidades base do usuário­alvo.
Mudança Aprovadas ­ As Solicitações de Mudança Não Aprovadas
poderão ser aprovadas pelo Dono do Produto durante o processo
Desenvolver o(s) Épico(s), às vezes com sugestões fornecidas pelos
stakeholders.
Riscos Identificados durante a criação dos Épicos, formam uma
saída importante desta fase e contribuem para o desenvolvimento do
Backlog Priorizado do Produto (também referido como o Backlog do
Produto do Risco Ajustado).

1 2 3 4 5 6 7 8 9 10
Criar o Backlog Priorizado do Produto
Entradas
Requisitos de Negócio é a soma de todos os conhecimentos
adquiridos através de várias ferramentas, como: entrevistas
com o usuário ou cliente, Questionários, Sessões JAD, Análise de
Gap, Análise SWOT, e outras reuniões, ajudam a ter uma melhor
perspectiva sobre os requisitos de negócio e a criar o Backlog
Priorizado do Produto.
Recomendações do Scrum Guidance Body
Durante a criação do Backlog Priorizado do Produto, as
Recomendações do Scrum Guidance Body podem
incluir informações sobre as regras, regulamentos, padrões e
melhores práticas, para o desenvolvimento do
Backlog Priorizado do Produto.A Identificação

1 2 3 4 5 6 7 8 9 10
Criar o Backlog Priorizado do Produto
Ferramentas
Métodos de Priorização da Estória de Usuário são algumas técnicas utilizadas para priorizar as
Estórias de Usuário, ou os requisitos no Backlog Priorizado do Produto, são apresentadas a seguir:
• Esquema de Priorização MoSCoW—O seu nome deriva das primeiras letras das palavras “Must have”
(deve ter), “Should have” (deveria ter), “Could have” (poderia ter), e “Won’t have” (não vai ter). Este
método de priorização é geralmente mais eficaz do que o de Esquemas Simples.
• Comparação Pareada—Nesta técnica, uma lista de todas as Estórias de Usuário no Backlog
Priorizado do Produto é criada e em seguida, cada Estória de Usuário é comparada individualmente
com as outras Estórias de Usuário da lista, um de cada vez. Cada vez que duas Estórias de Usuário são
comparadas, é tomada uma decisão em relação a qual das duas é mais importante.
• Método de Ponto­100— Trata­se de dar ao cliente 100 pontos que ele pode usar para votar nas
Estórias de Usuário que considerar mais importante.
Alguns Métodos de Estimativa da Estória de Usuáriopodem ser: 1. Reuniões dos Grupos de Usuários
2. Planejamento Poker, 3. Fist of Five, 4. Pontos de Estimativa de Custos, 5. Outras Técnicas de Estimativa
Expertise do Scrum Guidance Body, durante a criação do Backlog Priorizado do Produto, pode ser
relacionada às regras e aos regulamentos documentados, ou padrões e melhores práticas, para a
criação dos Épicos.

1 2 3 4 5 6 7 8 9 10
Criar o Backlog Priorizado do Produto
Saídas
Backlog Priorizado do Produto ­ é desenvolvido pelo Dono do
Produto, e contém uma lista de prioridades de negócios e de requisitos
dos projetos, escritos na forma de Épico(s), que são as Estória de
Usuário de alto nível. Ele é baseado em três fatores principais:
• Valor—O Dono do Produto é o responsável por garantir a entrega
dos produtos que fornecem em primeiro lugar, o nível mais alto de valor
de negócio.
• Risco e Incerteza— Quanto maior a incerteza, mais arriscado será o
projeto. Portanto, é importante que os produtos de maior risco sejam
classificados como de alta prioridade.
• Dependências—Os requisitos funcionais muitas vezes dependem de
outros requisitos funcionais e até mesmo não­funcionais.
• Estimativa— As estimativas de alto nível para o(s) Épico(s), também
estão disponíveis no Backlog Priorizado do Produto.
Os Critérios de Pronto são um conjunto de regras aplicáveis a todas
as Estórias de Usuário. É muito importante ter uma definição clara de
Pronto, porque esta, remove a ambiguidade dos requisitos e ajuda o
time a aderir às normas obrigatórias de qualidade.

1 2 3 4 5 6 7 8 9 10
Conduzir o planejamento da Release
Entradas
Calendário de Férias
É importante para o Time Scrum, manter o controle das datas
em que todos os membros do time estarão disponíveis. Isto
pode ser feito através do uso de um calendário
compartilhado que forneça as informações sobre os feriados
oficiais, férias, planos de viagem, eventos, etc. Este calendário
vai ajudar o time no planejamento e execução dos Sprints.
Recomendações do Scrum Guidance Body
No processo de Conduzir o Planejamento da Release, as
Recomendações do Scrum Guidance Body podem se
relacionar com as regras, regulamentos, padrões e melhores
práticas para desenvolver o Plano da Release. O Guidance
Body pode ser a melhor autoridade para definir as diretrizes
relacionadas ao valor de negócio, as expectativas da
release, as estratégias de implantação, a qualidade e a
segurança.

1 2 3 4 5 6 7 8 9 10
Conduzir o planejamento da Release
Ferramentas
As Sessões de Planejamento da Release servem para desenvolver um Plano da Release. O plano
define quando as funcionalidades ou de produtos utilizáveis serão entregues ao cliente.
Em Scrum, o principal objetivo das Sessões de Planejamento da Release é criar um cronograma de plano
da release, e permitir que o Time Scrum tenha uma visão geral do cronograma da release e entrega,
para que possam então ajustar­se de acordo com as expectativas do Dono do Produto e dos
stakeholders relevantes (principalmente do patrocinador do projeto).
Os Métodos de Priorização da Release são usados para desenvolver um plano da release. Esses
métodos são específicos da indústria e da organização e geralmente são determinados pela alta
administração de uma organização.

1 2 3 4 5 6 7 8 9 10
Conduzir o planejamento da Release
Saídas
Um Cronograma de Planejamento da Release afirma quais
entregáveis devem ser liberados para os clientes, juntamente com os
intervalos planejados e as datas para o seu lançamento.
O Dono do Produto e o Time Scrum decidem sobre a duração dos
Sprints para o projeto. Uma vez determinada, a duração do Sprint é
normalmente fixada para o projeto.
Clientes­alvo para a Release ­ Nem todos os lançamentos terão
como alvo todos os stakeholders ou usuários. O Stakeholder pode
optar por limitar certos lançamentos para um subconjunto de usuários.
Backlog do Produto Priorizado e Refinado
O Backlog Priorizado do Produto, desenvolvido no processo de Criar
o Backlog Priorizado do Produto, pode ser refinado neste processo.
Podendo haver clarificação adicional sobre as Estórias de Usuário no
Backlog Priorizado do Produto após a realização das Sessões de
Planejamento da Release, feitas pelo Time Central do Scrum e pelo(s)
Stakeholder(s).

1 2 3 4 5 6 7 8 9 10
Referências
Guia SCRUMBOK ­ Um guia do Conhecimento em SCRUM ­ Edição 3

1 2 3 4 5 6 7 8 9 10
Só mais uma coisa...

O professor não é dono do saber.

O professor é um organizador de conhecimento, que tem a experiência adequada
para selecionar o que é relevante neste mar infinito de informação.
marco@iftm.edu.br Telegram

Produzido em 2024