Como citar este material:

BARCAUI, André. Gerenciando projetos e produtos com scrum. Rio de Janeiro: FGV,
2022.

Todos os direitos reservados. Textos, vídeos, sons, imagens, gráficos e demais componentes
deste material são protegidos por direitos autorais e outros direitos de propriedade intelectual, de
forma que é proibida a reprodução no todo ou em parte, sem a devida autorização.
INTRODUÇÃO
Prezado(a) aluno(a),
O mundo definitivamente já não é mais o mesmo. Sempre tivemos
mudanças em toda a história da humanidade, mas nunca com tamanha
capilaridade e potencial de impacto como vemos nos dias de hoje. O
ritmo das mudanças e a sua crescente complexidade atingem escalas
exponenciais, demandando ações rápidas e efetivas das organizações.
Em um contexto assim, as respostas não podem ter o mesmo padrão
das primeiras revoluções industriais. Não se trata mais de treinar as
melhores pessoas e demandar que façam o trabalho repetitivo para o qual
foram contratadas. As pessoas e a sociedade como um todo clamam por
inovação, mas não se pode esperar inovação, nem mesmo criatividade, em
um ambiente fechado, com uma liderança baseada nos velhos padrões de
comando e controle. Inovar demanda certo grau de coragem, inspiração e
experimentação. Afinal, não se podem esperar resultados diferentes
fazendo as coisas da mesma maneira.
Os métodos ágeis e, em particular, o Scrum, vêm como resposta a
esse desafio de adaptação que os times de projetos vêm enfrentando.
Desenvolver novos produtos e serviços em uma realidade líquida como a
que vivemos demanda uma gestão capaz não só de ultrapassar esses
obstáculos, mas também de fazer uso deles por meio de um modelo
relativamente simples, mas extremamente poderoso de desenvolvimento.
É sobre isto que vamos estudar: como funciona o framework
Scrum e como ele pode facilitar a vida das equipes de projetos,
promovendo um ambiente saudável e, ao mesmo tempo, produtivo de
trabalho.
Dessa forma, o objetivo geral desta disciplina consiste em
compreender os principais conceitos sobre o framework Scrum, os seus
papéis-chave, as suas cerimônias e os seus artefatos.
 Por sua vez, entre os objetivos específicos, podemos listar:
 conhecer as origens do Scrum;
 conhecer os valores Scrum;
 compreender a teoria e o funcionamento do framework Scrum;
 entender o funcionamento das sprints;
 saber escrever uma história de usuário;
 discutir técnicas de estimativa de esforço;
 entender os papéis contidos no Scrum;
 assimilar a dinâmicas das cerimônias do Scrum;
 aprender a utilizar os artefatos do Scrum e as suas respectivas metas;
 trabalhar formas de medição e acompanhamento de projetos;
 revisar boas práticas de Scrum;
 aprender a gerenciar riscos com Scrum;
 conhecer uma adaptação do Scrum denominada Scrumban e
 entender formas de escalada do Scrum na organização.

A fim de alcançar tais objetivos, a disciplina está estruturada em quatro módulos. No módulo
1, Introdução ao Scrum, fazemos uma revisão do histórico da agilidade e dos seus conceitos básicos,
com destaque para o Manifesto Ágil e o próprio Scrum no contexto dos métodos ágeis; examinamos
a origem e a teoria por trás do Scrum, além dos seus pilares e dos valores associados; e, adicionalmente,
revisamos os conceitos dos diferentes tipos de ciclos de vida de projetos.
No módulo 2, Framework Scrum, apresentamos a estrutura do Scrum, ou seja, como o
framework funciona e como ele ajuda no sentido de gerar produtos e serviços de maneira iterativa
e incremental; e exploramos o conceito de sprints, os papéis no Scrum, bem como os seus principais
eventos, artefatos e respectivos compromissos.
No módulo 3, Histórias e Estimativas, tratamos de um tópico muito importante não só no
Scrum, mas em diversas outras metodologias ágeis: as histórias de usuário, as suas estimativas e as
formas de controle; e abordamos técnicas de estimativas no Scrum, além de ferramentas de
acompanhamento de projeto, tais como os gráficos de burnup e burndown.
Por fim, no módulo 4, Aspectos Avançados, cuidamos de aspectos adicionais e de cunho
avançado a respeito da dinâmica do Scrum, no que diz respeito à gestão de riscos, à comparação e
à utilização com Kanban, bem como à escalada do Scrum nas organizações, entre outras
considerações importantes que ajudam a alicerçar a sua implantação nas organizações.
Bom curso!
SUMÁRIO
MÓDULO I – INTRODUÇÃO AO SCRUM................................................................................................ 7

AGILIDADE ........................................................................................................................................... 7
MANIFESTO ÁGIL .............................................................................................................................. 10
ORIGEM DO SCRUM.......................................................................................................................... 13
TIPOLOGIA DE CICLOS DE VIDA ..................................................................................................... 17
CONCLUSÃO ..................................................................................................................................... 19

MÓDULO II – FRAMEWORK SCRUM...................................................................................................... 20

PAPÉIS NO SCRUM ............................................................................................................................ 20

Time Scrum................................................................................................................................ 20
T-Shaped e I-Shaped.................................................................................................................. 22
Product owner ........................................................................................................................... 23
Scrum master............................................................................................................................. 24
Desenvolvedores ..................................................................................................................... 25
EVENTOS DO SCRUM ........................................................................................................................ 26
Sprints ........................................................................................................................................ 26
Sprint planning .......................................................................................................................... 27
Daily Scrum ................................................................................................................................ 28
Sprint review .............................................................................................................................. 29
Sprint retrospective ................................................................................................................... 29
ARTEFATOS E COMPROMISSOS ..................................................................................................... 32
Product backlog ......................................................................................................................... 32
Sprint backlog ............................................................................................................................ 34
Incremento ............................................................................................................................... 34
ENTENDENDO O FRAMEWORK SCRUM ........................................................................................... 35
CONCLUSÃO ..................................................................................................................................... 38

MÓDULO III – HISTÓRIAS E ESTIMATIVAS ......................................................................................... 40

HISTÓRIAS DE USUÁRIO .................................................................................................................. 40

ESTIMATIVAS ..................................................................................................................................... 44
Ideal hours ................................................................................................................................. 47
Story points ................................................................................................................................ 47
Dot voting ................................................................................................................................... 50
T-shirt sizing .............................................................................................................................. 51
Planning poker ........................................................................................................................... 52
GRÁFICOS DE ACOMPANHAMENTO .............................................................................................. 53
Gráfico de burndown ............................................................................................................... 54
Gráfico de burnup .................................................................................................................... 55
CONCLUSÃO ..................................................................................................................................... 58
MÓDULO IV – ASPECTOS AVANÇADOS.............................................................................................. 60

GESTÃO DE RISCOS .......................................................................................................................... 60

SCRUMBAN ........................................................................................................................................ 67
ESCALANDO O SCRUM ..................................................................................................................... 71
Scaled Agile Framework............................................................................................................. 72
Scrum@Scale ............................................................................................................................. 77
Nexus ......................................................................................................................................... 81
Large-Scale Scrum ..................................................................................................................... 83
Disciplined Agile ......................................................................................................................... 84
CONCLUSÃO ..................................................................................................................................... 90

BIBLIOGRAFIA ...................................................................................................................................... 91

PROFESSOR-AUTOR ............................................................................................................................. 95
MÓDULO I – INTRODUÇÃO AO SCRUM

Este módulo faz uma revisão do histórico da agilidade e dos seus conceitos básicos, com
destaque para o Manifesto Ágil e o próprio Scrum no contexto dos métodos ágeis; revisa a origem
e a teoria por trás do Scrum, além dos seus pilares e dos valores associados; adicionalmente, examina
os conceitos dos diferentes tipos de ciclos de vida de projetos.
As unidades do módulo estão divididas da seguinte forma:
 Unidade 1.1 – Agilidade;
 Unidade 1.2 – Manifesto ágil;
 Unidade 1.3 – Origem do Scrum e
 Unidade 1.4 – Tipologia de ciclos de vida.

Ao final do módulo, espera-se que o você tenha uma boa noção de como se iniciou o
movimento ágil e de como o Scrum se insere nesse cenário.

Agilidade
Vivemos em um mundo fascinante. Não por acaso, denominando “mundo Vuca”, que faz
uso de um acrônimo em inglês para: volátil, incerto, complexo e ambíguo, criado pelo U.S. Army
War College, procurando refletir sobre o estado em que mundo se encontrava após o fim da Guerra
Fria. Com efeito, as transformações ocorrem em ritmo incessante, por isso estamos todos nós,
pessoas e organizações, tentando adaptar-nos o tempo todo.
 São vários os agentes de mudança que influenciam nesse contexto. Entre eles, podemos destacar:
 a própria tecnologia, à medida que vivemos cada vez mais em um filme de ficção científica
como Matrix, por exemplo;
 o mercado e a globalização, que influenciam, em todos os sentidos, tanto as empresas
quanto nações inteiras;
 a sociedade, que na sua constante mutação, acaba sofrendo e sendo agente de mudança, e
 os clientes, que, cada vez mais exigentes, demandam experiências positivas e encantamento.

Figura 1 – Agentes de mudança

Fonte: elaborado pelo autor.

Como prosperar em um ambiente tão desafiador? Algumas empresas conseguem esse intento
de maneira extremamente profícua, criando e ditando novos rumos para a sociedade como um
todo. Esse fenômeno é visível em diversos setores da economia, mas, particularmente, no segmento
da tecnologia. Inclusive, poderíamos argumentar que toda organização é de tecnologia em algum
grau. Entretanto são vários os casos de empresas, inclusive de tecnologia, que perderam o timing
ou o rumo dos seus próprios produtos e serviços, por não terem sido rápidas o suficiente para captar
e implementar o que o mercado demandava ou o que os seus clientes consideravam pertinente.

8
 Por outro lado, temos organizações que acabaram gerando novos modelos de negócio, novas
economias, conquistando literalmente milhões de clientes a partir de ideias criativas que se
transformaram em inovação. Exemplos como: Tesla, Amazon, Spotify, Netflix, Apple, entre tantas
que hoje influenciam tão diretamente as nossas vidas e que primam por diminuir a fricção entre
produtos e serviços e os seus usuários (BARCAUI, 2020).
O segredo por trás dessas organizações está na agilidade da sua gestão, mas não devemos
confundir agilidade com velocidade ou pressa. Para Meyer (2015, p. 10), agilidade é o
desenvolvimento intencional de competências, capacidades e confiança para aprender, adaptar e
inovar em contexto de mudança. Verstraete (2004) aventa que o nível de agilidade nos negócios
envolve a latência entre o aparecimento de um evento externo e a implantação da mudança
apropriada. Para Wadhwa e Rao (2003), agilidade nos negócios seria a habilidade de lidar com
mudanças que são, em grande medida, imprevisíveis, com respostas mais inovadoras. Ramasesh,
Kulkarni e Jayakumar (2001) defendem que a agilidade é a exploração bem-sucedida de bases
competitivas – velocidade, flexibilidade, inovação, proatividade, qualidade e lucratividade – por
meio da integração de recursos reconfiguráveis e melhores práticas em um ambiente rico em
conhecimento para fornecer produtos e serviços voltados para o cliente em um contexto de
mudança. Denning (2019, p. 34), por sua vez, sugere que a gestão ágil não trata de fazer mais
trabalho em menos tempo, mas, sim, de gerar mais valor com menos trabalho.
Como é possível observar, as diferentes definições de agilidade convergem para a capacidade
da organização de lidar com mudanças imprevistas. Mais ainda, se ela é capaz de responder de
maneira inovadora, e não apenas pré-definida. Traduzindo para a prática, agilidade não trata de
tecnologia ou de post-its coloridos colocados na parede. É muito mais uma mentalidade do que
propriamente um conjunto de ferramentas. Visa colocar o cliente no centro de tudo, subordinando
toda a cadeia de valor da organização a esse mandamento primordial. A burocracia não faz parte da
agilidade. Pelo menos não aquela burocracia ruim, obtusa, deletéria, que só serve para gerar
aborrecimento. Sistemas, processos lentos, níveis de hierarquia, entre outras questões não se devem
entrepor entre a empresa e o desejo do cliente. Não podemos aceitar que a área fim da empresa,
intrinsicamente ligada ao seu propósito, seja submissa e trabalhe para área meio. Nesse sentido, a
agilidade preconiza a redução de desperdícios, o trabalho de forma mais inteligente, gerando mais
valor com menos trabalho (DENNING, 2018).
Outro ponto importante é que agilidade está diretamente associada à inovação. Por uma razão
muito simples, é impossível pensar em sustentabilidade e desenvolvimento dos negócios em um
mundo Vuca, sem inovar. Ficar parado no tempo ou comemorando eternamente o sucesso dentro
de uma zona de conforto é sinônimo de fragilidade, e o prognóstico não costuma ser positivo em
condições como essa. Inovar é preciso, mas, para tanto, a organização tem de ser mais tolerante ao
risco e ao erro. Até porque não é possível acertar em todas as tentativas. Pelo contrário, a história
está cheia de exemplos de produtos que eram destinados a determinado fim, mas que acabaram
tendo outra finalidade e foram um tremendo sucesso. Para tanto, é preciso experimentar!

9
 Dito isso, é importante ressaltar que não existe um caminho único para toda e qualquer
organização em termos de agilidade. A agilidade ocorre por meio do desenvolvimento deliberado
de competências, e não tem uma data específica para ocorrer. Trata-se de um processo
extremamente idiossincrático em cada organização, e a perspectiva dos métodos ágeis veio a facilitar
tremendamente a sua introdução e manutenção.

Manifesto ágil
A origem dos métodos ágeis está diretamente relacionada à história do desenvolvimento de
software. No decorrer dos anos 1960-1970, eram comuns os chamados mainframes ou grandes
computadores que ocupavam enormes espaços. Na verdade, esses computadores existem até hoje e
continuarão a existir em função de demandas específicas de segurança, volume de dados etc. Era
uma época em que a atividade de programação – hoje mais conhecida pelos verbos “desenvolver”
ou “codar” – era realizado por poucos profissionais especialistas. Tratava-se de um momento quase
que artesanal de programação, que representou o alicerce para tudo que viria depois, mas que
também apresentava as suas deficiências.

Figura 2 – Evolução do desenvolvimento de software

Fonte: elaborado pelo autor.

Com a proliferação dos desktops, laptops e com a própria evolução do poder de

processamento e da internet, o desenvolvimento de software sofreu um boom, até pela necessidade
de automação dos negócios. Ocorre que esse notável crescimento não necessariamente veio
acompanhado da qualidade. São diversos os relatórios de institutos como o Standish Group (Figura
3) que relatam problemas relativos à falha total ou parcial do produto desenvolvido.

10
 Figura 3 – Chaos Report

resolução moderna para todos os projetos

2011 2012 2013 2014 2015

bem-sucedido 29% 27% 31% 28% 29%

desafiador 49% 56% 50% 55% 52%

falho 22% 17% 19% 17% 19%

*The Modern Resolution (OnTime, OnBudget, with a satisfactory result) of all software projects from FY2011-2015 within the new
CHAOS database. Please note that the rest of this report CHAOS Resolution will refer to the Modern Resolution definition not the
Traditional Resolution definition.

Fonte: HASTIE, Shane; WOJEWODA, Stéphane. Standish Group 2015 Chaos Report: Q&A with Jennifer Lynch. InfoQ, 4 de
outubro de 2015. Disponível em: <https://www.infoq.com/articles/standish-chaos-2015>.

Nesse contexto, era preciso “moralizar” o processo de desenvolvimento de software visando

agregar maior valor. Para tanto, foram criados processos de engenharia de software mais prescritivos,
tais como o Rational Unifed Process (RUP) e modelos de maturidade que auxiliavam e serviam de
referência para os desenvolvedores e as suas organizações. O exemplo mais famoso talvez seja o
Capability Maturity Model (CMM), criado na década de 1980.
Em paralelo, era preciso dar certa flexibilidade aos desenvolvedores para que o processo não
sobrepujasse o produto em si. Foi assim que na década de 1990 surgiam metodologias tais como:
 Rapid Application Development (RAD) – que prometia uma entrega rápida, de forma
iterativa e incremental;
 Dynamic System Development Model (DSDM) – framework de abordagem
iterativa e incremental de desenvolvimento de sistemas;
 Feature Driven Development (FDD) – metodologia que une práticas de outros métodos,
com foco nas funcionalidades almejadas, e
 Extreme Programming (XP) – trabalhando com equipes pequenas, considerando
requisitos em constante mutação, com foco em feedback constante e entrega incremental.

Essas e outras metodologias – inclusive, o Scrum em 1993 – surgiram como tentativa de

resposta aos desafios de um ambiente de transformação incessante, em que os usuários nem sempre
sabem o que querem e, quando sabem, mudam de opinião com frequência. Era também um esforço
de tentar balancear uma entrega de qualidade com mais velocidade e assertividade.

11
 Em fevereiro de 2001, um marco muito importante para o desenvolvimento de software e,
consequentemente, para as metodologias ágeis como um todo, foi instaurado: 17 expoentes da área
se reuniram em um resort de esqui em Utah e desenvolveram o que ficou conhecido com Manifesto
Ágil (BECK et al., 2001).

Figura 4 – Autores do Manifesto Ágil

Fonte: McGAW; Daniel. Pouring gas on the fire with agile marketing. SlideShare, 12 de maio de 2014. Disponível em:
<https://www.slideshare.net/danmcgaw/agile-marketing-34576267>.

Desde então, os valores introduzidos pelo Manifesto Ágil servem como base para toda uma
comunidade que visa à agilidade nos seus processos de desenvolvimento de software. De fato, como
veremos mais à frente, hoje em dia, esses valores não se aplicam apenas ao segmento de tecnologia
da informação (TI), mas a diversos outros segmentos de mercado. Os valores propostos pelo
manifesto podem ser vistos na Figura 5, a seguir:

Figura 5 – Valores do Manifesto Ágil

Fonte: elaborado pelo autor.

12
 Em outras palavras, mesmo havendo valor nos itens à direita, a orientação seria de valorizar
mais os itens à esquerda. Nota-se uma quebra de paradigmas muito grande em cada ponto exibido
pelo manifesto quanto à valorização das pessoas, ao produto efetivamente utilizável, à busca pela
colaboração e à adaptação. Todos esses pontos estão devidamente presentes na práxis de Scrum.
O manifesto também definiu 12 princípios derivados dos valores:
1. A prioridade é satisfazer ao cliente por meio da entrega contínua e adiantada de software
com valor agregado.
2. Mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento.
Processos ágeis tiram vantagem das mudanças visando à vantagem competitiva para o cliente.
3. Entregar frequentemente software funcionando, de poucas semanas a poucos meses, com
preferência à menor escala de tempo.
4. Pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por
todo o projeto.
5. Construa projetos em torno de indivíduos motivados. Dê a eles o ambiente e o suporte
necessário e confie neles para fazer o trabalho.
6. O método mais eficiente e eficaz de transmitir informações para e entre uma equipe de
desenvolvimento é por meio de conversa face a face.
7. Software funcionando é a medida primária de progresso.
8. Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, os
desenvolvedores e os usuários devem ser capazes de manter um ritmo constante
indefinidamente.
9. Contínua atenção à excelência técnica e ao bom design aumenta a agilidade.
10. Simplicidade: a arte de maximizar a quantidade de trabalho não realizado é essencial.
11. As melhores arquiteturas, os melhores requisitos e os melhores designs emergem de
equipes auto-organizáveis.
12. Em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz, então refina e
ajusta o seu comportamento de acordo.

Origem do Scrum
O efeito do Manifesto Ágil foi e continua sendo extraordinário. A partir do seu conjunto de
valores e princípios, diversas práticas ágeis passaram a ser desenvolvidas e compiladas, promovendo
e acelerando a entrada da agilidade nas organizações, incluindo a expansão do Scrum.

13
 Figura 6 – Práticas ágeis

Fonte: elaborado pelo autor.

Ainda que os autores do Scrum tenham participado como signatários do Manifesto Ágil, a
criação do framework ocorreu ainda na década de 1990. Os seus criadores, Jeff Sutherland e Ken
Schwaber, sugerem que a sua inspiração foi o artigo “The new product development game: stop
running the relay race and take up rugby”, escrito pelos professores japoneses Takeushi e Nonaka e
publicado em 1986. A analogia utilizada no artigo faz alusão à forma como os times de
desenvolvimento de produtos realizavam a sua operação em diversos tipos de segmento, como uma
equipe no jogo de rugby. A palavra “Scrum” aparece no artigo, ainda que de forma tímida, apenas
uma vez. Posteriormente, a mesma metáfora seria utilizada por Degrace e Stahl (1990), ainda que não
da forma estruturada que Sutherland e Schwaber apresentaram em 1993 quando lançaram o
framework.

Figura 1 – Scrum: reinício de jogada no jogo de Rugby

Fazemos referência ao Scrum como um framework – e não como uma metodologia – porque
a ideia por trás dele não é indicar o que fazer, mas, sim, deixar o seu praticante à vontade para
implementá-lo dentro das particularidades e das possibilidades do seu ambiente. Mais ainda, em
um framework também é possível abarcar diferentes práticas ou mesmo métodos, na medida da
necessidade e da maturidade da organização. Inclusive, os próprios autores comentam no Guia

14
Scrum (2020, p. 4) que “o framework é propositalmente incompleto, apenas definindo as partes
necessárias para implementar a teoria do Scrum”.
Outro ponto extremamente relevante diz respeito à origem do Scrum e, até certo ponto, de todo
o arcabouço da mentalidade ágil, que tem origens no empirismo e no pensamento Lean. O significado
do Lean envolve a mudança pela qual as organizações criam valor para os clientes, evidenciando questões
como: foco no cliente, busca obsessiva pela qualidade eliminação de desperdício e aprendizagem
contínua, entre outros (BALLÉ et al., 2019). A releitura e a incorporação desses princípios feitas pelos
métodos ágeis foram brilhantes e, ao mesmo tempo, cruciais para a sua aceitação e disseminação.
O Scrum trabalha com três pilares empíricos: transparência, inspeção e adaptação. A
transparência permite a inspeção. A inspeção sem transparência é enganosa e gera desperdício. A
transparência permite a inspeção, e a inspeção sem transparência é enganosa, podendo chegar ao
limite da patologia organizacional se não resolvida. A inspeção também favorece a adaptação, dado
que o Scrum é projetado para provocar mudanças. Na prática, o time Scrum se adapta à medida
que aprende algo novo na inspeção. É fato que a adaptação se torna mais difícil sem o
empoderamento do time, tópico que será discutido mais à frente neste curso.
Também é necessário mencionar que o Scrum trabalha com o seu próprio conjunto de
valores, muito relacionados à valorização das pessoas enquanto indivíduos e como time,
conforme a Figura 8, a seguir:

Figura 8 – Valores Scrum

15
 Fonte: Valores Scrum. ScrumAlliance. Disponível em: <https://www.Scrumalliance.org>.
O time, enquanto se compromete a atingir os seus objetivos, também subentende que os seus
membros devem colaborar uns com os outros. O respeito pessoal e o profissional, além da coragem
para experimentar e enfrentar desafios, também são disseminados. Os membros do time aprendem,
exploram e abraçam esses valores à medida que trabalham com Scrum.
Do ponto de vista de promoção das práticas do Scrum, ainda que existam diversas instituições
que promovam o Scrum internacionalmente, incluindo processos de filiação, treinamento e
certificação, 1 as principais são:

Quadro 1 – Principais instituições promotoras do Scrum

Disponível em:
<https://www.Scrumalliance.org>.

1
O processo de certificação é particular de cada instituição e não faz parte da missão didática deste material. Entretanto é
possível obter facilmente informações sobre as trilhas de certificações nos respectivos sites das instituições.

16
 Disponível em:
<https://www.Scrum.org>.

Tipologia de ciclos de vida

Normalmente, nós nos referimos ao Scrum como um framework iterativo e incremental para
o desenvolvimento de produtos, mas poderíamos descrevê-lo como um framework ágil também.
Para entender melhor essa afirmação, é preciso levar em consideração alguns tipos de ciclo de vida
de projetos, conforme a Figura 9, a seguir:

17
 Figura 9 – Tipos de ciclo de vida de projetos

preditivo = A B C D E

iterativo = A B C D E A B C D E A B C D E

Não tentar fazer tudo mudança mudança

certo desde o começo.

incremental = A B C D E A B C D E

Não tentar construir

tudo de uma vez.

adaptativo =
iterativo
+
incremental
A B C D E A B C D E A B C D E

Fonte: elaborado pelo autor.

O primeiro deles é um dos ciclo de vida mais utilizado no mercado de maneira geral. Trata-
se de um ciclo preditivo, que tem por característica a tentativa de fazer um detalhado planejamento
do que será feito, como será feito, com as devidas estimativas e análises, visando a uma entrega única
ao final do projeto. Nesse tipo de ciclo, o escopo precisa ser conhecido e detalhado previamente,
para que as entregas possam ser estabelecidas também com antecedência.
Entretanto, caso sejam necessárias alterações de escopo, todo um processo de gestão de
mudanças precisa estar implantado, de forma a evitar problemas posteriores de discordância ou até de
não aceitação das entregas. É muito comum nos referirmos a ciclos preditivos como “cascata” –
waterfall –, com forma de gerenciamento em fases sequenciais, planejamento detalhado e escopo fixo.
O ciclo iterativo já acomoda mudanças de outra maneira: o seu progresso depende de
contínuas e progressivas iterações visando ao refinamento do que será desenvolvido. Nessa lógica,
o próprio feedback do usuário do produto serve de insumo para a próxima iteração, e assim
sucessivamente, promovendo mudanças na medida da necessidade. Já o ciclo incremental incorpora
a ideia da entrega em etapas, na qual cada incremento adiciona uma funcionalidade e representa
um pedaço do produto final. Uma diferença em relação ao iterativo é que o incremento não é
necessariamente será objeto de refinamento futuro.

18
 O ciclo adaptativo é aquele que promove a junção dos ciclos iterativos e incrementais. Ao
mesmo tempo em que o produto vai sendo entregue em partes, também vai sendo refinado em
função do feedback dos usuários. Na prática, poderíamos usar o termo “ágil” para representar o
ciclo adaptativo, na medida em que integra as características dos dois ciclos anteriormente vistos.
Curiosamente, o mercado produziu um embate dicotômico entre os dois extremos
representados pelos ciclos preditivo e adaptativo. É como se os gerentes de projeto tradicionais
considerassem que a agilidade se refere apenas a um episódio passageiro, e como se os chamados
“agilistas” entendessem que a gestão de projetos tradicional está fadada a sumir, dadas as
vantagens dos métodos ágeis.
O observador mais atento vai ter a chance de concluir que os diferentes tipos de abordagem
têm, cada qual, a sua aplicação em função do momento, do contexto e da necessidade do ambiente
em que está sendo empregada. Da mesma forma que não se usa uma colher para cortar uma carne,
também não se utiliza um garfo para tomar uma sopa. Em outras palavras, métodos mais
preditivos continuarão a ser utilizados em projetos que demandem um maior grau de
planejamento e previsibilidade, assim como métodos adaptativos se adequam mais a projetos que
exijam mais adequação. Sem falar em alguns métodos que cogitam a utilização de práticas
híbridas, dependendo da situação.
Se ponderarmos quanto à reflexão acima, veremos que alguns pontos podem ser analisados
no momento de escolha entre uma abordagem preditiva ou adaptativa. Entre eles:
 nível de incerteza associado ao escopo do projeto;
 grau de domínio da tecnologia envolvida;
 formato da gestão de mudanças;
 volume da participação dos stakeholders no desenvolvimento do projeto;
 tipo de contrato associado ao projeto – preço fixo, time-material;
 tamanho, maturidade e localização da equipe;
 grau de documentação desejado e
 expectativa de entrega – única x incremental.

Conclusão
Neste primeiro módulo, revisamos a origem do fenômeno da agilidade, dando destaque para
o Manifesto Ágil como pedra fundamental do Movimento Ágil. Além disso, comentamos sobre o
nascedouro do framework Scrum e abordamos um tema muito importante para que se entenda o
contexto em que o Scrum se enquadra: a tipologia dos ciclos de vida de projetos.
No próximo módulo, veremos mais detalhadamente o framework Scrum em si, as suas
características, os seus eventos, os seus papéis e os seus artefatos.

19
MÓDULO II – FRAMEWORK SCRUM

O segundo módulo do curso apresenta a estrutura do Scrum, ou seja, como é o

funcionamento básico do framework e como ele ajuda a gerar produtos e serviços de maneira
iterativa e incremental. Além disso, explora o conceito de sprints, os papéis no Scrum, os seus
principais eventos, os seus artefatos e os respectivos compromissos.
As unidades do módulo estão divididas da seguinte forma:
 Unidade 2.1 – Papéis no Scrum;
 Unidade 2.2 – Eventos do Scrum;
 Unidade 2.3 – Artefatos e compromissos e
 Unidade 2.4 – Entendendo o framework Scrum.

Ao final do módulo, espera-se que você entenda a dinâmica do framework Scrum e as suas
principais características.

Papéis no Scrum
Time Scrum
O time Scrum é composto de um pequeno número de pessoas trabalhando em esquema
colaborativo e distribuído em três papéis complementares: product owner, Scrum master e
desenvolvedores.
 Figura 10 – Time Scrum

O time é responsável por todas as atividades relacionadas ao produto sendo elaborado e prima
por trabalhar em um ritmo sustentável, o que aprimora o foco e a consistência do próprio time. Em
última análise, o time Scrum é responsável pela criação de um incremento de valor a cada sprint,
conforme veremos mais à frente neste módulo.
Uma quebra de paradigma significativa é que dentro desse time não existem hierarquias
ou mesmo subtimes. Trata-se de uma unidade harmônica que visa gerar valor para os clientes
a cada entrega.
O time é, tipicamente, multifuncional, objetivando que os seus membros possuam as
competências necessárias para o trabalho a ser realizado. Espera-se que seja também autogerenciável,
o que lhe confere autonomia outorgada pela organização para decidir internamente quem faz o quê,
como e quando.
Quanto ao número de pessoas envolvidas em um time Scrum, a recomendação dos seus
criadores é de que a equipe não ultrapasse 10 pessoas. Em outras palavras, seria composto de 10 ou
menos pessoas (SUTHERLAND; SCHWABER, 2020). A razão por trás dessa sugestão é que times
menores se comunicam melhor e tendem a ser mais produtivos. Fato esse que levou à popularmente
conhecida “regra das duas pizzas”, em que nenhuma equipe deveria ser maior do que duas pizzas
poderiam alimentar. De fato, a possibilidade de entropia é menor em times com menos
componentes. Essa regra é baseada no número de canais de comunicação que crescem
geometricamente, não linearmente (ABILLA, 2006), conforma a fórmula n* (n-1) / 2, na qual “n”
é igual ao número de pessoas envolvidas no processo.

Figura 11 – Canais de comunicação de uma equipe

Fonte: adaptado de Lalsing (2012)

21
 Caso o time Scrum fique muito grande, a recomendação é que sejam subdivididos em outros
times Scrum, compartilhando a mesma meta do produto, product backlog e product owner.
O time pode criar também uma espécie de acordo de trabalho que seja coerente e interessante
para o seu funcionamento. Os acordos são uma maneira objetiva e poderosa de criar diretrizes
explícitas sobre a cultura de trabalho a ser implantada. Em geral, o acordo é composto de um
pequeno conjunto de diretrizes criadas pelo time Scrum para o próprio time, estabelecendo as
expectativas que cada membro tem em relação ao outro. Não existe uma relação única de normas
para o acordo, podendo incluir: horas acordadas de trabalho; definição do calendário; tópicos a
serem revisados na reunião diária; uso de celulares durante as cerimônias; definição de feito (DoD);
como limitar o trabalho em progresso (WIP), entre outras possíveis considerações, dependendo do
contexto da equipe.

T-Shaped e I-Shaped
Conforme mencionado, os times Scrum são teoricamente compostos de profissionais com
diferentes perfis técnicos agrupados. No gerenciamento de projetos tradicional, essa equipe é escolhida
pelo gerente de projeto ou alcançada por meio do melhor esforço em uma disputa entre as várias áreas
funcionais da organização. Nesse modelo tradicional, as tarefas são atribuídas a cada um no
organograma pelo próprio gerente e seguidas no padrão comando e controle. Por outro lado, em uma
abordagem ágil como o Scrum, busca-se explorar o conceito de auto-organização e autogestão. Em
outras palavras, o Scrum sugere que a equipe deve organizar-se para planejar, estimar e distribuir
funções, com eventual liderança surgindo da necessidade específica de cada iteração.
Nesse sentido, algumas pessoas têm um profundo conhecimento sobre um tópico específico,
mas também versatilidade para colaborar em outras áreas do projeto. Se considerarmos o trabalho em
andamento, isso pode ser uma grande vantagem no tempo de espera para as atividades do projeto.
Essas são as pessoas em forma de T (T-shaped), com profundidade em um domínio específico,
habilidades menos desenvolvidas em áreas associadas, mas boas habilidades de colaboração.
Outro exemplo é o “pente quebrado” (broken comb), ou pessoas com vários níveis de
especialização em muitas habilidades diferentes. Esse é um recurso extremamente importante para
equipes multidisciplinares devido às inúmeras necessidades e demandas que essa equipe pode ter a
cada iteração ou lançamento de produto. Afinal, compartilhar problemas e soluções de forma
honesta e transparente é uma das prerrogativas do Scrum.
Por outro lado, em times de projeto também existem pessoas conhecidas como I-shaped,
que possuem um nível de conhecimento profundo em uma determinada área, mas
completamente incapazes de colaborar fora do seu domínio de conhecimento. Em outras palavras,
apesar da sua grande profundidade e eventualmente do seu alto rendimento individual, a sua
largura operacional fica reduzida.

22
 De modo geral, para equipes multifuncionais, pessoas T-shaped ou broken comb são
geralmente mais úteis por causa da sua complementaridade e do seu perfil “generalista técnico”,
que incentiva o compartilhamento de responsabilidade, mas as equipes não são formadas apenas
levando em consideração o perfil técnico de cada componente. As pessoas são diferentes nos seus
estilos, gostos, trajes, desejos, perfis e também em questões comportamentais.
Desse modo, existe um componente intrínseco à equipe que pode facilitar a sua composição e
o seu desenvolvimento ou, simplesmente dificultar muito, se não inviabilizar o autogerenciamento: a
maturidade da equipe. Equipes de baixa maturidade podem misturar aspectos do laissez-faire e
demonstrar até certa carência do estilo de comando e controle. Claro que, ao formar a equipe, esse
detalhe pode parecer menos significativo, mas assim que o time começa o desenvolvimento do
produto de fato, as diferenças tendem a se tornar mais evidentes. Eventualmente, essas equipes podem
nunca atingir a alta performance na sua plenitude.

Product owner
O product owner (PO) é responsável por maximizar o valor do produto resultante do
trabalho do time Scrum. Trata-se de uma pessoa exclusiva, e não um comitê, e o seu trabalho inclui:
 gerenciar a lista de requisitos (product backlog);
 ordenar os itens do product backlog;
 ser fonte de informações sobre as prioridades do projeto;
 desenvolver e comunicar explicitamente a meta do produto;
 garantir que o product backlog seja transparente, visível e compreensível;
 gerenciar frequente e continuamente os diversos stakeholders para garantir visibilidade a todos;
 maximizar o valor do trabalho realizado (ROI) e
 assegurar a qualidade da entrega do produto.

Figura 12 – Product owner

23
 Segundo os criadores do Scrum, o PO pode realizar ele mesmo o trabalho listado acima ou
delegar a responsabilidade a outros, mas sempre mantendo a responsabilidade. É de fundamental
importância que a organização reconheça a sua função e as suas decisões, dado que as necessidades
dos stakeholders estarão representadas por meio de um backlog gerenciado pelo PO. Qualquer
pessoa que deseje alterar o product backlog deverá fazê-lo por meio do PO.

Scrum master
O Scrum master (SM) é o responsável pela eficácia do time Scrum, melhorando as suas
práticas dentro do framework.

Figura 13 – Scrum master

É incumbido também de suportar a equipe no uso do Scrum, tanto em relação à teoria quanto
em relação à prática. O seu trabalho inclui:
 garantir a adesão do time aos valores, às práticas e às regras do Scrum;
 remover barreiras e impedimentos que atrapalhem o progresso do time;
 ajudar e educar a organização a adotar o framework Scrum;
 facilitar cerimônias Scrum na medida da necessidade;
 treinar os membros do time em autogerenciamento e cross-funcionalidade;
 ajudar o time a se concentrar na criação de incrementos de alto valor que atendam à
definição de feito (item que veremos mais à frente);
 ajudar os stakeholders a compreender e aplicar uma abordagem empírica para trabalhos
complexos;
 garantir que todos os eventos Scrum ocorram e sejam positivos, produtivos e mantidos
dentro do timebox;
 ajudar o time Scrum a entender a necessidade de itens do product backlog claros e
concisos;
 ajudar a estabelecer o planejamento empírico do produto para um ambiente complexo e

24
  facilitar a colaboração com os stakeholder, conforme solicitado ou necessário.
Desenvolvedores
Os desenvolvedores – developers – são pessoas do time Scrum responsáveis por criar qualquer
aspecto de um incremento utilizável a cada sprint. Como dito anteriormente, as habilidades
específicas necessárias a cada equipe variam de acordo com a maturidade, mas também com o tipo
de organização, o segmento e o grau de especialização, entre outras considerações. Todavia os
desenvolvedores normalmente são responsáveis por:
 criar um plano para o sprint (sprint backlog);
 adaptar o seu plano a cada dia em direção à meta do sprint;
 introduzir gradualmente qualidade aderindo a uma definição de feito (DoD) e
 responsabilizar-se mutuamente como profissionais.

Figura 14 – Desenvolvedores

Ressalta-se que não há títulos no time, no sentido de que todos fazem parte de um mesmo e
congruente grupo de pessoas. O Scrum prega a transparência de informações na qual as pessoas são
alocadas de forma adjacente uma das outras, de forma que a comunicação passa a ocorrer de maneira
mais fluida e “osmótica” (COCKBURN, 2006). Obviamente, essa autonomia deve estar alinhada
com os objetivos estratégicos da empresa, e o sistema de incentivos também deve ser modificado
para acomodar realizações do time, e não individuais, como de costume (BARCAUI, 2020).
Devemos enfatizar também que, apesar da designação “desenvolvedores” poder insuflar uma
conotação relativa a projetos de software apenas, nada estaria mais longe da verdade. Pode-se
constatar o trabalho de desenvolvedores em qualquer tipo de produto ou serviços sendo
empreendido, independentemente da sua natureza. Como dito pelos seus próprios criadores, o uso
da palavra foi feito não para excluir, mas para simplificar (SUTHERLAND; SCHWABER, 2020).

25
Eventos do Scrum
Os eventos no Scrum são oportunidades inestimáveis de inspeção e adaptação dos seus
artefatos, além de exemplos de transparência. A sua utilização visa determinar certo ritmo regular
de trabalho, minimizando o uso de qualquer outro tipo de reunião não previsto no framework.
Sugere-se ainda que os eventos, se possível, sejam realizados no mesmo local com fins de
padronização e redução da complexidade. De preferência, os eventos devem ser facilitados de tal
forma a serem produtivos, envolventes e agradáveis.

Sprints
O coração do Scrum são as chamadas sprints, que funcionam como base para todas as
cerimônias do Scrum. Na prática, a sprint nada mais é do que uma iteração ou um período de
tempo fixo – timebox – que, por via de regra, tem duração de uma a quatro semanas, como se fosse
um miniprojeto. Uma nova sprint sempre se inicia após a conclusão da sprint anterior. Outras
metodologias ágeis já trabalhavam com o conceito de timeboxes, mas os criadores do Scrum
resolveram chamá-la de sprint, em função da sua percepção de que o termo evoca uma qualidade
de intensidade (SUTHERLAND, 2014).
Todo trabalho necessário para o atingimento da meta do produto ocorre dentro das sprints.
Em tese, não é permitida nenhuma mudança durante a sprint que possa colocar em risco a sua meta.
Além disso, está previsto o refinamento do product backlog, e a perspectiva é de que não se perca de
vista a qualidade. O escopo do que está sendo desenvolvido pode sempre ser esclarecido e renegociado
com o PO, conforme as sprints vão passando, e o aprendizado da equipe vai enriquecendo.
O fato de durarem um mês ou menos permite certa previsibilidade em direção à meta do
produto, ao menos uma vez por mês. Parece pouco relevante, mas a questão do tempo fixo das
sprints é extremamente motivador do ponto de vista da equipe. Esse ponto é corroborado pela
teoria motivacional temporal (STEEL; KONIG, 2006), que explica o quanto os prazos impactam
a alocação dinâmica de atenção.
Tendo isso em vista, os POs têm uma tendência a preferirem sprints mais curtas, de uma
semana, que geram retornos e ciclos de aprendizagem mais rápidos. Além disso, reduzem o risco
relacionado ao esforço, à energia e ao custo do que está sendo desenvolvido a um período de
tempo menor, dado que, se houver um problema, a sua detecção é mais célere. Já o SM e os
desenvolvedores tendem a preferir sprints maiores, com mais tempo para trabalhar em direção
a meta. Na prática, o mercado tem trabalhado com a “média”, optando por duração de sprints
de duas e três semanas.
Existe apenas um caso em que uma sprint pode ser cancelada depois de iniciada. É quando a
sua meta se torna obsoleta. Somente o PO tem a autoridade necessária para tomar essa decisão.

26
 Cabe uma menção especial à chamada “sprint zero”, também chamada de pré-projeto. O
principal objetivo da sprint zero é criar um esqueleto do projeto. Nesse momento, a equipe ainda não
tem dados suficientes sobre tudo o que será desenvolvido, não conhece ainda a sua própria capacidade
de trabalho e, eventualmente, nem mesmo as idiossincrasias dos stakeholders do projeto. Ainda que
a ideia da sprint zero seja popular em equipes com menos experiência no uso do framework Scrum,
o conceito não faz parte framework Scrum e não caracteriza uma sprint verdadeiramente.

Sprint planning
O planejamento da sprint – sprint planning – define o trabalho que será realizado na sprint.
Trata-se uma reunião colaborativa no início de cada sprint em que todo time Scrum participa e na
qual o PO deve garantir que todos estão preparados para discutir os itens mais relevantes do product
backlog e como eles se relacionam com a meta do produto. Obviamente, se necessário, outros
especialistas além da equipe Scrum podem ser convidados também a participar.
O tempo de reunião é proporcional ao número de semanas da sprint multiplicado por dois.
Quer dizer, se temos uma sprint de três semanas, a recomendação é um sprint planning de seis
horas, e assim por diante. Durante a reunião, serão discutidos basicamente três tópicos:
 Por que a sprint é valiosa?
 O que pode ser feitio nessa sprint?
 Como o trabalho escolhido será realizado?

A partir da definição do PO de como o produto agrega valor na sprint, o time Scrum colabora
para a definição de uma meta da sprint, que simboliza a razão por trás do valor daquela sprint.
Efetivamente, os desenvolvedores selecionam os itens do product backlog que vão incluir na sprint
a ser realizada, sabendo que esses itens podem ser refinados durante o processo, gerando mais
segurança. O aprendizado adquirido a cada sprint é crucial para o progresso do trabalho, dado que
a cada sprint o time conhece mais sobre o produto e sobre si mesmo, o que, com o tempo, permite
o estabelecimento da capacidade e da velocidade da equipe.
A capacidade representa informações sobre quantas pessoas estarão disponíveis em cada
sprint, por quanto tempo, o seu percentual de alocação etc. (alguém da equipe pode não estar
alocado full-time, entrar de férias durante o período do projeto, etc.). A velocidade está relacionada
ao histórico de quanto trabalho o time Scrum conseguiu realizar em sprints anteriores.
Uma última entrada para a reunião de planejamento da sprint é o resultado da reunião de
retrospectiva anterior. Falaremos da reunião de retrospectiva mais à frente ainda neste módulo, mas
se trata de uma entrada que não deve ser desprezada, na medida em que traz perspectivas de
melhoria em relação à reunião anterior.

27
 Cada item do backlog representa uma história de usuário, como veremos mais adiante no
próximo módulo. As histórias são quebradas em tarefas executáveis, e o grau de esforço de cada história
é estimado pelo time. É importante ratificar que o time de desenvolvedores tem total autonomia para
decidir como prefere decompor os itens do product backlog visando criar um incremento que atenda à
definição de feito (DoD). Se juntarmos a meta da sprint, os itens selecionados do product backlog para
sprint e o plano para entregá-los, temos o que chamamos de sprint backlog.

Daily Scrum
A reunião diária – daily Scrum – é assim chamada porque promove uma reunião enxuta entre
os desenvolvedores, com duração de aproximadamente 15 minutos a cada dia da sprint. Esses
encontros são realizados todos os dias no mesmo local e horário, preferencialmente, em pé, de forma
a gerar certo desconforto, minimizando o risco de que se estenda. Esse procedimento assíduo e
continuado identifica impedimentos, faz fluir as comunicações e reduz a necessidade de outras
reuniões ao longo do dia.
Quanto ao seu funcionamento, até bem pouco tempo, era sugerido que cada membro da
equipe comentasse a respeito de três perguntas básicas: o que completou desde a última reunião
diária? O que vai fazer antes da próxima reunião diária? Quais são os possíveis obstáculos a serem
enfrentados? Hoje em dia, esse formato é opcional, na medida em que os desenvolvedores têm toda
a liberdade para selecionar qualquer estrutura que mais lhes pareça interessante para a cerimônia de
daily Scrum, desde que se concentrem no progresso em direção à meta da sprint. Esse movimento
gera foco e melhora o autogerenciamento.

Figura 15 – Exemplo de produto de daily meeting

28
 Gráficos de burndown e burnup podem ser atualizados, conforme veremos mais à frente na
unidade 3. Esse movimento é importante para que os desenvolvedores possam ajustar o seu plano
de ação. Obviamente, a daily não é o único momento em que isso pode ser feito, uma vez que os
membros do time se encontram ao longo do dia para discussões particulares e mais pormenorizadas
sobre adaptação ou replanejamento da sprint.

Sprint review
A reunião de revisão da sprint – sprint review – serve para inspecionar o resultado da sprint,
demonstrando o resultado aos stakeholders, além de discutir o progresso em relação à meta do
produto. O product backlog também pode sofrer ajustes visando atender novas oportunidades. Trata-
se de uma sessão de trabalho, que leva aproximadamente uma hora para cada semana de sprint.
Apesar de, tipicamente, ser nessa reunião que o time de desenvolvedores demonstra o
incremento e responde a perguntas dos stakeholders, nada impede que ao longo da sprint, o PO ou
outros stakeholders tenham contato com as histórias sendo desenvolvidas, no que convencionou-se
denominar de just-in-time reviews.

Sprint retrospective
A retrospectiva da sprint – sprint retrospective –, como o nome sugere, é uma reunião que
visa ao aperfeiçoamento da qualidade e da eficácia do trabalho sendo desenvolvido a cada sprint,
constituindo evento-chave para melhoria contínua de todo o processo. Assim como a reunião de
revisão, a retrospectiva tem duração aproximada de uma hora para cada semana de sprint. O time
Scrum inspeciona como foi a última sprint em relação aos processos e às ferramentas utilizados,
mas também em relação a cada indivíduo e às suas interações.
São discutidas lições aprendidas em relação ao que deu certo durante a sprint, o que deu
errado – evidenciando oportunidades de melhoria – e eventuais surpresas. As reparações ou os
melhoramentos mais impactantes devem ser tratados com maior celeridade, podendo ser incluídos
até mesmo no sprint backlog da próxima sprint. A retrospectiva finaliza cada sprint, sendo o último
evento realizado pela equipe.

29
 Figura 16 – Exemplo de produto de reunião de retrospective

Como se trata de uma cerimônia interna do time que, usualmente, debate temas
potencialmente melindrosos, é interessante que o ambiente esteja preparado para esse tipo de
reunião. Essa disposição normalmente é realizada pelo SM, visando à coleta de dados e à tomada
de decisão sobre o que modificar para a próxima sprint.
Existem diversas alternativas de dinâmicas disponíveis para as retrospectivas, inclusive com
algumas incluindo aspectos lúdicos, visando tornar o evento algo o mais agradável possível. De
modo algum esse material esgota essas opções, mas, apenas a título ilustrativo, selecionamos duas
delas: five whys e smiley faces.
 Cinco porquês (five whys) – pode ser utilizada para a identificação de impedimentos, mas
é mais comumente usada para a análise da causa raiz de um problema. É promovida uma
discussão com os membros do time para analisar o problema e identificar a sua causa raiz,
perguntando até cinco vezes “por quê?” para superar o pensamento habitual. É imperioso
distinguir as causas dos sintomas e prestar atenção à lógica da relação de causa e efeito para
identificar a causa raiz.

30
 Figura 17 – Exemplo de dinâmica do five whys

 Smiley faces – a dinâmica opera verificando o que foi que deixou a equipe nervosa, triste
e alegre. É possível trabalhar até mesmo com escalas para cada nível de emoji utilizado.

Figura 18 – Exemplo de dinâmica smiley faces

31
Artefatos e compromissos
Os artefatos no Scrum são utilizados para representar trabalho ou valor, sempre visando à
transparência, de forma que todos que os inspecionem tenham a mesma base para a adaptação.
Cada artefato possui um compromisso associado, objetivando reforçar o empirismo e os valores
Scrum para todos os stakeholders. Os compromissos por artefato são:
 product backlog – meta do produto;
 sprint backlog – meta da sprint e
 incremento – definição de feito (DoD).

Product backlog
O product backlog (PB) é uma lista ordenada de funcionalidades associadas ao produto.
Trata-se da fonte única de trabalho a ser realizado pelo time Scrum. Fisicamente, essa lista pode
estar em um arquivo Excel (.xls), em post-its ou em qualquer outro formato que seja mais prático
ao time.
A priorização dos seus itens é feita pelo PO junto aos stakeholders, levando em consideração
o valor que cada funcionalidade agrega, o custo e o risco associados. Os itens do PB que podem ser
realizados pelo time em uma sprint são selecionados para o evento de sprint planning.
Os atributos de cada item do PB podem variar de acordo com o domínio de trabalho, mas
geralmente incluem: descrição, ordem e tamanho. Os desenvolvedores são responsáveis pelo
dimensionamento, mas o PO pode influenciá-los ajudando-os a entender a demanda. A
responsabilidade por atualizar, priorizar e dar visibilidade do PB é do PO.
É importante notar a característica dinâmica e, eventualmente, incompleta que o PB possui,
uma vez que a demanda e os desejos dos stakeholders podem mudar ao longo do tempo. Diante disso,
espera-se que um trabalho de refinamento – grooming – contínuo seja efetuado, visando quebrar e
incluir definição adicional aos itens do PB para que se tenham itens menores e mais precisos.
O refinamento tem como propósito promover uma “limpeza” ou “arrumar a casa”,
aprimorando o PB a cada sprint, conforme o necessário. Normalmente, é realizado próximo ao final
da sprint, garantindo um backlog apurado para a próxima iteração. Itens podem ser: incluídos,
excluídos ou alterados no PB, dependendo da escolha feita pelo PO. Ainda que a priorização possa
ser feita segundo diversos critérios, normalmente os itens de maior valor e maior risco aparecem na
frente, seguidos daqueles de maior valor e menor risco, depois os de menor valor e menor risco e,
por último, os de menor valor e maior risco (Figura 19).

32
 Figura 19 – Priorização do PB

Uma das técnicas utilizadas para a priorização de demandas é conhecida pelo acrônimo
MoSCoW (AGILE BUSINESS CONSORTIUM, 2017), introduzida pela metodologia Dynamic
Systems Development Method (DSDM). Com esse prisma, para cada requisito do backlog, deve-
se atribuir uma das quatro letras M, S, C ou W, cada uma com um significado distinto.

Figura 20 – Técnica MoSCoW de priorização

Aqueles itens do backlog que forem “must-have” são considerados como vitais ou críticos para a
geração de valor ou representam algum tipo de norma obrigatória que precisa ser implementada de
forma imperiosa. Os itens listados como “should-have” também são importantes, mas não
fundamentais para entrega naquele momento. Já os listados como “could-have” são desejáveis, mas não
necessários.
Em outras palavras, itens que podem ser desenvolvidos quando mais recursos estiverem
disponíveis. Por último, aqueles itens listados como “won’t-have”, por vezes denominados também

33
“would-like”, têm o consentimento dos stakeholders que são itens de menor importância ou que
podem esperar para serem executados.
O compromisso do PB é a meta do produto. Um objetivo de longo prazo que descreve o
estado futuro do que será desenvolvido e serve como alvo para o time Scrum se planejar. Tem um
limite claro e stakeholders bem definidos, lembrando que um produto ou um serviço é um meio
para entrega de valor.

Sprint backlog
O sprint backlog (SB) é composto da meta da sprint (por que), mais o conjunto de itens que
foram selecionados para aquela sprint (o que) na sprint planning e um plano de ação para a entrega
do incremento (como). Na prática, trata-se de um plano preparado pelos desenvolvedores dando
visibilidade sobre o que eles pretendem realizar durante a sprint para o atingimento da meta da
sprint. O SB deve possuir detalhes suficientes para permitir a inspeção do seu progresso durante a
daily Scrum e pode ser atualizado ao longo da sprint, conforme o aprendizado adquirido pela
equipe, criando, alterando ou eliminando tarefas.
A meta é o objetivo final da sprint. Traduz-se em um compromisso dos desenvolvedores
que visa dar coerência, foco e motivação ao trabalho. Além disso, cria uma espécie de amálgama
entre os desenvolvedores, facilitando a comunicação, a colaboração e a visão quanto ao que se
almeja ao final da sprint. A meta é criada durante a cerimônia de sprint planning e depois
adicionada ao SB, que, da mesma forma que o PB, também pode assumir o formato de um
arquivo Excel ou um post-it, entre outros.

Incremento
Cada incremento representa um passo a mais em direção à meta do produto, uma vez que
é adicionado aos incrementos anteriores e verificado para garantir que todos funcionem de
maneira harmoniosa juntos. Os desenvolvedores podem criar mais de um incremento em uma
mesma sprint. Nunca é demais lembrar que o incremento deve ser utilizável a fim de gerar valor.
A apresentação de um ou mais incrementos produzidos é feita na sprint review, mas não se resume
somente a esse evento. Em outras palavras, não há problema algum em fazer a entrega de um
incremento antes do final da sprint.
Um incremento nasce no momento em que um item do PB atende à definição de feito, que
representa o compromisso do incremento. A definição de feito – Definition of Done (DoD) – cria
transparência ao esclarecer a todos os stakeholders um entendimento comum de qual trabalho foi
concluído como parte do incremento. Se um item do PB não atende à DoD, não poderá ser
apresentado na sprint review, voltando ao PB para ser repriorizado.

34
 A DoD é a mesma para todo e qualquer item do PB e, via de regra, é criada antes de iniciar
o desenvolvimento do produto, antes mesmo da primeira sprint. Caso seja necessário rever a DoD,
o evento mais adequado é a retrospectiva. Se a DoD para um incremento faz parte dos padrões e
das normas da organização, o time Scrum deve, minimamente, segui-las. Se esse padrão não existir,
o próprio time Scrum deve criar uma DoD adequada ao produto a ser desenvolvido.
Apenas a título de informação, o mercado trabalha também com uma definição de pronto –
Definition of Ready (DoR) – que simboliza uma lista de requisitos de que determinado item do PB
necessita para estar apto a entrar no SB. O item só será movido do PB para o SB se esse check list estiver
todo atendido, caso contrário, o item ainda não é considerado preparado para entrar em produção.

Entendendo o framework Scrum

Uma vez que aprendemos um sobre os papéis, os eventos, os artefatos e os compromissos do
Scrum, é importante compreender como tudo isso funciona de maneira conjunta. Em outros
termos, como opera o framework Scrum na prática.

Figura 21 – Funcionamento do framework Scrum

35
 O processo tem início à medida que o product owner interage com os diversos stakeholders
envolvidos no processo para entender a sua necessidade. É previsto que, muito possivelmente, ainda
não se tenha a concepção fechada do escopo nesse momento. É provável também que exista uma
ideia inicial ou um conjunto de requerimentos para o produto ou o serviço que se deseja produzir.
Como visto no primeiro módulo, em ciclos ágeis existe uma tendência ao refinamento do produto
durante a sua própria construção e de acordo com o feedback dos usuários. Em que pese essa
característica, é importante a constituição da meta de produto, promovendo uma visão mais clara
do que será desenvolvido a todo o time e descrevendo o estado futuro do produto.
Conforme o entendimento do PO a respeito do que os stakeholders almejam, são listados os
itens do product backlog – que no próximo módulo ganharão a alcunha de user stories – que
formam a visão inicial que se tem a respeito da meta do produto. Essa lista inicial de funcionalidades
pretendidas deve ser devidamente priorizada pelo PO junto aos stakeholders.
A partir do entendimento do product backlog, é agendada uma reunião de sprint planning
para a seleção dos itens que farão parte da primeira sprint. Efetivamente, essa lista de itens representa
o sprint backlog, que o time de desenvolvedores se compromete a produzir durante a sprint. O time
também determina a meta da sprint e faz as devidas quebras de itens de backlog em tarefas. Lembre-
se, porém, que o time de desenvolvedores decide como vai produzir as funcionalidades,
transformando-as em um incremento. O time também decide a duração das sprints para aquele
projeto, que pode ser de uma a quatro semanas.
Os desenvolvedores podem até mesmo criar histórias, além do PO, mas quem define a
prioridade é sempre o PO. Por outro lado, a estimativa de esforço de cada história não é feita pelo
PO, mas pelos desenvolvedores.
Estimativas serão tópico do nosso próximo módulo, mas é importante ressaltar que podem
ser feitas durante as reuniões de refinamento do backlog do produto, mas apenas se toda equipe de
desenvolvimento participar do refinamento do backlog. Se isso não for possível, o time deve reunir-
se uma vez por sprint para estimar novos trabalhos para os quais o PO possa precisar de uma
estimativa. Os itens a serem estimados são novos itens de backlog ou itens que foram divididos para
melhor ajuste. É possível fazer estimativas também durante a sprint planning, mas normalmente é
muito tarde para o PO ajustar prioridades com base nessas estimativas.
O desenvolvimento propriamente dito tem andamento, sempre com apoio do Scrum master
removendo impedimentos e tentando garantir um ambiente seguro, frutífero e com um mínimo de
interrupções para os desenvolvedores. Durante as sprints, é possível ver o trabalho colaborativo
fluindo, com frequente utilização de post-its e reuniões diárias de 15 minutos (daily Scrums). Ao
final da sprint, um incremento de produto deve ter sido produzido dentro dos parâmetros da
definição de feito (DoD) e apresentado aos stakeholders na reunião de revisão (sprint review).
Outro ponto relevante é que, antes de um novo sprint começar, o PO deve garantir que
product backlog tenha sido priorizado. No Scrum, não existe uma cerimônia oficial para esse fim,
mas, em geral, essa é uma atividade que o PO realiza após conversar com os stakeholders para

36
entender as suas necessidades e os seus desejos. A priorização deve acontecer o mais tarde possível
na sprint – algo em torno dos últimos dois dias da sprint – e antes da próxima. Como é esperada
uma proximidade do PO em relação aos stakeholders, o ato de priorizar deveria ser quase orgânico,
mas como situações e contextos podem mudar durante a sprint e como novos aprendizados podem
surgir com base na sprint atual, é importante o PO separar um tempo para essa atividade.
É oportuno ratificar que a sprint review não é a única hora possível para os desenvolvedores
se encontrarem com os stakeholders do projeto. Nada impede que o Scrum master ou mesmo os
desenvolvedores promovam esse encontro com os stakeholders durante uma sprint para analisar
uma funcionalidade sendo construída. Esse procedimento é inclusive desejável. O final da sprint
também constitui um momento importante para tratar do refinamento do product backlog para a
próxima sprint. Novos histórias podem ser necessárias, outras podem ter de ser excluídas,
modificadas ou decompostas. O product backlog está sempre sendo atualizado e tendo os seus itens
repriorizados de acordo com a necessidade dinâmica dos stakeholders.
A última cerimônia da sprint é a retrospectiva, que conta com a participação de todo time,
mas não mais dos stakeholders. Como visto anteriormente, trata-se de uma reunião interna que visa
ao aprimoramento da qualidade e da eficácia do trabalho sendo desenvolvido a cada sprint. Uma
vez com o feedback dos stakeholders e também com as lições internas aprendidas, parte-se para um
novo ciclo, que reinicia com o planejamento de uma nova sprint e a geração de um novo sprint
backlog, uma nova meta de sprint, e assim por diante.
Para que se tenha uma ideia visual de todos os eventos em uma típica sprint, desenhamos o mapa
da Figura 22, a seguir, considerando uma sprint de duas semanas. Obviamente, esse mapeamento de
eventos pode e deve ser customizado em função das necessidades específicas de cada equipe Scrum.

Figura 22 – Mapa de eventos em uma sprint de duas semanas

Fonte: adaptado de COHN, Mike. What happens and when during a sprint. Mountain Goat Software. Disponível em:
<https://www.mountaingoatsoftware.com/blog/what-happens-when-during-a-sprint>.

37
Conclusão
Neste segundo módulo, fizemos uma análise detalhada do Scrum em todas as suas principais
vertentes, incluindo a descrição dos papéis adotados, a mecânica das cerimônias e dos artefatos
utilizados, bem como dos respectivos compromissos. Além disso, fizemos uma revisão geral do
funcionamento do framework como um todo para facilitar o entendimento da sua estrutura e dos
seus procedimentos. No próximo módulo, vamos falar sobre as chamadas histórias de usuário e
sobre como fazer estimativas, além de explorar gráficos que facilitam o controle de projetos Scrum.

38
MÓDULO III – HISTÓRIAS E ESTIMATIVAS

Este módulo trata de um tópico muito importante não só no Scrum, mas em diversas outras
metodologias ágeis: as histórias de usuário, as suas estimativas e as formas de monitoramento.
Abordada técnicas de estimativas no Scrum, além de ferramentas de acompanhamento de projeto,
tais como: gráficos de burn-up e burn-down.
As unidades do módulo estão divididas da seguinte forma:
 Unidade 3.1 – Histórias de usuário;
 Unidade 3.2 – Estimativas e
 Unidade 3.3 – Gráficos de acompanhamento.

Ao final do módulo, você deverá ter aptidão para fazer uso de histórias de usuário; descrever
as funcionalidades esperadas de um produto, bem como as suas principais formas de estimativa; e
utilizar gráficos de acompanhamento do projeto.

Histórias de usuário
As histórias de usuário – user story – têm a sua origem no XP, com objetivo de descrever as
demandas dos clientes em um estilo de caso de uso – use case –, mas com menos detalhes e escrito
de maneira bem direta, informal e em linguagem natural, visando à conversa e à troca de ideias
durante as cerimônias Scrum. Normalmente, é escrita pelo PO e contém, basicamente, uma
descrição curta da necessidade dos stakeholders. Em outras palavras, representam os itens do
product backlog a serem desenvolvidos pela equipe Scrum.
 Um ponto importante é que a escrita da história de usuário é feita sob o ponto de vista de
quem precisa da necessidade, e não de quem está desenvolvendo. Na sua forma mais conhecida,
explica para quem, o que e por que a história está sendo criada (COHN, 2004). É dessa forma que
as equipes Scrum criam ou documentam requisitos. O mais comum é que a história de usuário
apareça na forma de um cartão, tanto no formato eletrônico, como na sua forma física, utilizando
post-its, opção preferida por muitos, pela facilidade de visualização.

Figura 23 – Formato da user story

Fonte: Cohn (2004)

Alguns exemplos podem ser vistos na Figura 24, a seguir:

Figura 24 – Exemplos de histórias de usuário

41
 Ainda que o modelo de Cohn (2004) seja o mais comum, existem diversas variações da sua
aplicação, tais como:
 Como um <papel/persona/perfil> e
 Quero/preciso/necessito de <meta/desejo>.

Seja qual for o formato escolhido, o mais habitual é que as histórias de usuário possuam os
chamados Três Cs (JEFFRIES, 2001). O primeiro “C” é relativo ao próprio cartão, que tangibiliza
a história e garante que esta seja sucinta e objetiva. O segundo “C” é de conversa, dado que a história
não é uma lei ou uma determinação, mas, sim, uma ferramenta que possibilita o diálogo e a tomada
de decisão da equipe Scrum. O terceiro e último “C” é de confirmação, ou seja, deve possuir
critérios e testes que estabeleçam como a funcionalidade deve comportar-se depois de entregue.

Figura 25 – Três Cs das User Stories

Fonte: Jeffries (2001)

Outra boa prática é perseguir o acrônimo Invest (WAKE, 2003), o qual determina que a
história de usuário deve ser:
 independente (independent) – ela não depende de outra, e outras não dependem dela,
pois podem ser implementadas em qualquer ordem;
 negociável (negotiable) – boas histórias capturam a essência, e não os detalhes de
funcionalidades, pois estes devem ser cocriados entre o cliente e os desenvolvedores;
 valiosa (valuable) – deve agregar valor ao cliente;
 estimável (estimable) – precisa ter o seu esforço estimado, mesmo que de forma relativa;

42
  pequena (small) – deve ser possível entregá-la à sprint, mas não tão pequena que não
agregue valor, e
 testável (testable) – deve ser passível de testes para validar requisitos funcionais e não
funcionais.

Como já mencionado anteriormente, os critérios de aceitação das histórias de usuário

funcionam como regras que visam garantir o seu correto comportamento após a implantação. O
seu atingimento simboliza a correta entrega da história e permite que esta seja testada. Uma história
de usuário pode ter quantos critérios de aceitação forem necessários. Melhor dizendo, o PO pode
utilizá-los para explicar aos desenvolvedores o que precisa estar feito para que a funcionalidade gere
valor, conforme o exemplo da Figura 26, a seguir:

Figura 26 – Exemplo de critério de aceitação para uma user story

Como potencial mentor da startup,

eu quero preencher um formulário para ser mentor,
para que eu possa ajudar os fundadores nos seus negócios

Critérios de aceitação:

 O formulário de aplicação não deve ter mais do que quatro caixas para serem preenchidas.
 As perguntas devem ter questões mandatórias.
 Todo tempo de aplicação não pode levar mais do que 10min.

Um ponto importante é que não devemos confundir critérios de aceitação com a definição
de feito (DoD). A DoD é um acordo definido pelo time Scrum aplicável a todas as histórias de
usuário, por exemplo, o código do sistema desenvolvido deve estar no ambiente de homologação.
Já os critérios de aceitação são particulares para cada história de usuário.
Em resumo, para que uma história seja considera entregue, ela tem de atender a todos os
critérios de aceitação próprios dela, mas os critérios especificados na DoD.
Uma última consideração que deve ser feita é relativa ao tamanho das histórias. Quando uma
história é considerada muito grande ou ainda se existe alguma incerteza em relação ao seu
detalhamento, temos o que denominamos de um épico. Em função do tamanho, provavelmente
essa história não estará completa em uma sprint e não será transformada diretamente em incremento
de produto. Dessa forma, deverá ser fatiada em histórias menores a fim de serem priorizadas e
estimadas, conforme explicado na próxima unidade deste módulo.

43
 Figura 27 – Diferentes níveis de user story

Da mesma forma, podemos entender também uma história de usuário como uma coleção de
tarefas a serem realizadas. As tarefas representam o meio pelo qual a equipe implementará a
funcionalidade em si, em um nível de granularidade maior. Em outras palavras, tarefas são
atividades que os desenvolvedores precisam realizar para entregar as histórias de usuário. Em que
pese que a realização de tarefas sugira uma sensação de progresso no trabalho, realizá-las de forma
aleatória consome esforço e gera custos, sem necessariamente incrementar o valor naquilo que está
sendo desenvolvido. É preciso não perder de vista que as tarefas por si só não têm valor, apenas as
histórias de usuários entregues representam valor.

Estimativas
Como visto no primeiro módulo, existem vários tipos de ciclo de vida. Independentemente
do ciclo adotado, antever estimativas é sempre um desafio. Mais ainda em ambientes complexos,
nos quais o horizonte é, por definição, desconhecido. Mesmo assim, não é incomum a demanda
por estimativas, se considerarmos que as organizações estão acostumadas e, em muitos casos,
precisam lidar com prazos definidos.

44
 Equipes são levadas a estimar o tempo do projeto que será desenvolvido por meio de um product
backlog, predizer quando uma nova versão do produto estará disponível, indicar quando as correções
de bugs estarão concluídas, quanto vai custar determinada funcionalidade, entre outras questões. O
motivo óbvio pelo qual as organizações demandam estimativas é que diversas ações são planejadas com
base nesse tipo de levantamento: lançamento de novos produtos, campanhas de marketing, entre tantas
outras possibilidades do cotidiano de uma empresa. Além disso, do ponto de vista comportamental, as
estimativas suportam a redução da incerteza, apoiam a tomada de decisão e estabelecem confiança. Além
de toda essa utilidade legítima das estimativas, Boehm (1980) adverte que a estimativa e o planejamento
não são apenas para formatar cronogramas, mas também são instrumentos para a busca por valor.
Para que se tenha uma ideia do quão intrincado é esse debate, existe um movimento na
internet denominado #NoEstimates, o qual, em resumo, sugere que a maioria das coisas que
realmente importam não podem ser medidas; no entanto, fazemos justamente o contrário,
permitindo que as coisas que podem ser medidas passem a ser as que nos interessam. Além disso,
como se sabe, estimativas são afetadas pelo tamanho do requisito a ser desenvolvido, por
informações que, por vezes, acabam sendo irrelevantes, por requisitos extras ou até mesmo por
efeitos de ancoragem 2 para cima ou para baixo.
Tanto é assim que o Project Management Institute (PMI), referência mundial em gerência
de projetos, sugere que as estimativas passam por um intervalo assimétrico à medida que são
produzidas. Para o PMI, a ordem de magnitude inicial varia de -25% a +75% da estimativa
realizada. A próxima estimativa a ser feita é a orçamental, com um intervalo de -10% a +25%,
seguida da estimativa definitiva final, com um intervalo de -5% a +10%. Boehm (1980) foi na
mesma linha, só que de maneira simétrica, quando esboçou a primeira versão do que depois seria
denominado de “cone da incerteza”.
A Figura 28, a seguir, mostra os intervalos iniciais de incerteza em diferentes pontos de um
projeto em cascata. Como é possível observar, o cone mostra que no início do projeto, uma
estimativa de cronograma está tão distante quanto 60% a 160%. Melhor dizendo, um projeto com
duração prevista de 10 semanas pode levar de seis a 16 semanas. Depois que os requerimentos forem
redigidos, a estimativa ainda pode estar errada de +/- 15% em qualquer direção, e assim por diante,
até que o produto esteja aceito.

2
Viés cognitivo que se “ancora” em parte da informação recebida para a tomada de decisão. Tendência muito comum em
todas as pessoas.

45
 Figura 28 – Cone da incerteza

Fonte: adaptado de Boehm (1980)

Se com métodos preditivos já é tarefa hercúlea fazer estimativas, como fazê-lo no contexto da
agilidade? Até porque, como comentamos, mesmo considerando um ambiente ágil, portanto,
empírico, a cobrança por estimativas costuma aparecer.
Em métodos ágeis, a resposta para essa questão é respondida de uma forma incremental e
iterativa. As estimativas devem refletir o esforço e a complexidade das histórias que estão sendo
trabalhadas. Veja que não estamos falando em dias ou horas de trabalho, como tradicionalmente
seria feito, mas, sim, em uma estimativa relativa, que compara histórias de usuário entre si para
deliberar sobre o grau de esforço associado a cada uma delas. Essa consideração pode ser usada para
medir a velocidade da equipe, estimar a quantidade de sprints em um projeto e tomar melhores
decisões em relação a priorizações, entre outras possibilidades.
Os desenvolvedores são os responsáveis pelas estimativas, e o objetivo é chegar a um consenso
sobre a velocidade da equipe. Em outras palavras, quanto de esforço uma equipe suporta por sprint.
A premissa é que as histórias apresentam níveis diferentes de requisitos, e o time abraça essa
variabilidade aplicando uma faixa de tamanho relativa ao esforço. Com o tempo e com o
aprendizado adquirido a cada sprint, as equipes podem não só medir a sua velocidade, como
também estabilizar e ainda procurar meios para acelerar a sua própria métrica.

46
 Nesse sentido, existem várias opções de estimativas ágeis disponíveis para o time Scrum e,
normalmente, o Scrum master assume o papel de mediador junto ao time em cada uma das
alternativas. Esse material não pretende de forma alguma esgotar todas as possibilidades, mas, sim,
mostrar algumas das mais utilizadas, ressaltando mais uma vez, que a equipe tem toda a liberdade
de escolher o método que pretende usar para fazer as suas estimativas.

Ideal hours
A estimativa em horas ideais, ou dias ideais, trabalha com pressupostos de forma absoluta,
determinística. A premissa é que o desenvolvedor trabalhará sem interrupções e que dedicará 100%
do seu tempo nas histórias do product backlog que tem de produzir. Além disso, assume-se que
todos os recursos necessários para a execução das tarefas estarão disponíveis, sem hiatos de nenhuma
espécie. Em outras palavras, é como se cada profissional da equipe estivesse livre e sem distúrbios
para trabalhar durante uma sprint.
Embora seja tentador pensar dessa forma, é notório que esse “mundo ideal” não existe na
prática. Todos nós somos levados a participar de reuniões, respondera a e-mails, entre outras
atividades, que tiram o foco e fazem com que as horas ideais e as horas decorridas sejam
completamente diferentes.
Uma história de usuário pode ser estimada mais facilmente em dias ideais do que em dias
decorridos. A estimava em dias decorridos exigiria considerarmos todos os distúrbios a que um
desenvolvedor pode estar exposto durante o seu trabalho. Se estimarmos em dias ideais,
consideraremos apenas a quantidade de tempo que a história levará, uma tentativa válida, ainda que
menos precisa. Desse forma, caso seja feita a opção por horas ou dias ideais, é melhor que se
considere uma estimativa ideal única para toda a história, e não a estimativa de tempo de cada
pessoas para a mesma história (COHN, 2006). Como exemplo, se tivermos: três dias de
programador, dois dias de especialista de banco de dados e um dia do testador, é melhor estimar
seis dias ideais para a história.

Story points
Os pontos de história são uma unidade de medida que expressam uma estimativa de esforço
geral em relação a cada história do product backlog. Só que diferente das horas ideais, os story
points são atribuídos de maneira relativa a cada história em função do grau de esforço que cada
membro do time imagina ser necessário ao seu desenvolvimento. A estimativa de pontos de história
é normalmente feita nas sessões de refinamento do backlog, quando o backlog como um todo é
avaliado pela equipe Scrum.
Usando pontos de história, conseguimos separar a estimativa de esforço da estimativa de
duração, ainda que esforço e cronograma estejam relacionados. Contudo é difícil identificar uma
história a partir da escala atribuída a ela.

47
 Para tanto, cada equipe deve encontrar uma história básica. Não é necessariamente a menor,
mas aquela com a qual todos possam identificar-se. Alguns sugerem pegar a história mais simples,
outros recomendam uma história considerada de esforço médio. Seja qual for a opção da equipe, uma
vez escolhida, o dimensionamento de todas as demais histórias deve ser realizado em comparação com
a história base escolhida. Esse dimensionamento favorece uma melhor visão do escopo, retifica
suposições errôneas e, fundamentalmente, faz uso de perspectivas múltiplas para determinar o
tamanho do trabalho, o que minimiza a chance de qualquer viés isolado ou mesmo Hippo. 3
O número de pontos associados a uma história representa o seu tamanho geral, não
existindo uma fórmula pré-definida para avaliar o seu tamanho. Essa estimativa é uma junção da
quantidade de esforço imaginada para aquela história, o seu grau de complexidade inerente e o risco
associada a ela. Desse modo, uma história que foi considerada com oito pontos deve gerar quatro
vezes mais esforço que uma história estimada com dois pontos e duas vezes menos esforço que uma
história estimada com 16 pontos. Ao final, o que se tem é uma lista de histórias ordenadas por
pontos, que podem ser muito úteis para aferir a velocidade da equipe.
Velocidade é uma medida da taxa de progresso do time Scrum. É calculada somando o
número de pontos de história atribuídos a cada história de usuário que a equipe concluiu durante
a sprint. Se a equipe completar três histórias, cada uma estimada em três pontos de história, a sua
velocidade será de nove pontos.
Depois de concluir nove pontos de história na última sprint, o melhor palpite é que vai
completar nove pontos de história na próxima sprint. Como se trata de uma medida relativa, não
importa se são três histórias de três pontos cada ou duas histórias de quatro e cinco pontos,
respectivamente. Somando as estimativas de pontos de história de todas as histórias do backlog,
temos a estimativa total de pontos de história do projeto como um todo. Uma vez entendendo a
velocidade da equipe, é possível dividir o tamanho total pela velocidade para saber o número de
sprints necessárias ao projeto. Podemos também transformar essa duração em um plano mapeado
em um calendário. Quer dizer, estimamos o tamanho, mas derivamos a duração (COHN, 2006).
Essa duração pode ser utilizada para o planejamento de uma release – versão – do produto
que se está construindo. Uma release é totalização de um bloco de sprints ou a soma de incrementos
que retrata uma parte do produto que é disponibilizado aos stakeholders. Via de regra, a estratégia
de releases (Figura 29) é definida pelo product owner com antecedência, estabelecendo a frequência
com que devem ser liberadas as releases do produto. Pode ficar definido que será ao final de
múltiplas sprints ou em um esquema de entrega contínua, ao final de cada sprint.

3
Acrônimo de: High-Paid Person Opinion, para representar a tendência de valorizar a opinião daqueles com mais alto salário.

48
 Figura 29 – Exemplo de planejamento de releases

Se um projeto tem 100 pontos de história ao todo e sabemos que, historicamente, a

velocidade da equipe é de 10 pontos por sprint de duas semanas de duração, podemos derivar uma
duração de 10 sprints ou 20 semanas, supondo que a velocidade do time se mantenha estável em
relação ao seu histórico. Mas e quando isso não acontece?
Valores históricos são extremamente úteis, contanto que: i) os dados históricos estejam
disponíveis; e ii) as características do projeto anterior sejam mais ou menos parecidas com as do
projeto que se pretende estimar. Se isso não for possível, outra maneira que encaixa perfeitamente
no conceito da experimentação da agilidade é executar algumas sprints e, em seguida, estimar a
velocidade a partir da velocidade efetiva durante essas sprints. Em síntese, a melhor maneira de
prever a velocidade é observá-la. Com o tempo e com a progressão das sprints, a velocidade da
equipe aflora de maneira mais fidedigna. Nesse contexto, os erros de planejamento ficam mais
evidentes e facilitam a autocorreção.
Como última opção, quando não temos dados históricos e não é possível rodar algumas
sprints para observar a velocidade da equipe, podemos tentar fazer uma previsão. Significa
decompor as histórias em tarefas, estimar essas tarefas, analisar quanto trabalho cabe em uma sprint
e, em seguida, calcular a velocidade que seria alcançada se esse trabalho fosse concluído em uma
sprint.
Um ponto a ser ressaltado, conforme a Figura 30 a seguir, é que a velocidade estimada no
início de uma sprint pode não ser igual à velocidade real da equipe ao final da sprint.

49
 Figura 30 – Velocidade estimada x velocidade real

Fonte: adaptado de Kniberg (2007, p. 26)

A velocidade real é baseada na estimativa inicial de cada história, e quaisquer modificações na

estimativa de tempo da história durante a sprint são ignoradas. Ainda que diversos fatores possam
influir na velocidade, como estimativas incorretas, riscos, etc., essa medida continua sendo útil,
mesmo que a história não tenha ficado completa, porque nos permite tomar ciência da diferença
aproximada de quanto imaginávamos que seria o esforço de uma história em relação a quanto
realmente foi colocado.
O Scrum, assim como todos os métodos ágeis, respeita a sua origem Lean e considera que o que
vale são as tarefas realizadas. Aquilo feito parcialmente não é considerado entregue (KNIBERG, 2007).
Um último ponto relativo aos pontos de história é que, com frequência, infelizmente, acabam
sendo usados para fins que não de estimativa e priorização. Não é incomum no mercado que os
pontos de história sejam utilizados para a avaliação de membros da equipe, confundidos com
medida de produtividade e utilizados na confecção de cronogramas detalhados. Não podemos
esquecer a característica empírica do framework ágil na sua essência.

Dot voting
A dot voting, como o nome induz, é uma votação por pontos a qual permite que as equipes
apontem quais ideias ou tarefas consideram de maior prioridade. Geralmente, é uma ferramenta
para a tomada de decisão, como selecionar os dois ou três itens mais relevantes durante uma reunião
de retrospectiva. Mas serve também para o exercício de estimativa, na medida em que cada
desenvolvedor recebe um pequeno número de pontos na forma de adesivos e os usa como votos
para indicar o tamanho e a importância de um item do backlog.

50
 Figura 31 – Dot voting

Todas as histórias de usuários são colocadas em uma parede ou disponibilizadas virtualmente

pelo product owner. Todos votam por pontos ao mesmo tempo, e não em turnos. Isso ajuda a
revelar a visão do grupo em vez da opinião do membro mais influente da equipe.
Cada desenvolvedor é convidado a dar os seus votos nas histórias que ele considerar maiores.
Quanto mais votos um item obtém, maior o seu tamanho e maior a sua prioridade.
Para votar, basta colocar um ponto ao lado da opção preferida. Esse processo é repetido até
que os quatro ou cinco votos de cada desenvolvedor se esgotem. Ao final desse processo, a história
com maior número de votos é denominada como maior, e aquela com menor número de votos é a
menor. Uma pessoa pode votar mais de uma vez em uma mesma história. Podemos também dividir
as histórias em grupos após as discussões: alta prioridade, baixa prioridade e média prioridade.
Histórias de usuários de alta prioridade são postadas no mural para receber os votos. Isso é feito até
que o pedido final seja alcançado com o acordo de todos stakeholders.

T-shirt sizing
A T-shirt sizing é uma técnica de estimativa relativa feita com base na analogia com o
tamanho de camisetas. As histórias são classificadas em tamanhos de camiseta: XS, S, M, L, XL.
Com a medição de camisetas, os desenvolvedores recebem uma solicitação para avaliar se eles acham
que uma história é extrapequena, pequena, média, grande, extragrande ou duplo extragrande. Os
tamanhos podem, se necessário, receber valores numéricos após a conclusão da estimativa.

Figura 32 – T-shirt sizing

Fonte: GOTHAL, Pradnya. Agile Estimation and Planning. We Are BookMyShow, 1º de agosto de 2017. Disponível em:
<https://we-are.bookmyshow.com/agile-estimation-and-planning-5c1eee3b9559>.

51
 Os valores abaixo das camisetas são sugestões baseadas na sequência de Fibonacci, 4 e existe
um bom motivo para a utilização desse artifício. Os números utilizados na sequência de Fibonacci
se distanciam de forma suficiente para que seja possível facilmente percebermos a diferença, dado
que a nossa mente não trabalha com incrementos instáveis, mas, sim, com saltos irregulares de um
estado para o outro (SUTHERLAND, 2014). A sequência de Fibonacci é regularmente utilizada
quando trabalhamos com pontos de história também.

Planning poker
Da mesma forma, o planning poker pode trabalhar com a sequência de Fibonacci ou com
uma outra sequência escolhida (0, 1, 2, 5, 10, 20, 30, 50, etc.). O fato de ser aplicado de uma
maneira gamificada o torna muito atraente para a maioria dos times Scrum (COHN, 2006).
Além das cartas com os valores, também é comum a utilização de cartas especiais. A carta de
infinito representa um valor infinitamente grande de esforço, a carta zero significa que a história ou
a tarefa é desnecessária, a carta 0,5 significa apenas um pequeno esforço para a conclusão da história,
a interrogação é jogada quando um desenvolvedor não está confiante para atribuir um valor, e a
carta do café simboliza a sugestão de uma pausa para reflexão antes da tomada de decisão.

Figura 33 – Planning Poker

Para cada história de usuário, o product owner lê a sua descrição e fica disponível para
responder a quaisquer perguntas que os desenvolvedores tenham a respeito. Depois que todas as
perguntas tiverem resposta, cada avaliador seleciona em particular uma carta que representa a sua
estimativa e joga a carta com a face para baixo sobre a mesa. Essa carta contém o valor numérico de
pontos que cada desenvolvedor considera adequado para que a história seja concluída.

4
Sequência que forma um padrão no qual o número seguinte na sequência é igual à soma dos dois anteriores: 0, 1, 1, 2,
3, 5, 8, 13, 21, 34, 55, ...

52
 Depois disso, as cartas são viradas simultaneamente e mostradas, de forma que todos possam
ver cada estimativa feita. É provável que, a princípio, as estimativas sejam significativamente
diferentes. Os desenvolvedores devem explicar os seus argumentos quanto às estimativas
representadas nas cartas. Isto é, o jogo promove uma discussão saudável entre os desenvolvedores,
dado que cada um tem de explicar aos demais as razões pelas quais considera que uma história tem
menos ou mais esforço.
O grupo discute as histórias, e as suas estimativas durante alguns minutos e depois é feita
uma nova rodada de estimativas com as cartas, que são mantidas em sigilo até que todos tenham
feito as suas estimativas e colocado a sua carta virada para baixo na mesa. Em muitos casos, já na
segunda rodada, as opiniões sobre as estimativas já tenderão a convergir, baseadas nas
argumentações feitas por cada desenvolvedor na rodada anterior. Aquele que colocou a carta 3 agora
pode colocar 21, em função da influência do justificativa do colega na rodada anterior. Caso todos
venham a convergir já na segunda rodada, a estimativa da história estará pronta. Caso contrário, o
processo se repete até que todos convirjam em uma única estimativa que será usada para a história
de usuário. Mesmo que não haja um consenso perfeito, procura-se uma estimativa pelo menos
próxima. Como exemplo, em uma situação em que os quatro desenvolvedores colocam: 8, 8, 5, 8,
o Scrum master pode perguntar à pessoa que colocou 5 se ela se incomoda de o time ir com a
estimativa de 8 para a história em questão.

Gráficos de acompanhamento
Existem várias formas para a medição do progresso do trabalho de uma equipe Scrum.
Veremos alguns tipos de gráficos que exemplificam isso. Entretanto cabe ressaltar, logo no início
desta unidade, que ainda que comparação de previsto versus realizado seja relevante, nunca devemos
perder de vista outros tipos de métricas, tais como: o lead time, ou o tempo decorrido desde que
um item entrou no backlog até a sua entrega ao cliente, quão satisfeitos os clientes estão com as
entregas realizada, quão felizes as equipes Scrum estão trabalhando, como está o retorno do
investimento realizado, a qualidade do que está sendo entregue e quanto tempo as equipes gastam
com inovação. O ponto aqui é que gráficos são úteis, e podemos fazer uso deles, mas o mais
importante ao fim do dia é o valor gerado para os stakeholders. Por conseguinte, as medições e o
próprio framework Scrum como um todo são inúteis quando o time Scrum é incapaz de entregar
um incremento útil e valioso ao final de uma sprint.

53
Gráfico de burndown
O gráfico de burndown é uma ferramenta visual que funciona, basicamente, como um
radiador de informação. A sua invenção é creditada a Ken Schwaber, um dos criadores do Scrum,
que o utilizou a partir dos anos 2000 para demonstrar de forma simples e prática a evolução de
projetos de software. É assim chamado porque literalmente analisamos quanto já foi “queimado”
em relação ao trabalho restante.

Figura 34 – Gráfico de burndown

O eixo Y representa o trabalho a ser feito em termos de pontos de história, e o eixo X

representa o tempo, estipulado em dias ou semanas. Se queimássemos uma quantidade ideal de
histórias por período de tempo, teríamos o que denominamos de “burn rate” ideal, representada na
linha verde da Figura 34. Nesse caso específico, considerando 300 pontos de história, em 20 dias,
deveríamos queimar 15 pontos de história por dia. O histograma do gráfico mostra quantas histórias
de fato foram sendo concluídas a cada dia, também demonstrado pela curva vermelha no gráfico,
que representa o progresso real.

54
 Como podemos imaginar, no cotidiano de projetos, é praticamente impossível que a linha real
acompanhe exatamente a linha ideal. O normal é que ela flutue acima ou abaixo da linha verde. Se a
linha real (vermelha) estiver acima a linha ideal (verde), significa que menos pontos de história foram
concluídos do que a média esperada, indicando um atraso na sprint. Já a situação em que a linha real se
encontra abaixo da linha ideal, denota que foram concluídos mais pontos de história do que o esperado
para aquele momento do sprint. Dessa forma, o gráfico mostra como o trabalho se desenvolve e quanto
trabalho ainda resta ser feito em qualquer dia até que todas as histórias estejam completas.
Claro que, para que isso seja possível, é necessária a atualização do gráfico regularmente, até
para que a informação seja o mais transparente possível, conforme proposto pelos pilares do Scrum.
Inclusive a sugestão é que seja colocado de forma bem visível para todo time. O segredo da eficácia
do gráfico de burndown reside justamente na simplicidade e na facilidade de aplicação.
Por óbvio, essa análise não pode ser totalmente fria porque depende de uma série de variáveis
e acontecimentos que podem justificar as razões de um eventual atraso ou uma aceleração na
produção de histórias de usuário. Como exemplo, apesar da nitidez do gráfico de burndown, ele
não permite analisar qualquer consideração relativa a possíveis mudanças de escopo sofridas pelo
projeto. Nesse contexto, caso tenha ocorrido um aumento ou uma redução de trabalho oriundo de
uma mudança de escopo ou qualquer modificação na estimativa do trabalho restante, isso também
não é refletido no gráfico.
Veremos a seguir que existe outra opção de gráfico que considera essa possiblidade. Outro
ponto é que o gráfico de burndown mostra apenas a quantidade de pontos de história realizados,
mas não quais histórias foram completadas ou mesmo se foram as histórias devidas que foram
completadas. De toda sorte, é sempre importante buscarmos entender as razões por trás das
variações, assim como o ajuste das expectativas dos stakeholders.

Gráfico de burnup
O gráfico de burnup é parecido com o de burndown, no sentido de que ambos visam
apresentar o progresso ao longo da sprint. Só que, enquanto o gráfico de burndown parte do total
de pontos de história a serem desenvolvidos e mostra o quanto está sendo “queimado” ao longo do
tempo, o gráfico de burnup parte do zero no tempo e cresce conforme as histórias vão sendo
desenvolvidas até todo o trabalho ter sido concluído no projeto. Em resumo, a informação é
praticamente a mesma, só que em sentidos diferentes. Com isso, a equipe Scrum tem liberdade de
escolha para trabalhar com burndown, burnup ou ambos, dependendo na preferência de
visualização. Um detalhe óbvio, porém, que cabe ser lembrado é que ambos os gráficos de
burndown e burnup dependem que boas estimativas tenham sido feitas.

55
 Figura 35 – Gráfico de burnup

Devido à sua característica, o gráfico de burnup é mais utilizado para a medição do projeto
como um todo. O eixo Y mostra o total de pontos associados à evolução do escopo do projeto; e o
eixo X, o tempo. Uma linha de escopo (verde) é traçada evidenciando o total de pontos de história
a serem realizados. Já a linha de baixo demonstra o progresso do time em direção a completar o
projeto, ou seja, quando as linhas se tocam. A distância entre as linhas a cada unidade de tempo no
eixo X indica a quantidade de trabalho que falta ser entregue. Caso a linha de baixo não logre atingir
a linha de escopo, significa que o time não conseguiu atingir a meta desejada. A atualização pode
ser feita ao final de cada sprint.
Uma vantagem do gráfico de burnup sobre o de burndown é que nele é possível observar
mudanças realizadas no escopo e, mais ainda, o desempenho da equipe em frente a essas distorções.
Na Figura 36, a seguir é possível notar que o escopo seguiu normalmente até o quinto mês de
trabalho, quando foi feita uma mudança no escopo do projeto, levando a um aumento de 300 para
500 pontos de história.

56
 Figura 36 – Gráfico de burnup com mudança de escopo

Analogamente ao gráfico de burndown, seria preciso analisar as circunstâncias do ocorrido para

entender o quanto o progresso foi afetado e como a equipe está reagindo a essa alteração. Claramente,
o time está em pleno desenvolvimento e iria finalizar o projeto no sexto ou no sétimo mês. Entretanto,
com a mudança solicitada, a performance do time parece ter diminuído por alguma razão, como a
linha de baixo dá a entender. A situação teria de ser analisada pela própria equipe, para que os
impactos do ocorrido possam ser adequadamente tratados no decorrer do projeto.
Feito o entendimento dos gráficos, cabe salientar mais uma vez que o objetivo do Scrum é
lidar com situações complexas por meio do empirismo, entregando incrementos com qualidade e
de forma frequente. Se isso não estiver acontecendo, de nada adiante um gráfico consistente e com
linhas compatíveis entre si.

57
Conclusão
Neste terceiro módulo, falamos de um tópico muito importante na constituição de projetos
baseados em Scrum: as histórias de usuário, que são um expediente muito comum no mercado, que
traduzem os desejos de funcionalidades dos stakeholders em itens de backlog. Além disso,
abordamos um tema polêmico no Scrum e na agilidade em geral, relacionado às famigeradas
estimativas e como isso é normalmente abordado em equipes ágeis. Por último, tratamos de gráficos
de acompanhamento que facilitam o controle de projetos baseados em Scrum.
No próximo módulo, falaremos sobre tópicos avançados relacionados ao Scrum, incluindo o
importante processo de escalada do framework na organização.

58
MÓDULO IV – ASPECTOS AVANÇADOS

No quarto módulo, são abordados aspectos avançados a respeito da dinâmica do Scrum, no

que diz respeito às técnicas de gestão de riscos, à comparação e à utilização do Scrum com Kanban,
bem como à escalada do Scrum, entre outras considerações importantes que ajudam a alicerçar a
sua implantação nas organizações.
As unidades do módulo estão divididas da seguinte forma:
 Unidade 4.1 – Gestão de riscos;
 Unidade 4.2 – Scrumban e
 Unidade 4.3 – Escalando o Scrum.

Ao final do módulo, espera-se que você possa fazer uso desses outros aspectos relativos ao
Scrum, de forma a auxiliar a implantação do framework na sua organização.

Gestão de riscos
Como não poderia deixar de ser, a equipe Scrum também se preocupa com os riscos do
projeto. Aliás, pode-se afirmar que o framework Scrum é, na sua própria constituição, uma forma
de tratamento de riscos muito eficaz. Primeiramente, é preciso lembrar que existem riscos tanto
positivos quanto negativos. Os riscos são positivos, quando retratam oportunidades; ou negativos,
quando representam ameaças. No caso especificamente do Scrum, riscos negativos representam
tudo aquilo que é contra a geração de valor.

60
 Curiosamente, o Guia Scrum (SUTHERLAND; SCHWABER, 2020) não aborda
ostensivamente o gerenciamento de riscos, exceto em três momentos, quando menciona que: i) o Scrum
emprega uma abordagem iterativa e incremental para otimizar a previsibilidade e controlar o risco; ii)
artefatos com baixa transparência podem levar a decisões que diminuem o valor e aumentam o risco;
iii) quando o horizonte de uma sprint é muito longo, a meta da sprint pode tornar-se inválida, a
complexidade pode aumentar e, consequentemente, o risco. Sprints mais curtas podem gerar ciclos de
aprendizagem mais rápidos e limitar os riscos de custo e esforço. Como é possível perceber, a conotação
de risco dada pelos autores é mais pelo viés negativo propriamente dito que pelo positivo.
Não obstante, riscos estão presentes em todo tipo de projeto, seja qual for a abordagem ou o
ciclo de vida. A gestão de riscos pode variar em função da preferência de cada time, mas, na essência,
passa pela identificação dos riscos, pela análise, pela resposta aos riscos e pelo monitoramento
contínuo da sua aplicação. Esses processos podem ocorrer a cada sprint, dado que as condições, o
ambiente e os fenômenos ao redor do projeto se transformam de maneira crônica e incessante.

Figura 37 – Gestão de riscos

Os próprios eventos Scrum são muito úteis para gerenciar riscos. As equipes o fazem de
maneira consciente, natural ou mesmo inconsciente, na medida em que o gerenciamento de risco
é empírico e constante. Se pararmos para refletir, a sprint existe como mecanismo também de
redução de risco por meio da experimentação sucessiva. Se levarmos em conta a possibilidade da
entrega de um incremento e o desejo dos stakeholders, a decisão sobre a duração da sprint, que
abordamos anteriormente, é um expediente de limitação do risco.

61
 Ao final da sprint, o refinamento do product backlog é uma excelente oportunidade para o
time Scrum e os demais stakeholders analisarem questões do tipo: qual história apresenta maior
risco ou maior valor? Qual apresenta valor baixo e risco elevado? Vale a pena mantê-la no product
backlog? Que experimentos teriam de ser realizados para validar essa hipótese?
A identificação de riscos no framework Scrum pode ser realizada durante todos os eventos
do Scrum. Desde o planejamento macro do produto, o product owner, junto com os demais
membros do time precisa analisar o risco de cada história porque, associado ao valor do negócio,
o risco é outro critério importante ao priorizar as funcionalidades a serem implementadas.
Requisitos com maior risco são frequentemente os primeiros a serem realizados, dado que quanto
mais rápida a falha, menor o custo. Por essa razão, é importante considerar a inclusão sobre
informações de risco no product backlog.
Durante a sprint planning, todo o time é levado a discutir aqueles itens do product backlog
que serão selecionados para a próxima sprint. A montagem do sprint backlog deve levar em
consideração histórias que apresentem riscos elevados, pois caso o risco não seja tratado a tempo,
pode impactar a entrega do incremento.
A sprint review também oferece um bom momento para a identificação de riscos, dado que
o seu objetivo é a apresentação do incremento e a inspeção do que foi feito. Trata-se da ocasião
ideal para discutir os riscos de negócios e tecnologia enquanto se debate o incremento atual e as
perspectivas. É por isso que mesmo uma sprint review sem resultados concretos a apresentar,
ainda que se transforme em uma cerimônia potencialmente desagradável, deve ser conduzida,
porque pode levar a discussões sobre o produto como um todo, condições novas de mercado,
aspiração renovadas dos stakeholders.
Na daily Scrum, o time é levado a criar um plano para cada dia de trabalho específico. Nessa
reunião, cada membro expõe os possíveis impedimentos que possa pôr em risco a meta da sprint.
Os impedimentos podem ser classificados com riscos potenciais ou como issues, caso já sejam um
fato. Essa expressão issue – questão – pode gerar dúvidas e, por conseguinte, é importante que seja
esclarecida. Enquanto risco é um evento eminentemente incerto, o issue é um problema, um
conflito ou uma questão aberta que já ocorreu e que, portanto, demanda o devido tratamento.
Já a sprint retrospective, que naturalmente já promove uma revisão da sprint, oferece uma
oportunidade ímpar de o time Scrum se autoavaliar e buscar aspectos de melhoria para a próxima
sprint. Essa cerimônia discute processos, pessoas, ferramentas e a própria definição de feito (DoD).
À medida que são debatidos aspectos positivos e negativos, riscos são também identificados e planos
mitigatórios podem ser traçados para catalisar ou mitigar o seu efeito.

62
 A análise dos riscos pode fazer uso da tradicional matriz probabilidade/impacto, que
atende ao intuito de ajudar na priorização de respostas com base na qualificação dos riscos,
conforme a Figura 38, a seguir.

Figura 38 – Matriz P x I: probabilidade e impacto

Probabilidade Graduação do Risco = P x I

Alta

Média

Baixa

Baixa Média Alta

Impacto

A matriz permite a classificação dos riscos de maneira bem clara e acessível. As células vermelhas
indicam alta probabilidade e alto impacto, as células amarelas apresentam riscos ou oportunidades
intermediárias, enquanto as verdes indicam baixa probabilidade ou baixo impacto. Obviamente, na
definição das probabilidades de ocorrência possíveis, devem-se evitar os valores das extremidades, de
0% e 100% (BARCAUI; REGO, 2019), dado que simbolizaria a não existência do risco ou a certeza
da sua ocorrência, respectivamente. A Tabela 1, a seguir, facilita a quantificação dos riscos.

63
 Tabela 1 – Análise quantitativa dos riscos

exposição exposição
impacto
risco probabilidade ao risco sprint ao risco
(dias)
(dias) (dias)

cliente demanda
manual mais
30% 15 4,5 1 24,5
detalhado do que
imaginávamos

roteador XPTO
ficará preso na 55% 5 2,75 2 20
alfândega

não vamos
conseguir
formatar o 20% 10 2 3 17,25
relatório ABC a
tempo

jurídico não estará

pronto para
10% 10 1 4 15,25
validar o módulo
JUR

perda de um
membro da equipe
em função da
60% 20 12 5 14,25
demanda do seu
próprio
departamento

ambiente de
homologação não 15% 15 2,25 6 2,25
disponível

exposição = 24,5 0

64
 Durante a análise dos riscos, a identificação, a qualificação e a quantificação dos valores
podem ser utilizadas para construir um gráfico de burndown de riscos (Figura 39) que rastreia os
esforços gerais de gerenciamento de risco. Essa ferramenta, semelhante ao gráfico de burndown
anteriormente estudado, também deixa claro para o time Scrum se existe um risco residual na sprint,
composto do risco residual cumulativo de histórias de usuário junto com o risco vinculado a
estratégias de resposta, que não pode ser inteiramente eliminado. Além disso, ele exibe claramente
a dinâmica da gestão de risco ao longo das sprints (MORAN, 2016).

Figura 39 – Gráfico de burndown de riscos

Uma vez identificados e analisados, a equipe pode trabalhar nas respostas que dará a cada risco.
As respostas aos riscos são extremamente situacionais e dependentes de uma série de fatores, como a
maturidade da equipe, o contexto e a cultura organizacional, entre outros, mas a tipologia de resposta
aos riscos negativos passa por ações de: eliminação, mitigação, transferência ou aceitação do risco.
A eliminação está ligada a uma ação que remova a ameaça do ambiente da equipe Scrum. Já
uma ação de mitigação preconiza a redução da probabilidade ou do impacto do risco. Dado que o
efeito do risco é medido pelo produto da probabilidade pelo impacto, qualquer redução em uma
das variáveis reduz automaticamente o risco. A transferência é uma ação que transmite ou conjuga
com terceiros os efeitos do risco. Por último, a aceitação é o acolhimento do risco, que pode ser
feito de maneira passiva ou ativa. A passiva é aquela em que o time decide documentar e tratar o
risco no momento em que ele acontecer (virar um issue). A aceitação ativa estabelece uma reserva
para lidar com o risco caso ele aconteça.
Evidentemente, novos riscos podem aparecer a cada sprint, outros podem deixar de existir, e
a qualificação também pode mudar dependendo das circunstâncias. Desse modo, a efetiva gestão
de riscos demanda um monitoramento contínuo, não só para garantir que as respostas adotadas
estejam adequadas, mas também para salvaguardar um refinamento dos riscos ao longo das sprints.

65
 Duas ponderações finais a respeito dos riscos em projetos Scrum se fazem necessárias. A
primeira delas é relativa às chamadas spikes. Trata-se de um termo originado no método XP que
retrata um tipo especial de história de usuário, usado para obter conhecimento a respeito de uma
abordagem técnica ou funcional. Em outras palavras, quando o time apresenta algum grau de
insegurança sobre a história que precisa ser desenvolvida, que pode variar desde como deve ser a
quebra em tarefas até como organizar o trabalho, tomar uma decisão build-or-buy, 5 testar uma nova
tecnologia, entre outras possibilidades.
O objetivo da spike é justamente o de mitigar o risco relativo a determinada história ou
aumentar a confiabilidade da estimativa elaborada. O tamanho máximo da spike equivale ao tempo
de duração da sprint que o contém e, ao final da sprint, a spike pode ser dada como concluída ou
não, como qualquer outra história.
A segunda consideração é a respeito dos de uma prática conhecida em projetos preditivos que
envolve a colocação de buffers ao longo do projeto. O conceito por trás do uso de buffers seria o da
mitigação de riscos, já que a sua aplicação sugere a colocação de um tempo a mais no projeto para
o caso de problemas que possam ocorrer. Existem aqueles que fazem uso de buffers nas sprints para
administrar dívidas técnicas, bugs, ou mesmo para acomodar novas demandas que possam aparecer.
Prática mais comum em profissionais que migraram de projetos estilo cascata para projetos ágeis.
Trata-se de uma questão de cunho comportamental, mais do que puramente técnico.
Entretanto precisamos lembrar da relevância e da seriedade dos valores e dos pilares Scrum
revisados no primeiro módulo do nosso curso. Um dos valores é a abertura, no qual o time concorda
em estar aberto a todo trabalho e aos desafios relativos à sua execução, e outro é o respeito, no qual
os membros do time respeitam uns aos outros por serem pessoas capazes e independentes. Isso sem
falar na coragem, que é necessária ao time para fazer a coisa certa. Sobretudo, temos o pilar da
transparência que sugere honestidade, sinceridade e lisura em tudo o que está sendo desenvolvido.
Dessa forma, o uso de buffers não só vai contra os valores e os pilares do Scrum, como também não
é uma prática orientada pelos seus criadores.

5
Decisão de desenvolver ou comprar.

66
Scrumban
Em muitas implantações do Scrum, observa-se o uso do Kanban de forma acoplada, o que
pode tornar a aplicação do framework ainda mais dinâmica. O Kanban é um método para definir,
gerenciar e melhorar serviços que entregam trabalho de conhecimento (ANDERSON;
CARMICHAEL, 2016). Dito de outra forma, o Kanban deixa visível a maneira de trabalhar do
time por meio de um sistema de fluxo de entrega representado nos chamados quadros Kanban, que
limitam a quantidade de trabalho em progresso, ou Work in Progress (WIP). Essa limitação de
WIP impede que muito ou pouco trabalho entre no sistema, melhorando o fluxo de valor e criando
um sistema “puxado” em que um trabalho só é colocado no sistema quando outro trabalho é
concluído e a capacidade se torna disponível (ao contrário) de “empurrado” para ele quando um
novo trabalho é exigido. Isso porque, como sabemos, é muito mais fácil iniciar uma tarefa do que
terminá-la.

Figura 40 – Exemplo de quadro Kanban

Ainda que os meandros do método Kanban fujam ao escopo deste curso, alguns dos seus
princípios se fazem importantes até para que possamos compreender as possibilidades de aplicação
junto ao Scrum. O método sugere começar pelo que se faz atualmente, ou seja, começar de maneira
simples e ir melhorando por meio de mudanças evolutivas. No Kanban, o trabalho é gerenciado, e
as pessoas se auto-organizam ao redor dele. O tempo médio para a entrega de uma tarefa é
denominado lead time, e a frequência com que os itens são entregues é conhecida como througpout.
O framework Scrum é relativamente mais prescritivo que o Kanban. Em outros termos, o
Scrum, ainda que seja leve, possui mais regras a serem seguidas. Todavia ambos são extremamente
adaptativos, empíricos e seguem os mandamentos da filosofia Lean. A seguir, no Quadro 2, temos
uma frugal comparação entre o framework Scrum e o método Kanban.

67
 Quadro 2 – Comparativo entre Scrum e Kanban

Scrum Kanban

Usa timeboxes (sprints). Não trabalha com timeboxes.

Descreve papéis a serem seguidos (PO, Não prescreve papéis, ainda que seja
SM, desenvolvedores). possível o uso de SDMs e SRMs.

Usa velocidade como métrica para

melhoria de processo, isto é,
Usa lead time e o througpout como métricas
histórias/sprint. Uma vez conhecendo a
para melhoria de processo.
velocidade, esta se torna uma orientação
para o limite de WIP.

Costuma fazer uso de gráficos de

Costuma fazer uso de CFDs.
burndown e burnup.

Pode trabalhar com estimativas, mas o foco

Normalmente, trabalha com estimativas.
maior é nas prioridades.

As histórias são quebradas para caber Não prescreve nenhum tamanho de história
dentro de uma sprint. em particular.

O backlog da sprint pertence a um Um quadro Kanban pode ser compartilhado

determinado time. por múltiplos times ou pessoas.

Limita o WIP de forma indireta, por Limita o WIP de forma direta, em função da
iteração (sprint). capacidade e do estado do fluxo de trabalho.

Times multifuncionais são opcionais, e o

quadro Kanban não precisa pertencer a uma
Sugere times multifuncionais. equipe específica. O quadro está relacionado a
um fluxo de trabalho, não necessariamente a
uma equipe.

O quadro Kanban é reiniciado ao final de

O quadro é, normalmente, persistente.
cada sprint.

Não adiciona itens a uma iteração em Pode adicionar itens sempre que houver
andamento. capacidade disponível.

68
 Um ponto importante nessa comparação é quanto à solicitação de mudanças. O time
Scrum resiste a mudanças enquanto estiver dentro do período da sprint. Um novo item é
colocado no product backlog, mas só será desenvolvido na próxima sprint. Já no Kanban, um
novo item pode ser adicionado a qualquer momento, com a ressalva de que só será colocado para
a produção à medida que a capacidade se tornar disponível.
Embora o Scrum seja mais utilizado para o desenvolvimento de produtos e Kanban mais para
fluxos operacionais nos quais a entrada de trabalho seja imprevisível, não é incomum que, durante
as sprints, os times Scrum façam uso de quadros Kanban para acompanhar o andamento das
histórias selecionadas para aquela iteração. Não só facilita a visualização, como também promove a
transparência, a inspeção e a adaptação, pilares do framework.

Figura 41 – Quadro Kanban com Scrum, durante a sprint

Entretanto, para expandir ainda mais as qualidades do framework e do método, podemos

tentar uma fórmula que oportunize uma junção de ambos. Com isso, temos o Scrumban, uma
solução interessante para times que necessitam da estrutura do Scrum, mas com a flexibilidade do
Kanban. Originalmente, denominado como Scrum-ban (LADAS, 2008), o método descreve um
processo evolutivo, que quebra algumas regras normalmente exercitadas no Scrum, mas em
compensação, torna o processo ainda mais enxuto, tendo o fluxo do Kanban como fio condutor.
O Guia Scrum (SUTHERLAND; SCHWABER, 2020) não demanda um quadro Kanban,
mas como mencionado anteriormente, as equipes Scrum fazem uso ostensivo de um quadro
Kanban para efeito de visualização do desenvolvimento das histórias ao longo da sprint. Se
pensarmos nas três colunas clássicas do quadro Kanban (“to do”, “in progress”, “done”), a coluna
do “to do” pode ser traduzida como o sprint backlog das tarefas selecionadas pela equipe. Já a coluna
“in progress” representa tudo o que está sendo trabalhado pela equipe naquela sprint específica.

69
 No melhor estilo Kanban, é importante definir os limites de WIP, mas ao processo como um
todo, e não por pessoa. Em outras palavras, não é recomendado atribuir histórias a membros
específicos do time como parte do refinamento do backlog ou do planejamento da sprint. Desse
modo, o time trabalha junto para resolver bloqueios que possam estar impedindo determinada
tarefa de ser completada, em vez de pegar mais histórias no backlog para desenvolver. O sistema
puxado é habilitado pelo limite colocado na coluna “in progress”. Apenas quando uma tarefa é
finalizada – e movida para coluna de “done” – é que alguma capacidade é liberada para que uma
nova história possa ser puxada da coluna de “to do” para coluna de “in progress”.
Incontestavelmente, à proporção que o processo evolui, o time pode e deve incluir mais
colunas no quadro para representar de forma mais fidedigna o trabalho sendo realizado.
Entretanto, para evitarmos que o trabalho seja eventualmente empurrado de uma coluna para
outra, podemos fazer uso de buffers de espera antes que uma tarefa possa ser puxada para uma
nova etapa do processo, como demonstrado na Figura 42, a seguir. A coluna “in progress” foi
subdividida em três outras colunas que correspondem melhor ao processo sendo conduzido, e o
buffer é a coluna de “aguardando aprovação”.

Figura 42 – Limitando o WIP

Até então, nenhuma regra do Scrum “puro” foi quebrada. Sem embargo, no Scrumban, nós
trocamos as atribuições de tarefas às pessoas por priorizações. Podemos fazer isso criando outra
coluna após o backlog, intitulada “pronto” dedicada a mostrar quais tarefas estão prontas para serem
trabalhadas e já na ordem de priorização (Figura 43). Com isso, rompemos com a tradição de
estimativas no Scrum.
Como frisamos anteriormente, na filosofia Lean, qualquer atividade que não agrega valor é
considerada um desperdício. Nesse sentido, a estimativa das histórias no sprint backlog é eliminada
desse processo. Isso significa não trabalhar mais com pontos de história, planning poker ou qualquer
outra forma de estimativa. O evento de sprint planning passa a ser um evento de priorização, e não
mais de dimensionamento de tarefas.

70
 Figura 43 – Priorização do trabalho no Scrumban

Outra quebra no Scrum tradicional, essa mais profunda ainda, diz respeito ao processo de
sprint planning. Não queremos que as histórias sejam empurradas do product backlog para o sprint
backlog, como prescreve o Scrum, mas, sim, puxadas pela capacidade do sistema como um todo.
Isso significa dizer que a sprint planning não ocorre mais em tempos pré-determinados pelo
tamanho da sprint, mas, sim, sob demanda do próprio trabalho, no formato just-in-time. É como
se colocássemos um limite mínimo de atividades – trigger point – para o sprint backlog. Quando
esse ponto é atingido, seria hora para uma nova sessão de planejamento, ou replanishing, como é
dito no Kanban, com foco na priorização de tarefas. Melhor dizendo, seria concentrar esforços em
descobrir qual é a próxima tarefa que o time deve desenvolver. Já os eventos de review, daily e
retrospective são aproveitados conforme proposto pelo Scrum.
Como vimos, o Scrumban promove um sistema puxado de geração de valor que ajuda a
identificar itens de maior valor, desenvolvê-los e entregá-los aos devidos stakeholders, mas depois
de analisarmos o seu funcionamento, fica uma provocação: o nome “Scrumban” está adequado, ou
seria mais coerente chamá-lo de “Kanbum”?

Escalando o Scrum
Até então, falamos do Scrum como um framework para o desenvolvimento de produtos em
uma escala pequena e de forma isolada, mas seria legítimo pensar também no desenvolvimento de
grandes projetos, com mais de um time Scrum rodando ao mesmo tempo. Ademais, seria razoável
considerar que, em uma organização, seja a empresa inteira ou um departamento, o mais comum é
que tenhamos um portfólio de projetos e programas, inclusive com interdependência entre eles.
Ocorre que o que funciona bem para um pequeno time carece de ajustes e adequações para times
maiores. Sem falar que se faz necessário um aculturamento e um alinhamento das práticas ágeis,
disponibilização de recursos, entre outros desafios corporativos. Como fazer uso do Scrum para o
desenvolvimento em grande escala?

71
 A premissa da escalada ágil é que o tamanho dos times permanece reduzido, mas o número
de times aumenta. Nesse sentido, diversos modelos de referência para a escalada ágil foram
produzidos e estão disponíveis no mercado: SAFe, Scrum of Scrums, DAD, Nexus, LeSS, entre
muitos outros. Nesse sentido, optamos por descrever aqueles que mais têm tido aplicação no
mercado mundial (DIGITAL.AI, 2020).
Todos suportam a aplicação do framework Scrum, sendo que alguns suportam também
Kanban, XP e outros métodos. Obviamente, cada um tem a sua própria formatação em termos de
papéis associados, governança e formato das cerimônias. Não faz parte do escopo desse curso uma
revisão detalhada de todos eles, mas achamos importante incluir um pequeno resumo das suas
principais características de forma a permitir não só o reconhecimento do valor de cada modelo,
mas também os seus âmbitos de aplicação, as suas diferenças e as suas afinidades.
É importante ratificar que esse material não faz qualquer juízo de valor no sentido da
comparação entre modelos de escalada ágil. Reconhecemos que cada modelo tem particularidades,
pontos fortes e carências. Entendemos também, com base na experiência, que o processo de escalada
ágil é algo extremamente idiossincrático em cada organização. Nesse sentido, advertimos que
qualquer modelo a ser adotado deve ser precedido de um estudo aprofundado das características
culturais e de maturidade do ambiente. Ponderamos que os modelos de escalada ágil, cada um na
sua característica, são excelentes referências que servem como ponto de partida para implantações
ágeis em escala, mas não necessariamente de chegada. Muito provavelmente, será preciso um esforço
de adaptação, no melhor estilo ágil, em função do contexto singular de cada negócio. Feito esse
pequeno disclaimer, vamos ao resumo de cada um deles.

Scaled Agile Framework

O Scaled Agile Framework (SAFe) 6 foi desenvolvido por Dean Leffingwell e Drew Jemilo em
2011 com o nome original de Agile Enterprise Big Picture, no sentido de tentar aproveitar e
acomodar os métodos ágeis existentes e aplicá-los aos times, aos programas e ao portfólio das
organizações. Com o crescimento do movimento ágil em todo mundo, o SAFe foi sendo atualizado
e passou a ser um dos modelos de escalada ágil mais populares.
O modelo promove alinhamento, colaboração e entrega em um grande número de equipes
ágeis. Ele foi formado em torno de três corpos primários de conhecimento: desenvolvimento ágil,
desenvolvimento enxuto – Lean – de produtos e pensamento sistêmico. O mais interessante do
SAFe é que na medida em que as empresas vão crescendo, o modelo oferece uma abordagem
estruturada para o escalada ágil. Existem quatro configurações no SAFe para acomodar os diferentes
níveis de escala: Essential SAFe, Large Solution SAFe, Portfolio SAFe e Full SAFe.

6
Disponível em: <https://www.scaledagileframework.com>.

72
 A princípio, quando falamos de um time, os artefatos, os eventos e os papéis são muito
parecidos com o do Scrum. Os times visam à entrega de valor de pequenos espaços de tempo
denominados iterações, equivalente às sprints, e podem fazer uso de outros métodos além do Scrum,
como o Kanban ou mesmo o Scrumban. Assim como no Scrum, o PO dá a direção do que precisa
ser construído, e os times fazem uma reunião diária denominada daily standup para discutir como
estão progredindo em relação aos objetivos da iteração. Também da mesma forma que no Scrum,
ao final da iteração, são realizadas cerimônias de revisão e de retrospectiva da iteração, com o SM
atuando como coach da equipe. Quando temos um produto que demanda mais de um time, no
Essential Safe esse conjunto de times é denominado de Agile Release Train (ART), com função de
alinhar as equipes em uma missão compartilhada. Cada ART representa uma organização virtual
de profissionais multidisciplinares, de 50 a 125 pessoas, que planeja e desenvolve em conjunto.
O ART trabalha dentro de um período de tempo denominado Program Increment (PI), que
normalmente compreende cinco iterações, conforme a Figura 44. Antes do início do
desenvolvimento, os times se juntam para um evento denominado PI planning, objetivando
planejar o trabalho a ser desenvolvido. Esse evento é facilitado por um papel denominado Release
Train Engineer (RTE), que serve como uma espécie de SM para o ART. Analogamente, existe o
papel do Product Manager (PM) para prover a visão e servir de elo entre o ART e as partes
interessadas da organização, como o PO faria em um time isolado. O PM e os POs em um ART
devem formar uma relação de trabalho eficaz, assim como a RTE em relação aos SMs de cada
equipe. Existe ainda um chamado de system architect, responsável por definir guiar o ART quanto
à visão da arquitetura da solução que será desenvolvida.

Figura 44 – Essential SAFe

Fonte: SAFe 5 for Lean Enterprises. Scaled Agile Framework. Disponível em: <https://www.scaledagileframework.com>.

73
 O evento de PI planning pode ser considerado o núcleo do Essential SAFe, uma vez que
promove o direcionamento sobre o que será entregue e como. Um quadro – ou a junção de diversos
quadros – é normalmente utilizado para ajudar na visualização das dependências entre os diversos
times, conforme as figuras a seguir.

Figura 45 – Exemplos de quadro na PI planning

74
 Usando o exemplo de dois times, é possível visualizar o quadro geral e também os quadros
individuais de duas equipes, as suas histórias por iteração e também as interdependências. A cada
iteração, o ART faz uma demonstração da solução integrada; e, ao final da PI, todos os times se
encontram em um evento de inspeção e adaptação para procurar meios de melhorar no próximo PI.
Os desejos dos stakeholders são mapeados pelo PM por meio do foco no cliente, fazendo uso
de métodos como Design Thinking. O ART garante um canal de entrega contínua que explora,
integra e entrega de maneira constante, usando técnicas de DevOps – aplicável para o caso de
software – e gerando valor quando demandado.

75
 Por vezes, dependendo do tamanho e da complexidade do produto a ser desenvolvido,
somente um ART não é suficiente. No Large Solution SAFe, é formado um constructo
organizacional denominado solution train, que serve para coordenar e alinhar diversos ARTs, bem
como contribuições de fornecedores. Nesse nível, temos três novos papéis: solution manager (SM),
solution architect e solution train engineer, papéis que congregam os PMs, system architects e
RTEs, respectivamente. A ideia é alinhar a solução com a estratégia da organização.

Figura 46 – Large Solution SAFe

Fonte: SAFe 5 for Lean Enterprises. Scaled Agile Framework. Disponível em: <https://www.scaledagileframework.com>.

Além desses dois níveis, ainda temos mais dois estágios de escalada. O Portfolio SAFe alinha
a estratégia com a execução e organiza o desenvolvimento da solução em torno do(s) fluxo(s) de
valor e uma governança enxuta. Além de fazer uso de outros papéis como o Enterprise Architect e
os Epic Owners. Já o Full SAFe representa a configuração mais abrangente do SAFe. Suporta a
integração de grandes soluções corporativa e, tipicamente, requer centenas de pessoas para o seu
desenvolvimento e a sua manutenção.

76
Scrum@Scale
O Scrum@Scale 7 surgiu como uma alternativa proposta por um dos criadores do Scrum para
viabilizar uma escalada linear do framework Scrum, por meio da coordenação eficaz de diversos
times Scrum operando ao mesmo tempo. A sua operação faz uso da estrutura original do framework
Scrum, mas operando por meio de redes de equipes, de forma orgânica, trabalhando dentro de uma
burocracia mínima viável (MVB).
Uma MVB compreende um conjunto de processos e governança mínimos necessários às
atividades da organização, sem impedir a entrega de valor para o cliente, ajudando a gerar agilidade
para os negócios e diminuindo o tempo da tomada de decisão (SUTHERLAND; SCRUM, 2021).
Ao implementar as redes de equipes, é desenvolvido um modelo de referência de atuação, antes
da escalada propriamente dita. Esse modelo compreende um pequeno conjunto de equipes que
precisam estar coordenadas para a entrega dos incrementos em um Scrum de Scrums (SoS). Essa
equipe-referência serve como um protótipo para escalar Scrum para outros conjuntos de equipes.
Os papéis, os artefatos e os eventos do Scrum original são também utilizados no SoS.
Entretanto, ainda que o Guia do Scrum (SUTHERLAND; SCHWABER, 2020) defina o tamanho
ideal do time como sendo de até 10 pessoas, o Scrum@Scale se baseia em uma pesquisa (HACKMAN,
2002) que sugere que o tamanho ideal de equipes é por volta de quatro a seis pessoas. De forma
análoga, é recomendado que esse padrão siga sendo o mesmo para o número de times em um SoS.

Figura 47 – Scrum of Scrums (SoS) de cinco times

Fonte: Sutherland e Scrum (2021, p. 7).

Notadamente, dependendo do tamanho e da complexidade do produto a ser desenvolvido,

mais de um SoS pode ser necessário. Nesses casos, um Scrum de Scrum de Scrums (SoSoS) pode
ser criado a partir de múltiplos Scrums de Scrums.

7
Disponível em: <https://www.Scrumatscale.com>.

77
 Figura 48 – Exemplo de Scrum of Scrums of Scrums (SoSoS)

Fonte: Sutherland e Scrum (2021, p. 8).

As versões escaladas dos eventos de daily Scrum e retrospectiva são facilitadas por um Scrum
of Scrums Master (SoSM). Na prática, o SoSM é responsável por garantir que todos os eventos
ocorram da maneira mais produtiva possível. Esse papel pode ser assumido por um dos SMs de
cada equipe Scrum ou por uma pessoa especialmente dedicada.
Já a sprint review e o refinamento do product backlog são facilitados por uma equipe de POs
guiada por um chief product owner (CPO). O sprint planning escalado é feito com a equipe de
POs e SMs. Para cada SoS, existe um backlog comum compartilhado que alimenta a rede de times
Scrum. Esse processo requer um time de POs e um CPO responsável por essa coordenação. O foco
principal da equipe é garantir que as prioridades das equipes individuais sigam um mesmo caminho.
Isso permite a coordenação de eventuais pendências das equipes individuais e também a construção
de um alinhamento com os stakeholders e as suas necessidades.
A daily tem basicamente a mesma função da daily original em cada time Scrum, só que como
está na perspectiva em escala, precisa entender o progresso coletivo e ser sensível aos impedimentos
levantados por cada equipe. Logo, pelo menos um representante de cada equipe participa de um
Scaled Daily Scrum (SDS), visando levantar possíveis impedimentos para cada equipe e
intraequipes, as interdependências mapeáveis, entre outros pontos.
A eficácia do SoS está diretamente ligada à capacidade da sua governança dentro do conceito
de burocracia mínima viável citado anteriormente. Desse modo, temos dois grupos de liderança
embutidos nessa configuração: um fórum denominado Executive MetaScrum (EMS) com foco no
que é produzido pelo SoS e uma Executive Action Team (EAT) que mira em como fazer isso da
maneira mais rápida.

78
 O EAT cumpre as responsabilidades do Scrum Master para toda organização. Essa equipe de
liderança cria um ecossistema ágil que permite que o modelo de referência funcione de forma
otimizada, conforme a Figura 49, a seguir.

Figura 49 – Exemplo de EAT coordenando cinco grupos de 25 times Scrum

Fonte: Sutherland e Scrum (2021, p. 11)

79
 Figura 50 – EMS e EAT coordenando cinco SoS de dois, três, quatro e cinco times

Fonte: Sutherland e Scrum (2021, p. 18)

No EMS, o CPO cumpre o papel de product owner para toda organização. É o fórum no
qual as lideranças e outras partes interessadas expressam as suas necessidades e as suas prioridades
para a equipe PO. Em nenhum outro momento durante o sprint, essas decisões devem ser feitas.
No contexto do EMS, é definida a visão organizacional, as prioridades estratégicas e o alinhamento
de todos os times em torno dos objetivos em comum.
Como é possível observar, o Scrum@Scale cresce em um formato fractal em relação aos
diversos times de desenvolvimento Scrum, mas mantendo fortemente os alicerces do Scrum como
base, o que possibilita uma visualização bem singular e compreensível do modelo como um todo.

80
Nexus
O Nexus 8 foi criado em 2015 e é mantido até hoje por Ken Schwaber, um dos pais do Scrum.
Trata-se de um framework que consiste em papéis, eventos, artefatos e técnicas que unem e
entrelaçam o trabalho de aproximadamente três a nove equipes Scrum trabalhando em um único
product backlog para construir um incremento integrado que atenda a uma meta de produto
(SCRUM.ORG, 2018).

Figura 51 – Framework Nexus

Fonte: Scrum.Org (2018, p. 5)

Na estrutura do Nexus, existe apenas um PO que gerencia um único product backlog,

visando à geração de um incremento integrado. Como no Scrum “puro”, os artefatos, os papéis e
os eventos são os mesmos, com algumas adições e regras a mais, visando à integração das equipes.
O refinamento do product backlog ganha uma importância maior no Nexus, dado que ajuda os
times a prever quais histórias serão entregues por quais times, ajudando inclusive a identificar
dependências entre as equipes. A duração e a frequência do refinamento vão depender das
dependências e do grau de incerteza inerente ao product backlog.
O sprint planning visa à coordenação de todos os times em cada sprint. O PO cumpre o seu
papel de priorização das histórias a serem selecionadas para a sprint backlog, com as dependências
identificadas e removidas por meio do refinamento feito no product backlog. O planejamento da sprint
estará completo quando cada time estiver com o seu sprint backlog montado. O resultado da sprint
planning envolve: uma meta da sprint Nexus que se alinha com a meta do produto e descreve a
finalidade que será alcançada durante a sprint; uma meta da sprint para cada time que se alinha com a
meta da sprint Nexus; um único Nexus sprint backlog que representa o trabalho em direção à meta da
sprint Nexus e torna as dependências entre equipes transparentes; um sprint backlog para cada equipe.

8
Disponível em: <https://www.Scrum.org/resources/nexus-guide>.

81
 O sprint backlog no Nexus compreende as histórias selecionadas nos sprint backlogs de cada
time envolvido. Atualizado diariamente, muitas vezes como parte da próxima daily Scrum. Nessa
reunião diária, membros selecionados de cada equipe verificam o que já foi feito em termos de
incremento e fazem com que se torne transparente qualquer problema relativo à integração ou às
dependências. O objetivo da reunião diária é justamente identificar quaisquer problemas de
integração e inspecionar o progresso em direção à meta da sprint. Melhor dizendo, a saída da daily
Scrum serve de insumo para o plano de trabalho de cada time individualmente. O daily Scrum de
cada equipe complementa o Nexus daily Scrum criando planos para o dia. Obviamente, a
comunicação entre as equipes pode ocorrer ao longo do dia para discussões mais detalhadas sobre
adaptações prementes.
Como no Scrum tradicional, a sprint review do Nexus é utilizada para obter feedback do
incremento integrado que foi entregue, além de congregar a revisão individual de cada equipe.
Como todo o incremento integrado é o foco para capturar feedback das partes interessadas, o evento
de sprint review no Nexus substitui sprint reviews individuais de time.
A sprint retrospective no Nexus conclui a sprint e envolve planejar maneiras de aumentar a
qualidade e a eficácia de todo o framework. O Nexus inspeciona como foi a última sprint em relação a
indivíduos, times, interações, processos, ferramentas e DoD. Além de melhorias individuais da equipe,
as retrospectivas da sprint das equipes Scrum complementam a retrospectiva geral da sprint Nexus.
Existe um papel no Nexus denominado “equipe de integração” (Nexus Integration Team),
cuja responsabilidade é garantir que um incremento integrado feito e produzido pelo menos uma
vez em uma sprint. Ele fornece o foco que torna possível a responsabilidade de vários times Scrum
se unirem para criar incrementos que gerem valor. A integração inclui questões técnicas e não
técnicas, além de potenciais impedimentos que afetem o time multifuncional. A equipe é formada
pelo PO, pelo SM e pelos demais membros apropriados do time Scrum. Membros apropriados são
as pessoas com habilidades necessárias e conhecimento para ajudar a resolver os problemas que o
Nexus enfrenta a qualquer momento, sendo que essa composição pode ser alterada com o tempo.
Como é possível notar, o Nexus mantém a essência de ser o Scrum, mas coloca um foco
muito grande na integração que se faz necessária entre as equipes, visando dar um tratamento
adequado às interdependências que, normalmente, são tão abundantes quanto críticas no
desenvolvimento de produtos.

82
Large-Scale Scrum
Parecido em vários aspectos com o Nexus, o framework Large-Scale Scrum (LeSS) 9 foi
lançado em 2008 com base nas experiências de Craig Larman e Bas Vodde. O modelo incrementa
o Scrum para comportar a sua aplicação em escala, mas sem perder a sua essência original e baseada
em alguns princípios alinhados com a filosofia Lean e diversas derivadas da sua aplicação, como a
teoria das filas, o pensamento sistêmico, o foco no cliente e no produto sendo desenvolvido, a
transparência e o aprendizado contínuo. Deixa claro também que o LeSS é, na verdade, o Scrum
regular com adição de algumas regras e alguns procedimentos para trabalhos em larga escala, com
times e locais múltiplos (LARMAN; VODDE, 2016). Podendo ser utilizado para equipes de
dezenas, centenas e até milhares de pessoas, nos mais diversos tipos de produtos.

Figura 52 – Framework LeSS

Fonte: Disponível em: <https://less.works/pt/less/framework/index>.

A dinâmica do LeSS (Figura 52) para até oito times concorrentes contempla um product
owner dando a visão do que será produzido e responsável por um product backlog único para as
equipes, e não um PB para cada equipe. A ideia é a entrega de um produto potencialmente utilizável
a cada sprint, de forma iterativa e incremental, só que, como estamos falando do Scrum em escala,
times múltiplos desenvolvem esse grande produto em um sprint compartilhado.
A estrutura do LeSS pressupõe um time autogerenciado, multifuncional e, preferencialmente,
próximo dos outros. O papel do Scrum master é em tempo integral e pode atender de um a três
times. A sprint é a nível de produto, não uma sprint diferente para cada time, sendo iniciada e
finalizada ao mesmo tempo. O resultado de cada sprint é um produto completo e integrado.

9
Disponível em: <https://www.less.works>.

83
 O evento de sprint planning consiste em duas partes que podem ser resumidas naquilo que
será realizado e como. A sprint planning 1 foca a seleção de itens do product backlog central e a
definição da meta da sprint. A sprint planning 2 é uma reunião separada por time, na qual cada
equipe cria o seu plano para chegar à definição de feito (DoD) durante a sprint. Cada time passa a
ter o seu próprio sprint backlog, com as suas respectivas histórias, tarefas e o seu plano de ação.
Cada time autogerenciado realiza também a sua própria daily meeting. Durante a sprint, o time
desenvolve as histórias selecionadas, enquanto colabora entre si e garante a integração entre equipes.
Essa coordenação entre times é decidida pelos próprios times, sem nenhum tipo de papel extra
visando a esse controle. Aliás, o LeSS traz consigo o conceito de just talk, o qual, em outras palavras,
sugere que as pessoas entre elas são capazes de resolver problemas relativos a dependências e
integração.
Temos apenas uma sprint review para que os times e os stakeholders possam explorar o que
foi entregue e determinar o próximo melhor produto a ser desenvolvido. Cada time faz uma
cerimônia própria de retrospectiva para inspecionar e adaptar a sua maneira de trabalho. Entretanto
os times, incluindo os POs e os SMs, fazem uso de um overall retrospective, para promover uma
retrospectiva geral e explorar potenciais impedimentos sistêmicos à geração de valor. Todo processo
é repetido a cada novo ciclo, sempre de forma empírica, visando ao aprendizado contínuo.
Ainda que os eventos de sprint planning, review e retrospective sejam realizados por todas as
equipes ao mesmo tempo, o refinamento do product backlog não precisa ser síncrono. Como explicado
no módulo 2, o refinamento é necessário a cada sprint para deixar as histórias preparadas para as
próximas sprints. Na metade da sprint, os times dão uma pequena parada para promover esse
refinamento.
Para equipes maiores que oito times em paralelo, existe a opção ainda do LeSS Huge, que
expande o framework para mais áreas e pessoas da organização, com algumas mudanças em termos
de cerimônias e criação de papéis.

Disciplined Agile
O Disciplined Agile (DA)10 foi propositalmente deixado por último nesta nossa singela
compilação de modelos de escalada ágil porque ele pode ser considerado como um toolkit estruturado
que orienta o processo de escalada organizacional a partir da compreensão do contexto em que será
aplicado.
Para entendermos o seu funcionamento, é importante conhecermos a sua origem, que foi na
IBM por meio de uma equipe de RUP liderada por Scott Ambler, que incluía também Mark Lines
em 2009. Ambos foram os criadores do modelo publicado inicialmente em 2012 (AMBLER;
LINES, 2020), que passou a ser de propriedade do Disciplined Agile Consortium em outubro do
mesmo ano. O foco inicial era desenvolver uma abordagem flexível e sensível à conjuntura do

10
Disponível em: <https://disciplinedagileconsortium.org>.

84
ambiente para DevOps e processos de TI. Com o tempo, o DA foi tendo a sua visão ampliada e
modernizada até o lançamento da sua quinta versão em 2020. O PMI anunciou a aquisição do DA
em agosto de 2019, e a sua utilização só vem crescendo desde então (DIGITAL.AI, 2020).
O modelo prescreve quatro camadas inter-relacionadas entre si na medida da escalada:
i) Foundation; ii) Disciplined DevOps; iii) Value Streams; e iv) Disciplined Agile Enterprise (DAE),
conforme a Figura 53. A primeira camada – foundation – funciona como a base conceitual do kit de
ferramentas DA, uma vez que inclui os princípios, as promessas e as diretrizes da mentalidade DA, os
conceitos fundamentais de Agile, Lean, abordagens seriais, funções e papéis da equipe, além do
alicerce para a escolha da sua forma de trabalhar (WoW), que é a filosofia básica por trás da agilidade.

Figura 53 – Camadas do Discipline Agile

Fonte: Ambler e Lines (2020, p. 10)

A camada de Disciplined DevOps estende a abordagem DevOps tradicional para a inclusão

de segurança e o gerenciamento de dados, de forma a propiciar resultados mais eficazes para a
organização. Também reconhece que, para situações em que se está lidando com centenas e até
mesmo milhares de sistemas, as atividades help desk e gerenciamento de release precisam ser
robustas. É nessa camada que se encontra o Disciplined Agile Delivery (DAD).
O DAD é a parte do kit de ferramentas do DA. Trata-se de uma abordagem híbrida ágil voltada
para o aprendizado e para as pessoas, orientada à geração de valor e escalável. É importante notar que

85
não se trata de uma metodologia. Inclusive, se o Scrum – ou outro método ágil – já estiver sendo
utilizado, segundo os autores, já se estaria fazendo uso de uma variação de um subconjunto do DAD.
Os papéis no modelo incluem um team lead, equivalente a um SM; PO; membros da equipe;
e um architect owner, responsável por orientar o time quanto às decisões relativas à arquitetura e
ao design, além de alguns papéis de suporte a essa equipe principal.
O mais interessante é que o DAD reconhece vários tipos de ciclos de vida à escolha da
organização, não prescrevendo uma fórmula única de trabalho e se autointitulando pragmático e
agnóstico nesse sentido. Na prática, o DAD constitui uma base flexível a partir da qual podemos
escalar a agilidade por meio de outros métodos. Isso ocorre porque as equipes enfrentam situações
diferentes, circunscritas por culturas igualmente distintas. Por conseguinte, um único ciclo de vida
não serve para todos da mesma forma. Reconhecendo esse fenômeno, o DAD oferece alguns
instrumentos para a análise de contexto. Entre eles, o fluxograma da Figura 54, a seguir:

Figura 54 – Fluxograma para a escolha de um ciclo de vida inicial

Fonte: adaptado de Ambler e Lines (2020, p. 98)

86
 Os tipos de ciclo de vida utilizados no fluxograma se encontram mais bem detalhados no
Quadro 3, a seguir. A curiosidade é que o DA considera também o ciclo de vida cascata – serial –
dentro das possibilidades, dependendo da maturidade da equipe, do ambiente etc.

Quadro 3 – Comparação entre ciclos de vida

ciclo de vida tipo de time time to market quando usar

ágil projeto médio equipes novas na prática ágil

equipes disciplinadas com

lean projeto rápido
requisitos em rápida evolução

entrega contínua: produto

rápido times de longa duração
ágil (vida longa)

entrega contínua: produto times de longa duração

muito rápido
lean (vida longa) disciplinados

identificação de um novo
produto ou serviço para o
exploratório/ mercado em que há um alto
experimental rápido
lean startup risco de mal-entendido sobre
as necessidades dos usuários
finais em potencial

quando se tem uma equipe de

programa
projeto médio projeto ágil muito grande,
(team of teams)
organizada em “time de times”

situações de baixo risco em

que os requisitos são estáveis,
cascata/serial projeto lento
e o problema tem uma solução
bem conhecida

Fonte: adaptado de Full delivery life cycles. Disciplined Agile, 2021.

Disponível em: <https://www.pmi.org/disciplined-agile/lifecycle#Lifecycles>.

87
 Independentemente do ciclo de vida adotado, para que a governança funcione de uma forma
mais profícua, o DAD é construído sobre a égide de quatro fases: inception, construction, transition
e ongoing. A fase de inception é a que conduz todo o trabalho inicial do projeto. Mesmo
considerando que o próprio termo “fase” não é muito comum na comunidade ágil, a realidade é
que as equipes acabam fazendo um trabalho pré-desenvolvimento – no segundo módulo do curso,
falamos sobre a expressão sprint zero, que também é utilizada de forma equivocada – até para que
todos tenham a visão do que será produzido.
Já na fase de construction, uma equipe desenvolverá de fato um produto potencial. Isso pode
ser feito por meio de um conjunto de iterações, por meio de uma abordagem lean, ou qualquer
outro dos ciclos de vida oferecidos, dependendo do WoW do time. Na transition, os times vão fazer
a passagem do produto para operações – handover – tentando otimizar os seus processos para que,
com o tempo, essa fase se torne mais curta e, preferencialmente, desapareça da adoção de estratégias
de implantação contínua. Finalmente, a fase de ongoing é aquela que permeia todas as demais fases
e procura evoluir sempre tanto as pessoas, quanto a estrutura como um todo.
A abordagem adotada pelo DAD é orientada a objetivos visando guiar as pessoas nas decisões
relacionadas ao processo que elas precisam tomar para adaptar e dimensionar estratégias ágeis, dado
o contexto da situação que enfrentam, para alcançar os resultados que almejam. São definidos 21
objetivos de processos distribuídos dentro das quatro fases anteriormente mencionadas, cada qual
com os seus respectivos pontos de decisão. O DAD sugere um conjunto de opções técnicas para
cada ponto de decisão de cada processo e, inclusive, indicando qual a opção seria a mais
recomendada entre as possíveis. Essa talvez seja uma das contribuições mais significativas do DA na
medida em que oferece um guia para determinar qual técnica tem maior potencial de resultado em
função de cada contexto.
Foge ao escopo deste material a descrição de cada um dos processos, mas, apenas a título de
visualização, segue a Figura 55, a seguir, contendo um mapa de objetivos de processos por fase do DAD.

88
 Figura 55 – Objetivos de processos por fase do DAD

Fonte: How to read process goal diagrams. Disciplined Agile, 2021.

Disponível em: <https://www.pmi.org/disciplined-agile/process-goals>.

A camada de value streams abrange os recursos necessários para a geração de fluxos de valor
aos clientes. Um fluxo de valor é formado pelo conjunto de ações que ocorrem para agregar valor
aos clientes, desde a solicitação inicial, passando por vários estágios, por uma ou mais equipes de
desenvolvimento, até a realização do valor em si.
Finalmente, a camada de Disciplined Agile Enterprise (DAE) é aquela que percebe e responde
mais rapidamente às mudanças do mercado. Isso é feito por meio da sua estrutura organizacional e
da sua cultura, que facilita a mudança dentro da circunstância que enfrenta. Essas organizações exigem
uma mentalidade de aprendizado e processos básicos enxutos e ágeis para impulsionar a inovação.
Uma consideração indispensável é que, para que qualquer um desses modelos de escalada
estudados possa ser implantado com maior probabilidade de sucesso, é interessante que ocorra um
movimento intencional da organização nesse sentido. Significa dizer que é preciso prever que
resistências aos caminhos da agilidade são muito comuns e passíveis de serem enfrentadas.
Mudanças culturais não são triviais e muitas vezes precisam envolver também alterações de
responsabilidades, hábitos e hierarquias, entre outras questões.
Como é possível perceber, a escalada ágil não envolve apenas um conjunto de regras e
mudanças de processos, mas transformações na própria estrutura e políticas organizacionais com
base no pensamento sistêmico. Só o fato de o time ser multifuncional, autogerenciado e autônomo
nas suas decisões já demanda uma mentalidade diferente da atuação por parte da organização.

89
 Normalmente, as equipes são formadas por funcionalidade, o que significa que o foco é
totalmente centralizado no cliente final, e não em uma estrutura hierárquica ou componentes
internos pré-existentes. A autonomia dos times é alinhada com a estratégia organizacional,
incentivando uma resposta natural à complexidade por meio da adaptação e de uma gestão que
canaliza as energias nas pessoas e no seu propósito.

Conclusão
Neste último módulo, vimos como a gestão de riscos é feita no Scrum. Aliás, exploramos o
fato de que o próprio framework é uma forma de mitigação de riscos em si. Também falamos de
uma prática muito comum no mercado, que é o uso do Scrum junto ao método Kanban.
Investigamos semelhanças e diferenças entre ambos. Ao final, apresentamos diversos modelos de
escalada que servem como ponto de partida para aqueles que almejam implantar Scrum em vários
times da sua organização.

90
BIBLIOGRAFIA
ABILLA, P. 2006. Team dynamics: size matters redux. Shmula, 24 de fevereiro de 2008. Disponível
em: <http://www.shmula.com/team-dynamics-size-matters-redux/182>.

AGILE BUSINESS CONSORTIUM. Agile PM Handbook. London: APMG International,

2017. v. 2.

AMBLER, S.; LINES, M. Choose your WoW! A disciplined Agile delivery handbook for
optimizing your way of working (WoW). Disciplined Agile. Edição do Kindle, 2020. v. 1 e 2.

ANDERSON, D.; CARMICHAEL, A. Essential Kanban condensed. Seattle: Kanban University,

2016.

BALLÉ, M; JONES, D.; CHAIZE, J.; FIUME, O. A estratégia Lean. Porto Alegre: Bookman, 2019.

BALOG, K. The concept and competitiveness of Agile organization in the fourth industrial
revolution’s drift. Strategic Management, v. 25, n. 3, p. 10-32, 2020.

BARCAUI, A. Fundamentos de gerenciamento de projetos. Rio de Janeiro: FGV, 2019.

BARCAUI, A. Agilidade. In: COSTA, H. (Org.). Gestão empresarial. Edição do Kindle, 2020,
p. 197-201.

BECK, M.; BEEDLE, M.; BENNEKUN, A. Van.; COCKBURN, A.; CUNNINGHAM, W.;
FOWLER, M.; GRENNING, J.; HIGHSMITH, J.; HUNT, A.; JEFFRIES, R.; KERN, J.;
MARICK, B.; MARTIN, R. C.; MELLOR, S.; SCHWABER, K;, SUTHERLAND, J.;
THOMAS, D. The manifesto for Agile software development, 2001. Disponível em:
<http://www.agilemanifesto.org>.

BOEHM, B. Software engineering economics. New Jersey: Prentice Hall, 1980.

COCKBURN, A. Agile software development: the cooperative game. Boston: Addison-Wesley, 2006.

COHN, M. User stories applied: for Agile software development. Boston: Addison-Wesley, 2004.

COHN, M. Agile estimating and planning. Boston: Addison-Wesley, 2006.

91
DEGRACE, P.; STAHL, L. H. Wicked problems, righteous solutions: a catalogue of modern
software engineering paradigms. New Jersey: Yourdon Press, 1990.

DENNING, S. The age of Agile. New York: Amacon, 2018.

DENNING, S. The quest for genuine business agility. Strategy & Leadership, v. 48, n. 1, p. 21-28,
2020.

DIGITAL.AI. 14th Annual State of Agile Report, 2020. Disponível em:

<https://stateofagile.com/#ufh-i-615706098-14th-annual-state-of-agile-report/7027494>.

HACKMAN, R. Leading teams: setting the stage for great performances. Boston: Harvard
Business Press, 2002.

HIGHSMITH, J. Agile project management: creating innovative products. MA, USA: Addison-
Wesley, 2004.

KNIBERG, H. Scrum and XP from the trenches. Toronto: C4Media, 2007.

KNIBERG, H.; SKARIN, M. Kanban and Scrum: making the most of both. Toronto: C4Media,
2010.

LADAS, C. Scrumban: and other essays on Kanban systems for Lean software development. Seattle:
Modus Cooperandi, 2008.

LALSING, V.; KISHNAH, S.; SAMEERCHAND, P. People factors in Agile software

development and project management. International Journal of Software Engineering &
Applications (IJSEA), v. 3, n. 1, p. 117-137, 2012.

LARMAN, C.; VODDE, B. Practices for scaling lean and Agile development. Boston: Addison-
Wesley, 2010.

LARMAN, C.; VODDE, B. Large-scale Scrum: more with LeSS. Boston: Addison-Wesley, 2016.

LEOPOLD, K. Rethinking Agile: why Agile teams have nothing to do with business agility.
Vienna: LEANability, 2019.

92
MEYER, P. The Agile shift. New York: Bibliomotion, 2015.

MORAN, A. Risk management in Agile projects. Isaca Journal, v. 2, n. 1, p. 1-4, 2016.

PATTON, J. User story mapping. California: O’Reilly Media, 2014.

PROJECT MANAGEMENT INSTITUTE (PMI). Agile practice guide. Newton Square: PMI, 2018.

RAMASESH, R.; KULKARNI, S.; JAYAKUMAR, M. Agility in manufacturing systems: an

exploratory modeling framework and simulations. Integrated Manufacturing Systems, v. 12, n. 6,
p. 534-548, 2001.

RIES, E. Lean startup. Los Angeles: Crown Business, 2011.

SCRUM.ORG. The Nexus Guide, 2021. Disponível em: <https://Scrumorg-website-

prod.s3.amazonaws.com/drupal/2021-01/NexusGuide%202021_0.pdf?nexus-
file=https%3A%2F%2FScrumorg-website-prod.s3.amazonaws.com%2Fdrupal%2F2021-
01%2FNexusGuide%25202021_0.pdf>.

STEEL, P.; KONIG, J. Integrating theories of motivation. Academy of Management Review,

v. 31, n. 4, p. 889-913, 2006.

SUTHERLAND, J. Scrum: a arte de fazer o dobro do trabalho na metade do tempo. São Paulo:
Leya, 2014.

SUTHERLAND, J.; SCHWABER, K. The Scrum Guide, 2020. Disponível em:

<https://www.Scrumguides.org/docs/Scrumguide/v2020/2020-Scrum-Guide-Portuguese-
European.pdf>.

SUTHERLAND, J.; SCRUM Inc. The Scrum@Scale Guide, 2021. Disponível em:
<https://www.Scrumatscale.com/Scrum-at-scale-guide>.

TAKEUCHI, H.; NONAKA, I. The new product development game: stop running the relay race
and take up rugby. Harvard Business Review, v. 64, n. 1, p. 137-147, 1986.

VACANTI, D. Actionable Agile metrics for predictability. LeanPub: Edição do Kindle, 2016.

93
VERSTRAETE, C. Planning for the unexpected: business agility. Manufacturing Engineer, v. 83,
n. 3, p. 18-21, 2004.

VERWIJS, C.; SCHARTAU, J.; OVEREEM, B. Zombie Scrum survival guide: a journey to
recover. Boston: Addison-Wesley, 2021.

WADHWA, S.; RAO, K. Flexibility and agility for enterprise synchronization: knowledge and
innovation management towards “flexagiligy”. Studies in Informatics and Control, v. 12, n. 2, p.
111-128, 2003.

WAKE, B. Invest in good stories and smart tasks. XP123: Exploring Extreme Programming, 2003.
Disponível em: <https://xp123.com/articles/invest-in-good-stories-and-smart-tasks>.

94
PROFESSOR-AUTOR
ANDRÉ BARCAUI

FORMAÇÃO ACADÊMICA
 Pós-Doutor em Administração pela FEA/USP.
 Doutor em Administração pela UNR.
 Mestre em Sistemas de Gestão pela UFF-RJ.
 Graduado em Tecnologia da Informação e Psicologia, com
formação em terapia cognitivo-comportamental.
 É certificado PMP, PMI-ACP e DASSM pelo Project
Management Institute, em KMP pela Kanban
University, Master Coach pelo Behavioral Coaching
Institute (BCI), Advanced Scrum Master pela Scrum
Alliance, Public-Private Partnerships Foundation (CP3P) pela APMG, SAFe
Agilist e Agile Coaching (ICP-ACC) pela ICAGile.

EXPERIÊNCIAS PROFISSIONAIS
 Palestrante e autor de diversos artigos e livros na área gerencial.
 É membro-fundador do PMI Chapter Rio e hoje faz parte do seu Conselho Consultivo.
 Foi project office manager da Hewlett-Packard Consulting, responsável pela região
Latino-Americana.

95