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 uma