Guia do Scrum

O Propósito do Scrum Guide

Desenvolvemos o Scrum no início dos anos 1990. Escrevemos a primeira versão do Scrum Guide em 2010 para ajudar pessoas em todo o mundo a entender o Scrum. Desde então, evoluímos o Guide através de pequenas atualizações funcionais.
Apoiamos isso juntos.

O Scrum Guide contém a definição do Scrum. Cada elemento do Scrum serve a um propósito específico que é essencial para o valor geral e os resultados alcançados com o Scrum. Alterar o núcleo ou as ideias fundamentais do Scrum, omitir elementos ou não seguir as regras do Scrum obscurece problemas, limita os benefícios e pode até tornar o Scrum inútil.

Acompanhamos o uso crescente do Scrum em um mundo cada vez mais complexo. Observamos com humildade como o Scrum é utilizado em diversas áreas de trabalho complexo além do desenvolvimento de software – onde o Scrum tem suas raízes. À medida que o uso do Scrum continua a se expandir, esse trabalho é realizado por desenvolvedores, pesquisadores, analistas, cientistas e outros especialistas. Usamos a palavra "Developers" no Scrum não para excluir ninguém, mas para simplificar. Qualquer pessoa que se beneficie do uso do Scrum deve se sentir incluída.

Ao usar o Scrum, padrões, processos e insights podem ser aplicados e desenvolvidos que se encaixam no framework Scrum conforme descrito neste documento. Sua descrição vai além do propósito do Scrum Guide, pois são dependentes do contexto e variam muito conforme o Scrum é utilizado. Tais táticas para aplicação dentro do framework Scrum variam amplamente e são descritas em outros lugares.

Ken Schwaber & Jeff Sutherland, Novembro de 2020

Definição do Scrum

Scrum é um framework leve que ajuda pessoas, equipes e organizações a gerar valor através de soluções adaptativas para problemas complexos.

Resumidamente, o Scrum exige que um Scrum Master promova um ambiente no qual

• um Product Owner organiza o trabalho de um problema complexo em um Product Backlog;
• o Scrum Team cria um Increment valioso a partir de uma seleção desse trabalho dentro de um Sprint;
• o Scrum Team e seus Stakeholders inspecionam os resultados e fazem adaptações para o próximo Sprint;
• esses passos se repetem.

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

Dentro do framework, diversos processos, técnicas e métodos podem ser utilizados. O Scrum envolve práticas existentes ou as torna desnecessárias. O Scrum torna visível a eficácia relativa da gestão atual, do ambiente e das técnicas de trabalho, permitindo que melhorias sejam realizadas.

Teoria do Scrum

O Scrum é baseado em empirismo e Lean Thinking. Empirismo significa que o conhecimento é adquirido através da experiência e que as decisões são tomadas com base em observações. O Lean Thinking reduz desperdícios e foca no essencial.

O Scrum utiliza uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos. O Scrum conta com grupos de pessoas que, juntas, possuem todas as habilidades e conhecimentos necessários para realizar o trabalho e compartilhar ou adquirir essas habilidades conforme necessário.

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

Transparência

O processo em desenvolvimento e o trabalho resultante precisam ser visíveis tanto para quem executa o trabalho quanto para quem o recebe. No Scrum, decisões importantes são baseadas no estado percebido dos seus três artefatos formais. Artefatos com pouca transparência podem levar a decisões que diminuem o valor e aumentam o risco.

A transparência possibilita a inspeção. Uma inspeção sem transparência é enganosa e gera desperdício.

Inspeção

Os artefatos do Scrum e o progresso em direção aos objetivos acordados devem ser inspecionados com frequência e cuidado para detectar variações ou problemas potencialmente indesejados. Para ajudar na inspeção, o Scrum oferece uma cadência através dos seus cinco eventos.

A inspeção possibilita a adaptação. Inspeção sem adaptação é considerada inútil. Os eventos do Scrum são projetados para provocar mudanças.

Adaptação

Se algum aspecto de um processo se desviar dos limites aceitáveis ou se o produto resultante não for aceitável, o processo aplicado ou os resultados produzidos precisam ser adaptados. A adaptação deve acontecer o mais rápido possível para minimizar desvios adicionais.

A adaptação se torna mais difícil quando as pessoas envolvidas não estão empoderadas ou não conseguem se autogerenciar. Espera-se que um Scrum Team se adapte no momento em que aprende algo novo através da inspeção.

Valores do Scrum

A aplicação bem-sucedida do Scrum depende de as pessoas se tornarem cada vez melhores em viver cinco valores:

• Comprometimento
• Foco
• Abertura
• Respeito
• Coragem

O Scrum Team se compromete a alcançar seus objetivos e a apoiar uns aos outros. Seu foco principal está no trabalho do Sprint, para alcançar o melhor progresso possível em direção a esses objetivos. O Scrum Team e seus stakeholders são abertos em relação ao trabalho e aos desafios. Os membros do Scrum Team se respeitam mutuamente como pessoas capazes e independentes, e são respeitados da mesma forma pelas pessoas com quem trabalham. Os membros do Scrum Team têm a coragem de fazer a coisa certa: trabalhar em problemas difíceis.

Esses valores orientam o Scrum Team em relação ao seu trabalho, suas ações e seu comportamento. As decisões tomadas, os passos dados e a forma como o Scrum é aplicado devem fortalecer esses valores, e não diminuí-los ou prejudicá-los. Os membros do Scrum Team aprendem e exploram os valores enquanto trabalham com os eventos e artefatos do Scrum. Quando esses valores são incorporados pelo Scrum Team e pelas pessoas com quem ele trabalha, os pilares empíricos do Scrum — Transparência, Inspeção e Adaptação — ganham vida e constroem confiança.

Scrum Team

O componente central do Scrum é uma pequena equipe de pessoas, um Scrum Team. O Scrum Team é composto por um Scrum Master, um Product Owner e Developers. Dentro de um Scrum Team não existem subequipes ou hierarquias. Trata-se de uma unidade coesa de profissionais focados em um objetivo: a Meta do Produto.

Scrum Teams são interdisciplinares, ou seja, os membros possuem todas as habilidades necessárias para criar valor em cada Sprint. Além disso, são autogerenciados, 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 trabalho significativo dentro de um Sprint, geralmente 10 pessoas ou menos. De modo geral, constatamos que equipes menores se comunicam melhor e são mais produtivas. Quando os Scrum Teams ficam grandes demais, devem considerar se reorganizar em múltiplos Scrum Teams coesos, todos focados no mesmo produto. Portanto, devem compartilhar a Meta do Produto, o Product Backlog e o Product Owner.

O Scrum Team é responsável (responsible) por todas as atividades relacionadas ao produto: colaboração com stakeholders, verificação, manutenção, operação, experimentos, pesquisa e desenvolvimento, e tudo mais que possa ser necessário. A organização o estrutura e capacita de forma que ele gerencie seu próprio trabalho. Trabalhar em Sprints com um ritmo sustentável melhora o foco e a continuidade do Scrum Team.

Todo o Scrum Team é responsável pelos resultados (accountable) de criar um Increment valioso e útil a cada Sprint. O Scrum define três responsabilidades específicas pelos resultados dentro do Scrum Team: Developers, Product Owner e Scrum Master.

Developers

Developers são as pessoas no Scrum Team que se comprometem a criar todos os aspectos de um Increment utilizável a cada Sprint.

As habilidades específicas necessárias aos Developers costumam ser amplas e variam conforme o contexto do trabalho. No entanto, os Developers são sempre responsáveis pelos resultados de:

• criar um plano para o Sprint, o Sprint Backlog;
• garantir qualidade através da aderência a uma Definition of Done;
• adaptar diariamente seu plano para atingir a Meta do Sprint; e
• responsabilizar-se mutuamente como profissionais.

Product Owner

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

O Product Owner também é responsável pelos resultados do gerenciamento eficaz do Product Backlog, o 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 compreendido.

O Product Owner pode realizar o trabalho acima pessoalmente ou delegar a responsabilidade pela execução a outros. Independentemente disso, o Product Owner permanece responsável pelos resultados.

Para que o Product Owner tenha sucesso, toda a organização deve respeitar suas decisões. Essas decisões são visíveis no conteúdo e na ordenação do Product Backlog, bem como no Increment inspecionável durante a Sprint Review.

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 pelos resultados de estabelecer o Scrum conforme definido no Scrum Guide. Faz isso ajudando todos a compreenderem a teoria e a prática do Scrum, tanto dentro do Scrum Team quanto na organização.

O Scrum Master é responsável pelos resultados da eficácia do Scrum Team. Faz isso capacitando o Scrum Team a melhorar 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 diversas formas, incluindo:

• orientar os membros da equipe em autogestão e colaboração interdisciplinar;
• apoiar o Scrum Team a focar na criação de Increments de alto valor que atendam à Definition of Done;
• promover a remoção de impedimentos ao progresso do Scrum Team; e
• garantir que todos os eventos do Scrum aconteçam, sejam positivos, produtivos e respeitem a timebox.

O Scrum Master serve ao Product Owner de diversas formas, incluindo:

• ajudar a encontrar técnicas para definição eficaz da Meta do Produto e gerenciamento do Product Backlog;
• ajudar o Scrum Team a compreender a necessidade de itens do Product Backlog claros e precisos;
• ajudar a estabelecer planejamento empírico de produto para um ambiente complexo; e
• facilitar a colaboração com stakeholders conforme solicitado ou necessário.

O Scrum Master serve à organização de diversas formas, incluindo:

• liderar, treinar e orientar a organização na adoção do Scrum;
• planejar e recomendar implementações do Scrum na organização;
• ajudar colaboradores e stakeholders a compreender e aplicar uma abordagem empírica para trabalho complexo; e
• remover barreiras entre stakeholders e Scrum Teams.

Eventos do Scrum

O Sprint é um contêiner para todos os outros eventos. Cada evento no Scrum é uma oportunidade formal de inspecionar e adaptar os artefatos do Scrum. Esses eventos são especialmente projetados para criar a transparência necessária. Quando um evento não é realizado conforme prescrito, perde-se a oportunidade de inspecionar e adaptar. Os eventos são usados no Scrum para criar regularidade e minimizar a necessidade de reuniões não definidas no Scrum. Idealmente, todos os eventos são realizados no mesmo horário e local para reduzir a complexidade.

O Sprint

Os 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. Um novo Sprint começa imediatamente após a conclusão do Sprint anterior.

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

Durante o Sprint

• não são feitas mudanças que colocariam em risco a Meta do 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 à medida que mais conhecimento é adquirido.

Os Sprints permitem previsibilidade ao garantir inspeção e adaptação do progresso em direção à Meta do Produto pelo menos uma vez por mês. Quando o horizonte de um Sprint é muito longo, a Meta do Sprint pode se tornar obsoleta, a complexidade pode aumentar e o risco pode crescer. Sprints mais curtos podem ser utilizados para gerar mais ciclos de aprendizado e limitar o risco de custos e esforço a um período menor. Cada Sprint pode ser considerado um projeto curto.

Existem várias práticas para prever o progresso, como Burn-Down Charts, Burn-Up Charts ou Diagramas de Fluxo Cumulativo. Embora tenham se mostrado úteis, não substituem a importância do empirismo. Em ambientes complexos, não se sabe o que vai acontecer. Apenas o que já aconteceu pode ser usado para tomada de decisões antecipadas.

Um Sprint pode ser cancelado se a Meta do Sprint se tornar obsoleta. Apenas o Product Owner tem autoridade para cancelar o Sprint.

Sprint Planning

O Sprint Planning inicia o Sprint ao definir o trabalho a ser realizado durante o Sprint. Esse 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 se relacionam com a Meta do Produto. O Scrum Team também pode convidar outras pessoas para participar do Sprint Planning para fins de consultoria.

O Sprint Planning aborda os seguintes tópicos:

Tópico Um: Por que este Sprint é valioso?

O Product Owner propõe como o produto pode aumentar seu valor e utilidade no Sprint atual. Todo o Scrum Team então trabalha junto para definir uma Meta do Sprint que comunique por que o Sprint é valioso para os stakeholders. A Meta do Sprint deve ser finalizada antes do término do Sprint Planning.

Tópico Dois: O que pode ser concluído (Done) neste Sprint?

Em conversa com o Product Owner, os Developers selecionam itens do Product Backlog para incluir no Sprint atual. O Scrum Team pode refinar esses itens durante esse 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. No entanto, quanto mais os Developers souberem sobre seu desempenho passado, sua capacidade futura e sua Definition of Done, mais confiantes estarão em suas previsões para o Sprint.

Tópico Três: Como o trabalho selecionado será realizado?

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

A Meta do Sprint, os itens do Product Backlog selecionados para o Sprint e o plano para entregá-los são chamados coletivamente de Sprint Backlog.

O Sprint Planning tem duração máxima de oito horas para um Sprint de um mês. Para Sprints mais curtos, o evento geralmente é mais curto.

Daily Scrum

O propósito do Daily Scrum (ou Daily Stand-up) é inspecionar o progresso em direção à Meta do Sprint e adaptar o Sprint Backlog conforme necessário, ajustando o trabalho planejado.

O Daily Scrum é um evento de 15 minutos para os Developers do Scrum Team. Para reduzir a complexidade, é realizado no mesmo horário e local em cada dia de trabalho do Sprint. Se o Product Owner ou o Scrum Master estiver trabalhando ativamente em itens do Sprint Backlog, participa como Developer.

Os Developers podem escolher qualquer estrutura e técnicas, desde que seu Daily Scrum se concentre no progresso em direção à Meta do Sprint e crie um plano executável para o próximo dia de trabalho. Isso cria foco e promove o autogerenciamento.

Os Daily Scrums melhoram a comunicação, identificam impedimentos, promovem a tomada rápida de decisões e eliminam consistentemente a necessidade de outras reuniões.

O Daily Scrum não é a única oportunidade em que os Developers podem ajustar seu plano. Eles frequentemente se reúnem durante o dia para discussões mais detalhadas sobre adaptação ou replanejamento do trabalho restante do Sprint.

Sprint Review

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

Durante o evento, o Scrum Team e os stakeholders revisam o que foi realizado no 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 aproveitar novas oportunidades. O Sprint Review é uma sessão de trabalho, e o Scrum Team deve evitar limitá-lo a uma apresentação.

O Sprint Review é o penúltimo evento do Sprint e tem duração máxima de quatro horas para um Sprint de um mês. Para Sprints mais curtos, o evento geralmente é mais curto.

Sprint Retrospective

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

O Scrum Team inspeciona como foi o último Sprint em relação a indivíduos, interações, processos, ferramentas e sua Definition of Done. Os elementos inspecionados frequentemente variam de acordo com o domínio de trabalho. Suposições que desviaram o time são identificadas e suas origens exploradas. O Scrum Team discute o que correu bem durante o Sprint, quais problemas encontrou 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 abordadas o mais rápido possível. Podem até ser adicionadas ao Sprint Backlog do próximo Sprint.

A Sprint Retrospective encerra o Sprint. Ela tem duração máxima de três horas para um Sprint de um mês. Para Sprints mais curtos, o evento geralmente é mais curto.

Artefatos do Scrum

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

Cada artefato contém um compromisso para garantir que informações sejam fornecidas de forma a melhorar a transparência e o foco, tornando o progresso mensurável:

• Para o Product Backlog, é a Meta do Produto.
• Para o Sprint Backlog, é a Meta do Sprint.
• Para o Incremento, é a Definição de Pronto.

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

Product Backlog

O Product Backlog é uma lista emergente e ordenada das coisas necessárias para melhorar o produto. É a única fonte de trabalho a ser realizado pelo Scrum Team.

Itens do Product Backlog que podem ser concluídos (Done) pelo Scrum Team dentro de um Sprint são considerados prontos para seleção em um evento de Sprint Planning. Esse grau de transparência geralmente é alcançado por meio de atividades de Refinamento. O Refinamento do Product Backlog é o processo pelo qual os itens do Product Backlog são decompostos em elementos menores e mais precisos e definidos com mais detalhes. Esta é uma atividade contínua, através da qual mais detalhes como descrição, ordem e tamanho são adicionados. Os atributos frequentemente variam de acordo com o ambiente de trabalho.

Os Developers que realizarão o trabalho são responsáveis pela estimativa de tamanho. O Product Owner pode influenciar os Developers ajudando-os a entender os itens do Product Backlog e a fazer concessões.

Compromisso: Meta do Produto

A Meta do Produto descreve um estado futuro do produto, que pode servir como objetivo de planejamento para o Scrum Team. A Meta do Produto está no Product Backlog. O restante do Product Backlog surge para definir "o que" cumprirá a Meta do Produto.

Um produto é um instrumento para entregar valor. Ele tem limites claros, stakeholders conhecidos, usuários ou clientes claramente 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. O Scrum Team deve cumprir (ou abandonar) uma meta antes de avançar para a próxima.

Sprint Backlog

O Sprint Backlog consiste na Meta do Sprint (Por quê), nos itens do Product Backlog selecionados para o Sprint (O quê) e em um plano executável para a entrega do Incremento (Como).

O Sprint Backlog é um plano feito por e para os Developers. É uma imagem em tempo real e claramente visível do trabalho que os Developers planejam realizar durante o Sprint para alcançar a Meta do Sprint. Consequentemente, o Sprint Backlog é atualizado ao longo de todo o Sprint sempre que mais é aprendido. Deve conter detalhes suficientes para que eles possam inspecionar seu progresso na Daily Scrum.

Compromisso: Meta do Sprint

A Meta do Sprint é o único objetivo do Sprint. Embora a Meta do Sprint seja um compromisso dos Developers, ela oferece flexibilidade em relação ao trabalho exato necessário para alcançá-la. A Meta do Sprint também cria coerência e foco, incentivando assim o Scrum Team a trabalhar junto em vez de em iniciativas separadas.

A Meta do Sprint é criada durante o evento de Sprint Planning e então adicionada ao Sprint Backlog. Enquanto os Developers trabalham durante o Sprint, eles mantêm a Meta do Sprint em mente. Se descobrirem que o trabalho diverge de suas expectativas, eles colaboram com o Product Owner para negociar o escopo do Sprint Backlog dentro do Sprint, sem afetar a Meta do Sprint.

Incremento

Um Incremento é um passo concreto em direção à Meta do Produto. Cada Incremento é aditivo a todos os Incrementos anteriores e minuciosamente verificado para garantir que todos funcionem juntos. Para gerar valor, o Incremento deve ser utilizável.

Mais de um Incremento pode ser criado dentro de um Sprint. A soma deles é apresentada na Sprint Review, apoiando assim o empirismo. No entanto, um Incremento também pode ser entregue aos stakeholders antes do final do Sprint. A Sprint Review nunca deve ser considerada uma barreira para a entrega de valor.

O trabalho não pode ser considerado parte de um Incremento até que atenda à Definição de Pronto.

Compromisso: Definição de Pronto

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

No momento em que um item do Product Backlog atende à Definição de Pronto, nasce um Incremento.

A Definição de Pronto cria transparência ao fornecer a todos um entendimento compartilhado sobre qual trabalho foi concluído como parte do Incremento. Se um item do Product Backlog não atende à Definição de Pronto, ele não pode ser liberado nem 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 aderir à Definição de Pronto. Se vários Scrum Teams trabalham juntos em um produto, eles devem definir uma Definição de Pronto comum e todos devem segui-la.

Observação Final

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

Agradecimentos

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

Histórico do Scrum Guide
Ken Schwaber e Jeff Sutherland apresentaram o Scrum juntos pela primeira vez na conferência OOPSLA em 1995. Essa apresentação documentou essencialmente os aprendizados que Ken e Jeff haviam adquirido nos anos anteriores ao aplicar o Scrum, e representou a primeira publicação formal da definição do Scrum.

O Scrum Guide documenta o Scrum conforme foi desenvolvido, cresceu e foi mantido por Jeff Sutherland e Ken Schwaber ao longo de mais de 30 anos. Outras fontes fornecem padrões, processos e insights que complementam o framework Scrum. Estes podem levar ao aumento da produtividade, do valor, da criatividade e da satisfação com os resultados.

A história completa do Scrum é descrita em outro lugar. Para honrar os primeiros lugares onde foi testado e comprovado, reconhecemos a Individual Inc., Newspage, Fidelity Investments e IDX (agora GE Medical) como tal.

© 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.

As alterações em relação à versão de 2017 foram resumidas por Sohrab Salimi, CEO da Scrum Academy.

Esta versão (3.2) é uma tradução completamente nova por ocasião da publicação do Scrum Guide 2020. Data: 03.12.2020

Tradução

Este guia foi traduzido da versão original em inglês, fornecida por Ken Schwaber e Jeff Sutherland. Contribuíram para isso:
2020: Silke von der Bruck, Sabine Canditt, Jan Gretschuskin, Eva Gysling, Martin Hoppacher, Björn Jensen, Ralph Jocham, Dominik Maximini, Wolf Dieter Moggert, Peter Schmidt, Boris Steiner