AULA 2

METODOLOGIAS HÍBRIDAS
DE GERENCIAMENTO DE
PROJETOS

Prof. Luiz Fernando Nunes

TEMA 1 – ANÁLISE DE PROJETOS PREDITIVOS

Figura 1 – Ciclo de vida preditivo de um projeto

Nas abordagens preditivas, são definidos antecipadamente o escopo, o

prazo e o custo que irão compor todo o planejamento do projeto. Quando ocorrer
mudanças, elas somente serão executadas caso sejam aprovadas por um comitê
de gestão de mudanças.

• Possui escopo fechado;

• Existe um planejamento inicial;
• É realizada uma única entrega ao final do projeto;
• Existe um gerenciamento de orçamento;
• Mudanças são controladas por um comitê.

Figura 2 – Análise de projeto preditivo

Fonte: PMI, 2017.

2
TEMA 2 – ANÁLISE DE PROJETOS ÁGEIS

Figura 3 – Ciclo de vida ágil

Fonte: PMI, 2017.

Um ciclo adaptativo deve proporcionar entregas curtas, incrementais, que

possibilitem mudanças e exercitem a empatia com a real necessidade de geração
de valor para o cliente e tem as seguintes características:

• Possui escopo flexível;

• Entregas frequentes por ciclos curtos;
• Participação ativa do cliente em todo o projeto;
• Ciclo de feedback contínuo;
• Processo empírico.

TEMA 3 – CICLO DE VIDA HÍBRIDO

Figura 4 – Ciclo de vida híbrido de projetos

• Abordagens preditivas com práticas ágeis – não é necessário parar de

utilizar abordagens preditivas, mas vá incorporando outros métodos, sejam
eles ágeis ou de inovação e principalmente vá experimentando até
encontrar o equilíbrio ideal;

3
 • Abordagens ágeis com práticas preditivas – se está no caminho de
métodos ágeis, não tenha preconceito de entender que pode existir a
necessidade de práticas preditivas para otimizar seu modelo;
• Combinação de ciclos de vida – a junção de métodos permite quebrar
paradigmas e, principalmente, trazer a real necessidade do negócio ou
projeto.

Figura 5 – Diferentes abordagens ágeis

Saiba mais

Tailoring significa a identificação de qual o melhor método serve na medida

para cada contexto de projeto.
Quando falamos de tailoring, estamos dizendo que o líder de projetos, seja
ele gerente de projetos, product owner ou qualquer outro papel existente,
determina quais serão os processos adequados para a metodologia que cabe na
organização. Esse momento de ajuste da metodologia é uma etapa muito
importante para mensurar a maturidade de gerenciamento de projetos.

TEMA 4 – FRAMEWORK SCRUM

4.1 Visão geral sobre Framework Scrum

Jeff Sutherland criou o Scrum para utilizar na Easel Corporation em 1993.

Sua utilização seria no desenvolvimento de um software e para isso foram
utilizadas as bases do estudo de Takeuchi e Nonaka (1986). Tanto Jeff Sutherland

4
quanto Ken Schawber desenvolveram estudos e publicações que foram
fundamentais para popularizar o tema e difundir o framework no desenvolvimento
de software. Podemos destacar como principal publicação o The Scrum Guide
(Schwaber; Sutherland, 2020), em que constam todos pilares, eventos, papéis e
artefatos do framework Scrum.
Podemos definir o Scrum como um framework para gerenciamento de
projetos ágeis. Esse mesmo framework poderá tratar e resolver problemas em
níveis de complexidade alta e adaptativos. Não podemos considerar o Scrum
como um método mais fácil ou menos burocrático de gerenciar projetos, pois ele
não tem nenhum ponto que direcione para esse pensamento.
Um ponto fundamental do conceito ágil é centralizar o cliente no processo,
ou seja, gerar valor ao cliente é fundamental para o sucesso de cada entrega e
assim de todo backlog. Com o framework é possível empregarmos inúmeros
processos e técnicas, sempre buscando uma melhoria contínua tanto do produto
e toda a equipe de trabalho.
Para entender melhor o Scrum, é preciso compreender que esse framework
possui times associados a papéis, eventos, artefatos e regras. Vamos estudar
cada um destes itens, porém agora é importante entender o conceito do Scrum e
sua importância.
Como falamos de processos, o Scrum não é um processo padronizado em
que se aplica toda uma sequência metódica de passos para garantir que seja
entregue um produto ou serviço dentro do cronograma, custo e padrão de
qualidade de atenda os clientes. Podemos, então, enxergar o Scrum como uma
forma de organizar e gerenciar trabalho de forma a respeitar valores, princípios e
práticas.
O Scrum tem foco direto nas pessoas, baseando-se nos seguintes valores:

• Honestidade;
• Abertura;
• Coragem;
• Respeito;
• Foco;
• Confiança;
• Empoderamento;
• Colaboração.

5
 Para continuarmos nosso estudo aprofundado sobre Scrum, vamos
analisar uma palavra muito importante nesse contexto, que é o termo empírico,
ou seja, todo conhecimento é baseado em processos de decisão sobre o que é
conhecido. Podemos, assim, contextualizar como empírico um processo de
absorver conhecimento por meio de experiências vividas. Esse conhecimento
empírico, também chamado de senso comum, é baseado em experiência
imediata, não metódica e que não está interpretada com organização racional.

4.2 Pilares do Scrum

No Scrum, três pilares apoiam o processo empírico.

4.2.1 Transparência

Garante que os aspectos do processo que afetam o resultado sejam

visíveis e conhecidos a todos que controlam o resultado. Esses aspectos devem
ser de comum compreensão a todos observadores para que todos possuam um
mesmo entendimento do que está sendo apresentado.

4.2.2 Inspeção

Os artefatos do Scrum devem ser frequentemente inspecionados pelos

usuários e, por meio do progresso, deve ser direcionado ao objetivo da sprint para
dessa forma identificar variações indesejadas.

4.2.3 Adaptação

Se, durante a inspeção, um inspetor informa que um ou mais aspectos de

um processo possui desvio fora dos limites aceitáveis, impactando no resultado
do produto, o processo do produto/serviço deverá ser ajustado o mais breve
possível.

6
Figura 6 – Framework Scrum

Fonte: Scrum.org, [S.d.].

O Scrum apresenta quatro eventos formais para inspeção e adaptação:

• Planejamento da sprint;
• Reunião diária;
• Revisão da sprint;
• Retrospectiva da sprint.

4.3 Papéis

4.3.1 Product Owner

O Product Owner (dono do produto) é o papel responsável por maximizar

o valor produto, porém, essa determinação está um pouco complexa, por isso
vamos entendê-la de forma mais prática.
O papel do Product Owner é:

• Maximizar o valor do produto e do trabalho do time de desenvolvimento,

gerenciando de forma eficiente o backlog do produto;
• Deixar os itens do backlog do produto claros e fácil entendimento;
• Priorizar os itens do backlog do produto relacionando com as metas e
expectativas do cliente;
• Garantir o valor da entrega do trabalho do time de desenvolvimento;

7
 • Garantir visibilidade que o backlog do produto seja visível e transparente a
todo time de desenvolvimento;

4.3.2 Scrum Master

O Scrum master é o evangelizador do Scrum. Esse papel promove e

suporta o Scrum nas organizações, fazendo com que as pessoas entendam:

• A teoria;
• As práticas;
• As regras;
• Os valores do Scrum.

O Scrum Master tem como funções:

• Ajudar no entendimento e utilização da auto-organização e

interdisciplinaridade;
• O Scrum master não deve gerenciar o time de desenvolvimento;
• Ele treina o time de desenvolvimento em ambientes de difícil aceitação do
Scrum, garantindo que todos entendam o fluxo de processos deste;
• Facilitar os eventos do Scrum;
• Remover os impedimentos que possam interferir no objetivo do time de
desenvolvimento;
• Tem o papel de coach (técnico do time), ensinando e liderando o time de
desenvolvimento na criação de produtos de alto valor;
• Tem como principal papel orientar o time na realização dos trabalhos. Neste
ponto, é importante entender que o Scrum master não é gerente; é apenas
um guia que aponta o melhor caminho.

4.3.3 Developer

É responsabilidade do time de desenvolvimento executar o

desenvolvimento e transformar o backlog do produto em incremento e
funcionalidades, criando um sistema pronto que possa ser entregue ao cliente.
As características do time de desenvolvimento são as seguintes:

• Auto-organizados;
• Multifuncionais;
• Não reconhecem títulos para integrantes;
8
 • Não reconhecem subtimes;
• A responsabilidade pertence ao time de desenvolvimento,
independentemente das habilidades individuais.

4.4 Eventos

Os eventos no Scrum são utilizados para criar uma regularidade e

minimizar a necessidade de reuniões. Uma característica presente é que todos os
eventos são time-boxed, ou seja, todo evento tem uma duração máxima
estabelecida. Dessa forma, quando inicia uma Sprint, por exemplo, sua duração
é fixada e não pode ser reduzida ou aumentada.

4.4.1 Sprint

É o trabalho realizado em iterações ou ciclos de até um mês (quatro

semanas), quando o trabalho completo em cada Sprint deverá criar algo que
agrega valor ao cliente.
Toda Sprint tem uma data de início e data de fim bem definidas (Timebox)
e devem ter sempre a mesma duração. Um novo Sprint começa imediatamente
após a finalização do anterior.
Restrições durante a Sprint:

• Não é permitido mudança no escopo;

• Não é permitido mudança de pessoal;

4.4.2 Sprint Planning

Uma característica do Product Backlog é que ele pode representar várias

semanas ou meses de trabalho, muito maior que uma única Sprint (4 semanas).
Devido a esse Product Backlog com várias semanas, o product owner e a equipe
de desenvolvimento acordam um Sprint goal, que define o que o Sprint que vai
começar deve alcançar.

4.4.3 Daily Scrum

Em cada dia da Sprint, no mesmo horário, os membros da equipe de

desenvolvimento realizam uma reunião de duração fixa de quinze minutos, que
recebe o nome de Daily Scrum, que é uma atividade de inspeção e adaptação,

9
que possui uma abordagem comum de ter o Scrummaster como um facilitador da
reunião, provocando em cada membro da equipe a responder três perguntas:

• O que eu realizei desde a última Daily Scrum?

• O que eu planejo trabalhar para a próxima Daily Scrum?
• Quais são os obstáculos ou impedimentos que estão evitando que eu
avance?

A Daily Scrum não é:

• Uma atividade de solução de problemas;

• Uma reunião de Status Report;
• Uma reunião para lavar roupa suja ou discutir problemas de
relacionamento.

4.5 Definição de pronto (Done)

Quando um item do backlog do produto é descrito como pronto, devemos

entender o que isso significa. Cada equipe de desenvolvimento possui um
propósito, que na verdade é o propósito de cada Sprint: “Entregar incrementos de
funcionalidades potencialmente liberáveis que aderem à definição atual de pronto
do time Scrum” (Schwaber; Sutherland, 2017).
A definição de pronto faz parte:

• das convenções;
• dos padrões ou diretrizes de desenvolvimento da organização.

4.6 Revisão da Sprint (Sprint Review)

É a apresentação da Sprint. Seu objetivo é a revisão do Product Owner, ou

o próprio cliente, em todos os itens concluídos pelo Time. É um evento time-boxed
de quatro horas. É realizado uma comparação do que foi entregue e o que deveria
ter sido entregue.

4.7 Retrospectiva da Sprint (Sprint Retrospective)

É uma oportunidade para o Time Scrum inspecionar tudo que foi realizado
e criar um plano de melhorias a serem a aplicadas na próxima Sprint. Ela ocorre
após a Sprint Review e antes do planejamento da próxima Sprint. A reunião é um
evento Time-boxed de, no máximo, três horas para a Sprint de um mês. O
10
Scrummaster garante que o evento ocorra e que os participantes entendam seu
propósito.
A retrospectiva da Sprint tem os seguintes propósitos:

• Inspecionar como a última Sprint foi em relação às pessoas, aos

relacionamentos, aos processos e às ferramentas;
• Identificar e ordenar os principais itens que foram bem e as potenciais
melhorias;
• Criar um plano para implementar melhorias no modo que o Time Scrum faz
seu trabalho.

4.8 Artefatos

Os artefatos são utilizados como apoio ao Time Scrum para aplicar regras
que criam ligação entre os eventos, os papéis e os artefatos.

4.8.1 Backlog

• É o principal artefato do Scrum;

• Trata-se de uma lista ordenada de requisitos (estórias de usuários)
necessário do produto;
• O Backlog do produto lista todas as características, funções, requisitos,
melhorias e correções que formam as mudanças que devem ser feitos no
produto nas futuras versões;
• O Backlog do produto possui os atributos de descrição, ordem, estimativa
e valor;

O Backlog é dividido em conjuntos menores que contribuem para objetivos

específicos:

• Backlog do produto – todo Backlog que será trabalhado no projeto;

• Backlog da versão de entrega – parte do Backlog que será trabalhado na
versão de entrega definida entre o Time Scrum e o Cliente;
• Backlog da Sprint – parte do Backlog considerada preparada e
selecionada para ser trabalhada na versão da Sprint.

11
 Existem artefatos não oficiais, como:

• Histórias;
• Taskboard e gráfico Burndown.

TEMA 5 – KANBAN

5.1 Visão geral sobre Kanban

O Kanban foi originalmente criado no âmbito do Sistema Toyota de

Produção (TPS), no final da década de 1940, por Taichi Ohno. Com a
implementação da fabricação just in time em sua fábrica, ficou evidenciado o que
foi chamado de sistema puxado, em que toda produção era baseada na demanda
existente vinda do cliente, em vez de um sistema empurrado, em que uma
quantidade de itens era selecionada para a produção, porém sem necessidade e
geração de valor.
O termo Kanban se origina do japonês e pode ser traduzido como quadro
visual. Em seu aspecto mais simples, ele pode possuir apenas três colunas:

• Item;
• Em progresso;
• Concluído.

5.1.1 Características gerais do Kanban

• Kanban é um mecanismo que sustenta o Sistema Toyota de Produção e

uma abordagem kaizen para melhoria contínua;
• O primeiro sistema Kanban virtual para engenharia de software foi
implementado na Microsoft®, no início de 2014;
• Buscam um ritmo sustentável onde minimiza a resistência a mudança por
meio de abordagem evolutiva e incremental;
• A palavra Kanban, segundo Anderson (2017), é usada para se referir à
metodologia de melhoria de processo incremental e evolutiva que surgiu na
Corbis de 2006 a 2008 e evoluiu na comunidade de desenvolvimento de
software.

De acordo com Anderson (2017), “o Kanban é um método para definir,

gerenciar e melhorar serviços que oferecem trabalho de conhecimento, como

12
serviços profissionais, empregos ou atividades que envolvem criatividade e design
de software e produtos físicos”.

5.2 Princípios diretores

5.2.1 Sustentabilidade

A sustentabilidade levará em consideração toda a organização, pois atua

na construção de serviços quando é verificada toda a sobrecarga causada pelos
processos atuais. Quando falamos em sustentabilidade, temos de colocar em
prática uma palavra muito importante: equilíbrio, alcançado apenas quando
melhoramos a capacidade, engajamento e colaboração das pessoas na melhoria
do fluxo.

• Tem relação em encontrar um ritmo sustentável focado em melhoria;

• Olha para dentro da organização e equilibra a demanda com a capacidade.

5.2.2 Orientada a serviços

Orientação a serviços é a construção de uma junção de propósito da

organização que atinja seus clientes de maneiras positivas, agregando valor. Seu
objetivo é entregar serviços que estejam comprometidos com as necessidades
dos clientes.

• O foco é orientado a conseguir desempenho e maior satisfação do cliente;

• Prestar serviços aos clientes que estejam preparados para o fim e que
atendam suas necessidades.

5.2.3 Sobrevivência

Quando uma organização procura uma mudança evolutiva, ela está

buscando meios que garantam sua sobrevivência, com melhorias e evolução em
seus processos e garanta também que, diante de todas as necessidades que
sobrevenham no futuro, a empresa esteja apta para atingir a estrutura e a
competência.

• Seu objetivo é garantir que uma organização sobreviva e prospere em

tempos de mudança e incerteza;
• Promover o engajamento das partes envolvidas
13
5.3 Valores do Kanban

• Transparência – compartilhar informação gera melhoria no fluxo de valor

no negócio. A linguagem deve ser clara e direta;
• Equilíbrio – uma organização é composta de diferentes aspectos,
opiniões, pontos de vistas e capacidades. O entendimento como um todo
deve ser equilibrado para buscar efetividade, uma relação entre
demanda/capacidade;
• Colaboração – Kanban é totalmente direcionado a um trabalho
colaborativo e proporcionando melhoria nas relações;
• Foco no cliente – os clientes e o valor que recebem é um processo natural
do Kanban;
• Fluxo – O Kanban desenvolve nos times a capacidade de enxergar o fluxo
e compreendê-lo como ponto inicial em busca de valor;
• Liderança – liderança é a habilidade de inspirar, movimentar as pessoas
em busca de propósito e, por meio de palavras e técnicas, atingir os níveis
necessários para entregas de qualidade;
• Entendimento – é importante buscar conhecimento e entendimento
pessoal e da organização como um todo. O Kanban leva as pessoas a
buscarem esse conhecimento para melhoria do fluxo;
• Acordo – o Kanban possibilita uma capacidade de caminharmos juntos em
busca dos objetivos. Não é uma gestão do consenso, mas sim de um
compromisso compartilhado para melhorar;
• Respeito – David Anderson (2017) afirma que valorizar, entender e mostrar
consideração pelas pessoas é a maneira de se encontrar a base para todos
os valores.

5.4 Princípios do Kanban

Existem seis princípios fundamentais do Kanban, divididos em dois grupos.

5.4.1 Princípios da gestão de mudança

• Gestão de mudanças;
• Comece pelo que você faz agora;
• Acordar em buscar a melhoria por meio da mudança evolucionária;

14
 • Encorajar atos de liderança em todos os níveis.

5.4.2 Entrega ou implantação de serviços

• Entrega de serviços;
• Compreender e focar nas necessidades e expectativas dos seus clientes;
• Gerenciar o trabalho, deixar que as pessoas se auto-organizem em torno
dele;
• Desenvolver políticas para melhorar os resultados.

5.4.2 Exemplos de princípios da gestão de mudança

• “Comece pelo que estão fazendo agora”;

• Entender os processos atuais;
• Respeitar funções, papéis e responsabilidades atuais;
• “Acordo em buscar a melhoria através da mudança evolutiva”;
• “Fomentar a liderança em cada nível da organização”;
• Contribuições individuais;
• Liderança é promotora da mudança na organização;
• Diferentes níveis devem estar conectados.

5.5 Práticas gerais do Kanban

5.5.1 Visualizar

Além do quadro Kanban, é importante promover a visualização de políticas,

sendo vital destacar o status de cada item e as dependências existentes.
O quadro tem por características ser muito visível nas organizações e deve
estar em uma posição central. Todo o trabalho deve estar presente, e a
modificação deve possuir fácil acesso. O quadro Kanban deve ser desenhado por
uma equipe, não importando se de maneira digital ou física, pois é apenas
necessário que sirva para visualizar e facilitar o entendimento do fluxo de trabalho.

5.5.2 Limitar o WIP

Quando introduzimos limites em um sistema, estamos eliminando

desperdício e deixando esse sistema de possuir trabalhos parcialmente

15
completos. Isso significa trabalho em processo (work in process) e, para limitar,
devemos verificar alguns fatores importantes que não são tão visíveis que
auxiliam na determinação do WIP:

• Especificações que ainda não foram implementadas;

• Todo trabalho testar e integrado;
• Dívida técnica;
• Tarefas que necessitem de limitações de trabalho.

Figura 7 – Quadro Kanban e limites de WIP

O WIP definido de maneira correta promove ao trabalho uma maior

coordenação e um processo decisório mais eficientes. Um código ou
funcionalidades com mais qualidade identifica fatores fundamentais que
ocasionam os gargalos, por exemplo, bugs apresentados no fluxo.
Quando limitamos o trabalho, o fluxo é afetado diretamente, porém limitar
não significa fazer menos coisas e sim fazer as coisas certas por vez.
O objetivo de estabelecer WIP é reduzir o lead time, evitar gargalos,
apresentar menos atrasos, buscar um ritmo sustentável e com tudo isso claro
promove a melhoria no fluxo de trabalho.

5.5.3 Gerenciar o fluxo

O fluxo de trabalho maximiza a entrega de valor e minimiza as esperas. É

importante entender o custo do atraso (CoD – Cost of Delay) dos itens de trabalho.

5.6 Políticas explícitas

Políticas explícitas definem processos, criam restrições a ações e devem

ser, segundo Anderson (2016), sempre aplicáveis e facilmente modificáveis.

16
5.6.1 Implementar ciclos de feedback

Os ciclos de feedback são uma parte fundamental de qualquer processo

que proponha mudanças.

5.7 Métricas

5.7.1 Cumulative Flow Diagram

Gerenciar um fluxo de trabalho exige que tenhamos certo grau de

acompanhamento, mas imagine você pilotando um automóvel ou quem sabe um
avião sem um painel de controle. Sem números, sem velocidade, sem destino e
praticamente sem nenhuma perspectiva.
O Cumulative Flow Diagram é um gráfico que fornece uma visualização que
podemos chamar de estratégica do nosso fluxo de trabalho. Esse gráfico ajuda a
identificar os gargalos no fluxo de uma forma totalmente visual.
No gráfico CFD, cada cor é a representação de uma raia do quadro e a sua
quantidade de atividades existentes. A estrutura do gráfico é extremamente
simples, o eixo horizontal representa as semanas, dias, Sprints. O eixo vertical
indica o número de itens (atividades), em que cada área e sua respectiva cor é
uma etapa.

Figura 8 – Cumulative Flow Design

17
5.7.2 Lead Time (tempo de espera)

Tempo em que um item está em processo entre os pontos de compromisso

e de entrega.

Lead time = tempo de trabalho + tempo na fila

Um dos pontos importantes de entendimento do fluxo de trabalho é analisar

quando um item está em trabalho ou aguardando na fila de espera. A boa gestão
do fluxo deve garantir uma movimentação natural dos itens e que eles
permaneçam o mínimo de tempo possível na fila de espera.
Talvez você não veja na prática essa fila de espera, mas ela existe e tem
forte influência no desempenho final do fluxo.

5.8 Eficiência do processo

5.8.1 Throughput (taxa de entrega)

• É a quantidade média de itens que são entendidos como prontos, em

períodos que podem ser de dias, semanas ou meses;
• A frequência com que os itens são entregues.

18
5.8.2 Lei de Little

Segundo Anderson (2017), a Lei de Little em um sistema estável diz que a

quantidade média de tempo que algo leva para atravessar um processo é igual ao
número de atividades dividido por sua taxa de conclusão média.
Falando da Lei de Little, o tempo de entrega (Lead Time) é diretamente
proporcional à grande quantidade de trabalho em progresso (WIP). O professor
John Little provou que o número médio a longo prazo de cliente em um sistema
digamos estável é igual à taxa de chegada efetiva média a longo prazo.
Segundo Anderson (2017), a Lei de Little fornece uma visão a fim de
otimizar o tempo de espera para itens de trabalho e que devemos limitar o trabalho
em progresso.

5.8.3 Upstream e Downstream

Figura 9 – Upstream e Downstream

O Upstream trabalha no campo das ideias e desenvolvimento de produtos

ou serviços. Quando trabalhamos no campo das ideias, buscamos validar cada
item do fluxo ou projeto, ou seja, nada será comprometido se realmente não for
agregar valor como funcionalidade. Não se tornará item entregável no Discovery.
O Donwnstream trabalha com o serviço comprometido, aquele que deve
ser entregue. Nesse ponto, estamos praticamente dizendo ao cliente que existe
um acordo de entrega e que devemos cumpri-lo a fim de gerar valor e trazer
retorno para a organização.

19
REFERÊNCIAS

ANDERSON, D. J. Essential Kanban condensed. Seattle, Washington: Lean

Kanban University Press, 2017.

_____. Kanban Maturity Model: envolving fit for purpose organizations. Seattle,
Washington: Lean Kanban University Press, 2018.

CAMARGO; R.; RIBAS, T.; Gestão ágil de projetos: as melhores soluções para
suas necessidades. São Paulo: Saraiva Educação, 2019.

PMI – Project Management Institute. Guia Ágil. Newtown Square: PMI, 2017.

RUBIN, K. S. Scrum essencial: um guia prático para o mais popular processo

ágil. Rio de Janeiro: Alta Books, 2017.

SCHWABER, K.; SUTHERLAND, J. The Scrum Guide TM. Scrum Guides, nov.
2017. Disponível em: <https://scrumguides.org/docs/scrumguide/v2017/2017-
Scrum-Guide-US.pdf>. Acesso em: 19 abr. 2021.

SCHWABER, K.; SUTHERLAND, J. The Scrum Guide – The definitive guide to

Scrum: the rules of the game. Scrum Guides, 2020. Disponível em:
<https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf>.
Acesso em: 19 abr. 2021.

SCRUM.ORG. Disponível em: <https://www.scrum.org/>. Acesso em: 19 abr.

2021.

TAKEUCHI, H.; NONAKA, I. The New New Product Development Game. Harvard
Business Review, v. 64, n. 1, 1986.

20