Guia Scrum 2020

O Guia Scrum 2020TM

 

Objectivo do Guia Scrum

Desenvolvemos o Scrum no início dos anos 90. Escrevemos a primeira versão do Guia Scrum em 2010
para ajudar as pessoas de todo o mundo a compreender Scrum. Desde então, desenvolvemos o Guia
através de pequenas actualizações funcionais. Juntos, estamos por detrás dele.
O Guia Scrum contém a definição de Scrum. Cada elemento da estrutura serve um propósito
específico que é essencial para o valor global e resultados realizados com Scrum. Alterar o desenho do
núcleo ou ideias do Scrum, deixando de fora elementos, ou não seguir as regras do Scrum, encobre
problemas e limita os benefícios do Scrum, podendo mesmo torná-lo inútil.
Seguimos o uso crescente do Scrum dentro de um mundo cada vez mais complexo. Temos a
humildade de ver Scrum a ser adoptado em muitos domínios com trabalho essencialmente complexo,
para além do desenvolvimento de produtos de software onde 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 trabalho. Usamos a palavra "programadores" em 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 conhecimentos que se enquadram na estrutura do Scrum, tal como descrito neste
documento. A sua descrição está para além do objectivo do Guia Scrum porque são sensíveis ao
contexto e diferem muito entre as utilizações do Scrum. Tais tácticas de utilização dentro da estrutura
do Scrum variam muito e são descritas noutros locais.

Definição do scrum
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 Proprietário de Produto encomenda o trabalho para um problema complexo para um Backlog
de Produto.

2. A equipa Scrum transforma uma selecção da obra num Incremento de valor durante um Sprint.

3. A Equipa Scrum e os seus intervenientes inspeccionam os resultados e ajustam-se para a próxima

Sprint.
4. Repita
Scrum é simples. Experimente-o como está e determine se a sua filosofia, teoria e estrutura ajudam a
atingir objectivos e a criar valor. A estrutura Scrum é propositadamente incompleta, definindo apenas
as partes necessárias para implementar a teoria Scrum. O Scrum é construído com base na inteligência
colectiva das pessoas que o utilizam. Em vez de fornecer instruções detalhadas às pessoas, as regras
do Scrum guiam as suas relações e interacções.
Vários processos, técnicas e métodos podem ser utilizados no âmbito deste quadro. Scrum envolve as
práticas existentes ou torna-as desnecessárias. Scrum torna visível a eficácia relativa da gestão,
ambiente e técnicas de trabalho actuais, de modo a que se possam fazer melhorias.

Teoria Scrum
Scrum baseia-se no empirismo e no pensamento magro. 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.
Scrum emprega uma abordagem iterativa e incremental para optimizar a previsibilidade e para
controlar o risco. Scrum envolve grupos de pessoas que colectivamente possuem todas as
competências e perícia para fazer o trabalho e partilhar ou adquirir tais competências conforme
necessário.
Scrum combina quatro eventos formais para inspecção e adaptação dentro de um evento de
contenção, o Sprint. Estes eventos funcionam porque implementam os pilares empíricos Scrum de
transparência, inspecção, e adaptação.

Transparência
O processo emergente e o trabalho devem ser visíveis tanto para quem executa o trabalho como para
quem recebe o trabalho. Com Scrum, as decisões importantes baseiam-se na percepção do estado dos
seus três artefactos formais. Os artefactos que têm pouca transparência podem levar a decisões que
diminuem o valor e aumentam o risco.
A transparência permite a inspecção. A inspecção sem transparência é enganadora e esbanjadora.

Inspecção
Os artefactos Scrum e o progresso em direcção aos objectivos acordados devem ser inspeccionados
frequente e diligentemente para detectar variâncias ou problemas potencialmente indesejáveis. Para
ajudar na inspecção, o Scrum fornece cadência sob a forma dos seus cinco eventos.
A inspecção permite a adaptação. A inspecção sem adaptação é considerada inútil. Os eventos scrum
são concebidos para provocar a mudança.
Adaptação
Se quaisquer aspectos 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 materiais 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 têm poder ou auto-gestão.
Espera-se que uma equipa Scrum se adapte no momento em que aprende algo novo através da
inspecção.

Valores scrum
A utilização bem sucedida do Scrum depende de as pessoas se tornarem mais proficientes em viver
cinco valores:
Compromisso, Foco, Abertura, Respeito e Coragem
A Equipa Scrum compromete-se a alcançar os seus objectivos e a apoiar-se mutuamente. O seu foco
principal é o trabalho do Sprint para fazer o melhor progresso possível em direcção a estes objectivos.
A Equipa Scrum e os seus intervenientes estão abertos sobre o trabalho e os desafios. Os membros da
Scrum Team respeitam uns aos outros para serem capazes, pessoas independentes, e são respeitados
como tal pelas pessoas com quem trabalham. Os membros da Scrum Team têm a coragem de fazer a
coisa certa, de trabalhar em problemas difíceis.
Estes valores dão orientação à equipa Scrum no que diz respeito ao seu trabalho, acções, e
comportamento. As decisões que são tomadas, as medidas tomadas 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 artefactos 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, inspecção e adaptação ganham vida construindo confiança.

Equipa Scrum
A unidade fundamental do Scrum é uma pequena equipa de pessoas, uma equipa Scrum. A Equipa
Scrum é composta por um Scrum Master, um Proprietário de Produto, e Desenvolvedores. Dentro de
uma Equipe Scrum, não existem subequipas ou hierarquias. É uma unidade coesa de profissionais
focada num objectivo de cada vez, o Objectivo do Produto.
As Equipas Scrum 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 internamente
decidem quem faz o quê, quando, e como.
A equipa Scrum é 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 Equipas
Scrum se tornarem demasiado grandes, devem considerar a reorganização em múltiplas Equipas
Scrum coesas, cada uma focalizada no mesmo produto. Por conseguinte, devem partilhar o mesmo
Objectivo de Produto, o mesmo Backlog de Produto, e o mesmo Proprietário de Produto.
A Equipa Scrum é responsável por todas as actividades relacionadas com os produtos, desde a
colaboração dos intervenientes, verificação, manutenção, operação, experimentação, investigação e
desenvolvimento, e qualquer outra coisa que possa ser necessária. São estruturadas e habilitadas pela
organização a 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 equipa Scrum é responsável pela criação de um valioso e útil Incremento em cada Sprint.
Scrum define três responsabilidades específicas dentro da Equipa Scrum: os Desenvolvedores, o
Proprietário do Produto, e o Scrum Master.
Desenvolvedores
Os criadores são as pessoas da equipa Scrum que estão empenhados em criar qualquer aspecto de um
Incremento utilizável em cada Sprint.
As competências específicas necessárias aos Desenvolvedores são muitas vezes amplas e variam com
o domínio de trabalho. Contudo, os Programadores são sempre responsáveis por isso:
- Criação de um plano para o Sprint, o Sprint Backlog;
- Instilar qualidade aderindo a uma Definição de Feito;
- Adaptando o seu plano todos os dias em direcção ao Objectivo Sprint; e,
- Responsabilizando uns aos outros como profissionais.

Proprietário do produto
O Proprietário do Produto é responsável por maximizar o valor do produto resultante do trabalho da
equipa Scrum. A forma como isto é feito pode variar muito entre organizações, Equipas Scrum, e
indivíduos.
O Proprietário do Produto é também responsável pela gestão eficaz do Backlog de Produtos, que
inclui:
- Desenvolver e comunicar explicitamente o Objectivo do Produto;
- Criação e comunicação clara de artigos de Backlog de Produtos;
- Encomenda de artigos de Backlog de produtos; e,
- Assegurar que o Backlog do Produto é transparente, visível e compreendido.

O Proprietário do Produto pode fazer o trabalho acima referido ou pode delegar a responsabilidade a
outros. Independentemente disso, o Proprietário do Produto permanece responsável.
Para que os Proprietários de Produtos tenham sucesso, toda a organização deve respeitar as suas
decisões. Estas decisões são visíveis no conteúdo e encomenda do Backlog do Produto, e através do
Incremento inspeccionável na Revisão Sprint.
O Proprietário do Produto é uma pessoa, não um comité. O Proprietário do Produto pode representar
as necessidades de muitos intervenientes no Backlog do Produto. Aqueles que querem alterar o
Backlog do Produto podem fazê-lo, tentando convencer o Proprietário do Produto.

Scrum Master
O Scrum Master é responsável pelo estabelecimento do Scrum tal como definido no Guia Scrum.
Fazem-no ajudando todos a compreender a teoria e a prática do Scrum, tanto dentro da equipa Scrum
como dentro da organização.
O Scrum Master é responsável pela eficácia da Scrum Team. Fazem-no permitindo à Scrum Team
melhorar as suas práticas, no âmbito do Scrum.
Os Scrum Masters são verdadeiros líderes que servem a Equipa Scrum e a organização maior.
O Scrum Master serve a Scrum Team de várias maneiras, incluindo
- Treinar os membros da equipa na auto-gestão e na multifuncionalidade cruzada;
- Ajudar a equipa Scrum a concentrar-se na criação de aumentos de alto valor que vão ao encontro
da Definição de Feito;

- Causando a remoção de impedimentos ao progresso da Scrum Team; e

- Assegurar que todos os eventos Scrum têm lugar e são positivos, produtivos e mantidos dentro da
caixa de tempo.
O Scrum Master serve o Proprietário do Produto de várias maneiras, incluindo:
- Ajudando a encontrar técnicas para uma definição eficaz dos Objectivos do Produto e gestão do
Backlog de Produtos;

- Ajudar a Equipa Scrum a compreender a necessidade de artigos claros e concisos do Backlog de

Produtos;

- Ajudando a estabelecer o planeamento empírico de produtos para um ambiente complexo; e,

- Facilitar a colaboração das partes interessadas, conforme solicitado ou necessário.

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

- Liderar, treinar e treinar a organização na sua adopção do Scrum;
- Planeamento e aconselhamento de implementações Scrum dentro da organização;
- Ajudar os empregados e as partes interessadas a compreender e a decretar uma abordagem
empírica para trabalhos complexos; e

- Eliminação de barreiras entre as partes interessadas e as equipas Scrum.

Scrum Eventos
O Sprint é um recipiente para todos os outros eventos. Cada evento no Scrum é uma oportunidade
formal para inspeccionar e adaptar os artefactos Scrum. Estes eventos são especificamente
concebidos para permitir a transparência necessária. O não funcionamento de quaisquer eventos
conforme prescrito resulta na perda de oportunidades de inspecçã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.
Optimamente, todos os eventos são realizados ao mesmo tempo e no mesmo local para reduzir a
complexidade.

O Sprint
Os Sprints são a batida do coração de 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.
Todo o trabalho necessário para alcançar o Objectivo do Produto, incluindo o Planeamento Sprint,
Scrums Diário, Revisão Sprint, e Retrospectiva Sprint, acontece dentro de Sprints.
Durante o Sprint:
- Não são feitas alterações que ponham em perigo o Objectivo do Sprint;
- A qualidade não diminui;
- O Backlog do Produto é refinado conforme necessário; e,
- O âmbito pode ser clarificado e renegociado com o Proprietário do Produto à medida que mais se
for aprendendo.
Os Sprints permitem a previsibilidade, assegurando a inspecção e adaptação do progresso para um
Objectivo de Produto pelo menos todos os meses do calendário. Quando o horizonte de um Sprint é
demasiado longo, o Objectivo do Sprint pode tornar-se inválido, a complexidade pode aumentar, e o
risco pode aumentar. Sprints mais curtos podem ser utilizados para gerar mais ciclos de aprendizagem
e limitar o risco de custo e esforço a um período de tempo menor. Cada Sprint pode ser considerado
um projecto curto.
Existem várias práticas para prever o progresso, como queimadas, queimadas, 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ões prospectivas.
Um Sprint pode ser cancelado se o Objectivo Sprint se tornar obsoleto. Apenas o proprietário do
produto tem autoridade para cancelar o Sprint.

Planeamento de Sprint
O Planeamento do Sprint inicia o Sprint, estabelecendo o trabalho a ser realizado para o Sprint. Este
plano resultante é criado pelo trabalho colaborativo de toda a equipa Scrum.
O Proprietário do Produto garante que os participantes estão preparados para discutir os itens mais
importantes do Backlog do Produto e como eles mapeiam para o Objectivo do Produto. A Equipa
Scrum pode também convidar outras pessoas a participar no Planeamento da Sprint para darem
conselhos.
O Plano Sprint aborda os seguintes tópicos:
Tópico Um: Porque é que este Sprint é valioso?

O Proprietário do Produto propõe como o produto poderia aumentar o seu valor e utilidade no actual
Sprint. Toda a equipa Scrum colabora então para definir um Objectivo Sprint que comunica a razão
pela qual o Sprint é valioso para as partes interessadas. O Objectivo Sprint deve ser finalizado antes
do fim do Planeamento Sprint.
Tópico Dois: O que se pode fazer neste Sprint?

Através de discussão com o Proprietário do Produto, os Desenvolvedores seleccionam itens do

Backlog do Produto para incluir no Sprint actual. A Equipa Scrum pode refinar estes itens durante este
processo, o que aumenta a compreensão e a confiança.
Seleccionar quanto pode ser completado dentro de um Sprint pode ser um desafio. Contudo, quanto
mais os Desenvolvedores souberem sobre o seu desempenho passado, a sua capacidade futura, e a
sua Definição de Feito, mais confiantes estarão nas suas previsões de Sprint.
Tópico Três: Como será feito o trabalho escolhido?

Para cada item de Backlog de Produto seleccionado, os Desenvolvedores planeiam o trabalho

necessário para criar um Incremento que corresponda à Definição de Feito. Isto é frequentemente
feito decompondo os itens de Backlog de Produto em itens de trabalho mais pequenos de um dia ou
menos. A forma como isto é feito fica ao critério exclusivo dos Programadores. Ninguém mais lhes diz
como transformar itens de Backlog de Produtos em Aumento de Valor.
O Objectivo do Sprint, os artigos do Produto Backlog seleccionados para o Sprint, mais o plano para a
sua entrega são referidos em conjunto como o Sprint Backlog.
O planeamento de Sprint é programado para um máximo de oito horas por um Sprint de um mês. Para
Sprints mais curtos, o evento é normalmente mais curto.

Scrum Diário
O objectivo do Scrum Diário é inspeccionar o progresso em direcção ao Objectivo Sprint e adaptar o
Sprint Backlog conforme necessário, ajustando o trabalho planeado que se aproxima.
O Daily Scrum é um evento de 15 minutos para os Desenvolvedores da Equipa Scrum. Para reduzir a
complexidade, é realizado ao mesmo tempo e em todos os dias úteis do Sprint. Se o proprietário do
produto ou Scrum Master estiver a trabalhar activamente nos itens do Sprint Backlog, eles participam
como Desenvolvedores.
Os Desenvolvedores podem seleccionar qualquer estrutura e técnicas que queiram, desde que o seu
Scrum Diário se concentre no progresso em direcção ao Objectivo Sprint e produza um plano
accionável para o dia de trabalho seguinte. Isto cria foco e melhora a auto-gestão.
Os Scrums diários melhoram as comunicações, identificam impedimentos, promovem a tomada de
decisões rápidas e, consequentemente, eliminam a necessidade de outras reuniões.
O Daily Scrum não é a única vez que os Desenvolvedores são autorizados a ajustar o seu plano.
Encontram-se frequentemente ao longo do dia para discussões mais detalhadas sobre a adaptação ou
reprogramação do resto do trabalho do Sprint.

Revisão da Sprint
O objectivo da Revisão da Sprint é inspeccionar o resultado da Sprint e determinar as futuras
adaptações. A Equipa Scrum apresenta os resultados do seu trabalho aos principais interessados e são
discutidos os progressos em direcção ao Objectivo do Produto.
Durante o evento, a equipa Scrum e as partes interessadas 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 Backlog de Produtos também pode ser ajustado para ir ao encontro de novas
oportunidades. A Revisão Sprint é uma sessão de trabalho e a Equipa Scrum deve evitar limitá-la a
uma apresentação.
O Sprint Review é o segundo a último evento do Sprint e é cronometrado a um máximo de quatro
horas por um Sprint de um mês. Para Sprints mais curtos, o evento é geralmente mais curto.

Retrospectiva de Sprint
O objectivo da Retrospectiva Sprint é planear formas de aumentar a qualidade e eficácia.
A Equipa Scrum inspecciona como correu a última Sprint no que diz respeito a indivíduos, interacções,
processos, ferramentas, e a sua Definição de Feito. Os elementos inspeccionados variam
frequentemente com o domínio do trabalho. As suposições que os desviaram são identificadas e as
suas origens exploradas. A equipa Scrum discute o que correu bem durante o Sprint, que problemas
encontrou, e como esses problemas foram (ou não) resolvidos.
A Equipa Scrum identifica as mudanças mais úteis para melhorar a sua eficácia. As melhorias mais
impactantes são abordadas o mais rapidamente possível. Podem até ser adicionadas ao Sprint Backlog
para o próximo Sprint.
A Retrospectiva do Sprint conclui o Sprint. É cronometrada a um máximo de três horas por um Sprint
de um mês. Para Sprints mais curtos, o evento é normalmente mais curto.
Artefactos de scrum
Os artefactos do Scrum representam trabalho ou valor. São concebidos para maximizar a
transparência da informação chave. Assim, todos os que os inspeccionam têm a mesma base de
adaptação.
Cada artefacto 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 Backlog de Produtos, é o Objectivo do Produto.
- Para o Sprint Backlog é o Objectivo Sprint.
- Para o Incremento é a Definição de Feito.

Estes compromissos existem para reforçar o empirismo e os valores Scrum para a equipa Scrum e as
suas partes interessadas.

Backlog de produtos
O Backlog de Produtos é uma lista emergente e ordenada do que é necessário para melhorar o
produto. É a única fonte de trabalho levada a cabo pela equipa Scrum.
Os produtos em atraso que podem ser feitos pela equipa Scrum dentro de um Sprint são considerados
prontos para selecção num evento de Planeamento Sprint. Normalmente adquirem este grau de
transparência após a refinação das actividades. O refinamento do Backlog de Produtos é o acto de
decompor e definir melhor os itens do Backlog de Produtos em itens mais pequenos e mais precisos.
Esta é uma actividade contínua para acrescentar detalhes, tais como descrição, encomenda, e
tamanho. Os atributos variam frequentemente com o domínio de trabalho.
Os Desenvolvedores que irão fazer o trabalho são responsáveis pelo dimensionamento. O Proprietário
do Produto pode influenciar os Desenvolvedores, ajudando-os a compreender e a seleccionar as
compensações.
Compromisso: Objectivo do produto

O Objectivo do Produto descreve um estado futuro do produto que pode servir de alvo para a Equipa
Scrum planear contra. O Objectivo do Produto está no Backlog do Produto. O resto do Backlog de
Produtos surge para definir "o que" irá cumprir o Objectivo do Produto.
Um produto é um veículo para entregar valor. Tem um limite claro, intervenientes conhecidos, utilizadores
ou clientes bem definidos. Um produto pode ser um serviço, um produto físico, ou algo mais abstracto.

O Objectivo do Produto é o objectivo a longo prazo para a Equipa Scrum. Devem cumprir (ou
abandonar) um objectivo antes de assumirem o próximo.

Sprint Backlog
O Sprint Backlog é composto pelo Objectivo do Sprint (porquê), o conjunto de artigos do Produto
Backlog seleccionados para o Sprint (o quê), bem como um plano accionável para a entrega do
Incremento (como).
O Sprint Backlog é um plano de e para os Desenvolvedores. É uma imagem altamente visível e em
tempo real do trabalho que os Desenvolvedores planeiam realizar durante o Sprint, a fim de alcançar o
Objectivo do Sprint. Consequentemente, o Sprint Backlog é actualizado durante todo o Sprint à
medida que se vai aprendendo mais. Deverá ter detalhes suficientes para que possam inspeccionar o
seu progresso no Scrum Diário.
Compromisso: Objectivo da Sprint

O Objectivo do Sprint é o único objectivo para o Sprint. Embora o Objectivo do Sprint seja um
compromisso dos Desenvolvedores, proporciona flexibilidade em termos do trabalho exacto
necessário para o alcançar. O Objectivo Sprint também cria coerência e foco, encorajando a Equipa
Scrum a trabalhar em conjunto e não em iniciativas separadas.
O Objectivo Sprint é criado durante o evento de Planeamento Sprint e depois adicionado ao Sprint
Backlog. Como os Desenvolvedores trabalham durante o Sprint, têm em mente o Objectivo do Sprint.
Se o trabalho se revelar diferente do que esperavam, colaboram com o Proprietário do Produto para
negociar o âmbito do Backlog de Sprint dentro do Sprint sem afectar o Objectivo do Sprint.

Incremento
Um Incremento é um trampolim de betão em direcção ao Objectivo do Produto. Cada Incremento é
aditivo a todos os Incrementos anteriores e cuidadosamente verificado, assegurando que todos os
Incrementos funcionam em conjunto. A fim de fornecer valor, o Incremento deve ser utilizável.
Podem ser criados aumentos múltiplos dentro de um Sprint. A soma dos Incrementos é apresentada
na Sprint Review, apoiando assim o empirismo. No entanto, um Aumento pode ser entregue aos
interessados antes do fim do Sprint. A Revisão de Sprint nunca deve ser considerada como uma porta
para a libertação de valor.
O trabalho não pode ser considerado parte de um Incremento, a menos que cumpra a Definição de
Feito.
Compromisso: Definição de Feito

A Definição de Feito é uma descrição formal do estado do Incremento quando este cumpre as
medidas de qualidade exigidas para o produto.
No momento em que um item do Backlog de Produto satisfaz a Definição de Feito, nasce um
Incremento.
A Definição de Feito cria transparência ao proporcionar a todos uma compreensão partilhada do
trabalho que foi concluído como parte do Incremento. Se um item do Backlog de Produto não
corresponder à Definição de Feito, não pode ser lançado ou mesmo apresentado na Sprint Review. Em
vez disso, regressa ao Backlog do Produto para consideração futura.
Se a Definição de Feito para um incremento fizer parte dos padrões da organização, todas as Equipas
Scrum devem segui-lo como um mínimo. Se não for uma norma organizacional, a Equipa Scrum deve
criar uma Definição de Feito apropriada para o produto.
Os Desenvolvedores são obrigados a conformar-se com a Definição de Feito. Se houver várias equipas
Scrum a trabalharem em conjunto num produto, devem definir e cumprir mutuamente a mesma
Definição de Feito.

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

Agradecimentos
Pessoas

Dos milhares de pessoas que contribuíram para Scrum, devemos destacar aquelas que foram
instrumentais 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 em conjunto. Muitos
outros contribuíram nos anos seguintes e, sem a sua ajuda, Scrum não seria refinado como é hoje.
História do Guia Scrum

Ken Schwaber e Jeff Sutherland co-apresentaram Scrum pela primeira vez na Conferência da OOPSLA
em 1995. 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 Scrum documenta Scrum tal como desenvolvido, evoluído e sustentado durante mais de 30
anos por Jeff Sutherland e Ken Schwaber. Outras fontes fornecem padrões, processos e percepções
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 lugar. Para honrar os primeiros lugares onde foi
experimentado e provado, reconhecemos Individual Inc., Newspage, Fidelity Investments, e IDX (agora
GE Medical).
© 2020 Ken Schwaber e Jeff Sutherland Esta publicação é oferecida para licença sob a licença Attribution
Share-Alike da Creative Commons, acessível em https://creativecommons.org/licenses/by-sa/4.0/legalcode
e também descrita em forma de resumo em https://creativecommons.org/licenses/by-sa/4.0/. Ao utilizar
este Guia Scrum, reconhece e concorda que leu e aceita estar vinculado aos termos da licença Attribution
Share-Alike da Creative Commons.

Filiações