gerenciando_projetos_produtos_scrum

Prévia do material em texto

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 
 
 
 
 
 
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. 
 
MÓDULO I – INTRODUÇÃO AO SCRUM 
 
8 
 
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. 
 
 9 
 
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 burocracianã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! 
 
10 
 
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. 
 
 11 
 
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. 
 
 
12 
 
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. 
 
 13 
 
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 melhoresdesigns 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. 
 
 
 
14 
 
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 
 
 15 
 
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 
 
16 
 
 
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. 
 
 17 
 
 
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: 
 
 
 
18 
 
Figura 9 – Tipos de ciclo de vida de projetos 
 
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. 
 
preditivo = A B C D E
iterativo =
Não tentar fazer tudo
certo desde o começo.
mudança mudança
A B C D E
incremental =
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
A B C D E
A B C D E A B C D E A B C D E
 
 19 
 
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 
preditivoscontinuarã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.
 
 
 
 
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. 
 
 
MÓDULO II – FRAMEWORK SCRUM 
 
 21 
 
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) 
 
 
22 
 
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. 
 
 23 
 
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 assimque 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 
 
 
 
24 
 
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 
 
 25 
 
 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). 
 
 
26 
 
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. 
 
 27 
 
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 devegarantir 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. 
 
 
28 
 
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 
 
 
 29 
 
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. 
 
 
 
30 
 
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. 
 
 
 
 31 
 
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 
 
 
 
 
32 
 
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). 
 
 
 
 33 
 
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 
 
34 
 
“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. 
 
 
 35 
 
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 
 
 
 
 
36 
 
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 timede 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 
 
 37 
 
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>. 
 
38 
 
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.
 
 
 
 
 
 
 
 
 
 
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. 
 
MÓDULO III – HISTÓRIAS E ESTIMATIVAS 
 
 41 
 
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 
 
 
42 
 
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 qualdetermina 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; 
 
 43 
 
 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. 
 
 
 
44 
 
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. 
 
 
 45 
 
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 ancoragem2 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. 
 
46 
 
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 umafaixa 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. 
 
 47 
 
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. 
 
48 
 
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. 
 
 49 
 
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. 
 
 
 
 
50 
 
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 quaisquermodificaçõ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. 
 
 
 51 
 
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>. 
 
52 
 
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, ... 
 
 53 
 
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 entregarum incremento útil e valioso ao final de uma sprint. 
 
 
 
54 
 
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. 
 
 
 55 
 
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. 
 
 
 
56 
 
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. 
 
 
 
 57 
 
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. 
 
 
 
58 
 
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.
 
 
 
 
 
 
 
60 
 
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. 
 
MÓDULO IV – ASPECTOS AVANÇADOS 
 
 61 
 
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. 
 
 
62 
 
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. 
 
 
 63 
 
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. 
 
 
 
64 
 
Tabela 1 – Análise quantitativa dos riscos 
risco probabilidade 
impacto 
(dias) 
exposição 
ao risco 
(dias) 
sprint 
exposição 
ao risco 
(dias) 
cliente demanda 
manual mais 
detalhado do que 
imaginávamos 
30% 15 4,5 1 24,5 
roteador XPTO 
ficará preso na 
alfândega 
55% 5 2,75 2 20 
não vamos 
conseguir 
formatar o 
relatório ABC a 
tempo 
20% 10 2 3 17,25 
jurídico não estará 
pronto para 
validar o módulo 
JUR 
10% 10 1 4 15,25 
perda de um 
membro da equipe 
em função da 
demanda do seu 
próprio 
departamento 
60% 20 12 5 14,25 
ambiente de 
homologação não 
disponível 
15% 15 2,25 6 2,25 
exposição = 24,5 0 
 
 
 
 65 
 
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 umadas 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. 
 
66 
 
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. 
 
 67 
 
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. 
 
 
 
68 
 
Quadro 2 – Comparativo entre Scrum e Kanban 
Scrum Kanban 
Usa timeboxes (sprints). Não trabalha com timeboxes. 
Descreve papéis a serem seguidos (PO, 
SM, desenvolvedores). 
Não prescreve papéis, ainda que seja 
possível o uso de SDMs e SRMs. 
Usa velocidade como métrica para 
melhoria de processo, isto é, 
histórias/sprint. Uma vez conhecendo a 
velocidade, esta se torna uma orientação 
para o limite de WIP. 
Usa lead time e o througpout como métricas 
para melhoria de processo. 
Costuma fazer uso de gráficos de 
burndown e burnup. 
Costuma fazer uso de CFDs. 
Normalmente, trabalha com estimativas. 
Pode trabalhar com estimativas, mas o foco 
maior é nas prioridades. 
As histórias são quebradas para caber 
dentro de uma sprint. 
Não prescreve nenhum tamanho de história 
em particular. 
O backlog da sprint pertence a um 
determinado time. 
Um quadro Kanban pode ser compartilhado 
por múltiplos times ou pessoas. 
Limita o WIP de forma indireta, por 
iteração (sprint). 
Limita o WIP de forma direta, em função da 
capacidade e do estado do fluxo de trabalho. 
Sugere times multifuncionais. 
Times multifuncionais são opcionais, e o 
quadro Kanban não precisa pertencer a uma 
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 
cada sprint. 
O quadro é, normalmente, persistente. 
Não adiciona itens a uma iteração em 
andamento. 
Pode adicionar itens sempre que houver 
capacidade disponível. 
 
 
 69 
 
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 noScrum, 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. 
 
70 
 
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. 
 
 71 
 
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? 
 
 
72 
 
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>. 
 
 73 
 
A princípio, quando falamos de um time, os artefatos, os eventos e os papéis são muitoparecidos 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>. 
 
 
74 
 
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 
 
 
 75 
 
 
 
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. 
 
 
76 
 
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. 
 
 
 
 77 
 
Scrum@Scale 
O Scrum@Scale7 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>. 
 
78 
 
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 focono 
que é produzido pelo SoS e uma Executive Action Team (EAT) que mira em como fazer isso da 
maneira mais rápida. 
 
 79 
 
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) 
 
 
 
 
80 
 
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. 
 
 81 
 
Nexus 
O Nexus8 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>. 
 
82 
 
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. 
 
 
 
 83 
 
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>. 
 
84 
 
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çãoda 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>. 
 
 85 
 
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 
 
86 
 
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) 
 
 87 
 
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 
lean projeto rápido 
equipes disciplinadas com 
requisitos em rápida evolução 
entrega contínua: 
ágil 
produto 
(vida longa) 
rápido times de longa duração 
entrega contínua: 
lean 
produto 
(vida longa) 
muito rápido 
times de longa duração 
disciplinados 
exploratório/ 
lean startup 
experimental rápido 
identificação de um novo 
produto ou serviço para o 
mercado em que há um alto 
risco de mal-entendido sobre 
as necessidades dos usuários 
finais em potencial 
programa 
(team of teams) 
projeto médio 
quando se tem uma equipe de 
projeto ágil muito grande, 
organizada em “time de times” 
cascata/serial projeto lento 
situações de baixo risco em 
que os requisitos são estáveis, 
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>. 
 
 
 
88 
 
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 otempo, 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. 
 
 
 
 89 
 
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. 
 
 
90 
 
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. 
 
 
 
 
 91 
 
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. 
 
92 
 
 
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. 
 
 
 93 
 
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. 
 
 
94 
 
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>. 
 
 
 95 
 
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. 
 
 
 
 
 
 
 
	INTRODUÇÃO
	SUMÁRIO
	MÓDULO I – INTRODUÇÃO AO SCRUM
	Agilidade
	Manifesto ágil
	Origem do Scrum
	Tipologia de ciclos de vida
	Conclusão
	MÓDULO II – FRAMEWORK SCRUM
	Papéis no Scrum
	Time Scrum
	T-Shaped e I-Shaped
	Product owner
	Scrum master
	Desenvolvedores
	Eventos do Scrum
	Sprints
	Sprint planning
	Daily Scrum
	Sprint review
	Sprint retrospective
	Artefatos e compromissos
	Product backlog
	Sprint backlog
	Incremento
	Entendendo o framework Scrum
	Conclusão
	MÓDULO III – HISTÓRIAS E ESTIMATIVAS
	Histórias de usuário
	Estimativas
	Ideal hours
	Story points
	Dot voting
	T-shirt sizing
	Planning poker
	Gráficos de acompanhamento
	Gráfico de burndown
	Gráfico de burnup
	Conclusão
	MÓDULO IV – ASPECTOS AVANÇADOS
	Gestão de riscos
	Scrumban
	Escalando o Scrum
	Scaled Agile Framework
	Scrum@Scale
	Nexus
	Large-Scale Scrum
	Disciplined Agile
	Conclusão
	BIBLIOGRAFIA
	PROFESSOR-AUTOR
	ANDRÉ BARCAUI
	FORMAÇÃO ACADÊMICA
	EXPERIÊNCIAS PROFISSIONAIS