Scrum Tutorial Definitivo

rildo.santos@etecnologia.com.brVersão 4 Jun 2013 | RFS
SCRUM®,OTutorialDefinitivo
Todos os direitos reservados e protegidos © 2006 e 2013
Rildo Santos (@rildosan)
rildo.santos@etecnologia.com.br
skype: rildo.f.santos
http://rildosan.com/
(11) 99123-5358
(11) 99962-4260
www.etcnologia.com.br
O Tutorial
Definitivo
versão 4 | Jun 2013

Todos os direitos reservados e protegidos © 2006 e 2013 2
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 equilíbrio 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.

Objetivo:
Objetivo:
O Scrum é um Método Ágil para execução de qualquer projeto ou trabalho.
O Objetivo deste Tutorial é prover conhecimento, apresentar e discutir o SCRUM e suas
práticas aplicadas a projetos de desenvolvimento de software.
Pré-requisito:
Não há.

1 – Desafios do desenvolvimento de Software
2 – Sobre o SCRUM
3 – Entendendo SCRUM
4 – Estudo de Caso
Conteúdo:

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

2 – Sobre o SCRUM
Conteúdo:

Objetivo:
Parte 1 - Desafios do desenvolvimento de Software
Objetivo:
Apresentar e discutir os principais desafios dos projetos de desenvolvimento de software.
Pré-requisito:
Não há.

Desafios do Desenvolvimento
de Software

Quanto tempo vai levar ?
O tempo é outro grande desafio, é raro
(posso até afirmar que não existe) um cliente
que diga: “Demore o tempo que for necessário,
pois, não temos pressa nenhuma”.
Geralmente o cliente quer o software funcionando
Para ontem...
Quanto custará ?
Todo cliente quer saber quanto custará
o software...
O primeiro desafio é conseguir responder qual é o
custo do software e em quanto tempo o cliente vai ter o
software funcionando.
1º. Desafio: Responder ao cliente

2º. Desafio: Falha na Comunicação das equipes de TI

3º. Desafio: Entender as necessidades dos clientes
Quando não se entende as necessidades dos clientes, não se pode entregar valor ao cliente.

4º. Desafio: Compreender por que os projetos falham:
37% das falhas estão
relacionadas com
requisitos
Craig Larman, Agile and Iterative Development: A Manager’s Guide, Addison Wesley Professional
(2004)
12
Informação
errada
13%
Requisitos
incompletos
12%
Mudança de
Requisitos
12%
Falta de
conhecimento
técnico
7%
Falta de
competência
6%
Outros
50%

5º. Desafio: Identificar o que é “necessidade” e o que é “desejo”
Craig Larman, Agile and Iterative Development: A Manager’s Guide, Addison Wesley Professional
(2004)
13
Sempre
7% Freqüentemente
13%
As vezes
16%
Raramente
19%
Nunca
45%
Contudo, a
maioria das
funcionalidades
nunca são
usadas pelos
usuários
Uso de funcionalidades do Software

Como aumentar a produtividade da equipe
de desenvolvimento de software ?
6º. Desafio: Aumentar produtividade da equipe de desenvolvimento:
Satisfação dos Clientes

Qual é a solução ?
Contratar mais desenvolvedores...
Mas, será que a contratação
de novas pessoas garante
o aumento de produtividade ?
A falta de produtividade pode afetar o negócio
The Mythical Man Month by Frederick Brooks, 1975*.
Quando um projeto está atrasado, contratar novas pessoas para ajudar no projeto pode servir apenas
para atrasá-lo ainda mais.
Pois, as novas pessoas precisam primeiro entender o que é projeto, objetivos, escopo,
funcionalidades e etc, para depois começar a produzir, ou seja, temos que considerar o tempo que
será gasto com explicações, orientações, comunicação e treinamento das novas pessoas, devemos
considerar o esforço da gestão de projetos que aumentará
Ao calcular o tempo que será necessário para desenvolver um software, temos que adicionar um
tempo extra, pois os desenvolvedores precisam de "tempo para pensar“, “tempo para pesquisar” além
do "tempo para desenvolver"
"Adicionar novas pessoas a um projeto de software atrasado só adiará a sua entrega." –
A Lei de Brooks

7º. Desafio: Escolher framework certo para desenvolver software ?
Cascata
RUP
SCRUM,
Lean,
Kanban,
XP...

8º. Desafio: Como reter os bons profissionais ?
Quantas vezes já montamos boas equipe, mas de repente as pessoas começam a
sair...a trocar de emprego.
A retenção de bons profissionais é grande desafio da atualidade, pessoas trocam
muito mais de emprego do que a 10 anos atrás.
Insegurança, chefes tiranos, a falta de respeito, falta de reconhecimento e de e ambiente
“estressante” são as algumas das causas que fazem os profissionais de trocarem de
emprego. A maioria das pessoas mudam de emprego por problema com o seu chefe e não
por motivo de salário.

Por que precisamos dos Métodos Ágeis ?
Para enfrentar estes desafios:
Utilização de métodos ágeis,
como SCRUM, pode amenizar
estes problemas.
Problemas clássicos (ou tradicionais):
Stakeholders (Clientes):
- Têm dificuldades em externar suas necessidades
- Geralmente fazem mudanças de requisitos
- Precisam do software funcionando para
ontem
Desenvolvedores:
- Não sabem ou não querem elicitar requisitos
- Dificilmente conseguem atender todas as
demandas de negócio
- Tem dificuldade em comunicar e entender
os clientes

Cliente x Desenvolvedores:
Clientes:
- Alguns clientes têm dificuldades em externar
suas necessidades ou desejos de forma clara e objetiva
(Não sabem o que querem)
- Geralmente fazem mudanças de requisitos durante o
desenvolvimento ou quando o software é entregue.
- Sempre precisam do software funcionando para ontem
- Não têm tempo e nem paciência para falar com os
desenvolvedores.
Desenvolvedores:
- Não sabem ou não querem conversar com o cliente
- Dificilmente conseguem atender o negócio e todas suas
demandas
- Têm dificuldade em se comunicar e entender os clientes

Como enfrentar estes desafios: “O SCRUM é sua sogra”
O SCRUM pode ser uma forma para enfrentar estes desafios, O SCRUM não vai
aumentar a produtividade da equipe, não vai fazer você entregar software mais cedo,
nem melhorar a qualidade do software e nem otimizar os custos do projeto de
desenvolvimento.
O “SCRUM é como sua SOGRA” ele vai apontar os principais problemas, falhas e pontos
críticos (riscos) do projeto de desenvolvimento, aquilo que realmente precisa ser
melhorado, mas se as pessoas envolvidas com o projeto não tomarem nenhuma ação (ou
melhor: tomarem atitudes) os problemas continuaram a existir e levaram a maioria dos
projetos para a “marcha da morte”.
O Scrum vai deixar todos os problemas aparentes.

2 – Sobre o SCRUM
Conteúdo:

Objetivo:
Parte 2 – Sobre SCRUM:
Objetivo:
Apresentar Manifesto Ágil e o SCRUM, as principais características e práticas.
Pré-requisito:
Não há.

Sobre o SCRUM
Parte 2

24
As Raízes do Scrum:
Artigo: “The New, New
Product Development Game
de Nonaka e Takeushi na
Hardvard Bussines Review
TimeBoxes
SmallTalk
Engineering Tools
Desenvolvimento
iterativo e
incremental
Sprint
Backlog
Produto
2-4 Semanas
24 horas
Produto
Backlog
Reunião
diária

O que é TimeBox ?
É duração fixa (imutável).
É um conceito diz que a quantidade de tempo é imutável, ou seja, tem duração
fixa - a quantidade de dias não poderá aumentar. Assim, evita-se atrasos no prazo
de entrega e facilita o planejamento.
No Scrum as cerimônias e/ou eventos com duração fixa (Time-Boxes) são:
- Reunião de Planejamento da Release,
- Sprint (iteração),
- Reunião de Planejamento da Sprint,
- Revisão da Sprint.
- Retrospectiva da Sprint.
- Reunião Diária.
Exemplos de Timebox:
A Sprint (que é uma iteração) que deve ser realizada de 2 a 4 semanas, no qual a
equipe de desenvolvedores deverá produzir um entregável de valor para o cliente
(mais frente discutiremos melhor isto).
A entrega de valor é a meta da Sprint, a duração da Sprint deverá ser combinada
com o cliente, antes do começo da execução da Sprint.
Se foi acertado que a Sprint tem a duração de 4 semanas, logo esta duração
será fixa (não mudará).
Durante a Sprint são realizadas as Reuniões Diárias, uma reunião diária tem a
duração fixa de 15 minutos.
Ao final da Sprint, é feita a reunião de Revisão da Sprint. Para Sprints
de um mês, essa é uma reunião com duração fixa de quatro horas.
Após a Revisão da Sprint e antes da próxima Reunião de Planejamento
da Sprint, a Equipe Scrum tem a Reunião de Retrospectiva da Sprint.
essa reunião, te duração fixa de três horas.

Abordagem Iterativo e Incremental:
Devido a complexidade, tamanho, mudanças de requisitos,
urgência e necessidade de demonstrar valor mais rápido, fica
quase inconcebível desenvolver software utilizando o modelo
cascata, ou seja, desenvolver todo o software em uma única
vez.
Desenvolvimento Iterativo e incremental é uma estratégia de
planejamento (que segue a linha dividir para conquistar) ,
onde o software é construído em partes, ou seja, em ciclos
(iterações), a cada iteração é feito um novo incremento (uma
parte do software funcional) até completar o software.
Incremental
Entrega 1 Entrega 2 Entrega 3
Iterativo

27
O qual é propósito do SCRUM ?
Scrum vem sendo utilizado para o desenvolvimento de
produtos complexos desde o início dos anos 90.
Scrum não é um “processo “ ou uma “técnica “ para o
desenvolvimento de produtos.
Ao invés disso, é um framework dentro do qual você pode
empregar diversos processos e técnicas. O papel do Scrum é
fazer transparecer a eficácia relativa das suas práticas de
desenvolvimento para que você possa melhorá-las, enquanto
provê um framework dentro do qual produtos complexos
podem ser desenvolvidos.
Por ser um framework, o SCRUM não é uma ferramenta, nem
metodologia, nem processo e nem uma solução completa para o
desenvolvimento de software, ele é um framework (uma estrutura),
ou seja um “guia de referência” , isto significa que o “Scrum não
vai lhe dizer como fazer as coisas! “
Por ser um framework, ele pode ser utilizado com as práticas de
engenharia de software e/ou metodologia de desenvolvimento que já
existem dentro da organização.
O SCRUM pode ser utilizado para desenvolver qualquer produto e
não só software.

28
Qual é a teoria do SCRUM ?
A TEORIA DO SCRUM:
Scrum, que é fundamentado na teoria de controle de processos empíricos*, emprega uma
abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos
Processo Definido:
São processos que se conhece todas as variáveis, têm poucas ou nenhuma
mudança ao logo do processo, são repetitivos e são previsíveis.
Geralmente existe uma documentação aplicada a execução do processo.
Exemplo: Linha de produção
*Processos Empíricos:
São aqueles processos que não se conhece todas as variáveis, têm
mudanças ao logo do processo, não são repetitivos e são imprevisíveis.
Geralmente baseado na experiência e no conhecimento de quem executa o
processo.
Exemplo: Desenvolvimento de Software.
Quando desenvolvemos um software as vezes não conhecemos todos os
requisitos, e os requisitos que são conhecidos mudam com certa frequência
e geralmente todas as estimavas são feitas baseada no conhecimento das
pessoas, isto quer dizer, que o mesmo trabalho feito por equipes diferentes
a duração pode variar, pois, a equipe mais experiente deve realizar o
trabalho mais rápido do que a equipe menos experiente. Isso porque o
desenvolvimento de software é um problema complexo, que se comporta de
forma imprevisível.
O que são processos empíricos ?
Antes de responder a pergunta, precisamos saber que existem dois tipos de processos:

29
Os pilares do SCRUM:
Três pilares sustentam qualquer implementação de controle de processos empíricos.

30
O primeiro pilar:
A transparência garante que aspectos
do processo que afetam o resultado
devem ser visíveis para aqueles que
gerenciam os resultados.
Esses aspectos não apenas devem ser
transparentes, mas também o que está
sendo visto deve ser conhecido.
Isto é, quando alguém que inspeciona
um processo acredita que algo está
“pronto”, isso deve ser equivalente à
definição de “pronto” utilizada.
O segundo pilar:
Os diversos aspectos do processo devem ser inspecionados com uma frequência suficiente
para que variações inaceitáveis no processo possam ser detectadas. A frequência da
inspeção deve levar em consideração que qualquer processo é modificado pelo próprio
ato da inspeção. O problema acontece quando a frequência de inspeção necessária
excede a tolerância do processo à inspeção. Os outros fatores são a habilidade e a
aplicação das pessoas em inspecionar os resultados do trabalho.

31
O terceiro pilar:
Se o “inspetor” determinar, a partir da
inspeção, que um ou mais aspectos do
processo estão fora dos limites aceitáveis e
que o produto resultante será inaceitável, ele
deverá ajustar o processo ou o material
sendo processado. Esse ajuste deve ser
feito o mais rápido possível para minimizar
desvios posteriores.
Existem três pontos para inspeção e
adaptação em Scrum. A Reunião Diária (2) é
utilizada para inspecionar o progresso em
direção à Meta da Sprint e para realizar
adaptações que otimizem o valor do próximo
dia de trabalho. Além disso, as reuniões de
Revisão da Sprint (3) e de Planejamento da
Sprint (1) são utilizadas para inspecionar o
progresso em direção à Meta da Release e
para fazer as adaptações que otimizem o
valor da próxima Sprint.
E a Retrospectiva da Sprint (4) é utilizada
para revisar a Sprint passada e estabelecer
que adaptações tornarão a próxima Sprint
mais eficiente, produtiva, recompensadora e
gratificante.
2
1 3
4

O Manifesto Ágil:
Fonte: http://agilemanifesto.org/iso/ptbr/
O SCRUM é um Metodo Ágil

Princípios por trás do Manifesto Ágil:
Nós seguimos estes princípios:
 Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com
valor agregado.
 Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento.
 Processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente.
 Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência à
menor escala de tempo.
 Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por todo o projeto.
 Construa projetos em torno de indivíduos motivados.
 Dê a eles o ambiente e o suporte necessário e confie neles para fazer o trabalho.
 O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de desenvolvimento
é através de conversa face a face.
 Software funcionando é a medida primária de progresso.
 Os processos ágeis promovem desenvolvimento sustentável.
 Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante
indefinidamente.
 Contínua atenção à excelência técnica e bom design aumenta a agilidade.
 Simplicidade -- a arte de maximizar a quantidade de trabalho não realizado -- é essencial.
 As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis.
 Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz e então refina e ajusta seu
comportamento de acordo.

Como Ser Ágil ?
Como ser ágil ?
1 - Para “ser ágil” é preciso colocar em prática os valores e os princípios do Manifesto Ágil.
Exemplo:
Se uma organização implementou o SCRUM e aparentemente tudo ocorre bem...mas, se equipe não
está conseguindo entregar “software funcionando” ao cliente a quatro meses, podemos afirmar que
existe uma equipe ágil ?
Vejamos o que diz o Manifesto Ágil:
“Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com preferência
à menor escala de tempo.”
Podemos concluir que a equipe não é ágil, pois além da implementação do SCRUM, que é um
método ágil, ela também deverá levar em conta os valores e princípios do Manifesto Ágil, ou seja,
entregar software funcionando com certa regularidade.

Como Ser Ágil ?
Como ser ágil ?
2 – Além de implementar o SCRUM para Gestão de Projetos de desenvolvimento de software
também adote práticas de Engenharia de Software Ágil, tais como XP e FDD.

Engenharia de Software 100% “Ágil:
O SCRUM é utilizado para Gestão de Projetos. Já para as práticas de
Engenharia de Software podemos utilizar o FDD para os requisitos de
software e arquitetura e as Práticas do XP para o desenvolvimento de
software (codificação, testes e refactoring).
Como Ser Ágil ?

Método de Gestão de Projetos Tradicionais.
- Não tem auto gestão.
- Não são auto-organizadas.
- São fortemente hierarquizada. Com liderança
baseada no “comando-controle”.
- Equipe formada por especialistas.
Equipe: Tradicional x Colaborativa
auto GestãoTradicional
A auto gestão: Requer alto comprometimento da
equipe, que é a chave para a produtividade. Equipe
motivada produz mais e melhor.
O Comando-controle: Pode levar ao baixo
comprometimento e desmotivação é sinônimo de
baixa produtividade e produtos de baixa qualidade.
Existem alguns tipos de equipe, vamos comparar o formato Tradicional e de auto Gestão:
Como ser ágil ?
3 – Para trabalhar como o SCRUM é preciso trabalhar em equipe:
Método Ágil
- ter auto gestão,
- ser Auto organizada;
- ser Interdisciplinar
- não ter Hierarquia formal,
- ter responsabilidade.

As Características da Equipe:
Interdisciplinares e Sem hierarquia formal:
Equipes também são interdisciplinares: os membros da equipe devem ter todo o conhecimento e
habilidades necessárias para entregar a meta da Sprint.
Membros da equipe geralmente possuem conhecimentos especializados, tais como: programação,
testes, controle de qualidade, análise de negócios, arquitetura, desenho de interface de usuário e
modelagem de dados. No entanto, o conhecimento que os membros devem compartilhar - isto é, a
habilidade de trabalhar um item do Product Backlog (ou um requisito) e transformá-lo em um produto
(software funcionando) tendem a ser mais significativas do que aqueles que eles não dividem.
As pessoas que se recusam a programar porque são arquitetas ou designers não se adaptam bem a
equipe. Todos devem contribuir, mesmo que isso exija aprender novas habilidades ou lembrar-se de
antigas. Na equipe não há hierarquia nem títulos, todos são iguais e não há exceções a essa regra. As
equipes também não devem ter sub-equipe dedicados a áreas particulares como testes, banco de
dados ou análise de negócios.
Como ser ágil ?
3 – Para trabalhar como o SCRUM é preciso trabalhar em equipe:
Auto Gestão e Auto-organização:
A equipe possui a auto gestão e é auto-organizada. Não deve haver
interferência externa, nem o ScrumMaster ou Product Owner - pode dizer
como a equipe deve se organizar ou fazer inferência na forma de trabalho da
equipe. A equipe deve ser capaz de se auto-organizar para dividir e fazer
trabalho.
Equipe de desenvolvedores é muito parecida com um equipe de Volley Ball,
onde todos tem um único objetivo e são interdisciplinares no jogo.
Responsabilidade:
A equipe de desenvolvedores é responsável transformar os itens do Product Backlog em
funcionalidades potencialmente entregáveis a cada Sprint.

Reforçando: “Não existe a Bala de Prata”
SCRUM não é a Bala de Prata:
O SCRUM não é a solução completa para os
problemas de produtividade, complexidade,
custo, prazo e qualidade do processo de
desenvolvimento de software.
“Não existe solução mágica para problemas complexos”
Contudo, você pode utilizar o SCRUM para:
- SCRUM é ideal para desenvolvimento de software complexos onde os requisitos mudam rapidamente;
- SCRUM é método ágil para gerenciar e controlar desenvolvimento de trabalho;
- SCRUM possibilita que você utilize as praticas de engenharia existentes e que já são conhecidas;
- SCRUM é baseado na abordagem interativa e incremental;
- Equipe de desenvolvedores (ou time) deve ter auto gestão;
- SCRUM é o caminho para detectar e causa raiz e a remoção de qualquer coisa que esteja impedindo o
desenvolvimento e/ou entrega de software/produtos;
- SCRUM é o caminho para maximizar a produtividade;
- SCRUM vai dá transparência ao processo de desenvolvimento de software.
Veja Lei F. Brooks, Não existe bala de prata

Algumas empresas que estão usando SCRUM:
Quais empresas estão utilizando o
SCRUM?
Algumas empresas brasileiras

41
Exercício
Leia o texto e complete a lacuna (no último paragrafo):
O processo de captação de talentos no futebol:
Baseado no texto do Fabrício Moreira*
Um dos aspectos mais importantes dos grandes clubes de futebol está relacionado à captação de
talentos para compor suas categorias de base, e posteriormente formar esses atletas para ingressarem
no profissional. Para entendermos melhor os caminhos atualmente traçados por esses candidatos a
futuros atletas de futebol precisamos analisar as formas que costumam chegar esses garotos até os
clubes brasileiros e iniciar os seus treinamentos junto às equipes de base.
Considerando que hoje esse processo de detecção difere em muito daqueles praticados anteriormente,
e que cada vez mais, tem se tornado precoce e competitivo, em que a concorrência chega a ser
absurda. Se pudéssemos ter acesso aos números de garotos avaliados anualmente nos grandes clubes
em relação aos selecionados, chegaríamos certamente a esta conclusão.
O objetivo deste texto é relatar os diversos mecanismos de captação de talentos em prática nos grandes
clubes do futebol profissional brasileiro. Dentre os mecanismos, destacamos cinco principais e dois
secundários. Podemos destacar alguns dos principais: as avaliações “peneiras”; campeonatos e jogos
amistosos; indicações; escolas licenciadas “franquias” e os observadores técnicos. Entre as
secundárias, destacamos: as clínicas de futebol e o intercâmbio internacional.
As chamadas “peneiras” são um dos mecanismos mais conhecidos e utilizados no meio do futebol.
Porém, é um processo ___________________, baseado na observação dos treinadores em uma única
situação (muitas vezes apenas de jogo e de curta duração). Neste caso, muitos clubes pré-selecionam
alguns garotos para continuarem os testes por pelo menos uma semana no clube, ou mais um dia, no
mínimo.
http://www.universidadedofutebol.com.br/2010/07/1,14757,UM+RELATO+SOBRE+O+PROCESSO+DE+CAPTACAO+DE+TALENTOS+NO+FUTEBOL.aspx?p=1

2 – Sobre o SCRUM
Conteúdo:

Objetivo:
Parte 3 – Entendendo SCRUM
Objetivo:
Apresentar de forma detalhada o framework SCRUM segundo o Guia do Scrum.
Pré-requisito:
Não há.

Entendendo o SCRUM
Parte 3

Framework Scrum:
Artefatos
Sprint
Backlog
Produto
Planejamento
da Sprint
Reunião
diária
2-4 Semanas
24 horas
Revisão
da Sprint
Retrospectiva
da Sprint
Visão
Reuniões
Product
Backlog
Legenda:
• Product Owner (PO)
• ScrumMaster (SM)
• Equipe Scrum
• Product Backlog
• Sprint Backlog
• Sprint Burndown
Papéis
Eventos (Reuniões)
Artefatos
Scrum é um framework para desenvolver e manter produtos complexos. Um framework dentro do qual
pessoas podem tratar e resolver problemas complexos e adaptativos, enquanto produtiva e criativamente
entregam produtos com o mais alto valor possível. Scrum é: Leve, Simples de entender e Extremamente
difícil de dominar
 Planejamento da Sprint
 Diária
 Revisão da Sprint
 Retrospectiva da Sprint
O framework Scrum consiste nas equipes do Scrum associadas a papéis, eventos, artefatos e regras.
Cada componente dentro do framework serve a um propósito específico e é essencial para o uso e
sucesso do Scrum.
45

Framework Scrum: Eventos de Duração Fixa:
Regras

As Regras fazem o elo entre os eventos com duração fixa (time-boxes), os papéis e os
artefatos do Scrum. As regras são descritas ao longo desta apresentação.
Alguns exemplos de Regras:
- Somente os membros da equipe de desenvolvimento podem falar durante uma Reunião Diária.
- Equipe deve possuir auto-gestão.;
- Somente o PO (Product Owner) definir e alterar a prioridade dos itens do Product Backlog.
- Uma pessoa não pode desempenhar o papel de PO e de Scrum Master no mesmo projeto.
- Somente o PO pode cancelar uma Sprint.
Framework Scrum: Regras

Framework Scrum: Papéis e Equipe
Papéis e Equipe

Papéis SCRUM:
Product Owner (PO), que é responsável por maximizar o valor do
trabalho que a equipe faz, PO também é responsável por:
- Definir a Visão do Produto
- Elaborar , Priorizar e manter o Product Backlog
- Definir ROI;
- Representar o cliente
- Aceitar ou rejeitar os entregáveis
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 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.
Equipe Scrum são projetados para otimizar flexibilidade e produtividade. Para esse fim, eles são auto-
organizáveis, interdisciplinares e trabalham em iterações. Cada equipe possui três papéis:

A Equipe SCRUM: ScrumMaster (SM) e Product Owner (PO):
O ScrumMaster é responsável por garantir que o Equipe Scrum esteja aderindo
aos valores do Scrum, às práticas e às regras. O ScrumMaster ajuda a Equipe
Scrum e a organização a adotarem o Scrum.
O ScrumMaster educa a Equipe Scrum treinando-o e levando-o a ser mais produtivo
e a desenvolver produtos de maior qualidade. O ScrumMaster ajuda a Equipe
Scrum a entender e usar auto-gerenciamento e interdisciplinaridade.
O ScrumMaster também auxiliar a equipe a fazer o seu melhor em um ambiente
organizacional que pode ainda não ser otimizado para o desenvolvimento de
produtos complexos.
Quando o ScrumMaster ajuda a realizar essas mudanças, isso é chamado de
“remoção de impedimentos”. No entanto, o ScrumMaster não gerencia a Equipe
Scrum; a Equipe Scrum é auto-organizável.
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.

A Equipe SCRUM: A Equipe
A Equipe (time) de desenvolvedores transformam o Product Backlog em incrementos
de funcionalidades potencialmente entregáveis em cada Sprint.
A equipe deve ser formada por pessoas “comprometidas” em atingir as metas das
Sprints .
A equipe deve ser interdisciplinar: os membros da equipe devem ter todo o
conhecimento e habilidades necessárias para entregar a meta da Sprint.
Membros da equipe geralmente possuem conhecimentos especializados, tais como:
programação, testes, controle de qualidade, análise de negócios, arquitetura,
desenho de interface de usuário e modelagem de dados. No entanto, o
conhecimento que os membros devem compartilhar - isto é, a habilidade de
trabalhar um item do Product Backlog (ou um requisito) e transformá-lo em um
produto (software funcionando) tendem a ser mais significativas do que aqueles que
eles não dividem.
As pessoas que se recusam a programar porque são arquitetas ou designers não
se adaptam bem a equipe. Todos devem contribuir, mesmo que isso exija
aprender novas habilidades ou lembrar-se de antigas. Na equipe não há hierarquia
nem títulos, todos são iguais e não há exceções a essa regra. As equipes também
não devem ter sub-equipe dedicados a áreas particulares como testes, banco de
dados ou análise de negócios.
A equipe possui a auto gestão e é auto-organizada. Não deve haver interferência
externa, nem o ScrumMaster ou Product Owner – ninguém pode dizer como a equipe
deve se organizar ou fazer inferência na forma de trabalho da equipe. A equipe deve
ser capaz de se auto-organizar para dividir e fazer trabalho. A equipe deve ser auto-
suficiente, cada membro da equipe aplica sua especialidade a todos os problemas.
A sinergia que resulta disso melhora a eficiência e eficácia geral da equipe como
um todo.

Equipe: Comprometimento e Tamanho:
Product Onwer
Equipe SCRUM Master
ComprometidosEnvolvidos
Stakeholders
(clientes e usuários finais)
O tamanho ótimo para uma equipe é de 7 pessoas, mais ou menos duas pessoas. Quando há
menos do que cinco membros em uma equipe, há menor interação e, como resultado, há menor
ganho de produtividade. Mais do que isso, a equipe poderá encontrar limitações de conhecimento
durante partes da Sprint e não ser capaz de entregar uma parte “pronta” do produto. Se há mais do
que 9 membros, há simplesmente a necessidade de muita coordenação. Equipe grandes geram
muita complexidade para que um processo empírico consiga gerenciar. Contudo, temos encontrado
algumas equipes bem-sucedidas que excederam os limites superior e inferior dessa faixa de tamanhos.
O PO e o ScrumMaster não estão incluídos nessa conta, a menos que também sejam porcos. A
composição da equipe pode mudar ao final da Sprint. Toda vez que a equipe muda, a produtividade
ganha através da auto-organização é reduzida. Deve-se tomar cuidado ao mudar a composição da
equipe.

Eventos

Eventos com duração fixa (time-boxes) :
Os eventos com duração fixa são utilizados para criar para criar regularidade, os seguintes eventos
têm a duração fixa:
- Reunião de Planejamento da Release
- Reunião de Planejamento da Sprint,
- Sprint,
- Reunião Diária,
- Revisão da Sprint
- Retrospectiva da Sprint.
Eventos:Visão Geral
Reunião
Diária
Product Backlog
Produto
Sprint Backlog
Sprint
A Sprint:
Parte central, ou o coração do Scrum, é a Sprint, que é uma iteração de um mês ou menos, de
duração consistente com o esforço de desenvolvimento. Todas as Sprints utilizam o mesmo
modelo de Scrum e todas as Sprints têm como resultado um incremento do produto final que é
potencialmente entregável. Cada Sprint começa imediatamente após a anterior.

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 vencedor da melhor maneira
possível?
- “Como podemos alcançar ou exceder a satisfação do cliente e o Retorno sobre
Investimento (ROI) desejados?”
O Plano da Release, que é o artefato resultante dessa reunião, 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.
O planejamento da release é opcional. Contudo, se a equipe Scrum iniciar o trabalho sem essa
reunião, a ausência de seu artefato aparecerá como um impedimento que deverá ser resolvido.
O trabalho para resolver o impedimento se tornará um item do 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. 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á possuem 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.

REUNIÃO DE PLANEJAMENTO DA RELEASE (continuação)
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. Há
diversas técnicas para fazê-lo que estão fora do alcance do Scrum, mas que apesar disso são úteis
quando usadas com ele.
Artefato resultante dessa reunião: Plano de Release
1 2 3 4 5 6
Plano de Release do Produto
Sprint #
Release #1 Release #2 Release #3
Release BurnDown
Visão do
PlanejamentoRelease #
Product
Backlog
Visão do Produto

Sprint
Backlog
Produto
Planejamento
da Sprint
Reunião
diária
24 horas
Revisão
da Sprint
Retrospectiva
da Sprint
Visão Produto
Backlog
Sprint
2-4 Semanas

REUNIÃO DE PLANEJAMENTO DA SPRINT
A Reunião de Planejamento da Sprint é o momento no qual a iteração é planejada. É fixada em oito
horas de duração para uma Sprint de um mês. Para Sprints mais curtas, aloca-se para essa
reunião aproximadamente 5% do tamanho total da Sprint, e ela consiste de duas partes. A primeira
parte, um evento com duração fixa de 4 horas, é o momento no qual é decidido “o quê” será feito
na Sprint. A segunda parte, também é um evento com duração fixa de 4 horas, é o momento no
qual a equipe entende “como” desenvolverá essa funcionalidade em um incremento do produto
durante a Sprint.
Na 1º a equipe Scrum trata da questão: “o quê?”.
O Product Owner apresenta a equipe o que é mais prioritário no Product Backlog.
Eles trabalham em conjunto para definir qual funcionalidade deverá ser desenvolvida durante a
próxima Sprint. As entradas para essa reunião são o Product Back, o incremento mais recente ao
produto, a capacidade da equipe e o histórico de desempenho da equipe.
Cabe somente a equipe a decisão de quanto itens do Product Backlog ela deve selecionar.
Somente a Equipe pode avaliar o que ele é capaz de realizar na próxima Sprint.
Meta da Sprint:
Uma vez selecionado o Product Backlog , a Meta da Sprint é delineada. A Meta da Sprint é o
objetivo que será atingido através da implementação do Product Backlog. Ela é uma descrição que
fornece orientação a equipe sobre a razão pela qual ele está desenvolvendo o incremento. A
Meta da Sprint é um subconjunto da Meta da Release.
O motivo para se ter uma Meta da Sprint é dar a equipe alguma margem com relação à funcionalidade.
Por exemplo, a meta para a Sprint acima poderia também ser: “Automatizar a funcionalidade de
modificação de conta de clientes através de um “middleware” seguro capaz de recuperar transações.”
Conforme a equipe trabalha, ela mantém a meta em mente. Para satisfazer a meta, elaa implementa a
funcionalidade e a tecnologia.
Se o trabalho se mostrar mais difícil do que a equipe esperava, a equipe então irá colaborar
com o Product Owner e implementar a funcionalidade apenas parcialmente.

REUNIÃO DE PLANEJAMENTO DA SPRINT (Continuação):
Na segunda parte da Reunião de Planejamento da Sprint, a equipe trata a questão:
“como?”.
Durante as quatro horas seguintes da Reunião de Planejamento da Sprint, a equipe
define como transformará o Backlog do Produto selecionado durante a Reunião de
Planejamento (o quê) em um incremento pronto. A equipe geralmente começa
projetando o trabalho. Enquanto projeta, a equipe identifica tarefas. Essas tarefas
são “pedaços” detalhados do trabalho necessário para converter os itens do Product
Backlog em software funcional. As tarefas devem ser decompostas para que
possam ser feitas em menos de um dia. Essa lista de tarefas é chamada de Sprint
Backlog que é um artefato do SCRUM. A equipe se auto-organiza para se encarregar
e se responsabilizar pelo trabalho contido na Sprint Backlog , tanto durante a Reunião
de Planejamento da Sprint quanto no próprio momento da execução da Sprint.
O Product Owner está presente durante a segunda parte da Reunião de
Planejamento da Sprint para esclarecer o Product Backlog e para ajudar a
efetuar trocas. Se a equipe concluir que ele tem trabalho demais ou de menos,
ele pode renegociar os itens do Product Backlog escolhido com o Product Owner.
A equipe também pode convidar outras pessoas , tais como clientes finais e/ou
especialista de negócio, a participarem da reunião para fornecerem conselhos
técnicos ou sobre o domínio em questão.
Geralmente, uma equipe nova percebe pela primeira vez se irá ganhar ou perder
como uma equipe - não individualmente - nessa reunião. A equipe percebe que
deve contar consigo mesmo. Conforme ele percebe isso, ele começa a se auto-
organizar para assumir as características e comportamento de uma verdadeiro
equipe.
Artefato resultante dessa reunião: Sprint Backlog
Incluir novo
cliente
alterar
cliente
consultar
cliente
Fazer Testes
Unitários
Sprint Backlog
Fazer UI
Fazer as
Tabelas

Sprint
Backlog
Produto
Planejamento
da Sprint
Reunião
diária
Sprint
2-4 Semanas
24 horas
Revisão
da Sprint
Retrospectiva
da Sprint
Visão Produto
Backlog

A SPRINT
A Sprint é uma iteração. Sprints são eventos com duração fixa. Durante a Sprint, o ScrumMaster
garante que não será feita nenhuma mudança que possa afetar a Meta da Sprint. Tanto a composição
da equipe quanto as metas de qualidade devem permanecer constantes durante a Sprint. As
Sprints contêm e consistem na reunião de Planejamento de Sprint, o trabalho de
desenvolvimento, a Revisão da Sprint e a Retrospectiva da Sprint. As Sprints ocorrem uma após
a outra, sem intervalos entre elas.
Um projeto serve para cumprir alguma função. Em desenvolvimento de software, o projeto é
utilizado para desenvolver um produto ou sistema. Cada projeto consiste em uma definição do
que será desenvolvido, um plano para desenvolvê-lo, o trabalho realizado de acordo com o
plano e o produto resultante. Cada projeto possui um horizonte, que é o período de tempo para
o qual o plano é válido. Se o horizonte for longo demais, a definição poderá ter mudado, variáveis
demais poderão ter surgido, o risco poderá ser grande demais etc. Scrum é um framework para
projetos cujo horizonte não é superior ao período de um mês, onde já há complexidade suficiente tal
que um horizonte mais longo seria arriscado demais. A previsibilidade do projeto deve ser
controlada pelo menos a cada mês, e o risco de que o projeto saia de controle ou se torne
imprevisível é contido pelo menos a cada mês.
As Sprints podem ser canceladas antes que o prazo fixo da Sprint tenha acabado. Somente o
Product Owner tem a autoridade para cancelar a Sprint, embora ele possa fazê-lo sob influência
das partes interessadas, da equipeou do ScrumMaster. Sob que tipo de circunstâncias pode ser
necessário cancelar uma Sprint? A gerência pode precisar cancelar uma Sprint se a Meta da Sprint
se tornar obsoleta. Isso pode ocorrer se a empresa mudar de direção ou se as condições do
mercado ou tecnologia mudarem. Em geral, uma Sprint deve ser cancelada se ela não fizer mais
sentido dadas as circunstâncias atuais, todavia isso deve ser uma exceção. Porém, por causa da curta
duração das Sprints, raramente isso faz sentido.
Artefato resultante dessa iteração: Parte do produto

Sprint
Backlog
Produto
Planejamento
da Sprint
Reunião
diária
Sprint
2-4 Semanas
24 horas
Revisão
da Sprint
Retrospectiva
da Sprint
Visão Produto
Backlog

REUNIÃO DIÁRIA
A equipe deve se encontrar diariamente para uma reunião de 15 minutos chamada Reunião
Diária. Essa reunião é sempre feita no mesmo horário e no mesmo local durante as Sprints.
Durante a reunião, cada membro explica:
1. O que ele realizou desde a última reunião diária;
2. O que ele vai fazer antes da próxima reunião diária; e
3. Quais obstáculos estão em seu caminho.
As Reuniões Diárias melhoram a comunicação, eliminam outras reuniões, identificam e
removem impedimentos para o desenvolvimento, ressaltam e promovem a tomada rápida de
decisões e melhoram o nível de conhecimento de todos acerca do projeto.
O ScrumMaster deve garantir que a equipe realize essa reunião. A equipe é responsável por
conduzir a Reunião Diária. O ScrumMaster ensina a equipe a manter a Reunião Diária com curta
duração, reforçando as regras e assegurando que as pessoas falem brevemente. O ScrumMaster
também enfatiza a regra de que galinhas não estão autorizadas a falar e nem a interferir de modo
algum na Reunião Diária.
A Reunião Diária não é uma reunião de status. Ela é só para as pessoas que estão
transformando os itens do Product Backlog um incremento (a equipe), e para mais ninguém. A
equioe se comprometeu com uma Meta da Sprint, e a esses itens do product Backlog. A
Reunião Diária é uma inspeção do progresso na direção da Meta da Sprint (as três
perguntas).
Geralmente acontecem reuniões subsequentes para realizar adaptações ao trabalho que está por
vir na Sprint. A intenção é otimizar a probabilidade de que a equipe alcance sua Meta. Essa é uma
reunião fundamental de inspeção e adaptação no processo empírico do Scrum.

Sprint
Backlog
Produto
Planejamento
da Sprint
Reunião
diária
Sprint
2-4 Semanas
24 horas
Revisão
da Sprint
Retrospectiva
da Sprint
Visão Produto
Backlog

REVISÃO DA SPRINT
Ao final da Sprint, é feita a reunião de Revisão da Sprint. Para Sprints de um mês, essa é uma
reunião com duração fixa de 4 horas. Para Sprints de durações mais curtas, essa reunião não deve
tomar mais do que 5% do total da Sprint. Durante a Revisão da Sprint, a equipe Scrum e as partes
interessadas colaboram sobre o que acabou de ser feito.
Baseados nisso e em mudanças no Product Backlog feitas durante a Sprint, eles colaboram sobre
quais são as próximas coisas que podem ser feitas. Essa é uma reunião informal, com a
apresentação da funcionalidade, que tem a intenção de promover a colaboração sobre o que fazer em
seguida.
A reunião inclui ao menos os seguintes elementos. O Product Owner identifica o que foi feito e o
que não foi feito. A equipe discute sobre o que correu bem durante a Sprint e quais problemas foram
enfrentados, além de como esses problemas foram resolvidos. A equipe então demonstra o trabalho
que está pronta e responde a questionamentos. O Product Owner então discute o Product Backlog
da maneira como esse se encontra.
Ele faz projeções de datas de conclusão prováveis a partir de várias hipóteses de velocidade. Em
seguida, o grupo inteiro colabora sobre o que foi visto e o que isso significa com relação ao que fazer
em seguida. A Revisão da Sprint fornece entradas valiosas para as reuniões de Planejamento de
Sprints seguintes.

Sprint
Backlog
Produto
Planejamento
da Sprint
Reunião
diária
Sprint
2-4 Semanas
24 horas
Revisão
da Sprint
Retrospectiva
da Sprint
Visão Produto
Backlog

RETROSPECTIVA DA SPRINT
Após a Revisão da Sprint e antes da próxima reunião de Planejamento da Sprint, a equipe Scrum
tem a reunião de Retrospectiva da Sprint.
Nessa reunião, com duração fixa de três horas, o ScrumMaster encoraja a equipe a revisar, dentro
do modelo de trabalho e das práticas do processo do Scrum, seu processo de
desenvolvimento, de forma a torná-lo mais eficaz e gratificante para a próxima Sprint. Existem
diversas técnica que são úteis em uma Retrospectiva.
A finalidade da Retrospectiva é inspecionar como foi a última Sprint em se tratando de pessoas,
das relações entre elas, dos processos e das ferramentas. A inspeção deve identificar e priorizar
os principais itens que correram bem e aqueles que, se feitos de modo diferente, poderiam ter
deixado as coisas ainda melhores. Isso inclui a composição da equipe, os preparativos para
reuniões, ferramentas, definição de “pronto”, métodos de comunicação e processos para
transformar itens do Product Backlog em alguma coisa “pronta”.
No final da Retrospectiva da Sprint, a equipe Scrum deve ter identificado as ações de melhoria
factíveis que será implementada na próxima Sprint. Essas mudanças se tornam a adaptação para
a inspeção empírica.

Artefatos
Framework Scrum: Artefatos

Scrum tem quatro artefatos principais:
- Product Backlog: é uma lista priorizada de tudo que pode ser necessário no 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.
- Release Burndown: Mede o Product Backlog restante ao longo do tempo de um Plano de
Release do Produto.
- Sprint Burndown: Mede os itens da Sprint Backlog restantes ao longo do tempo de uma Sprint.

PRODUCT BACKLOG e RELEASE BURNDOWN
Os requisitos para o produto que a equipe está desenvolvendo estão listados no 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.
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á.
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.
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.

PRODUCT BACKLOG e RELEASE BURNDOWN (continuação):
Quando um produto é utilizado, que seu valor aumenta e que o cliente fornece feedback, o
Product Backlog poderá se tornar uma lista maior e mais aprofundada. Os requisitos nunca param
de mudar. 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
minimizar 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.
Frequentemente, múltiplas equipes trabalham juntas no mesmo produto. Um único Product
Backlog é usado para descrever o trabalho a ser realizado no produto. Então, um atributo que
agrupe os itens é aplicado no Backlog do Produto.
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.
O gráfico de 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.
As estimativas dos itens do Product Backlog são inicialmente calculadas durante o Planejamento
da Release, e posteriormente à medida que itens forem sendo criados. Durante a preparação do
Product Backlog , os itens são revistos e revisados.
Entretanto, eles podem ser atualizados em qualquer momento. A equipe é responsável por todas
as estimativas. O Product Owner (PO) pode influenciar a equipe, ajudando-o a entender e a
escolher as mudanças, mas a estimativa final é feita pelo equipe. O Product Owner mantém o
Product Backlog e o Release Burndown do Backlog atualizados e publicados todo o tempo. Uma
linha de tendência pode ser traçada baseada na mudança do trabalho restante.

PRODUCT BACKLOG: Exemplo
Tema* Item Prioridade Pontos (estimados)
Venda de
Passagem
Vender passagens áreas Alta 40
Venda de
Passagem
Consulta de disponibilidade de
passagens áreas
Alta 13
Check-in Fazer check-in Alta 40
Check-in Cancelar Check-in Alta 8
Programa de
Fidelidade
Adesão ao programa de
fidelidade
Média 20
Programa de
Fidelidade
Consultar os pontos do
programa de fidelidade
Média 5
Atendimento ao
cliente
Fazer registro de comentários,
sugestões e reclamações dos
clientes
Baixa 8
Atendimento ao
cliente
Responder ao cliente (por e-
mail)
Baixa 5
Nota: O que é Tema ?
Tema é utilizado para agrupar “Estórias do Usuários” relacionadas, as estórias são representam o detalhamento dos itens do Backlog, ao usar o
conceito de “tema”, ele poderá facilitar as atividades de priorização e de estimativa.
Product Backlog

RELEASE BURNDOWN: Exemplo
Sprints
Pontos(estimados)
150
100
50
0
Sprint #1 Sprint #2 Sprint #13 Sprint #4
139
Release Burndown
90
52
20
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.

SPRINT BACKLOG E SPRINT BURNDOWN:
A Sprint Backlog consiste nas tarefas que a equipe executa para transformar os itens do Product
Backlog em um incremento “pronto”. Muitas deles são elaboradas durante a Reunião de
Planejamento da Sprint.
A Sprint Backlog é todo trabalho que a equipe identifica como necessário para alcançar a Meta da
Sprint. Os itens do Sprint Backlog devem ser decompostos. A decomposição deve ser suficiente
para que mudanças no progresso possam ser entendidas na Reunião Diária.
A equipe modifica a Sprint Backlog no decorrer da Sprint. Quando chega às tarefas individuais, a
equipe pode descobrir que mais ou menos tarefas serão necessárias, ou que uma determinada
tarefa levará mais ou menos tempo do que era esperado. À medida que novo trabalho surge, a
equipe o adiciona a Sprint Backlog.
À medida que se trabalha nas tarefas ou que elas são completadas, as horas estimadas de trabalho
restantes para cada tarefa são atualizadas. Quando se verifica que determinadas tarefas são
desnecessárias, elas são removidas.
Somente a equipe pode modificar a Sprint Backlog durante uma Sprint, pode mudar o seu conteúdo
ou as suas estimativas. A Sprint Backlog é um retrato em tempo real altamente visível do
trabalho que a equipe planeja efetuar durante a Sprint, e ela pertence unicamente a equipe.

SPRINT BACKLOG E SPRINT BURNDOWN: Exemplo
Na reunião de Planejamento da
Sprint, PO deverá apresentar a
visão do produto, Product Backlog
e seus Itens, comentando o nível
de prioridade de cada item. Os
membros da equipe devem
selecionar os itens com os maiores
níveis de prioridades para fazer
parte da Sprint.
Como cliente de negócio, eu quero fazer check-in
pela web para que fique menos tempo em filas.
Pontos: ?
Titulo: “Fazer Check-in”
Prioridade: Alta
Estória do Usuário A estória do usuário auxilia no
entendimento do que deve ser
feito, ela 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)

SPRINT BACKLOG E SPRINT BURNDOWN: Exemplo
Pontos: ?
Prioridade: Alta
Estória do Usuário
Quebrar a estória do Usuário em
tarefas:
- Para facilitar a estimativa de
velocidade da equipe, considere
quebrar a estória em tarefas, isto
pode fazer que todos os membros
da equipe visualizem todas as
tarefas que devem ser feitas para
implementar o item do backlog.
Mas, ainda precisamos estimar os
pontos...
Sprint Backlog
Fazer Check-in
Fazer
interface
do usuário
Integrar
com Sistema
de Reserva
Criar
Componentes
de validação
Executar
testes
unitários
Executar
testes de
aceitação
Impressão
do Ticket
A Sprint Backlog é um
artefato resultante da reunião
de Planejamento da Sprint

Estimando os pontos da “Estória do Usuário”:
Uma breve introdução sobre estimativa:
Estimar é Difícil ?
- Estimativa (mundo real) representa um valor aproximado.
- Estimativa (em desenvolvimento de software) algumas pessoas acham que representa um valor exato.
Contudo, devemos estimar as Estórias do Usuário para saber se elas “cabem” dentro de uma Sprint.
Uma vez que os pontos são estimados eles ajudam a definir a velocidade da equipe, a partir deste
parâmetro, podemos chegar a conclusão se estória cabe ou não dentro da Sprint. Se ela não couber a
opção é quebrar esta estória em estórias menores.
Pessoal, qual
estimativa para
essa estória...
Product Owner
Titulo: Pagamento com Cartão de Crédito Prioridade: ?
Quem ?
como um cliente
O que ?
preciso de uma interface de pagamento por cartão de
crédito que seja intuitiva e fácil de usar.
Por que ?
Com objetivo de facilitar os pagamentos.
Pontos: ?
Exemplo de Estórias do Usuário:

Baseado na duração de tarefas.
- 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
Baseia-se no tamanho da estória influenciado pela:
- 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.
Pontos de Estória (Story Points)
Principais técnicas:
◦ Opinião de especialista;
◦ Analogia;
◦ Decomposição (Dividir para conquistar).
Dias Ideais (Ideal Days)
Pontos de Estória:
◦ Valores relativos
◦ Mais abstrato
Ideal Days:
◦ Mais fácil para iniciantes
◦ Fácil de explicar
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.

Estimativa* e o Planning Poker:
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
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.
Pessoal, qual é
estimativa para
essa estória...
Product Owner Equipe
40
40
40
100
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...
40
40
40
40
1ª. Rodada Quando todas as cartas
estiverem lançadas, elas
são viradas e caso não
haja consenso nos
pontos, as diferenças são
discutidas de forma
breve, e uma nova
rodada acontece até que
haja concesso.
Nª. Rodada
Equipe

SPRINT BACKLOG: Exemplo
Pontos: 40
Prioridade: Alta
Planning Poker, estória do usuário
e pontos de estória, nada disso faz
parte do framework Scrum,
contudo são técnicas e ferramentas
complementares ao framework.
Elas são altamente utilizadas para
fazer a estimativa de velocidade da
equipe.
E finalmente temos a Sprint
Backlog e podemos criar o Sprint
Burndonw.
Fazer Check-in
Fazer
interface
do usuário
Integrar
com Sistema
de Reserva
Criar
Componentes
de validação
Sprint Backlog
Executar
testes
unitários
Executar
testes de
aceitação
A Sprint Backlog é todo trabalho que a equipe identifica como necessário para alcançar a Meta da Sprint.
Impressão
do Ticket

SPRINT BACKLOG E SPRINT BURNDOWN:
A Sprint Burndown (ou Burndown ) é um gráfico da
quantidade restante de trabalho do Sprint Backlog em
uma determinada Sprint ao longo do tempo da Sprint.
Para criar esse gráfico, determine quanto trabalho resta
somando as estimativas do Backlog a cada dia da
Sprint.
A quantidade de trabalho restante para uma Sprint é a
soma do trabalho restante para tudo da Sprint Backlog.
Acompanhe essas somas diariamente e utilize-as para criar
um gráfico que mostre o trabalho restante ao longo do
tempo. Traçando uma linha através dos pontos no
gráfico, a equipe pode gerenciar seu progresso em
completar o trabalho de uma Sprint.
A duração não é considerada em Scrum. O trabalho
restante e a data são as únicas variáveis de interesse.
Uma das regras do Scrum está ligada ao objetivo de cada
Sprint, que é ter como resultado incrementos de
funcionalidade potencialmente entregáveis que estejam de
acordo com uma definição de “pronto”.
A Sprint Burndown é um artefato
que deve ser utilizado exclusivamente
pela equipe.
Se PO tentar fazer a gestão do
projeto com base na Sprint
Burndown é considerado como
micro-gerenciamento e que pode
levar ao comando-controle...
O PO deve fazer a gestão do projeto
olhando a Release Burndown.
Dica:
Sempre que possível, desenhe a Sprint Burndown em um
quadro que esteja na área de trabalho da equipe. É mais
provável que a equipe veja um gráfico grande e visível do que
um gráfico de feito em uma planilha de calculo.

SPRINT BURNDOWN : Exemplo
O Quadro de Tarefas também
não parte do framework
Scrum, ele parte de uma
técnica chamada Gestão à
Vista, que tem como objetivo
facilitar a comunicação e dar
visibilidade (transparência).
A transparência, que é dos pilares do Scrum, garante que
aspectos do processo que afetam o resultado devem ser visíveis
para aqueles que gerenciam os resultados. O Quadro de Tarefas
deixam a Sprint com visibilidade e transparência.

Pronto
Framework Scrum: Definição de Pronto

Uma conversa comum entre o cliente e o desenvolvedor:
[Cliente] E aí como anda o desenvolvimento da aplicação ?
[Desenvolvedor] Está pronta...
[Cliente] Isso quer dizer que eu posso implementa-la ?
[Desenvolvedor] Bem...ainda não, preciso fazer mais alguns testes...
[Cliente] Mas, aplicação não estava pronta..
84
Definição de Pronto (*DoD):
Definir claramente quando o produto estará “pronto”,
pois:
Pronto, para desenvolvedor significa:
- Encerrou a codificação...
Pronto, para PO significa:
- Quando foi entregue...
Pronto, para os usuários finais e/ou clientes significa:
- Quando o software começou a funcionar em ambiente
de produção...
Evite: A síndrome dos 90% feito (pronto).

No desenvolvimento de produtos, afirmar que a funcionalidade está pronta pode levar alguém a
presumir que ela está pelo menos bem codificada, refatorada, que tenha passado por testes
unitários, que tenha sido feito o “build” e que tenha passado por testes de aceitação.
Outros podem presumir que apenas o código tenha sido desenvolvido.
Se não houve definição de “pronto”, os outros dois pilares do controle de processos empíricos não
funcionam. Quando alguém descreve algo como “pronto”, todos devem entender o que “pronto”
significa.
“Pronto” define o que a equipe quer dizer quando se compromete a “aprontar” um item de
Product Backlog em uma Sprint. Alguns produtos não contêm documentação, de forma que sua
definição de “pronto” não inclui documentação. Um incremento completamente “pronto” inclui toda
a análise, projeto, refatoramento, programação, documentação e testes para o incremento e todos os
itens do Product Backlog no incremento. Os testes incluem testes de unidade, de
sistema, de usuário e de regressão, bem como testes não-funcionais como de performance, de
estabilidade, de segurança e de integração.
“Pronto” inclui também qualquer internacionalização necessária. Algumas equipes ainda não são
capazes de incluir em sua definição de “pronto” tudo o que é necessário para a implantação. Isto
deve estar claro para o Product Owner. Esse trabalho restante deverá ser feito antes que o
produto possa ser implantado e utilizado.
Scrum exige que a equipe desenvolva um incremento de funcionalidade do produto a cada
Sprint. Esse incremento deve ser potencialmente entregável, pois o Product Owner (PO)
pode optar por implantar a funcionalidade imediatamente. Para isso ser possível, o
incremento deve ser um pedaço completo do produto. Ele deve estar “pronto”. Cada
incremento deve ser adicionado a todos os incrementos anteriores e exaustivamente testado,
garantindo que todos os incrementos funcionem juntos.
A Definição de PRONTO

A Definição de PRONTO e “NÃO PRONTO”
Algumas organizações são incapazes de desenvolver um incremento completo dentro de uma
Sprint. Elas podem ainda não ter infraestrutura automatizada de testes para completar todos os
testes. Nesse caso, duas categorias são criadas para cada incremento: o trabalho “pronto” e
o trabalho “não pronto”. O trabalho “não pronto” é a porção de cada incremento que terá que ser
completada mais tarde. O Product Owner sabe exatamente o que ele está inspecionando ao final
da Sprint, porque o incremento atende à definição de “pronto” e o Product Owner entende essa definição.
O trabalho “não pronto” é adicionado a um item do Product Backlog o chamado “trabalho não pronto”, de
forma que ele se acumula e isso é refletido corretamente no gráfico de Release Burndown Release.
Essa técnica cria transparência no progresso em direção à entrega. A inspeção e a adaptação na
Revisão da Sprint serão tão precisas quanto essa transparência for.
Exemplo:
Se uma equipe não é capaz de realizar os testes de performance, regressão, estabilidade,
segurança e integração para cada item do Product Backlog, a proporção desse trabalho em
relação ao trabalho que pode ser pronto (análise, projeto, refatoramento, programação,
documentação, testes unitário e testes de usuário) é calculada.
Vamos supor que essa proporção é de seis peças de “pronto” e quatro peças de “não pronto”. Se a
equipe terminar um item de Product Backlog de seis unidades de trabalho (a equipe está
estimando baseado no que ele sabe como “aprontar”), quatro unidades serão acrescidas ao
item do Product Backlog denominado “trabalho não pronto” quando eles tiverem terminado.
Sprint a Sprint, o trabalho “não pronto” de cada incremento vai se acumulando e deve ser
tratado antes da entrega do produto. Esse trabalho é acumulado linearmente, embora haja algum
tipo de acúmulo exponencial que é dependente das características de cada organização.
Sprints são adicionados ao final de cada release para completar o trabalho “não pronto”. O
número de Sprints é imprevisível, visto que o acúmulo de trabalho “não pronto” não é linear.

Exercícios:
1 - Quando as regras não são declaradas, espera-se que os usuários de Scrum descubram o que
devem fazer. Não tente descobrir uma solução perfeita, porque geralmente o problema muda
rapidamente. Ao invés disso, tente algo e veja como se sai. Os mecanismos de inspeção-e-adaptação
inerentes à natureza empírica do Scrum irão lhe guiar.
[ ] Verdadeiro [ ] Falso
Responda Verdadeiro ou Falso para as declarações:
2 - O ScrumMaster trabalha com os clientes e a gerência para identificar e designar um Product Owner.
O ScrumMaster ensina ao Product Owner como fazer seu trabalho. Espera-se dos Product Owners que
eles saibam como conseguir otimizar valor através do Scrum. Se eles não souberem, consideramos o
ScrumMaster responsável.
3 - O ScrumMaster pode ser um membro da equipe; por exemplo, um desenvolvedor realizando tarefas
da Sprint. No entanto, isso frequentemente leva a conflitos quando o ScrumMaster deve escolher entre
remover impedimentos ou realizar tarefas.
4 - O ScrumMaster nunca deve ser o Product Owner.

Exercícios:
5 - O Product Owner pode ser um membro da equipe, trabalhando também na realização das tarefas.
Mas, essa responsabilidade adicional pode reduzir a sua habilidade de lidar com as partes
interessadas.
Responda Verdadeiro ou Falso para as questões:
6 – Se a equipe sentir que se comprometeu com mais do que podia, ele se encontra com o Product
Owner para remover ou reduzir o escopo da Sprint Backlog (itens do Product Backlog selecionado para
a Sprint). Se a equipe sentir que sobrará tempo ele pode trabalhar junto ao Product Owner para
selecionar mais do itens do Product Backlog.
7- Geralmente, somente 60-70% do total da Sprint Backlog será definido na Reunião de Planejamento
da Sprint. O restante é deixado para ser detalhado mais tarde ou são dadas estimativas grandes que
serão decompostas mais tarde na Sprint.
8 - Os itens do Product Backlog são comumente representados como “Estórias do Usuário”. Casos de
Uso também são apropriados.

Exercícios:
9 - Testes de aceitação fazem parte da Estória de Usuário, são utilizados parar substituir descrições
textuais mais detalhadas com uma descrição testável.
Responda Verdadeiro ou Falso para as questões:
10 - 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 Scrum e a organização tenham decidido usar. As unidades de tempo geralmente são
Estórias do Usuário.

2 – Sobre o SCRUM
Conteúdo:

Objetivo:
Estudo de Caso
Objetivo:
Apresentar um Estudo de Caso para demonstrar como aplicar as práticas do SCRUM em
projeto de desenvolvimento de Software.
Pré-requisito:
Conhecimento das práticas Scrum.

Estudo de Caso
Estudo de Caso

Framework SCRUM
Artefatos
Sprint
Backlog
Produto
Planejamento
da Sprint
Reunião
diária
Sprint
(2-4 Semanas)
24 horas
Revisão
da Sprint
Retrospectiva
da Sprint
Reuniões
• Sprint Burndown
• Release Burndown
Product
Backlog
Legenda:
• Product Owner (PO)
• ScrumMaster (SM)
• Equipe (time)
• Product Backlog
• Sprint Backlog
• Sprint Burndown
• Release Burndown
Papéis
Reuniões
Artefatos
• Planejamento da Release
• Planejamento da Sprint
• Diária
• Revisão da Sprint
• Retrospectiva da Sprint
Visão
Planejamento
da Release
93

Estudo de Caso: Visão
Sprint
Backlog
Produto
Planejamento
da Sprint
Reunião
diária
24 horas
Revisão
da Sprint
Retrospectiva
da Sprint
Visão
Produto
Backlog
Sprint
2-4 Semanas
Primeiro passo: definir a Visão do Produto.
Planejamento
da Release
1

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.
Estudo de Caso: 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.
Para definir a visão do Produto, primeiro é necessário entender qual é a real necessidade do cliente:
Após entender a necessidade do cliente, é hora de definir a Visão 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.
Após a definição da Visão do Produto, devemos definir a primeira “versão” do Product Backlog:
Funcionalidades do produto

Podemos fazer a declaração da Visão do Produto sem entender a real necessidade do cliente ?
Exercício:

Estudo de Caso: Reunião de Planejamento da Release
Sprint
Backlog
Produto
Planejamento
da Sprint
Reunião
diária
24 horas
Revisão
da Sprint
Retrospectiva
da Sprint
Visão
Produto
Backlog
Sprint
2-4 Semanas
Segundo passo: Realizar a Reunião de Planejamento da Release, o resultado desta reunião é o
Plano de Release e o Release Burndown (artefato Scrum).
Planejamento
da Release
2

O propósito da Reunião de Planejamento da Release é o de estabelecer o Plano de Release, as Metas
e Release Burndown (que é um artefato do Scrum) 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 de 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 custos prováveis que devem se manter se nada mudar. A
organização pode então inspecionar o progresso e fazer mudanças nesse Plano de Release a cada
Sprint.
O planejamento da release requer estimar e priorizar o Product Backlog para a release. Há diversas
técnicas para fazê-lo que estão fora do alcance do Scrum (lembre-se o SCRUM é framework ele não
indica nenhuma técnica), mas que apesar disso são úteis quando usadas com ele.
Planejamento
da Release
Product Backlog (visão inicial)
Product Backlog (priorizado)
Visão do Produto
Plano de Release
Entradas
Saídas
Release
Burndown
(artefato)
Equipe SCRUM

Plano de Release
Reserva Promoções
Programa de
Fidelidade
Tour VirtualReleases
Nível de
Prioridade
Relacionamento
ao cliente
Prazo
(estimado)
Alto Médio Médio Médio Baixo
30 dias 15 dias 7 dias 15 dias 15 dias
5 Releases
82 dias
1 Alto, 3 médio
e 1 baixo
1
2
3
Visão inicial do Product Backlog, antes da reunião de Planejamento da
Sprint, ele tem somente as funcionalidades do produto, agrupadas por
tema (este agrupamento é opcional).
O Plano de Release
é elaborado nessa
reunião. Nesse plano
define-se o prazo de
entrega do produto e
nível de prioridade
dos itens do backlog
O Plano de Release
é base para atualização
do Product Backlog
Agora ele apresenta o
nível de prioridade e
quantidade de pontos
estimados dos itens.
O PO é responsável
pela priorização dos
itens e a Equipe é
responsável pela
estimativa.

Releases
Pontos(estimados)
120
80
40
0
Release #1 Release #2 Release #3 Release #5
108
Release Burndown
68
48
20
40
Release #4
Com Product Backlog atualizado e o Plano de Release, o PO poderá construir o Release Burndown, que é um
dos artefatos do SCRUM. As estimativas dos itens do Product Backlog são inicialmente calculadas durante
a Reunião de Planejamento da Release.
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.
O Product Owner é responsável
por manter o Product Backlog e
o Release Burndown atualizados
e publicados todo o tempo.
Uma linha de tendência pode ser
traçada baseada na mudança do
trabalho restante.

O que aconteceria se a equipe SCRUM não fizer a Reunião de Planejamento da Release ?
Exercício:

Estudo de Caso: Reunião de Planejamento da Sprint
Sprint
Backlog
Produto
Planejamento
da Sprint
Reunião
diária
24 horas
Revisão
da Sprint
Retrospectiva
da Sprint
Produto
Backlog
Sprint
2-4 Semanas
Terceiro passo: Realizar a Reunião de Planejamento da Sprint, o resultado desta reunião são os
artefatos Sprint Backlog e Sprint Burndown.
Planejamento
da Release
Visão
3

Product Backlog: Sistema de Reserva On-Line
A Reunião de Planejamento da Sprint é o momento no qual a iteração é planejada. No nosso
exemplo a duração é fixada em 8 horas, pois, a Sprint tem a estimativa de um mês.
Essa reunião é dividida em duas partes:
1ª. Parte da Reunião (4 horas):
A equipe Scrum trata da questão: “o quê?”.
O PO apresenta a equipe o que é mais
prioritário no Product Backlog. Todos trabalham
em conjunto para definir qual funcionalidade
deverá ser desenvolvida durante a próxima
Sprint. O Product Backlog está ordenado de
acordo com nível de prioridade dos itens.
A equipe deve selecionar o item de maior
prioridade e definir qual será a meta da Sprint.
2ª. Parte da Reunião (4 horas):
A equipe trata a questão: “como?”.
Durante as 4 horas seguintes a equipe define como
transformará o item selecionado em incremento do
produto “pronto” e potencialmente entregável.
O PO estará presente para esclarecer dúvidas e para
ajudar a efetuar trocas, se necessário. Se a equipe
concluir que ela tem trabalho demais ou de menos,
ela pode renegociar os itens do Product Backlog
escolhido com o PO

Como cliente de negócio, eu quero fazer reserva de
apartamentos pela web para facilitar o meu
planejamento.
Pontos: ?
Titulo: “Fazer Reserva de Apartamentos”
Prioridade: Alta
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)
Detalhando os itens do Produto Backlog em estórias do usuário:
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.
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.
Cartão: Estória do Usuário são tradicionalmente
escritas em um cartão. Cartão podem ter notas,
estimativas, comentário observações e etc
Conversas: Detalhes que podem surgir durante as
conversas com PO (Product Owner) e/ou cliente.
Confirmação: Testes de aceitação “confirmam” se
a Estória do Usuário foi codificada da forma correta.
Testes de aceitação são tipo Caixa Preta.

Fazer Reserva
de Apartamentos
Executar
testes
unitários
Executar
testes de
aceitação
Criar
Tabelas
Como cliente de negócio, eu quero fazer reserva de
apartamentos pela web para facilitar o meu
planejamento.
Pontos: ?
Titulo: “Fazer Reserva de Apartamentos”
Prioridade: Alta
Criar
Interfaces
Do Usuário
Tarefas TécnicasTarefas de Negócio
Detalhando as Estórias do Usuário em Tarefas:
Devemos buscar meios para facilitar
a estimativa de velocidade da
equipe, quebrar a estória do usuário
em tarefas pode fazer que todos os
membros da equipe visualizem todas
as tarefas que devem ser feitas para
implementar a Estória do Usuário.
Testes de aceitação devem ser
escritos para detalhar melhor a
estória do usuário, geralmente eles
são escritos no versão do cartão.
Consulta de
Reserva de
Apartamento
Cadastro de
Fila de Espera
Cadastro de
Cliente
Confirmação
da Reserva

Scrum Tutorial Definitivo

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (12)

Semelhante a Scrum Tutorial Definitivo

Semelhante a Scrum Tutorial Definitivo (20)

Scrum Tutorial Definitivo