O Guia Scrum ^2020TM

Objetivo do Guia Scrum

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

O Guia Scrum contém a definição de Scrum. Cada elemento da estrutura serve a um propósito específico que é essencial para o valor geral e os resultados obtidos com o Scrum. Mudar o design central ou as ideias do Scrum, deixar de fora elementos ou não seguir as regras do Scrum, encobre problemas e limita os benefícios do Scrum, potencialmente até tornando-o inútil.

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

À medida que o Scrum é usado, padrões, processos e insights que se enquadram na estrutura Scrum conforme descrito neste documento podem ser encontrados, aplicados e concebidos. Sua descrição está além do propósito do Guia Scrum porque são sensíveis ao contexto e diferem amplamente entre os usos do Scrum. Essas táticas para uso na estrutura Scrum variam amplamente e são descritas em outro lugar.

Definição de Scrum

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

Resumindo, o Scrum requer um Scrum Master para promover um ambiente onde:

1. Um Product Owner ordena o trabalho de um problema complexo em um Product Backlog.
2. O Time Scrum transforma uma seleção do trabalho em um incremento de valor durante um Sprint.
3. O Time Scrum e seus stakeholders inspecionam os resultados e ajustam para o próximo Sprint.
4. Repita

Scrum é simples. Experimente como está e determine se sua filosofia, teoria e estrutura ajudam a atingir metas e criar valor. A estrutura Scrum é propositalmente incompleta, definindo apenas as partes necessárias para implementar a teoria Scrum. O Scrum é construído pela inteligência coletiva das pessoas que o utilizam. Em vez de fornecer instruções detalhadas às pessoas, as regras do Scrum orientam 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. O Scrum torna visível a eficácia relativa das atuais técnicas de gestão, ambiente e trabalho, para que melhorias possam ser feitas.

Teoria Scrum

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

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

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

Transparência

O processo e o trabalho emergentes devem ser visíveis para aqueles que executam o trabalho, bem como para aqueles que o recebem. Com o Scrum, decisões importantes são baseadas no estado percebido de seus três artefatos formais. Artefatos com baixa transparência podem levar a decisões que diminuem o valor e aumentam o risco.

A transparência permite a inspeção. A inspeção sem transparência é enganosa e um desperdício.

Inspeção

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

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

Adaptação

Se algum aspecto de um processo se desviar dos limites aceitáveis ​​ou se o produto resultante for inaceitável, o processo aplicado ou os materiais produzidos deverão ser ajustados. O ajuste deve ser feito o mais rápido possível para minimizar desvios adicionais.

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

Valores Scrum

O uso bem-sucedido do Scrum depende de as pessoas se tornarem mais proficientes na vivência de cinco valores:

Compromisso, Foco, Abertura, Respeito e Coragem

O Time Scrum se compromete a atingir seus objetivos e apoiar uns aos outros. Seu foco principal está no trabalho do Sprint para fazer o melhor progresso possível em direção a esses objetivos. O Time Scrum e seus stakeholders estão abertos sobre o trabalho e os desafios. Os membros do Time Scrum respeitam uns aos outros para serem pessoas capazes e independentes, e são respeitados como tal pelas pessoas com quem trabalham. Os membros do Time Scrum têm a coragem de fazer a coisa certa, de trabalhar em problemas difíceis.

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

Equipe Scrum

A unidade fundamental do Scrum é uma pequena equipe de pessoas, um Time Scrum. O Time Scrum consiste em um Scrum Master, um Product Owner e Desenvolvedores. Dentro de um Time Scrum, não existem subequipes ou hierarquias. É uma unidade coesa de profissionais focados em um objetivo de cada vez, a Meta do Produto.

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

O Time Scrum é pequeno 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 equipas mais pequenas comunicam melhor e são mais produtivas. Se os Times Scrum se tornarem muito grandes, eles devem considerar a reorganização em vários Times Scrum coesos, cada um focado no mesmo produto. Portanto, eles devem compartilhar o mesmo objetivo do produto, backlog do produto e proprietário do produto.

O Time Scrum é responsável por todas as atividades relacionadas ao produto, desde a colaboração das 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 o foco e a consistência do Time Scrum.

Todo o Time Scrum é responsável por criar um incremento útil e valioso a cada Sprint. Scrum define três responsabilidades específicas dentro do Time Scrum: os Desenvolvedores, o Dono do Produto e o Scrum Master.

Desenvolvedores

Desenvolvedores são as pessoas do Time Scrum que estão comprometidas em criar qualquer aspecto de um incremento utilizável em cada Sprint.

As habilidades específicas necessárias aos Desenvolvedores são geralmente amplas e variam de acordo com o domínio do trabalho. 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 Feito;
• Adaptando seu plano a cada dia em direção ao Sprint Goal; e,
• Responsabilizar-nos uns aos outros como profissionais.

Proprietário do produto

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

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

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

O Product Owner pode fazer 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 ordem do Backlog do Produto e através do Incremento inspecionável na Revisão do Sprint.

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

Scrum Master

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

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

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

O Scrum Master atende o Time Scrum de diversas maneiras, incluindo:

• Coaching dos membros da equipe em autogestão e multifuncionalidade;
• Ajudar o Time Scrum a focar na criação de incrementos de alto valor que atendam à Definição de Pronto;
• Provocar a remoção de impedimentos ao progresso do Time Scrum; e,
• Garantir que todos os eventos Scrum ocorram e sejam positivos, produtivos e mantidos dentro do prazo.

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

• Ajudar a encontrar técnicas para definição eficaz do Objetivo do Produto e gerenciamento do Backlog do Produto;
• Ajudar o Time Scrum a entender a necessidade de itens claros e concisos do 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 Master atende a organização de diversas maneiras, incluindo:

• Liderar, treinar e treinar a organização na adoção do Scrum;
• Planejar e aconselhar implementações de Scrum dentro da organização;
• Ajudar os funcionários e as partes interessadas a compreender e implementar uma abordagem empírica para trabalhos complexos; e,
• Removendo barreiras entre as partes interessadas e as equipes Scrum.

Eventos Scrum

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

Idealmente, todos os eventos são realizados no mesmo horário e local para reduzir a complexidade.

A corrida

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 o Objetivo do Produto, incluindo Planejamento do Sprint, Scrums Diários, Revisão do Sprint e Retrospectiva do Sprint, acontece dentro dos Sprints.

Durante a Sprint:

• Nenhuma alteração é feita que possa colocar em risco o objetivo do Sprint;
• A qualidade não diminui;
• O Backlog do Produto é refinado conforme necessário; e,
• O escopo pode ser esclarecido e renegociado com o Product Owner à medida que mais for aprendido.

Os sprints permitem a previsibilidade, garantindo a inspeção e a adaptação do progresso em direção a uma meta do produto pelo menos todos os meses. Quando o horizonte de um Sprint é muito longo, o Objetivo do Sprint pode se tornar inválido, a complexidade pode aumentar e o risco pode aumentar. Sprints mais curtos podem ser empregados 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 projeto curto.

Existem várias práticas para prever o progresso, como esgotamentos, esgotamentos ou fluxos cumulativos. Embora comprovadamente úteis, estes não substituem a importância do empirismo. Em ambientes complexos, o que acontecerá é desconhecido. Somente o que já aconteceu pode ser usado para a tomada de decisões voltadas para o futuro.

Um Sprint pode ser cancelado se o objetivo do Sprint se tornar obsoleto. Somente o Product Owner tem autoridade para cancelar o Sprint.

Planejamento de Sprints

O Sprint Planning inicia o Sprint definindo o trabalho a ser executado para o Sprint. Este plano resultante é criado pelo trabalho colaborativo de todo o Time Scrum.

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

O Planejamento do Sprint aborda os seguintes tópicos:

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

O Product Owner propõe como o produto poderia aumentar seu valor e utilidade no Sprint atual. Todo o Time Scrum 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 final do planejamento do Sprint.

Tópico Dois: O que pode ser feito neste Sprint?

Através de discussão com o Product Owner, os Desenvolvedores selecionam itens do Product Backlog para incluir no Sprint atual. O Time Scrum pode refinar esses itens durante esse processo, o que aumenta a compreensão e a confiança.

Selecionar quanto pode ser concluído em um Sprint pode ser um desafio. 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 de 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 Concluído. Isso geralmente é feito decompondo os itens do Product Backlog em itens de trabalho menores de um dia ou menos. A forma como isso é feito fica a critério exclusivo dos Desenvolvedores. Ninguém mais lhes diz como transformar itens do Backlog do Produto em incrementos de valor.

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

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

Scrum Diário

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

O Daily Scrum é um evento de 15 minutos para os Desenvolvedores do Time Scrum. Para reduzir a complexidade, ele é realizado no mesmo horário e local todos os dias úteis do Sprint. Se o Product Owner ou Scrum Master estiverem trabalhando ativamente em itens do Sprint Backlog, eles participam como Desenvolvedores.

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

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

O Daily Scrum não é o único momento em que os desenvolvedores podem ajustar seus planos. Eles frequentemente se reúnem ao longo do dia para discussões mais detalhadas sobre como adaptar ou replanejar o restante do trabalho do Sprint.

Revisão da Sprint

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

Durante o evento, o Time Scrum e os stakeholders analisam 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 atender novas oportunidades. A Sprint Review é uma sessão de trabalho e o Time Scrum deve evitar limitá-la a uma apresentação.

A Sprint Review é o penúltimo evento do Sprint e tem um limite de tempo de no máximo quatro horas para um Sprint de um mês. Para Sprints mais curtos, o evento geralmente é mais curto.

Retrospectiva da Sprint

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

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

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

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

Artefatos Scrum

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

Cada artefato contém o compromisso de garantir que forneça informações que melhorem a transparência e o foco em relação aos quais o progresso possa ser medido:

• Para o Product Backlog é o Objetivo do Produto.
• Para o Sprint Backlog é o Sprint Goal.
• Para o Incremento é a Definição de Feito.

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

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 Time Scrum.

Os itens do Product Backlog que podem ser executados pelo Time Scrum dentro de um Sprint são considerados prontos para seleção em um evento de Planejamento do Sprint. Geralmente adquirem esse grau de transparência após as atividades de refino. O refinamento do Backlog do Produto é o ato de dividir e definir ainda mais 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 do trabalho.

Os Desenvolvedores que farão o trabalho são responsáveis ​​pelo dimensionamento. O Dono do Produto pode influenciar os Desenvolvedores, ajudando-os a compreender e selecionar compensações.

Compromisso: Objetivo do Produto

O Objetivo do Produto descreve um estado futuro do produto que pode servir como uma meta para o Time Scrum planejar. O objetivo do produto está no backlog do produto. O restante do Backlog do Produto surge para definir “o que” cumprirá o Objetivo do Produto.

Um produto é um veículo para entregar valor. Tem um limite claro, partes interessadas conhecidas, 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 do Time Scrum. Eles devem cumprir (ou abandonar) um objetivo antes de assumir o próximo.

Pendências da Sprint

O Sprint Backlog é composto pela Meta do Sprint (por que), pelo conjunto de itens do Product Backlog selecionados para o Sprint (o quê), bem como por um plano acionável para entregar o Incremento (como).

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

Compromisso: Meta do Sprint

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

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

Incremento

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

Vários incrementos podem ser criados em um Sprint. A soma dos Incrementos é apresentada na Sprint Review apoiando assim o empirismo. No entanto, um incremento pode ser entregue às partes interessadas antes do final do Sprint. A Sprint Review nunca deve ser considerada uma porta 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 atende às medidas de qualidade exigidas para o produto.

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

A Definição de Concluído cria transparência ao fornecer a todos uma compreensão compartilhada de qual trabalho foi concluído como parte do Incremento. Se um item do Product Backlog não atender à Definição de Pronto, ele não poderá ser lançado ou mesmo apresentado na Sprint Review. Em vez disso, ele retorna ao Product Backlog para consideração futura.

Se a Definição de Pronto para um incremento fizer parte dos padrões da organização, todos os Times Scrum devem segui-la no mínimo. Caso não seja um padrão organizacional, o Time Scrum 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 Times Scrum trabalhando juntos em um produto, eles deverão definir e cumprir mutuamente a mesma Definição de Pronto.

Nota final

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

Reconhecimentos

Pessoas

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

Histórico do Guia Scrum

Ken Schwaber e Jeff Sutherland co-apresentaram o Scrum pela primeira vez na Conferência OOPSLA em 1995. Essencialmente, documentou o aprendizado 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 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 a estrutura Scrum. Isso pode aumentar a produtividade, o valor, a criatividade e a satisfação com os resultados.

A história completa do Scrum é descrita em outro lugar. Para homenagear os primeiros lugares onde foi testado e comprovado, 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 de forma resumida em https://creativecommons.org/licenses/by-sa/4.0/ . Ao utilizar este Guia Scrum, você reconhece e concorda que leu e concorda em obedecer aos termos da licença Atribuição Compartilhada pela mesma Licença Creative Commons.