O 2020 Scrum Guia^{Marca Registrada}

Objetivo do Scrum Guia

Nós desenvolvemos Scrum no início da década de 1990. Escrevemos a primeira versão do Scrum Guia em 2010 para ajudar pessoas em todo o mundo a entender Scrum. Desde então, evoluímos o Guia por meio de pequenas atualizações funcionais. Juntos, nós o apoiamos.

O Scrum O guia contém a definição de Scrum. Cada elemento da estrutura atende a um propósito específico que é essencial para o valor geral e os resultados alcançados com Scrum. Mudando o design central ou as ideias de Scrum, omitindo elementos ou não seguindo as regras de Scrum, encobre problemas e limita os benefícios de Scrum, potencialmente até mesmo tornando-o inútil.

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

Como Scrum está sendo usado, padrões, processos e insights que se encaixam no Scrum estrutura, conforme descrita neste documento, pode ser encontrada, aplicada e concebida. Sua descrição está além do propósito do Scrum Guia porque são sensíveis ao contexto e diferem amplamente entre Scrum usos. Tais táticas para uso dentro do Scrum a estrutura varia muito e é descrita em outro lugar.

Scrum Definição

Scrum é uma estrutura leve que ajuda pessoas, equipes e organizações a gerar valor por meio de soluções adaptativas para problemas complexos.

Em poucas palavras, Scrum requer um Scrum Mestre em promover um ambiente onde:

1. Um Product Owner ordena o trabalho para um problema complexo em um Product Backlog.
2. O Scrum A equipe transforma uma seleção do trabalho em um incremento de valor durante um Sprint.
3. O Scrum A equipe e suas partes interessadas inspecionam os resultados e os 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. Scrum a estrutura é propositalmente incompleta, definindo apenas as partes necessárias para implementar Scrum teoria. Scrum é construído pela inteligência coletiva das pessoas que o utilizam. Em vez de fornecer às pessoas instruções detalhadas, as regras de Scrum orientar seus relacionamentos e interações.

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

Scrum Teoria

Scrum baseia-se no empirismo e no pensamento enxuto. O empirismo afirma que o conhecimento advém da experiência e da tomada de decisões com base no que é observado. O pensamento enxuto reduz o desperdício e se concentra no essencial.

Scrum emprega uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos. Scrum envolve grupos de pessoas que coletivamente têm todas as habilidades e conhecimentos necessários para fazer o trabalho e compartilhar ou adquirir tais habilidades conforme necessário.

Scrum combina quatro eventos formais para inspeção e adaptação dentro de um evento de contenção, o Sprint. Esses eventos funcionam porque implementam o modelo empírico Scrum pilares de transparência, inspeção e adaptação.

Transparência

O processo e o trabalho emergentes devem ser visíveis tanto para aqueles que executam o trabalho quanto para aqueles que o recebem.Com 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 possibilita a inspeção. Inspeção sem transparência é enganosa e um desperdício.

Inspeção

O Scrum Os artefatos 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 auxiliar na inspeção, Scrum fornece cadência na forma de seus cinco eventos.

A inspeção possibilita a adaptação. A inspeção sem adaptação é considerada inútil. Scrum eventos 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 for inaceitável, o processo aplicado ou os materiais produzidos devem ser ajustados. O ajuste deve ser feito o mais rápido possível para minimizar novos desvios.

A adaptação torna-se mais difícil quando as pessoas envolvidas não têm autonomia ou não conseguem gerir-se a si próprias. Scrum Espera-se que a equipe se adapte no momento em que aprende algo novo por meio da inspeção.

Scrum Valores

Uso bem-sucedido de Scrum depende de as pessoas se tornarem mais proficientes em viver cinco valores:

Compromisso, Foco, Abertura, Respeito e Coragem

O Scrum A equipe se compromete a atingir seus objetivos e a apoiar uns aos outros. Seu foco principal é o trabalho do Sprint para alcançar o melhor progresso possível em direção a esses objetivos. Scrum A equipe e suas partes interessadas são abertas sobre o trabalho e os desafios. Scrum Os membros da equipe respeitam-se mutuamente por serem pessoas capazes e independentes, e são respeitados como tal pelas pessoas com quem trabalham. Scrum Os membros da equipe têm a coragem de fazer a coisa certa e de trabalhar em problemas difíceis.

Esses valores dão direção ao Scrum Equipe em relação ao seu trabalho, ações e comportamento. As decisões que são tomadas, as etapas executadas e a maneira como Scrum é usado deve reforçar esses valores, não diminuí-los ou miná-los. Scrum Os membros da equipe aprendem e exploram os valores à medida que trabalham com o Scrum eventos e artefatos. Quando esses valores são incorporados pelo Scrum A equipe e as pessoas com quem trabalham, o empírico Scrum pilares de transparência, inspeção e adaptação ganham vida construindo confiança.

Scrum Equipe

A unidade fundamental de Scrum é uma pequena equipe de pessoas, uma Scrum Equipe. A Scrum A equipe é composta por um Scrum Mestre, um Product Owner e Desenvolvedores. Dentro de um Scrum Equipe, não há subequipes ou hierarquias. É uma unidade coesa de profissionais focados em um objetivo de cada vez, a Meta do Produto.

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

O Scrum A equipe é pequena o suficiente para permanecer ágil e grande o suficiente para concluir um trabalho significativo dentro de um Sprint, normalmente com 10 pessoas ou menos. Em geral, descobrimos que equipes menores se comunicam melhor e são mais produtivas. Se Scrum As equipes se tornam muito grandes e devem considerar a reorganização em múltiplas equipes coesas. Scrum Equipes, cada uma focada no mesmo produto. Portanto, devem compartilhar o mesmo Objetivo do Produto, o mesmo Backlog do Produto e o mesmo Dono do Produto.

O Scrum A equipe é responsável por todas as atividades relacionadas ao produto, desde a colaboração com as partes interessadas, 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 capacitados pela organização para gerenciar seu próprio trabalho. Trabalhar em Sprints em um ritmo sustentável melhora a Scrum Foco e consistência da equipe.

O todo Scrum A equipe é responsável por criar um incremento valioso e útil a cada Sprint. Scrum define três responsabilidades específicas dentro do Scrum Equipe: os Desenvolvedores, o Product Owner e o Scrum Mestre.

Desenvolvedores

Os desenvolvedores são as pessoas no Scrum Equipe comprometida em criar qualquer aspecto de um Incremento utilizável a cada Sprint.

As habilidades específicas necessárias para os Desenvolvedores são geralmente amplas e variam de acordo com a área de atuação. No entanto, os Desenvolvedores são sempre responsáveis ​​por:

• Criando um plano para o Sprint, o Sprint Backlog;
• Incutir qualidade aderindo a uma Definição de Pronto;
• Adaptando seu plano a cada dia em direção à Meta do Sprint; e,
• Responsabilizando-nos mutuamente como profissionais.

Proprietário do produto

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

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

• Desenvolver e comunicar explicitamente o Objetivo do Produto;
• Criar e comunicar claramente os itens do Product Backlog;
• Solicitar itens do Backlog do Produto; e,
• Garantir que o Product Backlog seja transparente, visível e compreendido.

O Product Owner pode realizar o trabalho acima ou delegar a responsabilidade a terceiros. Independentemente disso, o Product Owner permanece 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 ordenação do Backlog do Produto, e por meio do Incremento inspecionável na Revisão do Sprint.

O Product Owner é uma pessoa, não um comitê. Ele pode representar as necessidades de muitas partes interessadas no Product Backlog. Aqueles que desejam alterar o Product Backlog podem fazê-lo tentando convencê-lo.

Scrum Mestre

O Scrum O Mestre é responsável por estabelecer Scrum conforme definido no Scrum Guia. Eles fazem isso ajudando todos a entender Scrum teoria e prática, tanto dentro da Scrum Equipe e organização.

O Scrum O Mestre é responsável por Scrum Eficácia da equipe. Eles fazem isso permitindo que Scrum Equipe para aprimorar suas práticas, dentro do Scrum estrutura.

Scrum Os mestres são verdadeiros líderes que servem Scrum Equipe e a organização maior.

O Scrum O Mestre serve o Scrum Equipe de várias maneiras, incluindo:

• Orientar os membros da equipe em autogestão e multifuncionalidade;
• Ajudando o Scrum Foco da equipe na criação de incrementos de alto valor que atendam à Definição de Pronto;
• Causando a remoção de impedimentos à Scrum Progresso da equipe; e,
• Garantir que todos Scrum os eventos acontecem e são positivos, produtivos e mantidos dentro do prazo.

O Scrum O Master atende o Product Owner de diversas maneiras, incluindo:

• Ajudar a encontrar técnicas para definição eficaz de metas de produto e gerenciamento de backlog de produto;
• Ajudando o Scrum A equipe entende a necessidade de itens claros e concisos no Backlog do Produto;
• Ajudar a estabelecer o planejamento empírico de produtos para um ambiente complexo; e,
• Facilitar a colaboração das partes interessadas conforme solicitado ou necessário.

O Scrum O Master atende a organização de diversas maneiras, incluindo:

• Liderar, treinar e orientar a organização em sua Scrum adoção;
• Planejamento e aconselhamento Scrum implementações dentro da organização;
• Ajudar os funcionários e as partes interessadas a compreender e implementar uma abordagem empírica para trabalhos complexos; e,
• Remover barreiras entre as partes interessadas e Scrum Equipes.

Scrum Eventos

O Sprint é um contêiner para todos os outros eventos. Cada evento em Scrum é uma oportunidade formal para inspecionar e adaptar Scrum artefatos. Esses eventos são projetados especificamente para permitir a transparência necessária. A não operação de quaisquer eventos conforme prescrito resulta em oportunidades perdidas de inspeção e adaptação. Os eventos são usados ​​em Scrum para criar regularidade e minimizar a necessidade de reuniões não definidas em Scrum.

O ideal é que todos os eventos sejam realizados no mesmo horário e local para reduzir a complexidade.

A corrida

Os sprints são a pulsaçã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 Planejamento de Sprint, Daily Scrums, Sprint Review e Sprint Retrospective acontecem dentro dos Sprints.

Durante o Sprint:

• Não são feitas alterações que possam colocar 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 é aprendido.

Sprints permitem previsibilidade, garantindo a inspeção e a adaptação do progresso em direção a uma Meta de Produto pelo menos uma vez por mês. Quando o horizonte de um Sprint é muito longo, a Meta do Sprint pode se tornar inválida, a complexidade pode aumentar e o risco pode aumentar. Sprints mais curtos podem ser empregados para gerar mais ciclos de aprendizado e limitar o risco de custo e esforço a um prazo menor. Cada Sprint pode ser considerado um projeto curto.

Existem diversas práticas para prever o progresso, como burn-downs, burn-ups ou fluxos cumulativos. Embora comprovadamente úteis, elas não substituem a importância do empirismo. Em ambientes complexos, o que acontecerá é incerto. Somente o que já aconteceu pode ser usado para a tomada de decisões com visão de futuro.

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

Planejamento de Sprint

O Planejamento do Sprint inicia o Sprint definindo o trabalho a ser executado. O plano resultante é criado pelo trabalho colaborativo de toda a equipe. Scrum Equipe.

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. Scrum A equipe também pode convidar outras pessoas para participar do Planejamento do Sprint para fornecer conselhos.

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. O todo Scrum A equipe então colabora para definir uma Meta do Sprint que comunique por que o Sprint é valioso para as partes interessadas. A Meta do Sprint deve ser finalizada antes do término do Planejamento do Sprint.

Tópico dois: O que pode ser feito neste sprint?

Por meio de discussão com o Product Owner, os Desenvolvedores selecionam itens do Product Backlog para incluir no Sprint atual. Scrum A equipe pode refinar esses itens durante esse processo, o que aumenta a compreensão e a confiança.

Selecionar o quanto pode ser concluído em um Sprint pode ser desafiador. No entanto, quanto mais os Desenvolvedores souberem sobre seu desempenho passado, sua capacidade futura e sua Definição de Pronto, mais confiantes estarão em suas previsões para o Sprint.

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

Para cada item selecionado do Backlog do Produto, os Desenvolvedores planejam o trabalho necessário para criar um Incremento que atenda à Definição de Pronto. Isso geralmente é feito decompondo os itens do Backlog do Produto em itens de trabalho menores, com duração de um dia ou menos. A forma como isso é feito fica a critério exclusivo dos Desenvolvedores. Ninguém mais lhes diz como transformar os itens do Backlog do Produto em Incrementos de valor.

O objetivo do Sprint, os itens do Product Backlog selecionados para o Sprint, além do plano para entregá-los, são chamados juntos de Sprint Backlog.

O Planejamento de Sprints tem um limite máximo de oito horas para Sprints de um mês. Para Sprints mais curtos, o evento geralmente é mais curto.

Diário Scrum

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

O Diário Scrum é um evento de 15 minutos para os desenvolvedores do Scrum Equipe. Para reduzir a complexidade, a Sprint é realizada no mesmo horário e local em todos os dias úteis. Se o Product Owner ou Scrum Os Mestres estão trabalhando ativamente em itens do Sprint Backlog e participam como Desenvolvedores.

Os desenvolvedores podem selecionar qualquer estrutura e técnicas que desejarem, desde que seu Daily Scrum Concentra-se no progresso em direção à Meta do Sprint e produz um plano de ação para o próximo dia de trabalho. Isso gera foco e melhora a autogestão.

Diário Scrums melhoram as comunicações, identificam impedimentos, promovem a tomada rápida de decisões e, consequentemente, eliminam a necessidade de outras reuniões.

O Diário Scrum não é o único momento em que os desenvolvedores podem ajustar seus planos. Eles costumam se reunir ao longo do dia para discussões mais detalhadas sobre a adaptação ou o replanejamento do restante do trabalho do Sprint.

Revisão de Sprint

O objetivo da Revisão do Sprint é inspecionar o resultado do Sprint e determinar adaptações futuras. Scrum A equipe apresenta os resultados do seu trabalho às principais partes interessadas e o progresso em direção à Meta do Produto é discutido.

Durante o evento, o Scrum A equipe e as partes interessadas revisam o que foi realizado no Sprint e o que mudou em seu ambiente. Com base nessas informações, os participantes colaboram para definir o que fazer em seguida. O Backlog do Produto também pode ser ajustado para atender a novas oportunidades. A Revisão do Sprint é uma sessão de trabalho e o Scrum A equipe deve evitar limitar-se a uma apresentação.

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

Retrospectiva do Sprint

O objetivo da Retrospectiva do Sprint é planejar maneiras de aumentar a qualidade e a eficácia.

O Scrum A equipe inspeciona como foi o último Sprint em relação a indivíduos, interações, processos, ferramentas e sua Definição de Pronto. Os elementos inspecionados geralmente variam de acordo com o domínio de trabalho. As suposições que os levaram ao erro são identificadas e suas origens exploradas. Scrum A equipe discute o que deu certo durante o Sprint, quais problemas foram encontrados e como esses problemas foram (ou não) resolvidos.

O Scrum A equipe identifica as mudanças mais úteis para melhorar sua eficácia. As melhorias mais impactantes são abordadas o mais rápido possível. Elas podem até ser adicionadas ao Backlog do Sprint para o próximo Sprint.

A Retrospectiva do Sprint conclui o Sprint.O tempo máximo para um Sprint de um mês é de três horas. Para Sprints mais curtos, o evento geralmente é mais curto.

Scrum Artefatos

ScrumOs artefatos representam trabalho ou valor. Eles são projetados para maximizar a transparência de informações importantes. Assim, todos que os inspecionam têm a mesma base para adaptação.

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

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

Esses compromissos existem para reforçar o empirismo e a Scrum valores para o Scrum Equipe e suas partes interessadas.

Backlog do produto

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

Itens do Backlog do Produto que podem ser feitos pelo Scrum As equipes dentro de um Sprint são consideradas prontas para seleção em um evento de Planejamento de Sprint. Geralmente, elas adquirem esse grau de transparência após atividades de refinamento. O refinamento do Backlog do Produto é o ato de decompor e definir os itens do Backlog do Produto em 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 Desenvolvedores que realizarão o trabalho são responsáveis ​​pelo dimensionamento. O Product Owner pode influenciar os Desenvolvedores, ajudando-os a entender e selecionar compensações.

Compromisso: Objetivo do Produto

A Meta do Produto descreve um estado futuro do produto que pode servir como uma meta para o Scrum Equipe para planejar. A Meta do Produto está no Backlog do Produto. O restante do Backlog do Produto surge para definir "o que" cumprirá a Meta do Produto.

Um produto é um veículo para entregar valor. Ele tem limites claros, stakeholders conhecidos e 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 Equipe. Eles devem cumprir (ou abandonar) um objetivo antes de assumir o próximo.

Backlog do Sprint

O Sprint Backlog é composto pelo Objetivo do Sprint (por quê), o conjunto de itens do Product Backlog selecionados para o Sprint (o quê), bem como um plano de ação para entregar o Incremento (como).

O Backlog da Sprint é um plano feito pelos e para os Desenvolvedores. É uma imagem altamente visível e em tempo real do trabalho que os Desenvolvedores planejam realizar durante a Sprint para atingir a Meta da Sprint. Consequentemente, o Backlog da Sprint é atualizado ao longo da Sprint à medida que mais aprendizado é obtido. Ele deve ter detalhes suficientes para que eles possam verificar seu progresso no Daily. Scrum.

Compromisso: Meta do Sprint

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

A Meta do Sprint é criada durante o evento de Planejamento do Sprint e, em seguida, adicionada ao Backlog do Sprint. À medida que os Desenvolvedores trabalham durante o Sprint, eles mantêm a Meta do Sprint em mente. Se o trabalho for diferente do esperado, eles colaboram com o Product Owner para negociar o escopo do Backlog do Sprint dentro do Sprint sem afetar a Meta do Sprint.

Incremento

Um incremento é um trampolim concreto em direção à meta do produto.Cada incremento é aditivo a todos os incrementos anteriores e rigorosamente verificado, garantindo que todos os incrementos funcionem em conjunto. Para gerar valor, o incremento deve ser utilizável.

Vários Incrementos podem ser criados dentro de um Sprint. A soma dos Incrementos é apresentada na Revisão do Sprint, reforçando assim o empirismo. No entanto, um Incremento pode ser entregue aos stakeholders antes do final do Sprint. A Revisão do Sprint nunca deve ser considerada uma porta de entrada para a liberação de valor.

O trabalho não pode ser considerado parte de um Incremento, a menos que atenda à Definição de Concluído.

Compromisso: Definição de Feito

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, um Incremento nasce.

A Definição de Pronto cria transparência ao fornecer a todos um entendimento compartilhado sobre o trabalho concluído como parte do Incremento. Se um item do Backlog do Produto não atender à Definição de Pronto, ele não poderá ser lançado ou mesmo apresentado na Revisão da Sprint. Em vez disso, ele retornará ao Backlog do Produto para consideração futura.

Se a Definição de Pronto para um incremento fizer parte dos padrões da organização, todos Scrum As equipes devem segui-lo no mínimo. Se não for um padrão organizacional, o Scrum A equipe deve criar uma Definição de Pronto apropriada para o produto.

Os desenvolvedores são obrigados a estar em conformidade com a Definição de Pronto. Se houver vários Scrum Equipes trabalhando juntas em um produto devem definir e cumprir mutuamente a mesma Definição de Pronto.

Nota final

Scrum é gratuito e oferecido neste Guia. O Scrum estrutura, conforme descrito aqui, é imutável. Embora implemente apenas partes de Scrum é 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.

Agradecimentos

Pessoas

Das milhares de pessoas que contribuíram para Scrum, devemos destacar aqueles 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 a ajuda deles, Scrum não seria refinado como é hoje.

Scrum História do Guia

Ken Schwaber e Jeff Sutherland apresentaram pela primeira vez Scrum na Conferência OOPSLA em 1995. Documentou essencialmente o aprendizado que Ken e Jeff adquiriram nos anos anteriores e tornou pública a primeira definição formal de Scrum.

O Scrum Documentos de guia 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 insights que complementam o Scrum estrutura. Isso pode aumentar a produtividade, o valor, a criatividade e a satisfação com os resultados.

A história completa de Scrum é descrito em outro lugar. Para homenagear os primeiros lugares onde foi testado e comprovado, reconhecemos a 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 descrito de forma resumida em https://creativecommons.org/licenses/by-sa/4.0/. Ao utilizar isso Scrum Guia, você reconhece e concorda que leu e concorda em se comprometer com os termos da licença Atribuição Compartilha-Igual da Creative Commons.