Ken Schwaber e Jeff Sutherland

O Guia do Scrum
O Guia Definitivo para o Scrum: As Regras do Jogo

Novembro de 2020

Licensed to Sara Regina da Silva Vieira - sreginavieira@gmail.com

 O Propósito do Guia do Scrum
Desenvolvemos o Scrum no início dos anos 1990. Escrevemos a primeira versão do Guia do
Scrum em 2010 para ajudar as pessoas em todo o mundo a entender o Scrum. Evoluímos o
Guia desde então por meio de pequenas atualizações funcionais. Juntos, nós os suportamos.

O Guia do Scrum contém a definição do Scrum. Cada elemento do framework serve a um

propósito específico que é essencial para o valor geral e os resultados obtidos com Scrum.
Mudar o modelo central ou ideias do Scrum, remover elementos ou não seguir as regras do
Scrum, encobre os problemas e limita os benefícios do Scrum, potencialmente até tornando-o
inútil.

Acompanhamos o uso crescente do Scrum em um mundo cada vez mais complexo. Estamos
muito orgulhosos em ver o Scrum sendo adotado em muitos domínios, que consistem de
trabalhos essencialmente complexos, indo além do desenvolvimento de produtos de software
onde o Scrum tem suas raízes. Conforme o uso do Scrum se espalha, desenvolvedores,
pesquisadores, analistas, cientistas e outros especialistas fazem o trabalho. Usamos a palavra
“developers” no Scrum não para excluir, mas para simplificar. Se você obtém valor do Scrum,
considere-se incluído.

Conforme o Scrum está sendo usado, padrões, processos e insights que se encaixam no
Framework Scrum conforme descrito neste documento podem ser encontrados, aplicados e
idealizados. Sua descrição está além do propósito do Guia do Scrum porque eles são sensíveis
ao contexto e diferem amplamente entre os usos do Scrum. Essas táticas para uso dentro do
framework Scrum variam amplamente e são descritas em outros lugares.

Ken Schwaber e Jeff Sutherland, Novembro de 2020

© 2020 Ken Schwaber and Jeff Sutherland

This publication is offered for license under the Attribution Share-Alike license of Creative Commons,
accessible at https://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary
form at https://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you
acknowledge and agree that you have read and agree to be bound by the terms of the Attribution
Share-Alike license of Creative Commons.

Licensed to Sara Regina da Silva Vieira - sreginavieira@gmail.com

 Definição do Scrum ....................................................................................................................................... 4
Teoria do Scrum ............................................................................................................................................ 4
Transparência................................................................................................................................................ 5
Inspeção ........................................................................................................................................................ 5
Adaptação ..................................................................................................................................................... 5
Os Valores do Scrum ..................................................................................................................................... 5
Scrum Team .................................................................................................................................................. 6
Developers .................................................................................................................................................... 6
Product Owner .............................................................................................................................................. 7
Scrum Master ................................................................................................................................................ 7
Eventos Scrum............................................................................................................................................... 8
A Sprint.......................................................................................................................................................... 8
Sprint Planning .............................................................................................................................................. 9
Daily Scrum ................................................................................................................................................. 10
Sprint Review .............................................................................................................................................. 11
Sprint Retrospective.................................................................................................................................... 11
Scrum Artifacts ............................................................................................................................................ 11
Product Backlog .......................................................................................................................................... 12
Compromisso: Meta do Produto ............................................................................................................ 12
Sprint Backlog ............................................................................................................................................. 13
Compromisso: Meta da Sprint ................................................................................................................ 13
Incremento.................................................................................................................................................. 13
Compromisso: Definição de Pronto ........................................................................................................ 14
Nota Final .................................................................................................................................................... 15
Reconhecimentos ................................................................................................................................... 15
Pessoas ................................................................................................................................................ 15
A História do Guia Scrum .................................................................................................................... 15
Tradução ............................................................................................................................................. 15
Mudanças entre o Guia Scrum 2017 e o Guia Scrum 2020 ................................................................ 16

Licensed to Sara Regina da Silva Vieira - sreginavieira@gmail.com

 Definição do Scrum
Scrum é um framework leve que ajuda pessoas, times e organizações a gerar valor por meio
de soluções adaptativas para problemas complexos.

Em suma, Scrum requer um Scrum Master para promover um ambiente onde:

1. Um Product Owner ordena o trabalho para um problema complexo em um Product

Backlog.
2. O Scrum Team transforma uma seleção do trabalho em um incremento de valor durante
um Sprint.
3. O Scrum Team e seus stakeholders inspecionam os resultados e se ajustam para o
próximo Sprint.
4. Repita

Scrum é simples. Experimente como está e determine se sua filosofia, teoria e estrutura
ajudam a atingir objetivos e criar valor. O framework Scrum é propositalmente incompleto,
apenas definindo as partes necessárias para implementar a teoria Scrum. O Scrum é
construído sobre a inteligência coletiva das pessoas que o utilizam. Em vez de fornecer às
pessoas instruções detalhadas, as regras do Guia do Scrum orientam seus relacionamentos e
interações.

Vários processos, técnicas e métodos podem ser empregados com o framework. Scrum se
acopla as práticas existentes ou as torna desnecessárias. Scrum torna visível a eficácia relativa
da gestão atual, meio ambiente e técnicas de trabalho, para que melhorias possam ser feitas.

Teoria do Scrum
Scrum é baseado no empirismo e lean thinking. O empirismo afirma que o conhecimento vem
da experiência e da tomada de decisões com base no que é observado. O lean thinking reduz o
desperdício e se concentra no essencial.

Scrum emprega uma abordagem iterativa e incremental para otimizar a previsibilidade e

controlar o risco. Scrum envolve grupos de pessoas que, coletivamente, possuem todas as
habilidades e conhecimentos necessários para fazer o trabalho e compartilhar ou adquirir essas
habilidades conforme necessário.

Scrum combina quatro eventos formais para inspeção e adaptação, contidos dentro de um
evento, a Sprint. Esses eventos funcionam porque implementam os pilares empíricos do
Scrum: transparência, inspeção e adaptação.

Licensed to Sara Regina da Silva Vieira - sreginavieira@gmail.com

 Transparência
O processo emergente e o trabalho devem ser visíveis tanto para quem executa o trabalho
quanto para quem recebe o trabalho. Com o Scrum, decisões importantes são baseadas no
estado percebido de seus três artefatos formais. Artefatos com baixa transparência podem
levar a decisões que diminuem o valor e aumentam o risco.
A transparência permite a inspeção. A inspeção sem transparência é enganosa e gera
desperdício.

Inspeção
Os artefatos do Scrum e o progresso em direção às metas acordadas devem ser inspecionados
com frequência e diligência para detectar variações ou problemas potencialmente indesejáveis.
Para ajudar na inspeção, o Scrum fornece cadência na forma de seus cinco eventos.

A inspeção habilita a adaptação. A inspeção sem adaptação é considerada inútil. Os eventos

Scrum são projetados para provocar mudanças.

Adaptação
Se algum aspecto de um processo se desviar fora dos limites aceitáveis ou se o produto
resultante for inaceitável, o processo que está sendo aplicado ou os materiais que estão sendo
produzidos devem ser ajustados. O ajuste deve ser feito o mais rápido possível para minimizar
novos desvios.

A adaptação se torna mais difícil quando as pessoas envolvidas não são empoderadas ou
auto-gerenciadas. Espera-se que um Scrum Team se adapte no momento em que aprende
algo novo por meio da inspeção.

Os Valores do Scrum
O sucesso do uso do Scrum depende das pessoas se tornarem mais proficientes em viver
cinco valores:
Compromisso, Foco, Abertura, Respeito e Coragem
O Scrum Team se compromete a atingir seus objetivos e suportar uns aos outros. Seu foco
principal é o trabalho da Sprint para fazer o melhor progresso possível em direção a essas
metas. O Scrum Team e seus stakeholders são abertos quanto ao trabalho e os desafios. Os
membros do Scrum Team se respeitam quanto a serem pessoas capazes e independentes, e
são respeitados como tal pelas pessoas com quem trabalham. Os membros do Scrum Team
têm a coragem de, fazer a coisa certa e trabalhar em problemas difíceis

Licensed to Sara Regina da Silva Vieira - sreginavieira@gmail.com

 Esses valores orientam o Scrum Team em relação ao seu trabalho, ações e comportamento.
As decisões que são tomadas, os passos dados e a forma como o Scrum é usado devem
reforçar esses valores, não diminuí-los ou miná-los. Os membros do Scrum Team aprendem e
exploram os valores à medida que trabalham com os eventos e artefatos do Scrum. Quando
esses valores são incorporados pelo Scrum Team e pelas pessoas com quem trabalham, os
pilares empíricos do Scrum de transparência, inspeção e adaptação ganham vida, construindo
confiança.

Scrum Team
A unidade fundamental do Scrum é um pequeno time de pessoas, um Scrum Team. O Scrum
Team consiste em um Scrum Master, um Product owner e Developers. Dentro de um Scrum
Team, não há sub-times ou hierarquias. É uma unidade coesa de profissionais focados em um
objetivo de cada vez, a Meta do Produto.

Os Scrum Teams são multifuncionais, o que significa que os membros possuem todas as
habilidades necessárias para criar valor a cada Sprint. Eles também são autogerenciáveis, o
que significa que decidem internamente quem faz o quê, quando e como.

O Scrum Team é pequeno o suficiente para permanecer ágil e grande o suficiente para concluir
um trabalho significativo dentro de uma Sprint, normalmente 10 ou menos pessoas. Em geral,
descobrimos que times menores se comunicam melhor e são mais produtivos. Se os Scrum
Teams se tornarem muito grandes, eles devem considerar a reorganização em vários Scrum
Teams coesos, cada um focado no mesmo produto. Portanto, eles devem compartilhar o
mesma meta do produto, Product Backlog e Product Owner.

O Scrum Team é responsável por todas as atividades relacionadas ao produto, desde a

colaboração com stakeholder, verificação, manutenção, operação, experimentação, pesquisa e
desenvolvimento, e qualquer outra coisa que possa ser necessária. Eles são estruturados e
empoderados pela organização para gerenciar seu próprio trabalho. Trabalhar em Sprints em
um ritmo sustentável melhora o foco e a consistência do Scrum Team.

Todo o Scrum Team é responsável por criar um Incremento valioso e útil a cada Sprint. Scrum
define três responsabilidades específicas dentro do Scrum Team: os Developers, o Product
Owner e o Scrum Master.

Developers
Developers são as pessoas do Scrum Team que estão comprometidas em criar qualquer
aspecto de um Incremento utilizável a cada Sprint.

As habilidades específicas necessárias pelos Developers geralmente são amplas e variam de

acordo com o domínio de trabalho. No entanto, os Developers são sempre responsáveis por:

Licensed to Sara Regina da Silva Vieira - sreginavieira@gmail.com

 ● Criar um plano para a Sprint, o Sprint Backlog;
● Introduzir gradualmente qualidade aderindo a uma Definition of Done;
● Adaptar seu plano a cada dia em direção à meta da Sprint; e,
● Responsabilizar-se mutuamente como profissionais.

Product Owner
O Product Owner é responsável por maximizar o valor do produto resultante do trabalho do
Scrum Team. A forma como isso é feito pode variar amplamente entre organizações, Scrum
Teams e indivíduos.

O Product Owner também é responsável pelo gerenciamento eficaz do Product Backlog , que
inclui:

● Desenvolver e comunicar explicitamente a meta do produto;

● Criar e comunicar claramente os itens do Product Backlog;
● Ordenar os itens do Product Backlog; e,
● Garantir que o Product Backlog seja transparente, visível e compreensível.

O Product Owner pode fazer o trabalho acima ou pode delegar a responsabilidade a outros.
Independentemente disso, o Product Owner ainda é o responsável.

Para que os Product Owners tenham sucesso, toda a organização deve respeitar suas
decisões. Essas decisões são visíveis no conteúdo e na ordem do Product Backlog e por meio
do incremento inspecionável na revisão da sprint.

O Product Owner é uma pessoa, não um comitê. O Product Owner pode representar as
necessidades de muitos stakeholders no Product Backlog. Aqueles que desejam alterar o
Product Backlog podem fazê-lo tentando convencer o Product Owner.

Scrum Master
O Scrum Master é responsável por estabelecer o Scrum conforme definido no Guia do Scrum.
Eles fazem isso ajudando todos a entender a teoria e a prática do Scrum, tanto no Scrum Team
quanto na organização.

O Scrum Master é responsável pela eficácia do Scrum Team. Eles fazem isso permitindo que o
Scrum Team melhore suas práticas, dentro do framework Scrum

Scrum Masters são verdadeiros líderes que servem ao Scrum Team e à organização como um
todo.

O Scrum Master serve ao Scrum Team de várias maneiras, incluindo:

Licensed to Sara Regina da Silva Vieira - sreginavieira@gmail.com

 ● Treinar os membros do time em autogerenciamento e cross-funcionalidade;
● Ajudar o Scrum Team a se concentrar na criação de incrementos de alto valor que
atendem à Definition of Done;
● Provocando a remoção de impedimentos ao progresso do Scrum Team; e,
● Garantir que todos os eventos Scrum ocorram e sejam positivos, produtivos e mantidos
dentro do Timebox.

O Scrum Master serve o Product Owner de várias maneiras, incluindo:

● Ajudar a encontrar técnicas para a definição eficaz de meta do Produto e gerenciamento

do Product Backlog;
● Ajudar o Scrum Team a entender a necessidade de itens do Product Backlog claros e
concisos;
● Ajudar a estabelecer o planejamento empírico do produto para um ambiente complexo;
e,
● Facilitar a colaboração dos stakeholder, conforme solicitado ou necessário.

O Scrum Master serve a organização de várias maneiras, incluindo:

● Liderar, treinar e orientar a organização na adoção do Scrum;

● Planejar e aconselhar implementações de Scrum dentro da organização;
● Ajudar os funcionários e os stakeholders a compreender e aplicar uma abordagem
empírica para trabalhos complexos; e,
● Remover barreiras entre stakeholders e Scrum Teams.

Eventos Scrum
A Sprint é um contêiner para todos os outros eventos. Cada evento no Scrum é uma
oportunidade formal para inspecionar e adaptar os artefatos do Scrum. Esses eventos são
projetados especificamente para permitir a transparência necessária. A falha em operar
quaisquer eventos conforme prescrito resulta em oportunidades perdidas de inspeção e
adaptação. Os eventos são usados no Scrum para criar regularidade e minimizar a
necessidade de reuniões não definidas no Scrum. O ideal é que todos os eventos sejam
realizados no mesmo horário e local para reduzir a complexidade.

A Sprint
Sprints são o coração do Scrum, onde ideias são transformadas em valor.

São eventos de duração fixa de um mês ou menos para criar consistência. Uma nova Sprint
começa imediatamente após a conclusão da Sprint anterior.

Licensed to Sara Regina da Silva Vieira - sreginavieira@gmail.com

 Todo o trabalho necessário para atingir a meta do Produto, incluindo Sprint Planning, Daily
Scrums, Sprint Review e Sprint Retrospective, acontece dentro de Sprints.

Durante a Sprint:

● Nenhuma mudança é feita que coloque em risco a meta da Sprint;

● A qualidade não diminui;
● O Product Backlog é refinado conforme necessário; e,
● O escopo pode ser esclarecido e renegociado com o Product Owner conforme mais é
aprendido.

Sprints permitem previsibilidade, garantindo a inspeção e adaptação do progresso em direção a

uma meta do Produto ao menos uma vez por mês. Quando o horizonte de uma Sprint é muito
longo, a meta da Sprint pode se tornar inválida, a complexidade pode aumentar e o risco pode
aumentar. Sprints mais curtas podem ser empregados para gerar mais ciclos de aprendizagem
e limitar os riscos de custo e esforço a um período de tempo menor. Cada Sprint pode ser
considerado um projeto curto.

Existem várias práticas para prever o progresso, como burn-downs, burn-ups ou cumulative
flows. Embora comprovadamente úteis, eles não substituem a importância do empirismo. Em
ambientes complexos, o que acontecerá é desconhecido. Somente o que já aconteceu pode
ser usado para a tomada de decisão voltada para o futuro.

Uma Sprint pode ser cancelada se a Meta da Sprint se tornar obsoleta. Apenas o Product
Owner tem autoridade para cancelar a Sprint.

Sprint Planning
A Sprint Planning inicia a Sprint ao definir o trabalho a ser realizado na Sprint. Este plano
resultante é criado pelo trabalho colaborativo de todo o Scrum Team.

O Product Owner garante que os participantes estejam preparados para discutir os itens mais
importantes do Product Backlog e como eles são mapeados para a Meta do Produto. O Scrum
Team também pode convidar outras pessoas para participar da Sprint Planning para fornecer
conselhos.

A Sprint Planning aborda os seguintes tópicos:

Tópico um: Por que esta Sprint é valiosa?

O Product Owner propõe como o produto pode aumentar seu valor e utilidade no Sprint atual.
Todo o Scrum Team então colabora para definir uma Meta da Sprint que comunica porque a
Sprint é valiosa para os stakeholders. A meta da Sprint deve ser finalizada antes do final da
Sprint Planning.

Licensed to Sara Regina da Silva Vieira - sreginavieira@gmail.com

 Tópico dois: O que pode ser feito nesta Sprint?

Por meio de discussão com o Product Owner, os Developers selecionam itens do Product
Backlog para incluir na Sprint atual. O Scrum Team pode refinar esses itens durante este
processo, o que aumenta a compreensão e a confiança.

Selecionar o quanto pode ser concluído em uma Sprint pode ser um desafio. No entanto,
quanto mais os Developers sabem sobre seu desempenho anterior, sua capacidade futura e
sua Definition of Done, mais confiantes eles estarão em suas previsões quanto a Sprint.

Tópico três: Como o trabalho escolhido será realizado?

Para cada item do Product Backlog selecionado, os Developers planejam o trabalho necessário
para criar um Incremento que atenda à Definition of Done. Isso geralmente é feito decompondo
itens do Product Backlog em itens de trabalho menores de um dia ou menos. A forma como
isso é feito fica a critério exclusivo dos Developers . Ninguém mais diz a eles como transformar
itens do Product Backlog em incrementos de valor.

A Meta da Sprint, os itens do Product Backlog selecionados para a Sprint, mais o plano para
entregá-los são chamados juntos de Sprint Backlog.

A Sprint Planning tem um Timebox definido com duração máxima de de oito horas para uma
Sprint de um mês. Para Sprints mais curtas, o evento geralmente é mais curto.

Daily Scrum
O propósito da Daily Scrum é inspecionar o progresso em direção a Meta da Sprint e adaptar o
Sprint Backlog conforme necessário, ajustando o próximo trabalho planejado.

A Daily Scrum é um evento de 15 minutos para os Developers do Scrum Team. Para reduzir a
complexidade, é realizado no mesmo horário e local, todos os dias úteis da Sprint. Se o
Product Owner ou o Scrum Master estão trabalhando ativamente nos itens do Sprint Backlog,
eles participam como Developers.

Os Developers podem selecionar qualquer estrutura e técnicas que quiserem, desde que seu
Daily Scrum se concentre no progresso em direção a Meta da Sprint e produza um plano de
ação para o próximo dia de trabalho. Isso cria foco e melhora o autogerenciamento.

As Daily Scrums melhoram as comunicações, identificam os impedimentos, promovem a rápida

tomada de decisões e consequentemente, eliminam a necessidade de outras reuniões.

10

Licensed to Sara Regina da Silva Vieira - sreginavieira@gmail.com

 A Daily Scrum não é o único momento em que os Developers podem ajustar seu plano. Eles
costumam se reunir ao longo do dia para discussões mais detalhadas sobre a adaptação ou
replanejamento do resto do trabalho da Sprint.

Sprint Review
O propósito da Sprint Review é inspecionar o resultado da Sprint e determinar as adaptações
futuras. O Scrum Team apresenta os resultados de seu trabalho para os principais
stakeholders e o progresso em direção a Meta do Produto é discutido.

Durante o evento, o Scrum Team e os stakeholders revisam o que foi realizado na Sprint e o
que mudou em seu ambiente. Com base nessas informações, os participantes colaboram sobre
o que fazer a seguir. O Product Backlog também pode ser ajustado para atender a novas
oportunidades. A Sprint Review é uma sessão de trabalho e o Scrum Team deve evitar limitá-la
a uma apresentação.

A Sprint Review é o penúltimo evento da Sprint e tem um Timebox com prazo máximo de
quatro horas para uma Sprint de um mês. Para Sprints mais curtas, o evento geralmente é
mais curto.

Sprint Retrospective
O propósito da Sprint Retrospective é planejar maneiras de aumentar a qualidade e a eficácia.

O Scrum Team inspeciona como foi a última Sprint em relação a indivíduos, interações,
processos, ferramentas e sua Definition of Done. Os elementos inspecionados geralmente
variam com o domínio de trabalho. As suposições que os desviaram são identificadas e suas
origens exploradas. O Scrum Team discute o que deu certo durante a Sprint, quais problemas
encontraram e como esses problemas foram (ou não) resolvidos.

O Scrum Team identifica as mudanças mais úteis para melhorar sua eficácia. As melhorias
mais impactantes são endereçadas o mais rápido possível. Essas podem até ser adicionadas
ao Sprint Backlog para a próxima Sprint.

A Sprint Retrospective conclui a Sprint. É limitada pelo Timebox de no máximo três horas para
uma Sprint de um mês. Para Sprints mais curtas, o evento geralmente é mais curto.

Scrum Artifacts
Os artefatos do Scrum representam trabalho ou valor. Eles são projetados para maximizar a
transparência das principais informações. Assim, todos os que os inspeciona têm a mesma
base para adaptação.

11

Licensed to Sara Regina da Silva Vieira - sreginavieira@gmail.com

 Cada artefato contém um compromisso para garantir que ele forneça informações que
aumentem a transparência e o foco contra o qual o progresso pode ser medido:

● Para o Product Backlog, é a Meta do produto.

● Para o Sprint Backlog, é a Meta da Sprint.
● Para o incremento, é a Definition of Done.

Esses compromissos existem para reforçar o empirismo e os valores Scrum para o Scrum
Team, e seus stakeholders.

Product Backlog
O Product Backlog é uma lista ordenada e emergente do que é necessário para melhorar o
produto. É a única fonte de trabalho realizado pelo Scrum Team.

Os itens do Product Backlog que podem ser realizados pelo Scrum Team em uma Sprint são
considerados preparados para seleção no evento Sprint Planning. Eles geralmente adquirem
esse grau de transparência após as atividades de refinamento. O Product Backlog refinement é
o ato de quebrar e incluir definição adicional aos itens do Product Backlog para ter itens
menores e mais precisos. Esta é uma atividade contínua para adicionar detalhes, como
descrição, ordem e tamanho. Os atributos geralmente variam de acordo com o domínio de
trabalho.

Os Developers que farão o trabalho são responsáveis pelo dimensionamento. O Product Owner
pode influenciar os Developers, ajudando-os a entender e selecionar trade-offs (trocas de
itens).

Compromisso: Meta do Produto

A Meta do Produto descreve um estado futuro do produto que pode servir como um alvo para o
Scrum Team planejar. A Meta do produto está no Product Backlog. O restante do Product
Backlog emerge para definir “o que” cumprirá a Meta do Produto.

Um produto é um veículo para entregar valor. Tem um limite claro, stakeholders

conhecidos, usuários ou clientes bem definidos. Um produto pode ser um serviço, um
produto físico ou algo mais abstrato.

A Meta do Produto é o objetivo de longo prazo para o Scrum Team. Eles devem cumprir (ou
abandonar) um objetivo antes de assumir o próximo.

12

Licensed to Sara Regina da Silva Vieira - sreginavieira@gmail.com

 Sprint Backlog
O Sprint Backlog é composto pela Meta da Sprint (por que), o conjunto de itens do Product
Backlog selecionados para a Sprint (o que), bem como um plano de ação para entregar o
Incremento (como).

O Sprint Backlog é um plano feito por e para os Developers. É uma imagem altamente visível,
em tempo real do trabalho que os Developers planejam realizar durante a Sprint para atingir a
Meta da Sprint. Consequentemente, o Sprint Backlog é atualizado ao longo da Sprint conforme
mais é aprendido. Deve ter detalhes suficientes para que eles possam inspecionar seu
progresso na Daily Scrum.

Compromisso: Meta da Sprint

A Meta da Sprint é o único objetivo da Sprint. Embora a Meta da Sprint seja um compromisso
dos Developers, esta fornece flexibilidade em termos do trabalho exato necessário para
alcançá-la. A Meta da Sprint também cria coerência e foco, encorajando o Scrum Team a
trabalhar junto ao invés de iniciativas separadas.

A Meta da Sprint é criada durante o evento Sprint Planning e então adicionada ao Sprint
Backlog. Conforme os Developers trabalham durante a Sprint, eles mantêm a Meta da Sprint
em mente. Se o trabalho acabar sendo diferente do que eles esperavam, eles colaboram com o
Product Owner para negociar o escopo do Sprint Backlog dentro da Sprint sem afetar a Meta
da Sprint.

Incremento
Um incremento é um trampolim concreto em direção a Meta do produto. Cada incremento é
adicionado a todos os incrementos anteriores e completamente verificado, garantindo que
todos os incrementos funcionem juntos. A fim de fornecer valor, o incremento deve ser
utilizável.

Vários incrementos podem ser criados em uma Sprint. A soma dos incrementos é apresentada
na Sprint Review, apoiando assim o empirismo. No entanto, um incremento pode ser entregue
aos stakeholders antes do final da Sprint. A Sprint Review nunca deve ser considerada um
marco para liberar valor.

O trabalho não pode ser considerado parte de um incremento a menos que atenda o Definition
of Done.

13

Licensed to Sara Regina da Silva Vieira - sreginavieira@gmail.com

 Compromisso: Definição de Pronto
A Definição de Pronto é uma descrição formal do estado do Incremento quando ela atende às
medidas de qualidade exigidas para o produto.

No momento em que um item do Product Backlog atende a Definicao de Pronto, um incremento

nasce.

O Definição de Pronto cria transparência ao fornecer a todos um entendimento compartilhado

de qual trabalho foi concluído como parte do Incremento. Se um item do Product Backlog não
atender à Definição de Pronto, ele não poderá ser liberado ou mesmo apresentado na Sprint
Review. Em vez disso, ele retorna ao Product Backlog para consideração futura.

Se a Definição de Pronto para um incremento faz parte dos padrões da organização, todos os
Scrum Teams devem segui-la como mínimo. Se não for um padrão organizacional, o Scrum
Team deve criar uma Definição de Pronto apropriada para o produto.

Os Developers devem estar em conformidade com a Definição de Pronto. Se houver vários

Scrum Teams trabalhando juntos em um produto, eles devem definir e cumprir mutuamente a
mesma Definição de Pronto.

14

Licensed to Sara Regina da Silva Vieira - sreginavieira@gmail.com

 Nota Final
Scrum é gratuito e oferecido neste Guia. O framework Scrum, conforme descrito aqui, é
imutável. Embora a implementação de apenas partes do Scrum seja possível, o resultado não
é Scrum. Scrum existe apenas em sua totalidade e funciona bem como um contêiner para
outras técnicas, metodologias e práticas.

Reconhecimentos

Pessoas
Das milhares de pessoas que contribuíram para o Scrum, devemos destacar aquelas que
foram fundamentais no início: Jeff Sutherland trabalhou com Jeff McKenna e John
Scumniotales, e Ken Schwaber trabalhou com Mike Smith e Chris Martin, e todos eles
trabalharam juntos. Muitos outros contribuíram nos anos seguintes e sem sua ajuda o Scrum
não seria refinado como é hoje.

A História do Guia Scrum

Ken Schwaber e Jeff Sutherland primeiramente co-apresentaram o Scrum na Conferência
OOPSLA em 1995. Essencialmente, documentou o aprendizado que Ken e Jeff obtiveram nos
poucos anos anteriores e tornou pública a primeira definição formal de Scrum.

O Guia do Scrum documenta o Scrum conforme desenvolvido, evoluído e sustentado por mais
de 30 anos por Jeff Sutherland e Ken Schwaber. Outras fontes fornecem padrões, processos e
percepções que complementam o framework Scrum. Estes podem aumentar a produtividade,
valor, criatividade e satisfação com os resultados.

A história completa do Scrum é descrita em outros lugares. Para homenagear os primeiros

lugares onde foi testado e comprovado, reconhecemos Individual Inc., Newspage, Fidelity
Investments e IDX (agora GE Medical).

Tradução
Este guia foi traduzido da versão original em inglês, fornecida pelas pessoas reconhecidas
acima. Os colaboradores desta tradução incluem Fábio Cruz, Eduardo Rodrigues Sucena e
Rodrigo Paulo Camargo.

15

Licensed to Sara Regina da Silva Vieira - sreginavieira@gmail.com

 Mudanças entre o Guia Scrum 2017 e o Guia Scrum 2020
Ainda Menos Prescritivo
Ao longo dos anos, o Guia Scrum começou a ficar um pouco mais prescritivo. A versão 2020 buscou
trazer o Scrum de volta a ser um framework minimamente suficiente removendo ou suavizando a
linguagem prescritiva, por exemplo: removidas as questões da Daily Scrum, linguagem suavizada em
relação a atributos do PBI, linguagem suavizada em relação a itens de retrospectiva no Sprint Backlog,
diminuição da seção referente ao Cancelamento da Sprint, e mais.

Um Time, focado em Um Produto

O objetivo era eliminar o conceito de um time separado dentro do time o que tem guiado para
comportamentos de “proxy” ou de “nós e eles” entre o PO e o Time de Desenvolvimento. Há agora
apenas um Scrum Team focado no mesmo objetivo, com três responsabilidades: PO, SM e Developers.

Introdução da Meta do Produto

O Guia Scrum 2020 introduz o conceito de Meta do Produto para fornecer foco para o Scrum Team em
direção a um objetivo mais valioso. Cada sprint deve trazer o produto mais próximo da Meta geral do
Produto.

Uma casa para a Meta da Sprint, Definicao de Pronto, e Meta do Produto

Os Guias Scrum anteriores descreviam a Meta da Sprint e a Definição de Pronto sem realmente lhes dar
uma identidade. Eles não eram bem um artefato mas eram de alguma forma anexados a artefatos. Com
a adição da Meta do Produto, a versão 2020 fornece mais clareza a isso. Cada um dos três artefatos
agora contém “comprometimentos” a eles. Para o Product Backlog é a Meta do Produto, o Sprint Backlog
tem a Meta da Sprint, e o Incremento possui a Definição de Pronto (agora sem as aspas). Eles existem
para trazer transparência e foco em direção ao progresso de cada artefato.

Auto-Gerenciáveis acima de Auto-Organizados

Os Guias Scrum anteriores se referiam ao Time de Desenvolvimento como Auto-Organizados,
escolhendo quem e como fariam o trabalho. Com mais foco no Scrum Team, a versão 2020 enfatiza um
Scrum Team auto-gerenciado, escolhendo quem, como e no que trabalhar.

Os Tres Topicos da Sprint Planning

Em adição aos tópicos da Sprint Planning “O que” e “Como”, o Guia Scrum 2020 coloca ênfase a um
terceiro tópico, “Por que”, referente a Meta da Sprint.

Simplificação Geral de Linguagem para uma Audiência mais Ampla

O Guia Scrum 2020 coloca ênfase na eliminação de informações redundantes e complexas assim como
removendo qualquer inferência remanescente ao trabalho de IT (por exemplo, testes, sistemas, design,
requerimento, etc). O Guia Scrum agora possui menos do que 13 páginas.

16

Licensed to Sara Regina da Silva Vieira - sreginavieira@gmail.com