Ken Schwaber & Jeff Sutherland 
 
 
 
 
 
 
 
 
 
 

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

Novembro 2020 
   

 
 

Objetivo do Guia do Scrum 
Desenvolvemos o Scrum no início dos anos 90. Escrevemos a primeira versão do Guia do Scrum em 2010 
para  ajudar  pessoas  em  todo  o  mundo  a  compreender  o  Scrum.  Desenvolvemos  o  Guia  desde  então 
através de pequenas atualizações funcionais. Juntos, estamos por detrás disto. 
 
O Guia do Scrum contém a definição de Scrum. Cada elemento da estrutura serve um objetivo específico 
que é essencial para o valor global e para os resultados obtidos com o Scrum. Mudar o desenho do seu 
núcleo ou as ideias do Scrum, deixando de fora elementos ou não seguindo as regras do Scrum, encobre 
os problemas e limita os benefícios do Scrum, podendo mesmo torná‐lo inútil. 
 
Nós seguimos o uso crescente do Scrum num mundo cada vez mais complexo. Temos a humildade de 
ver o Scrum a ser adotado em muitos domínios com trabalho essencialmente complexo, para além do 
desenvolvimento de produtos de software, onde o Scrum tem as suas raízes. À medida que a utilização 
do Scrum se espalha, os criadores, investigadores, analistas, cientistas e outros especialistas fazem o seu 
trabalho. Usamos a palavra "criadores" no Scrum não para excluir mas para simplificar. Se obtiver valor 
do Scrum, considere‐se incluído. 
 
À  medida  que  o  Scrum  vai  sendo  utilizado,  podem  ser  encontrados,  aplicados  e  concebidos  padrões, 
processos e perceções que se enquadrem na estrutura do Scrum, tal como descrito neste documento. A 
sua descrição está para além do objetivo do Guia do Scrum porque são sensíveis ao contexto e diferem 
muito  entre  as  utilizações  do  Scrum.  Tais  táticas  de  utilização  dentro  da  estrutura  do  Scrum  variam 
muito e são descritas noutros locais. 
 
 
  
Ken Schwaber & Jeff Sutherland Novembro 2020 
 
 
 
 
 
 
 
© 2020 Ken Schwaber and Jeff Sutherland 
 
This publication is offered for license under the Attribution Share‐Alike license of Creative Commons, 
accessible at http://creativecommons.org/licenses/by‐sa/4.0/legalcode and also described in summary 
form at http://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.   

1 
 

 
Objetivo do Guia do Scrum ........................................................................................................................... 1
Definição do Scrum ....................................................................................................................................... 3
Teoria do Scrum ............................................................................................................................................ 3
Transparência ............................................................................................................................................ 4
Inspeção .................................................................................................................................................... 4
Adaptação ................................................................................................................................................. 4
Valores do Scrum .......................................................................................................................................... 4
Scrum Team .................................................................................................................................................. 5
Developers ................................................................................................................................................ 5
Product Owner .......................................................................................................................................... 6
Scrum Master ............................................................................................................................................ 6
Eventos Scrum ............................................................................................................................................... 7
O Sprint ..................................................................................................................................................... 7
Sprint Planning .......................................................................................................................................... 8
Daily Scrum ............................................................................................................................................... 9
Sprint Review .......................................................................................................................................... 10
Sprint Retrospective ................................................................................................................................ 10
Artefatos do Scrum ..................................................................................................................................... 10
Product Backlog ...................................................................................................................................... 11
Compromisso: Product Goal ............................................................................................................... 11
Sprint Backlog ......................................................................................................................................... 11
Compromisso: Sprint Goal .................................................................................................................. 12
Increment ................................................................................................................................................ 12
Compromisso: Definition of Done ...................................................................................................... 12
Nota Final .................................................................................................................................................... 14
Agradecimentos .................................................................................................................................. 14
Pessoas ................................................................................................................................................ 14
A História do Guia do Scrum ............................................................................................................... 14
Tradução ............................................................................................................................................. 14
Mudanças do Guia do Scrum 2017 para o Guia do Scrum 2020 ........................................................ 15
   

2 
 

Definição do Scrum 
O  Scrum  é  uma  estrutura  leve  que  ajuda  as  pessoas,  equipas  e  organizações  a  gerar  valor  através  de 
soluções adaptativas para problemas complexos.  
  
Em poucas palavras, Scrum requer um Scrum Master para promover um ambiente onde: 
 
1. Um Product Owner encomenda o trabalho para um problema complexo num Product Backlog. 
2. A Scrum Team transforma uma seleção do trabalho num Increment de valor durante um Sprint. 
3. A Scrum Team e os seus stakeholders inspecionam os resultados e ajustam‐se para o próximo 
Sprint. 
4. Repete. 
  
O Scrum é simples. Experimente‐o como é e determine se a sua  filosofia, teoria e estrutura ajudam a 
atingir objetivos e a criar valor. A estrutura do Scrum é propositadamente incompleta, definindo apenas 
as  partes  necessárias  para  implementar  a  teoria  do  Scrum.  O  Scrum  é  construído  com  base  na 
inteligência coletiva das pessoas que o utilizam. Em vez de fornecer instruções detalhadas às pessoas, as 
regras do Scrum guiam as suas relações e interações. 
 
Vários processos, técnicas e métodos podem ser utilizados nesta estrutura. O Scrum envolve as práticas 
existentes  ou  torna‐as  desnecessárias.  O  Scrum  torna  visível  a  eficácia  relativa  da  gestão,  ambiente  e 
técnicas de trabalho atuais, de modo a que se possam fazer melhorias. 

Teoria do Scrum 
O Scrum baseia‐se no empirismo e no pensamento lean. O empirismo afirma que o conhecimento vem 
da  experiência  e  da  tomada  de  decisões  com  base  no  que  é  observado.  O  pensamento  lean  reduz  o 
desperdício e concentra‐se no essencial. 
 
O  Scrum  emprega  uma  abordagem  iterativa  e  incremental  para  optimizar  a  previsibilidade  e  para 
controlar  o  risco.  O  Scrum  envolve  grupos  de  pessoas  que  coletivamente  têm  todas  as  aptidões  e 
conhecimentos para fazer o trabalho e partilhar ou adquirir tais aptidões conforme necessário. 
  
O  Scrum  combina  quatro  eventos  formais  para  inspeção  e  adaptação  contidos  dentro  de  um  outro 
evento,  o  Sprint.  Estes  eventos  funcionam  porque  implementam  os  pilares  empíricos  Scrum  de 
transparência, inspeção e adaptação. 
 
 
 
 

3 
 

Transparência 
O processo emergente e o trabalho devem ser visíveis tanto para quem executa o trabalho como para os 
que  o  recebem.  Com  o  Scrum,  as  decisões  importantes  baseiam‐se  na  percepção  do  estado  dos  seus 
três artefatos formais. Os artefatos que têm pouca 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 é enganadora e um desperdício. 

Inspeção 
Os artefatos do Scrum e o progresso rumo aos objetivos acordados, devem ser inspecionados frequente 
e  diligentemente  para  detetar  variâncias  ou  problemas  potencialmente  indesejáveis.  Para  ajudar  na 
inspeção, o Scrum fornece cadência sob a forma dos seus cinco eventos. 
  
A inspeção permite a adaptação. A inspeção sem adaptação é considerada inútil. Os eventos do Scrum 
são concebidos para provocar mudanças. 

Adaptação 
Se  quaisquer  aspetos  de  um  processo  se  desviarem  para  fora  dos  limites  aceitáveis  ou  se  o  produto 
resultante  for  inaceitável,  o  processo  a  ser  aplicado  ou  os  artigos  a  serem  produzidos  devem  ser 
ajustados. O ajustamento deve ser feito o mais rapidamente possível para minimizar novos desvios. 
  
A  adaptação  torna‐se  mais  difícil  quando  as  pessoas  envolvidas  não  estão  capacitadas  nem  são 
autogeridas. Espera‐se que uma Scrum Team se adapte no momento em que aprende algo novo através 
da inspeção. 

Valores do Scrum 
A utilização bem‐sucedida do Scrum depende das pessoas se tornarem mais proficientes em viver cinco 
valores: 
Compromisso, Foco, Abertura, Respeito e Coragem 
A  Scrum  Team  compromete‐se  a  alcançar  os  seus  objetivos  e  a  apoiar‐se  mutuamente.  O  seu  foco 
principal é o trabalho do Sprint para fazer o melhor progresso possível em direção a estes objetivos. A 
Scrum Team e os seus stakeholders estão abertos em relação ao trabalho e aos desafios. Os membros 
da  Scrum  Team  respeitam‐se  uns  aos  outros  para  serem  capazes  e  pessoas  independentes,  sendo 
respeitados como tal pelas pessoas com quem trabalham. Os membros da Scrum Team têm a coragem 
de fazer o que está certo e trabalhar em problemas difíceis. 
 
 

4 
 

Estes  valores  dão  orientação  à  Scrum  Team  no  que  diz  respeito  ao  seu  trabalho,  ações  e 
comportamento.  As  decisões  que  são  tomadas,  os  passos  dados  e  a  forma  como  o  Scrum  é  utilizado, 
devem  reforçar  estes  valores  e  não  reduzi‐los  ou  miná‐los.  Os  membros  da  Scrum  Team  aprendem  e 
exploram os valores enquanto trabalham com os eventos e os artefatos do Scrum. Quando estes valores 
são  encarnados  pela  Scrum  Team  e  as  pessoas  com  quem  trabalham,  os  pilares  empíricos  Scrum  da 
transparência, inspeção e adaptação ganham vida construindo confiança. 

Scrum Team 
A unidade fundamental do Scrum é uma pequena equipa de pessoas, uma Scrum Team. A Scrum Team é 
composta  por  um  Scrum  Master,  um  Product  Owner  e  Developers.  Dentro  de  uma  Scrum  Team,  não 
existem subequipas ou hierarquias. É uma unidade coesa de profissionais, focada num objetivo de cada 
vez, o Product Goal. 
 
As  Scrum  Teams  são  multifuncionais,  o  que  significa  que  os  membros  têm  todas  as  competências 
necessárias  para  criar  valor  em  cada  Sprint.  Também  são  autogeridas,  o  que  significa  que  decidem 
internamente quem faz o quê, quando e como. 
 
A  Scrum  Team  é  suficientemente  pequena  para  permanecer  ágil  e  suficientemente  grande  para 
completar um trabalho significativo dentro de um Sprint, tipicamente 10 ou menos pessoas. Em geral, 
descobrimos  que  as  equipas  mais  pequenas  comunicam  melhor  e  são  mais  produtivas.  Se  as  Scrum 
Teams  se  tornarem  demasiado  grandes,  devem  considerar  a  reorganização  em  múltiplas  Scrum  Team 
coesas, focadas no mesmo produto. Por conseguinte, devem partilhar o mesmo Product Goal, Product 
Backlog e Product Owner. 
 
A Scrum Team é responsável por todas as atividades relacionadas com os produtos, desde a colaboração 
dos stakeholders, verificação, manutenção, operação, experimentação, investigação e desenvolvimento, 
assim como tudo o mais que possa ser necessário. São estruturadas e capacitadas pela organização para 
gerir  o  seu  próprio  trabalho.  Trabalhar  em  Sprints  a  um  ritmo  sustentável  melhora  o  foco  e  a 
consistência da Scrum Team. 
 
Toda a Scrum Team é responsável pela criação de um valioso e útil Increment em cada Sprint. O Scrum 
define  três  responsabilidades  específicas  dentro  da  Scrum  Team:  os  Developers,  o  Product  Owner  e  o 
Scrum Master. 

Developers 
Os Developers são as pessoas da Scrum Team que estão empenhados em criar qualquer aspeto de um 
Increment utilizável em cada Sprint.  
 
As  competências  específicas  necessárias  aos  Developers  são  frequentemente  amplas  e  variam  com  o 
domínio de trabalho. Contudo, os Developers são sempre responsáveis por: 

5 
 

 
● Criar um plano para o Sprint, o Sprint Backlog; 
● Incutir qualidade, aderindo a uma Definition of Done; 
● Adaptar o seu plano todos os dias na direção do Sprint Goal; e, 
● Responsabilizarem‐se uns aos outros como profissionais. 

Product Owner 
O  Product  Owner  é  responsável  por  maximizar  o  valor  do  produto  resultante  do  trabalho  da  Scrum 
Team. A forma como isto é feito pode variar muito entre organizações, ScrumTeams e indivíduos. 
  
O Product Owner é também responsável pela gestão eficaz do Product Backlog, que inclui: 
 
● Desenvolver e comunicar explicitamente o Product Goal; 
● Criar e comunicar claramente os itens do Product Backlog; 
● Ordenar os itens do Product Backlog; e, 
● Assegurar que o Product Backlog é transparente, visível e compreendido. 
  
O Product Owner pode fazer o trabalho acima referido ou pode delegá‐lo a outros. Independentemente 
disso, o Product Owner permanece responsável. 

Para  que  o  Product  Owner  tenha  sucesso,  toda  a  organização  deve  respeitar  as  suas  decisões.  Estas 
decisões são visíveis no conteúdo e ordenação do Product Backlog e através do Increment inspecionável 
na Sprint Review.  
  
O Product Owner é uma pessoa, não um comité. O Product Owner pode representar as necessidades de 
muitos intervenientes 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 pela implementação do Scrum tal como definido no Guia do Scrum. Fá‐lo 
ajudando todos a compreender a teoria e a prática do Scrum, tanto dentro da Scrum Team como dentro 
da organização. 
  
O Scrum Master é responsável pela eficácia da Scrum Team. Fá‐lo permitindo à Scrum Team melhorar as 
suas práticas, dentro da estrutura do Scrum. 
 
Os Scrum Masters são verdadeiros líderes que servem a Scrum Team e a organização em geral. 
 
O Scrum Master serve a Scrum Team de várias formas, incluindo: 

6 
 

● Treinar os membros da equipa na auto‐gestão e na multifuncionalidade; 
● Ajudando  a  Scrum  Team  a  concentrar‐se  na  criação  de  Increments  de  alto  valor  que  vão  ao 
encontro da Definition of Done; 
● Causar a remoção de impedimentos ao progresso da Scrum Team; e, 
● Assegurar  que  todos  os  eventos  do  Scrum  têm  lugar  e  são  positivos,  produtivos  e  mantidos 
dentro tempo previsto. 
 
O Scrum Master serve o Product Owner de várias formas, incluindo: 
  
● Ajudando  a  encontrar  técnicas  para  uma  definição  eficaz  do  Product  Goal  e  para  a  gestão  do 
Product Backlog; 
● Ajudando  a  Scrum  Team  a  compreender  a  necessidade  de  itens  claros  e  concisos  no  Product 
Backlog; 
● Ajudar a estabelecer o planeamento empírico do produto para um ambiente complexo; e, 
● Facilitar a colaboração dos stakeholders conforme solicitado ou necessário. 
 
O Scrum Master serve a organização de várias formas, incluindo:  
 
● Liderar, formar e treinar a organização na sua adopção do Scrum; 
● Planear e aconselhar implementações de Scrum dentro da organização;  
● Ajudar  funcionários  e  stakeholders  a  compreender  e  adoptar  uma  abordagem  empírica  para 
trabalhos complexos; e, 
● Remover barreiras entre stakeholders e Scrum Teams. 

Eventos Scrum 
O  Sprint  é  um  recipiente  para  todos  os  outros  eventos.  Cada  evento  no  Scrum  é  uma  oportunidade 
formal para inspecionar e adaptar os artefatos do Scrum. Estes eventos são especificamente concebidos 
para  permitir  a  transparência  necessária.  A  não  realização  de  quaisquer  eventos  conforme  prescrito, 
resulta na perda de oportunidades de inspeção e adaptação. Os eventos são utilizados no Scrum para 
criar regularidade e para minimizar a necessidade de reuniões não definidas no Scrum.  
Idealmente,  todos  os  eventos  são  realizados  à  mesma  hora  e  no  mesmo  local  para  reduzir  a 
complexidade. 

O Sprint 
Os Sprints são o bater de coração do Scrum, onde as ideias são transformadas em valor. 
 
São  eventos  de  duração  fixa  de  um  mês  ou  menos  para  criar  consistência.  Um  novo  Sprint  começa 
imediatamente após a conclusão do Sprint anterior. 
 

7 
 

Todo o trabalho necessário para alcançar o Product Goal, incluindo ol Sprint Planning, as Daily Scrums, a 
Sprint Review e a Sprint Retrospective, acontece dentro dos Sprints. 
 
Durante o Sprint: 
 
● Não são feitas alterações que possam pôr em perigo o Sprint Goal; 
● A qualidade não diminui; 
● O Product Backlog é refinado conforme necessário; e, 
● O  âmbito  pode  ser  clarificado  e  renegociado  com  o  Product  Owner  à  medida  que  mais  se  for 
aprendendo. 
  
Os  Sprints  permitem  a  previsibilidade,  assegurando  a  inspeção  e  adaptação  do  progresso  para  um 
Product  Goal  pelo  menos  uma  vez  por  mês.  Quando  o  horizonte  de  um  Sprint  é  demasiado  longo,  o 
Sprint  Goal  pode  tornar‐se  inválido  e  a  complexidade  e  o  risco  podem  aumentar.  Sprints  mais  curtos 
podem ser utilizados para gerar mais ciclos de aprendizagem e  limitar o risco de custo e esforço num 
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  fluxos  cumulativos. 
Embora  comprovadamente  úteis,  estas  não  substituem  a  importância  do  empirismo.  Em  ambientes 
complexos,  o  que  irá  acontecer  é  desconhecido.  Apenas  o  que  já  aconteceu  pode  ser  utilizado  para  a 
tomada de decisão prospetiva. 
 
Um  Sprint  pode  ser  cancelado  se  o  Sprint  Goal  se  tornar  obsoleto.  Apenas  o  Product  Owner  tem 
autoridade para cancelar o Sprint.  

Sprint Planning 
O  Sprint  Planning  inicia  o  Sprint,  determinando  o  trabalho  a  ser  realizado  para  o  mesmo.  Este  plano 
resultante é criado pelo trabalho colaborativo de toda a Scrum Team. 
 
O Product Owner garante que os participantes estão preparados para discutir os itens mais importantes 
do  Product  Backlog  e  a  forma  como  eles  se  refletem  no  Product  Goal.  A  Scrum  Team  pode  também 
convidar outras pessoas a participar no Sprint Planning para darem conselhos. 
 
O Sprint Planning aborda os seguintes tópicos: 
 
Tópico Um: Porque é que este Sprint é valioso?  
O Product Owner propõe como o produto poderia aumentar o seu valor e utilidade no Sprint atual. Toda 
a  Scrum  Team  colabora  então  para  definir  um  Sprint  Goal  que  comunica  a  razão  pela  qual  o  Sprint  é 
valioso para os stakeholders. O Sprint Goal deve ser definido antes do fim do Sprint Planning.  
 

8 
 

Tópico Dois: O que se pode fazer neste Sprint? 
Através  de  discussão  com  o  Product  Owner,  os  Developers  selecionam  itens  do  Product  Backlog  para 
incluir no Sprint atual. A Scrum Team pode refinar estes itens durante este processo, o que aumenta a 
compreensão e a confiança. 
 
Selecionar quanto pode ser concluído dentro de um Sprint pode ser um desafio. Contudo, quanto mais 
os Developers souberem sobre o seu desempenho passado, a sua capacidade futura e a sua Definition of 
Done, mais confiantes estarão nas suas previsões para o Sprint. 
 
Tópico Três: Como será feito o trabalho escolhido? 
Para cada item de Product Backlog selecionado, os Developers planeiam o trabalho necessário para criar 
um Increment que corresponda à Definition of Done. Isto é frequentemente feito decompondo os itens 
do Product Backlog em itens de trabalho mais pequenos, de um dia ou menos. A forma como isto é feito 
fica ao critério exclusivo dos Developers. Ninguém lhes diz como transformar itens de Product Backlog 
em Increments de valor. 
 
O Sprint Goal, os itens de Product Backlog selecionados para o Sprint e o plano de entrega dos mesmos, 
são referidos em conjunto como o Sprint Backlog. 
 
O Sprint Planning é limitado a um máximo de oito horas para um Sprint de um mês. Para Sprints mais 
reduzidos, o evento é normalmente mais curto.  

Daily Scrum 
O  objetivo  da  Daily  Scrum  é  inspecionar  o  progresso  rumo  ao  Sprint  Goal  e  adaptar  o  Sprint  Backlog 
conforme necessário, ajustando o trabalho planeado que se aproxima. 
 
A  Daily  Scrum  é  um  evento  de  15  minutos  para  os  Developers  da  Scrum  Team.  Para  reduzir  a 
complexidade, é realizado à mesma hora e em todos os dias úteis do Sprint. Se o Product Owner ou o 
Scrum  Master  estiver  a  trabalhar  ativamente  nos  itens  do  Sprint  Backlog,  eles  participam  como 
Developers.  
 
Os Developers podem selecionar qualquer estrutura e técnicas que desejarem, desde que a Daily Scrum 
se  concentre  no  progresso  rumo  ao  Sprint  Goal  e  produza  um  plano  acionável  para  o  dia  de  trabalho 
seguinte. Isto cria foco e melhora a auto‐gestão. 
  
As  Daily  Scrums  melhoram  as  comunicações,  identificam  impedimentos,  promovem  a  tomada  de 
decisões rápidas e, consequentemente, eliminam a necessidade de outras reuniões. 
 

9 
 

A Daily Scrum não é o único momento em que os Developers são autorizados a ajustar o seu plano. Eles 
reúnem‐se  frequentemente  ao  longo  do  dia  para  discussões  mais  detalhadas  sobre  a  adaptação  ou 
reorganização do resto do trabalho do Sprint. 
  

Sprint Review 
O  objetivo  da  Sprint  Review  é  inspecionar  o  resultado  do  Sprint  e  determinar  adaptações  futuras.  A 
Scrum  Team  apresenta  os  resultados  do  seu  trabalho  aos  principais  stakeholders  e  são  discutidos  os 
progressos rumo ao Product Goal. 
 
Durante o evento, a ScrumTeam e os stakeholders analisam o que foi realizado no Sprint e o que mudou 
no seu ambiente. Com base nesta informação, os participantes colaboram sobre o que fazer a seguir. O 
Product  Backlog  também  pode  ser  ajustado  para  ir  ao  encontro  de  novas  oportunidades.  A  Sprint 
Review é uma sessão de trabalho e a Scrum Team deve evitar limitá‐la a uma apresentação.  
 
A  Sprint  Review  é  o  penúltimo  evento  do  Sprint  e  é  limitada  a  um  máximo  de  quatro  horas  para  um 
Sprint de um mês. Para Sprints mais reduzidos, o evento é geralmente mais curto. 

Sprint Retrospective 
O objetivo da Sprint Retrospective é planear formas de aumentar a qualidade e eficácia. 
 
A  Scrum  Team  inspeciona  como  correu  o  último  Sprint  no  que  diz  respeito  a  indivíduos,  interações, 
processos, ferramentas e à sua Definition of Done. Os elementos inspecionados variam frequentemente 
com  o  âmbito  do  trabalho.  As  suposições  que  os  desviaram  são  identificadas  e  as  suas  origens 
exploradas. A Scrum Team discute o que correu bem durante o Sprint, que problemas encontrou e como 
esses problemas foram (ou não) resolvidos. 
 
A  Scrum  Team  identifica  as  mudanças  mais  úteis  para  melhorar  a  sua  eficácia.  As  melhorias  mais 
impactantes são endereçadas o mais rapidamente possível. Podem mesmo ser acrescentadas ao Sprint 
Backlog para o Sprint seguinte. 
 
A  Sprint  Retrospective  conclui  o  Sprint.  É  limitada  a  um  máximo  de  três  horas  para  um  Sprint  de  um 
mês. Para Sprints mais reduzidos, o evento é normalmente mais curto. 

Artefatos do Scrum  
Os artefatos do Scrum representam trabalho ou valor. São concebidos para maximizar a transparência 
da informação chave. Assim, todos os que os inspecionam têm a mesma base para adaptação.  
 

10 
 

Cada  artefato  contém  um  compromisso,  para  assegurar  que  fornece  informação  que  aumenta  a 
transparência e o foco, contra o qual o progresso pode ser medido:  
 
● Para o Product Backlog é Product Goal. 
● Para o Sprint Backlog é o Sprint Goal. 
● Para o Increment é a Definition of Done. 
 
Estes compromissos existem para reforçar o empirismo e os valores do Scrum para a Scrum Team e os 
seus stakeholders. 

Product Backlog 
O Product Backlog é uma lista emergente e ordenada do que é necessário para melhorar o produto. É a 
única fonte de trabalho levada a cabo pela Scrum Team.  
 
Os  artigos  do  Product  Backlog  que  podem  ser  feitos  pela  Scrum  Team  dentro  de  um  Sprint,  são 
considerados prontos para seleção num evento de Sprint Planning. Normalmente adquirem este grau de 
transparência  após  as  atividades  de  refinamento.  O  refinamento  do  Product  Backlog  é  o  ato  de 
decompor  e  definir  melhor  os  itens  do  mesmo  em  itens  mais  pequenos  e  mais  precisos.  Esta  é  uma 
atividade contínua para acrescentar detalhes, tais como descrição, ordenação e tamanho. Os atributos 
variam frequentemente com o domínio de trabalho. 
 
Os  Developers  que  irão  fazer  o  trabalho  são  responsáveis  pelo  dimensionamento.  O  Product  Owner 
pode influenciar os Developers ajudando‐os a compreender e a selecionar trade‐offs.  

Compromisso: Product Goal 
O  Product  Goal  descreve  um  estado  futuro  do  produto  que  pode  servir  de  meta  para  a  Scrum  Team 
delinear o seu planeamento. O Product Goal está no Product Backlog. O resto do Product Backlog surge 
para definir "o que" o Product Goal irá cumprir.  

Um  produto  é  um  veículo  para  entregar  valor.  Tem  um  limite  claro,  stakeholders  conhecidos, 
utilizadores  ou  clientes  bem  definidos.  Um  produto  pode  ser  um  serviço,  um  produto  físico,  ou 
algo mais abstrato.  

O  Product  Goal  é  o  objetivo  a  longo  prazo  para  a  Scrum  Team.  Devem  cumprir  (ou  abandonar)  um 
objetivo antes de assumirem o próximo.  

Sprint Backlog  
O  Sprint  Backlog  é  composto  pelo  Sprint  Goal  (porquê),  o  conjunto  de  itens  do  Produto  Backlog 
selecionados para o Sprint (o quê), bem como um plano acionável para a entrega do Increment (como). 
 

11 
 

O Sprint Backlog é um plano de e para os Developers. É uma imagem altamente visível e em tempo real 
do  trabalho  que  os  Developers  planeiam  realizar  durante  o  Sprint,  a  fim  de  alcançar  o  Sprint  Goal. 
Consequentemente,  o  Sprint  Backlog  é  atualizado  durante  o  Sprint  à  medida  que  se  vai  aprendendo 
mais. Deverá ter detalhe suficiente para que possam inspecionar o seu progresso na Daily Scrum.  

Compromisso: Sprint Goal 
O  Sprint  Goal  é  o  único  objetivo  para  o  Sprint.  Embora  o  Sprint  Goal  seja  um  compromisso  dos 
Developers, proporciona flexibilidade em termos do trabalho exato necessário para o alcançar. O Sprint 
Goal  também  cria  coerência  e  foco,  encorajando  a  Scrum  Team  a  trabalhar  em  conjunto  e  não  em 
iniciativas separadas. 
 
O Sprint Goal é criado durante o Sprint Planning e depois adicionado ao Sprint Backlog. Durante o seu 
trabalho  durante  o  Sprint,  os  Developers  mantêm  o  Sprint  Goal  em  mente.  Se  o  trabalho  se  revelar 
diferente do que esperavam, colaboram com o Product Owner para negociar o âmbito do Sprint Backlog 
dentro do Sprint sem afetar o Sprint Goal. 

Increment 
Um  Increment  é  um  degrau  concreto  em  direção  ao  Product  Goal.  Cada  Increment  é  acrescentado  a 
todos  os  Increments  anteriores  e  cuidadosamente  verificado,  assegurando  que  todos  os  Increments 
funcionam em conjunto. A fim de fornecer valor, o Increment deve ser utilizável. 
 
Podem ser criados multiplos Increments dentro de um Sprint. A soma dos Increments é apresentada na 
Sprint  Review,  apoiando  assim  o  empirismo.  No  entanto,  um  Increment  pode  ser  entregue  aos 
stakeholders antes do fim do Sprint. A Sprint Review nunca deve ser considerada como uma porta para 
a entrega de valor.   
 
O trabalho não pode ser considerado parte de um Increment a menos que cumpra a Definition of Done.  

Compromisso: Definition of Done 
A Definition of Done é uma descrição formal do estado do Increment quando este cumpre as medidas 
de qualidade exigidas para o produto.  
 
No momento em que um item do Product Backlog satisfaz a Definition of Done, nasce um Increment. 
 
A  Definition  of  Done  cria  transparência  ao  proporcionar  a  todos  uma  compreensão  partilhada  do 
trabalho  que  foi  concluído  como  parte  do  Increment.  Se  um  item  de  Product  Backlog  não  cumpre  a 
Definition  of  Done,  não  pode  ser  lançado  ou  mesmo  apresentado  na  Sprint  Review.  Em  vez  disso, 
regressa ao Product Backlog para consideração futura.  
 

12 
 

Se  a  Definition  of  Done  para  um  Increment  fizer  parte  dos  padrões  da  organização,  todas  as  Scrum 
Teams  devem  segui‐lo  como  um  mínimo.  Se  não  for  uma  norma  organizacional,  a  Scrum  Team  deve 
criar uma Definition of Done apropriada para o produto.   
 
Os  Developers  são  obrigados  a  cumprir  a  Definition  of  Done.  Se  existirem  várias  Scrum  Teams  a 
trabalhar em conjunto num produto, devem definir e cumprir mutuamente a mesma Definition of Done. 

13 
 

Nota Final 
O Scrum é gratuito e oferecido neste Guia. A estrutura do Scrum, tal como aqui delineado, é imutável. 
Embora  seja  possível  implementar  apenas  partes  do  Scrum,  o  resultado  não  é  considerado  Scrum.  O 
Scrum  existe  apenas  como  um  todo  e  funciona  bem  como  um  recipiente  para  outras  técnicas, 
metodologias e práticas. 

Agradecimentos 

Pessoas  
Dos  milhares  de  pessoas  que  contribuíram  para  o  Scrum,  nós  devemos  destacar  aquelas  que  foram 
essenciais  no  início:  Jeff  Sutherland  trabalhou  com  Jeff  McKenna  e  John  Scumniotales,  Ken  Schwaber 
trabalhou  com  Mike  Smith  e  Chris  Martin,  e  todos  eles  trabalharam  em  conjunto.  Muitos  outros 
contribuíram nos anos que se seguiram e sem a sua ajuda, o Scrum não estaria tão refinado como está 
atualmente.  

A História do Guia do Scrum 
Ken Schwaber e Jeff Sutherland co‐apresentaram o Scrum pela primeira vez na Conferência da OOPSLA 
em 1995. Esta apresentação documentou essencialmente a aprendizagem que Ken e Jeff obtiveram nos 
anos anteriores e tornou pública a primeira definição formal de Scrum. 
 
O Guia do Scrum documenta o Scrum tal como foi desenvolvido, evoluído e sustentado durante mais de 
30 anos por Jeff Sutherland e  Ken Schwaber. Outras fontes fornecem padrões, processos e ideias que 
complementam  a  estrutura  do  Scrum.  Estas  podem  aumentar  a  produtividade,  valor,  criatividade  e 
satisfação com os resultados. 
 
A história completa do Scrum é descrita noutro local. Para honrar os primeiros lugares onde foi testado 
e comprovado, queremos reconhecer a Individual Inc., Newspage, Fidelity Investments e IDX (agora GE 
Medical). 

Tradução 
Este guia foi traduzido por Pedro Silva e Mário Pereira, a partir da versão original em inglês fornecida 
por Ken Schwaber e Jeff Sutherland. 
 
 

14 
 

Mudanças do Guia do Scrum 2017 para o Guia do Scrum 2020 

Ainda menos prescritivo  
Ao  longo  dos  anos,  o  Guia  do  Scrum  começou  a  tornar‐se  um  pouco  mais  prescritivo.  A  versão  2020 
visava  trazer  o  Scrum  de  volta  a  uma  estrutura  minima  suficiente,  removendo  ou  suavizando  a 
linguagem  prescritiva,  por  exemplo,  removendo  as  perguntas  da  Daily  Scrum,  suavizando  a  linguagem 
em torno dos atributos dos itens do Produck Backlog, suavizando a linguagem em torno dos itens retro 
no Sprint Backlog, reduzindo a secção do cancelamento do Sprint, entre outros.  

Uma Equipa, centrada Num Produto 
O  objetivo  era  eliminar  o  conceito  de  uma  equipa  separada  dentro  de  uma  equipa  que  levou  a  um 
comportamento de "procuração" ou "nós e eles" entre o Product Owner e Equipa de Desenvolvimento. 
Existe agora  apenas uma  Scrum  Team  centrada no  mesmo objetivo, com três conjuntos  diferentes de 
responsabilidades: Product Owner, Scrum Master e Developers. 

Introdução do Product Goal  
O Guia do Scrum 2020 introduz o conceito de um Product Goal a fim de proporcionar um foco para a 
Scrum Team rumo a um objetivo de maior valor. Cada Sprint deve aproximar o produto do Product Goal 
geral.  

Uma Casa para o Sprint Goal, Definition of Done e Product Goal 
Os Guias do Scrum anteriores descreviam o Sprint Goal e a Definition of Done sem realmente lhes dar 
uma identidade. Não eram bem artefatos mas estavam de certa forma ligados a artefatos. Com a adição 
do Product Goal, a versão 2020 fornece mais clareza em torno disto. Cada um dos três artefatos contém 
agora  "compromissos"  com  eles.  Para  o  Product  Backlog  é  o  Product  Goal,  o  Backlog  de  Sprint  tem  o 
Sprint  Goal  e  o  Increment  tem  a  Definition  of  Done  (agora  sem  as  aspas).  Estes  existem  para  trazer 
transparência e concentração no progresso de cada artefato. 

Auto‐Gestão em vez de Auto‐Organização   
Os  anteriores  Guias  do  Scrum  referiam‐se  às  Equipas  de  Desenvolvimento  como  auto‐organizadas, 
escolhendo  quem  e  como  fazer  o  trabalho.  Com  um  maior  enfoque  na  Scrum  Team,  a  versão  2020 
enfatiza uma auto‐gestão da Scrum Team, escolhendo quem, como e em que trabalhar.  

Três Tópicos do Sprint Planning 
Para  além  dos  tópicos  do  Sprint  Planning  de  "O  quê"  e  "Como",  o  Guia  do  Scrum  2020  coloca  ênfase 
num terceiro tópico, "Porquê", referindo‐se ao Sprint Goal. 

15 
 

Simplificação geral da linguagem para um público mais vasto  
O  Guia  do  Scrum  2020  colocou  ênfase  na  eliminação  de  declarações  redundantes  e  complexas,  bem 
como  na  eliminação  de  qualquer  inferência  remanescente  ao  trabalho  de  TI  (por  exemplo,  testes, 
sistema, concepção, requisitos, etc.). O Guia do Scrum tem agora menos de 13 páginas. 
 

16