PROCESSOS DE

DESENVOLVIMENTO
DE SOFTWARE

Diego Martins Polla de Moraes

Introdução ao
método Scrum
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:

 Definir o método Scrum e seus papéis.

 Reconhecer os principais eventos em Scrum.
 Descrever os principais artefatos em Scrum.

Introdução
A transformação digital é o assunto do momento em qualquer organi-
zação. A empresa que não está buscando meios de se reinventar através
da transformação digital está correndo sérios riscos, inclusive no curto
prazo. Para fazer frente a esses desafios, equipes de desenvolvimento de
software buscam meios de entregar as soluções necessárias aos negócios,
cumprindo os prazos (cada vez mais curtos) e o orçamento (cada vez
mais apertado).
Neste capítulo, você vai estudar sobre o método Scrum, os papéis
envolvidos, eventos e regras que permitem o gerenciamento ágil de uma
equipe de desenvolvimento de software. Este conhecimento permitirá
que você participe de times ágeis que utilizam o Scrum com condições
de obter os melhores resultados em relação ao escopo e à qualidade
dos produtos, aos prazos de entrega e, consequentemente, aos custos.
Uma das principais características do Scrum é o aprendizado facilitado
do próprio método. Com um pouco de dedicação, você entenderá o
Scrum e conseguirá aplicá-lo no seu time. Quando uma equipe passa a
dominar o método, a sua principal característica é o autogerenciamento.
O comprometimento mútuo faz com que equipes autogerenciáveis
entreguem resultados inéditos.
2 Introdução ao método Scrum

1 Scrum e seus papéis

Scrum é um método para organização de equipes criado por Schwaber e
Sutherland (2017), no qual um grupo de pessoas se organiza para desenvolver
soluções para problemas complexos e adaptativos gerando produtos com alto
valor para as organizações. O Scrum vem sendo adotado amplamente por
equipes de desenvolvimento de software ao redor do mundo, pois sua utilização
tem trazido resultados expressivos.
Para Pressman e Maxim (2016), os princípios encontrados no Scrum são
coerentes com o manifesto ágil e oferecem condições de aplicar um processo
de desenvolvimento que envolva requisitos, análise, projeto, evolução e entrega.
O elemento-chave que faz com que o processo do Scrum seja executado é a
Sprint. A Sprint é um espaço de tempo definido para execução de um conjunto
de atividades.
Em sua obra, Cohn (2011) enfatiza que a adoção bem-sucedida e duradoura
do Scrum depende de cinco principais atividades:

1. reconhecimento que o processo atual não está mais permitindo a entrega

dos resultados esperados;
2. desejo de adotar o Scrum como meio de resolver os problemas atuais;
3. aptidão da equipe para obter êxito com o Scrum;
4. promoção do Scrum por meio de compartilhamento de boas práticas
para reconhecer o sucesso da aplicação do método;
5. transferência das implicações do uso de Scrum para toda a empresa.

A estrutura do método Scrum consiste na associação de times aos papéis,

na execução de eventos, na produção de artefatos e no cumprimento de suas
regras. Por se tratar de um método ágil, enxuto, cada componente do método
tem um motivo de existir e é essencial para o uso e sucesso da utilização do
Scrum (PRIKLADNICKI; WILLI; MILANI, 2014).
A fundamentação do Scrum está nas teorias empíricas de controle de pro-
cesso. Schwaber e Sutherland (2017) pontuam que o conhecimento do método
vem da experiência e a tomada de decisões é baseada neste conhecimento
acumulado. O Scrum permite que a utilização de uma abordagem iterativa e
incremental apresente previsibilidade e elevado controle de riscos, ampliando
cada vez mais o conhecimento do time.
Para implementar o controle de processo empírico é necessário dar atenção
a três pilares: transparência, inspeção e adaptação.
 Introdução ao método Scrum 3

 Transparência: os responsáveis pelos resultados devem ter visibilidade

sobre os aspectos significativos do processo. Isto requer aspectos defini-
dos por um padrão comum para que, independentemente do observador,
a leitura seja a mesma.
 Inspeção: os times que aplicam Scrum tem que inspecionar frequente-
mente os artefatos e o progresso em andamento para detectar desvios.
É necessário haver uma dosagem na periodicidade de inspeções, para
que não prejudique a execução das tarefas.
 Adaptação: quando é detectado algum desvio de qualidade no produto
ou no processo, a equipe deve solucionar o mais rapidamente possível.

São características dos times de Scrum:

 auto-organizáveis;
 multifuncionais;
 criativos;
 flexíveis;
 produtivos.

O Scrum tem três papéis principais, Product Owner (PO), Scrum Master
e Time de Desenvolvimento, que não devem ser confundidos com cargos. Os
papéis são atribuições que cada membro envolvido no Scrum tem, e envolvem
habilidades, responsabilidades e atribuições.

Product Owner (Dono do Produto)

Em sua obra, Prikladnicki, Willi e Milani (2014) afirmam que o PO é responsá-
vel por representar as necessidades dos usuários do produto a ser desenvolvido
perante o time. A tradução literal — dono do produto — representa exatamente
o papel de um PO: ele é o guardião do produto, responsável por torná-lo um
sucesso, utilizando o trabalho do Time de Desenvolvimento.
A principal função de um PO é o gerenciamento do backlog do produto.
Segundo Pressman e Maxim (2016), o backlog do produto é uma lista de requi-
sitos ou funcionalidades do projeto que gerarão algum impacto nos negócios do
cliente, ou seja, que fornecerão algum valor comercial. Schwaber e Sutherland
(2017) apresentam um detalhamento de como o gerenciamento deve ocorrer.

 expressar de forma clara os itens do backlog do produto;

4 Introdução ao método Scrum

 ordenar os itens do backlog do produto a título de prioridade para

alcançar melhor as metas de negócios do cliente;
 garantir o reconhecimento do valor do trabalho realizado pelo Time
de Desenvolvimento;
 garantir que o backlog do produto seja visível, transparente, claro para
todos, e mostrando o que o time Scrum precisa trabalhar no próximo
ciclo;
 garantir que a equipe tenha entendimento pleno dos itens do backlog
do produto.

É importante ressaltar que o PO é uma pessoa e não um comitê. O PO pode

ser o representante de um grupo que envolva mais pessoas, mas as decisões
devem ser únicas. Quem precisar de uma alteração nas prioridades dos itens
de backlog deve negociar com o PO.
Por isso para que a execução do Scrum ocorra com sucesso, toda a orga-
nização deve respeitar a atribuição e autonomia de um PO. Absolutamente
ninguém, mesmo que de um nível hierárquico organizacional mais alto tem
permissão para alterar as prioridades do Time de Desenvolvimento sem que
essa decisão tenha passado pelo PO.

Scrum Master
O Scrum Master é um líder servidor para o Time Scrum. Ele atua de modo
a garantir que o Scrum seja entendido e aplicado dentro do time. Ele atua
como um facilitador, um apoio para o time de desenvolvimento e para o PO
(PRESSMAN; MAXIM, 2016). O Scrum Master apoia o PO e o Time de
Desenvolvimento de diversas formas (SCHWABER; SUTHERLAND, 2017):

 definindo técnicas para o gerenciamento do backlog do produto;

 mantendo a comunicação da visão, do objetivo e de itens do backlog
do produto para o Time de Desenvolvimento;
 apoiando o Time de Desenvolvimento a criar itens de backlog do produto
de forma clara;
 praticando e compreendendo a agilidade;
 sendo um facilitador dos eventos do Scrum conforme exigidos ou
necessários;
 treinando o Time de Desenvolvimento para que ele seja autogerenciado
e interdisciplinar;
 Introdução ao método Scrum 5

 exercendo a liderança do Time de Desenvolvimento na criação de

produtos que agregam valor aos negócios;
 removendo impedimentos para o progresso das Sprints;
 planejando implantações de Scrum dentro da organização;
 ajudando colaboradores e partes interessadas a compreender e tornar
aplicável o Scrum e o desenvolvimento de produto;
 fazendo acontecer mudanças que aumentam a produtividade do time
Scrum;
 aumentando a eficácia da aplicação do Scrum em conjunto com outros
Scrum Masters.

Scrum Team (Time de Desenvolvimento)

É composto pelos profissionais responsáveis por entregar uma versão utilizável
que tem potencial para incrementar o produto ao final de cada ciclo, que no
Scrum é chamado de Sprint (PRIKLADNICKI; WILLI; MILANI, 2014).
Existe uma discussão sobre o tamanho ideal de um time de desenvolvi-
mento. A ideia é que ele seja grande o suficiente para entregar dentro de um
ciclo resultados significativos para o produto, mas pequeno o bastante para
se manter ágil. O Scrum tem uma série de eventos que envolvem o time de
desenvolvimento, portanto uma equipe muito numerosa pode gerar eventos
com tempo muito longo e inconclusivos. É importante ressaltar que equipes
minúsculas, com 3 ou menos integrantes, podem ter dificuldade de ter sucesso,
pela falta de multidisciplinaridade nas habilidades dos membros. Já equipes
com mais de 9 membros, por sua vez, têm uma tendência de ocupar um
tempo de trabalho de gerenciamento maior do Scrum Master (SCHWABER;
SUTHERLAND, 2017).
Os Times de Desenvolvimento são estruturados e autorizados pela organiza-
ção para organizar e gerenciar seu próprio trabalho. Eles têm as características
a seguir (SCHWABER; SUTHERLAND, 2017):

 São auto-organizados: o próprio Time de Desenvolvimento determina

como transformar o backlog do produto em entregas de funcionalidades
utilizáveis.
 São multifuncionais: para criar o incremento do produto, o time de
desenvolvimento deve ter todas as habilidades necessárias. Devem
fazer parte do time todas as pessoas necessárias para garantir a entrega.
É bem comum que integrantes do Time de Desenvolvimento tenham
6 Introdução ao método Scrum

habilidades específicas, mas a responsabilidade da entrega permanece

no time como um todo.
 O Time de Desenvolvimento é único: o time é um só e não contém
subdivisões dedicadas a domínios específicos de conhecimento, tais
como análise de requisitos ou testes, por exemplo.

2 Eventos do Scrum
O Scrum tem sua execução baseada em eventos que têm objetivos específicos.
A previsibilidade de uma série de eventos tem o intuito de criar regularidade
e reduzir a necessidade de ocorrer outras reuniões que não são previstas no
Scrum. Todos eventos têm uma duração máxima definida, priorizando a pro-
dutividade do time e evitando desperdícios (SCHWABER; SUTHERLAND,
2017).
A Sprint é o evento concentrador do Scrum, em que todos os outros eventos
estão contidos/vinculados. Segundo Pressman e Maxim (2016), a Sprint é um
período definido, que deve ter no máximo 1 mês de duração, em que uma equipe
Scrum se organizará para atingir um objetivo. O início de uma nova Sprint
acontece exatamente quando a anterior se encerra, mantendo um ciclo vivo.
Para Schwaber e Sutherland (2017), algumas regras precisam ser conside-
radas em relação a uma Sprint.

 Uma Sprint não pode ter seu término adiado. Chegada a data fim, es-
tando o trabalho totalmente concluído ou não, deve ser formalizado seu
encerramento. Nos eventos de encerramento da Sprint existe previsão
para tratar do trabalho não concluído.
 Após o início da Sprint as mudanças só podem ser executadas se não
colocarem em risco o objetivo da Sprint.
 As prioridades podem mudar a qualquer momento, mas quanto maior
for o tamanho da Sprint, maior a chance de isso ocorrer. Por isso, a
maioria dos times prefere utilizar Sprints com tempo de 15 dias de
trabalho. Quando o tamanho da Sprint é muito longo, os riscos são
potencializados, pois a necessidade de mudanças é muito mais provável.

Na Figura 1 é possível verificar como ocorre a sequência dos eventos de

uma Sprint: primeiro, na Sprint Planning (Reunião de Planejamento) são
selecionados itens do backlog do produto para formar o Sprint Backlog. A
Sprint se inicia com um período entre 1 a 4 semanas, e diariamente ocorre
 Introdução ao método Scrum 7

a Daily Meeting (Reunião Diária). Ao término da Sprint, para inspecionar o

incremento do produto entregue, é executada a Sprint Review (Reunião de
Revisão), e, para inspecionar e adaptar o processo, a Sprint Retrospective
(Reunião de Retrospectiva). A seguir você conhecerá melhor todos os eventos
do Scrum: Reunião de Planejamento da Sprint; Reunião Diária; Revisão da
Sprint; Retrospectiva da Sprint.

Sprint Retrospective

Daily Scrum

24h

Sprint Review
Sprint
1–4 Semanas

Sprint Planning

Backlog Sprint Backlog Incremento

do Produto

Figura 1. O ciclo do Scrum representando a ordem de execução dos eventos e os artefatos

gerados.
Fonte: Scrum.org (c2019, documento on-line).

Sprint Planning (reunião de planejamento)

A reunião de planejamento é o marco de início de uma Sprint. Nesta reunião,
com a presença do PO, do Scrum Master e do Time de Desenvolvimento, o
backlog do produto será avaliado e o time determinará o que pode ser entregue
como incremento do produto nessa Sprint e como o trabalho para realizar
esta entrega deve ser organizado (COHN, 2011). Para que isso ocorra, o PO
deve manter em dia todas suas atividades de gerenciamento de backlog. Ele
deverá apresentar ao Time de Desenvolvimento, em ordem de prioridade, o
que são os objetivos da Sprint. Cabe ao Time de Desenvolvimento avaliar a
quantidade de itens que poderão ser completados dentro do período da Sprint
(SCHWABER; SUTHERLAND, 2017).
Para que o time possa realizar essa definição, ele precisa determinar a sua
capacidade e produtividade dentro de uma Sprint. O time deverá determinar
como pretende executar todas as atividades para permitir realizar as entregas
da Sprint. Neste momento, o PO pode auxiliar a detalhar itens do backlog em
8 Introdução ao método Scrum

que o time tenha dúvidas. A oportunidade de o time se tornar auto-organizável

está neste evento. Todos têm oportunidade de discutir o plano a ser executado
na Sprint para permitir o sucesso.
Na conclusão de uma Sprint Planning, todos deverão estar alinhados com o
objetivo da Sprint, com a lista completa dos itens que serão executados dentro
daquele período, que se chama Sprint Backlog.

Daily Meeting (reunião diária)

A reunião diária, como seu próprio nome menciona, deve ocorrer em todos os
dias de trabalho. Este evento deve ter até 15 minutos de duração e ocorrer no
mesmo lugar e horário (trazendo simplicidade). O Scrum Master é responsável
por este evento acontecer, mas quem deve conduzi-la é o próprio Time de
Desenvolvimento (PRIKLADNICKI; WILLI; MILANI, 2014).
A ocorrência da reunião diária tem por objetivo reduzir a necessidade de
outras interações e concentrá-las, num momento único. Schwaber e Sutherland
(2017) sugerem que com a equipe reunida, cada membro do time deverá, de
forma estruturada ou não, responder às perguntas a seguir.

 O que eu executei ontem com o intuito de atingir a meta da Sprint?

 O que eu pretendo executar hoje com o intuito de atingir a meta da
Sprint?
 Eu estou com algum impedimento para executar minhas atividades
ou enxergo algum impedimento para que o time atinja seus objetivos?

Quando algum membro identifica a necessidade de obter um detalhamento

maior, ou até mesmo oferecer um auxílio na remoção de algum impedimento,
deve tratá-lo após a reunião diária, com o envolvimento apenas dos membros
necessários, que fazem parte daquela situação. Isso faz com que o tempo da
reunião seja mantido, e por consequência a produtividade do time (SCHWA-
BER; SUTHERLAND, 2017).
Nesta reunião, o time exercita os princípios da inspeção e adaptação —
pois todos conseguem obter informações sobre os andamentos dos trabalhos
e podem discutir meios de manter o rumo em direção ao objetivo da Sprint.
 Introdução ao método Scrum 9

Sprint Review (reunião de revisão da Sprint)

Na reunião de revisão da Sprint, todo o trabalho concluído durante o período
da Sprint será evidenciado pelo time. Participam desta reunião o time e as
partes interessadas que são convidadas pelo PO (COHN, 2011).
Segundo Schwaber e Sutherland (2017), o PO apresenta quais itens do
backlog foram considerados prontos na Sprint, e quais não ficaram prontos.
O time deve discutir os problemas que ocorreram durante a Sprint, o que pôde
ser resolvido, o que ocorreu bem.
Para os itens que não ficaram prontos, é necessário tomar algumas decisões:
Os que não foram iniciados, ou seja, nenhum esforço da equipe foi despendido,
se mantêm necessários? Redefinir a prioridade desses itens é essencial. Agora,
para os itens que tiveram algum progresso mas que não foram concluídos o
time deve determinar a quantidade de trabalho necessária para concluí-lo na
próxima Sprint. Também é o momento para se discutir os próximos passos;
revisar o backlog do produto e identificar prováveis novas metas, incluindo
orçamento e escopo do produto para as próximas versões.
Ao fim de uma reunião de revisão da Sprint o backlog do produto deve
estar revisado, contendo os prováveis itens para a próxima Sprint.

Sprint Retrospective (reunião de retrospectiva da

Sprint)
A Retrospectiva da Sprint é o momento em que o Time Scrum terá opor-
tunidade de inspecionar a si mesmo e traçar um plano de melhorias para
serem aplicadas na próxima Sprint. O objetivo da retrospectiva da Sprint é
evidenciar e incentivar a continuidade de práticas que foram benéficas para o
time e o andamento da Sprint, além de discutir e apresentar alternativas para
as situações que foram prejudiciais.
Para Schwaber e Sutherland (2017), o propósito da Retrospectiva da Sprint é:

 inspecionar como a Sprint ocorreu em relação às pessoas, aos relacio-

namentos, aos processos e às ferramentas;
 identificar e ordenar os principais itens que foram bem e as potenciais
melhorias;
 traçar um planejamento para implementar melhorias no modo que o
Time Scrum faz seu trabalho.
10 Introdução ao método Scrum

Ao final da Retrospectiva da Sprint, o Time Scrum terá identificado as

melhorias que serão implementadas na próxima Sprint. Isto passa a ser um
compromisso, mais uma vez firmando o conceito de auto-organizável. As
melhorias podem ser implementadas a qualquer momento, mas a reunião de
retrospectiva e as ações decorrentes dela farão com que o processo de inspeção
e adaptação se torne institucionalizado.

Apesar do Scrum ser de fácil entendimento, a sua aplicação, com resultados efetivos,
leva um certo tempo. A organização e a equipe têm que ter em mente que precisam
rodar vários ciclos até adaptar o seu meio de trabalho para obter resultados expressivos.
É comum que equipes que tiveram resultados ruins em duas ou três primeiras Sprints
abandonem o método afirmando que ele não funciona. Mas o aprendizado do Scrum
vem exatamente das experiências obtidas em cada ciclo.

3 Artefatos do Scrum
O Scrum é um método que permite a execução de um processo. Todo processo
utiliza artefatos como saídas e entradas de atividades. Eles são a representação
do trabalho da equipe, e permitem que as características de transparência,
inspeção e adaptação do Scrum sejam evidenciadas.

Backlog do produto
Segundo Schwaber e Sutherland (2017), o backlog do produto é composto
por todas as necessidades de desenvolvimento do produto através da visão do
cliente. Prikladnicki, Willi e Milani (2014), por sua vez, afirmam que somente
o PO pode inserir, remover ou reordenar a prioridade de itens. O backlog do
produto é um documento vivo, e nunca estará completo. O PO interagirá cons-
tantemente com as partes interessadas do produto a fim de manter este backlog
priorizado, atualizado e evoluindo (SCHWABER; SUTHERLAND, 2017).
Na Figura 2, temos um exemplo de um backlog de produto de um software
de controle de estoque. Nele estão listados uma série de requisitos funcio-
nais que o software deve atender. O PO deve manter esta lista priorizada e
atualizada, com todas as necessidades do cliente.
 Introdução ao método Scrum 11

Figura 2. Um exemplo do backlog de um produto de software de controle de estoque.

Backlog da Sprint
O backlog da Sprint é o conjunto de itens do backlog do produto selecionados
para serem desenvolvidos durante a Sprint. Ele também contém o plano para
tornar aquele backlog em um produto real e utilizável pelo cliente (PRIKLAD-
NICKI; WILLI; MILANI, 2014).
Somente o time de desenvolvimento tem autonomia para alterar os itens de
backlog durante uma Sprint. Isso é necessário pois o time tem o controle do
andamento das atividades e poderá decidir se algo pode ser alterado, paralisado
ou adicionado (SCHWABER; SUTHERLAND, 2017).
Na Figura 3, podemos observar uma lista de itens do backlog do produto,
selecionadas para serem desenvolvidas na Sprint 001. Esta seleção ocorre
na reunião de planejamento mediante a análise da capacidade de entrega da
equipe versus os itens do backlog do produto em ordem de prioridade. Quando
a Sprint é executada com sucesso, os itens do backlog da Sprint passam a
fazer parte do Incremento do Produto e podem ser utilizados pelos usuários.

Figura 3. Um exemplo de backlog da Sprint, com itens selecionados do backlog de um

produto de software de controle de estoque.
12 Introdução ao método Scrum

Quadro Kanban
O quadro Kanban é uma ferramenta de gestão visual que representa a carac-
terística de transparência do Scrum. Através de um quadro de tarefas, que
pode ser físico ou digital, a equipe visualiza os itens a serem desenvolvidos e
seu andamento (PRIKLADNICKI; WILLI; MILANI, 2014).
A divisão das colunas do quadro, que são os espaços em que os itens
podem ser alocados, geralmente é entre “Backlog”, “A fazer”, “Fazendo” e
“Pronto”. Estas divisões também podem ser personalizadas de acordo com a
necessidade da equipe, mas devem seguir a tendência do ágil — simplicidade.

Incremento
Espera-se que ao final de cada Sprint o time de desenvolvimento entregue uma
nova versão do produto que contenha os itens do backlog da Sprint para uso
pelo cliente. A equipe de desenvolvimento deve ter a visão que o cliente pode
decidir por publicar em produção aquele incremento do produto, portanto sua
qualidade deve estar ajustada às necessidades do cliente (PRIKLADNICKI;
WILLI; MILANI, 2014).

Definição de pronto
Este conceito é muito importante numa equipe Scrum. Podem existir vários
entendimentos do que seja “Pronto” para um item do Sprint backlog. Para um
determinado membro do time a definição de pronto pode significar que o item
foi acoplado ao código fonte sem causar erros. Já na visão de um tester, pode
significar “sem bugs”. E na visão de um analista de negócios, que atende às
necessidades do cliente (SCHWABER; SUTHERLAND, 2017).
É, no entanto, o consenso em torno desta definição que balizará a decisão
de quantos itens podem ser selecionados na reunião de planejamento. Afinal,
toda a equipe terá o mesmo entendimento do que é o “pronto”, permitindo
assim definir o quanto de capacidade produtiva a equipe possui. Com um
time de Scrum em constante evolução, é esperado que a definição de “pronto”
também siga evoluindo, considerando cada vez mais critérios de qualidade.
 Introdução ao método Scrum 13

O Scrum pode e deve ser implantado nos mais diversos ambientes organizacionais,
até mesmo nos mais tradicionais. A prova disso é o que aconteceu no Departamento
Federal de Investigação dos Estados Unidos (FBI) com o projeto Sentinel. Depois de
10 anos atuando neste projeto que estava perto do seu cancelamento, decidiu-se por
adotar o Scrum como última medida (SUTHERLAND, 2016).
O backlog do produto foi organizado em 670 histórias de usuário que foram de-
senvolvidas em 21 Sprints com 15 dias de duração. Se ao final da Sprint nem todas
histórias estavam prontas, mesmo assim a equipe apresentava as histórias finalizadas,
e apenas as que passassem nos testes eram dadas como concluídas. Desta forma o
projeto foi concluído cumprindo as metas de escopo, custo e prazo (REBELO, 2012).
O projeto foi tão bem-visto dentro do governo americano, que outros órgãos de-
cidiram adotar o Scrum, como o Departamento de Defesa, o Gabinete de Prestação
de Contas do Governo, a Nasa, o Escritório de Patentes e Marcas, o Departamento
de Relacionamento dos Veteranos e a Secretaria da Receita Federal (REBELO, 2012).

COHN, M. Desenvolvimento de software com Scrum: aplicando métodos ágeis com

sucesso. Porto Alegre: Bookman, 2011.
PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem profissional.
8. Porto Alegre: AMGH, 2016.
PRIKLADNICKI, R.; WILLI, R.; MILANI, F. Métodos ágeis para desenvolvimento de software.
Porto Alegre: Bookman, 2014.
REBELO, P. Agile no FBI: fazendo em 2 anos o que não se conseguiu em 10. InfoQ, [s.
l.], 14 nov. 2012. Disponível em: https://www.infoq.com/br/news/2012/11/agile-fbi/.
Acesso em: 22 maio 2020.
SCHWABER, K.; SUTHERLAND, J. Guia do Scrum: um guia definitivo para o Scrum: as
regras do jogo. [S. l.: s. n.], 2017. Disponível em: https://www.scrumguides.org/docs/scru-
mguide/v2017/2017-Scrum-Guide-Portuguese-Brazilian.pdf. Acesso em: 22 maio 2020.
SCRUM.ORG. What is Scrum? A better way of building products. c2019. 1 ilustração.
Disponível em: http://revistas.poli.br/index.php/repa/article/view/1234/531. Acesso
em: 22 maio 2020.
SUTHERLAND, J. Scrum: a arte de fazer o dobro do trabalho na metade do tempo. 2.
ed. São Paulo: Leya, 2016.
14 Introdução ao método Scrum

Os links para sites da web fornecidos neste capítulo foram todos testados, e seu fun-
cionamento foi comprovado no momento da publicação do material. No entanto, a
rede é extremamente dinâmica; suas páginas estão constantemente mudando de
local e conteúdo. Assim, os editores declaram não ter qualquer responsabilidade
sobre qualidade, precisão ou integralidade das informações referidas em tais links.