GESTÃO ÁGIL DE PROJETOS

Prévia do material em texto

W
BA
07
63
_V
2.
0
GESTÃO ÁGIL DE PROJETOS
2
Larissa Maria Palacio dos Santos
Londrina
Editora e Distribuidora Educacional S.A.
2023
 GESTÃO ÁGIL DE PROJETOS
1ª edição
3
2023
Editora e Distribuidora Educacional S.A.
Avenida Paris, 675 – Parque Residencial João Piza
CEP: 86041-100 — Londrina — PR
Homepage: https://www.cogna.com.br/
Diretora Sr. de Pós-graduação & OPM
Silvia Rodrigues Cima Bizatto
Conselho Acadêmico
Alessandra Cristina Fahl
Ana Carolina Gulelmo Staut
Camila Braga de Oliveira Higa
Camila Turchetti Bacan Gabiatti
Giani Vendramel de Oliveira
Gislaine Denisale Ferreira
Henrique Salustiano Silva
Mariana Gerardi Mello
Nirse Ruscheinsky Breternitz
Priscila Pereira Silva
Coordenador
Nirse Ruscheinsky Breternitz
Revisor
Quinhones de Santana
Editorial
Beatriz Meloni Montefusco
Carolina Yaly
Márcia Regina Silva
Paola Andressa Machado Leal
Dados Internacionais de Catalogação na Publicação (CIP)_____________________________________________________________________________ 
Santos, Larissa Maria Palacio dos
Gestão ágil de projetos/ Larissa Maria Palacio dos Santos, 
– Londrina: Editora e Distribuidora Educacional S.A 2023.
33 p.
ISBN 978-65-5903-301-0
1. Métricas de agilidade 2. Sprint 3. Scrum I. Título
CDD 371.36
_____________________________________________________________________________ 
 Raquel Torres – CRB 8/10534
S237g 
© 2023 por Editora e Distribuidora Educacional S.A.
Todos os direitos reservados. Nenhuma parte desta publicação poderá ser reproduzida ou 
transmitida de qualquer modo ou por qualquer outro meio, eletrônico ou mecânico, incluindo 
fotocópia, gravação ou qualquer outro tipo de sistema de armazenamento e transmissão de 
informação, sem prévia autorização, por escrito, da Editora e Distribuidora Educacional S.A.
https://www.cogna.com.br/
4
SUMÁRIO
Apresentação da disciplina __________________________________ 05
Da gestão de projetos tradicional à agilidade ________________ 07
SCRUM _______________________________________________________ 19
Kanban ______________________________________________________ 31
Métricas de agilidade ________________________________________ 42
GESTÃO ÁGIL DE PROJETOS
5
Apresentação da disciplina
Olá, aluno!
Nesta disciplina, você aprenderá sobre o universo de gerenciamento 
ágil de projetos de uma maneira bastante abrangente. O início de 
sua jornada se dará entendendo quais as raízes da agilidade – o lean 
manufacturing - e que a influenciam até os dias atuais. Aprender sobre 
as origens da agilidade será um diferencial para que você não só 
aprenda sobre alguns dos métodos e frameworks adotados, mas que 
também consiga desenvolver um raciocínio lógico que o leve a tomar 
decisões ágeis no dia a dia e impulsionar os resultados do seu trabalho, 
independentemente do contexto no qual você atua.
O estudo sobre os frameworks e métodos inicia com a apresentação do 
manifesto ágil e um estudo mais aprofundado sobre scrum. O scrum é 
hoje o framework ágil mais famoso no mercado, e nesta disciplina você 
aprenderá tudo o que está no scrum guide, com um viés de aplicação 
prática e detalhada, perpassando o conhecimento de conceitos, papéis, 
composição de times, gerenciamento de backlog, planejamento, 
acompanhamento e finalização de sprints. 
Você também terá a oportunidade de aprender sobre o método kanban, 
entendendo sobre seu conceito, suas cadências, filosofia e como 
implementá-lo para conseguir promover um processo de melhoria 
contínua em times e organizações. 
Por fim, você aprenderá sobre as métricas de agilidade, que são 
essenciais para auxiliá-lo a implementar e propor os kaizens – melhorias 
– embasados em dados, métricas e indicadores. Dentre as principais 
6
métricas trabalhadas abordaremos leadtime, throughput, Wip, gráficos de 
burndown e burnup. Esses indicadores serão um guia para orientar seu 
trabalho, independentemente do papel que você ocupa na organização, 
o que o ajudará a ser um agente de mudanças que provoca evoluções! 
7
Da gestão de projetos tradicional 
à agilidade
Autoria: Larissa Maria Palacio dos Santos
Leitura crítica: Quinhones de Santana
Objetivos
• Apresentar aos alunos as influências do lean no novo 
modelo de gestão.
• Mostrar como o processo de gerenciamento 
tradicional de projetos foi sendo transformado ao 
longo dos últimos anos.
• Explicar o manifesto ágil e seus principais conceitos.
8
1. Novo mundo, nova gestão
Não é novidade que o mundo das indústrias e da gestão vêm passando 
por inúmeras mudanças no decorrer das últimas décadas. Com tantas 
inovações surgindo para facilitar a vida das pessoas, das empresas e dos 
trabalhadores, tornar-se obsoleto o movimento que ocorre caso você 
não aja de forma inovadora, disruptiva e esteja à frente do mercado.
Hoje, a era industrial, na qual as empresas criavam mercado, ficou para 
trás e deu espaço a um novo cenário onde a criação do produto visa 
solucionar as dores dos consumidores ou criar um benefício para estes. 
Caso essas afirmações ainda não estejam fazendo sentido, basta pensar 
em inúmeras soluções que surgiram nos últimos anos e modificaram 
nosso modo de viver e interagir em sociedade: temos os bancos digitais, 
por exemplo, que nos levaram a um novo patamar de atendimento, em 
que quase todas as operações bancárias podem ser feitas na palma 
da mão, ou o pix, para facilitar o pagamento sem moeda ou cartão, 
que ganhou tanta força recentemente. Outros exemplos poderiam ser 
citados por aqui, por horas a fio, como serviços de transporte, solicitação 
de alimentos, ou leitura por aplicativos. 
Hoje o cenário do mercado é ditado cada vez mais pelo cliente e este 
deve estar no centro de todas as operações das empresas. Do lado 
positivo, ganhar escala e reconhecimento tornou-se muito mais fácil e 
rápido devido à possibilidade de replicação em rede que a internet e as 
redes sociais permitem.
O ambiente no qual vivemos atualmente tem sido chamado, desde 
a década de 1990, de mundo VUCA. Essa expressão surgiu na 
Universidade do Exército Norte-Americano – United States Army War 
College - e o acrônimo significa volátil, incerto, complexo e ambíguo 
(volatile, uncertain, complex, ambiguous). 
9
A velocidade diz respeito às mudanças que surgem diariamente no 
ambiente e que implicam desafios cada vez maiores às empresas, à 
medida que implementam mudanças no mercado. Tudo isso coloca as 
empresas em uma condição de obrigatoriedade de reagir, ser ágil, ser 
flexível e adaptar-se para sobreviver.
Tudo o que sabemos é que sempre haverá mudanças, ou seja, daí 
vem a palavra incerteza, dentro do acrônimo VUCA. A competição 
entre empresas está cada dia mais acirrada, obrigando as empresas 
a se planejarem, sabendo que precisarão rever seus planos com uma 
periodicidade curta, para que se adaptem às mudanças externas. É por 
esse motivo que aprofundaremos um pouco mais à frente que os ciclos 
de planejamento foram encurtados. Em outros tempos a administração 
previa planejamentos para cinco ou dez anos à frente, pois considerava 
o cenário externo como algo estável. Hoje sabe-se que a realidade 
mudou, e que é impossível prever de forma precisa o que faremos em 
10 anos. 
O termo “complexo”, por sua vez, remete novamente à aceleração no 
ritmo imposto pelo mercado atual e reforça a questão das incertezas 
sobre o futuro. Conviver com a incerteza exige flexibilidade e adaptação. 
A complexidade exige pensar além das relações de causa e efeito, e 
considerar influências de diferentes naturezas afetando o negócio e 
sendo por ele afetado. É por isso que temos uma nova premissa: a do 
aprendizado rápido e do teste. 
Por fim, o “A”, de VUCA, significa ambíguo, isto é, a precisão caiu por 
terra, dando margem sempre à possibilidade de inúmeros caminhos, 
rotas e estratégias a serem seguidos. Ao analisar oportunidades e ou 
desafios é preciso refletir sob diferentes aspectos, trazendo diferentes 
olhares, considerando que aquilo que eu sabia ontem pode não 
ser o melhor paraessa situação. Sendo assim, é preciso aprender a 
reaprender. 
10
2. Do modelo tradicional ao novo modelo
Se temos como premissa básica para o atual contexto a falta de 
previsibilidade acerca do futuro, aliada a tantas mudanças ocorrendo no 
cenário atual, é mais do que certo que o modelo de gestão precisa ser 
transformado também. 
O gerenciamento de projetos deve permitir que a empresa se adapte 
com rapidez às flutuações do mercado. Na antiga gestão, a palavra 
da moda à época era eficiência, ou seja, a capacidade de ser efetivo, a 
produtividade, o errar menos. Hoje, temos, pelo contrário, um cenário 
de abertura ao erro, onde este nos permite ter um aprendizado. 
Ninguém aqui está defendendo errar constante e irrestritamente, mas 
sim defendendo que as empresas e pessoas em posição de gestão 
devem arriscar-se ao erro quando se permitem testar coisas novas, 
implementar soluções, trazer ideias de negócios. A ideia é que ao errar, 
deve-se rapidamente perceber o erro e utilizá-lo como um gatilho de 
aprendizagem, promovendo a seguir um novo ciclo de melhorias. 
A palavra da vez é eficácia, ou seja, considerar a coisa certa a ser 
feita para os momentos e pessoas adequadas. Respeita-se aqui a 
individualidade das pessoas, especialmente os clientes, e percebe-se o 
quanto é possível aprender a cada interação. Sutherland e Sutherland 
(2018, p. 28) afirmam que “planejar é útil, seguir cegamente os planos é 
burrice”. 
A origem da agilidade nos remete ao sistema Toyota de produção 
(TPS) ou Lean Manufacturing (Manufatura Enxuta), criada logo após a 
Segunda Guerra Mundial. Muitos de seus princípios foram reescritos e 
repensados, mas influenciaram fortemente o manifesto ágil. 
Dentre os princípios norteadores temos a eliminação de desperdícios 
como destaque. O lean iniciou baseado na gestão de estoques, 
propondo uma nova perspectiva de produção sob demanda para 
11
eliminar desperdícios de materiais. Essa filosofia, no entanto, não se 
restringe à técnica de estoque zero e produção sob demanda, mas 
perpassou toda a organização propondo que todo processo, tarefa ou 
atividade que possa ser eliminada assim o seja. Em outras palavras, a 
ideia é que as empresas devem focar sua energia apenas naquilo que 
lhe é essencial. Desta forma, ao aderir à filosofia lean devemos sempre 
estar atentos sobre a real necessidade das coisas.
Outro princípio importante é o de fazer simples as coisas. Existe uma 
tendência em tentarmos mostrar sofisticação, cuidado e zelo que, 
muitas vezes, torna a companhia mais complexa. Soluções simples 
são o que precisamos. É preciso ainda, fazer o certo, no momento 
certo e aceitar as mudanças. Isso reforça o conceito do mundo VUCA 
mencionado anteriormente. 
Por fim, mas não menos importante, temos o fluxo contínuo de 
entregas. 
Entre as décadas de 80 e 90 os desenvolvedores e gerentes de projetos 
de software costumavam fazer longos planejamentos e esforços para 
o controle de atividades, por isso, também usavam documentações 
bastante detalhadas. A ideia era especificar todos os requisitos, 
no entanto, fazer isso é quase impossível, pois no momento do 
planejamento ainda não é possível pensar em detalhes micro. Para 
projetos pequenos, por sua vez, isso é desnecessário. Na gestão de 
projetos tradicional existe uma prática comum de buscar ter uma 
documentação e especificações detalhadas já na fase de planejamento, 
sobre esse tema, Foggetti (2015, p. 15) afirma:
Mesmo para grandes projetos, conseguir especificar todos os requisitos 
antes de começar a construir é quase uma tarefa de vidência! É como se, 
ao fazer a planta de uma casa, já conseguíssemos enxergar com clareza 
onde penduraremos os quadros. Contudo, para projetos menores, todo 
esse tempo gasto com planejamento e acompanhamento é desnecessário, 
12
e uma equipe muito grande pode mais atrapalhar do que ajudar o 
desenvolvimento. 
É por isso que, muitas vezes, o modelo tradicional, ou modelo clássico, é 
conhecido como metodologia orientada à documentação. Esse modelo 
caracteriza-se pelo desenvolvimento em cascata – ou “waterfall” – que em 
outras palavras significa que existe uma sequência de etapas a serem 
seguidas, sendo que uma só se inicia após a conclusão da anterior. Na 
gestão de projetos tradicional, utilizada não só para o desenvolvimento 
de software, mas para inúmeras aplicações no mercado, temos como 
etapas:
1. Definição de requisitos: estabelecimento de objetivos pelos 
clientes e descrição de diversas propriedades.
2. Projeto: normalmente caracterizado pela documentação definida 
de forma técnica para que o executor – programador – consiga 
interpretar.
3. Implementação e teste unitário: manter a capacidade de testar 
todas as entradas e saídas de um sistema. 
4. Integração/testes: combinação dos módulos do software para 
testagem em módulos. Nesta etapa testa-se a solução completa, 
com os módulos integrados, e em ambiente de produção.
5. Operação: o sistema é instalado e implementado, neste momento, 
podem ocorrer erros ou falhas não mapeadas anteriormente, e 
neste caso, elas devem ser corrigidas. Muitas vezes, nesta etapa 
surgem novos requisitos a serem criados. 
A partir da década de 1990 começaram a surgir novos modelos de 
desenvolvimento de softwares, que desta vez se caracterizavam por 
serem menores. Desta forma, diminuiu-se também o tempo investido 
13
em planejamento. Esse novo modelo de gerenciamento de projetos de 
software sofreu grande influência do modelo japonês de produção.
Mas antes de nos aprofundarmos sobre os novos modelos vamos 
compreender os aspectos relacionados ao sucesso em um projeto. 
Muito se fala em entregar os projetos dentro do prazo e orçamento 
como se estes fatores fossem os determinantes para o sucesso de um 
projeto. No entanto, há um outro fator determinante que tem relação 
com o retorno do investimento ao negócio. 
Há uma pressão no mercado para a conclusão dentro do prazo e 
orçamento, e cada vez mais vemos uma mudança de paradigma que 
leva em consideração o retorno financeiro. Sob o ponto de vista de 
projetos, é preciso pensar em três pontos: definição da solução para 
um problema, oportunidade ou necessidade; definição de critérios de 
seleção e priorização das ideias; e, por fim, definição da implementação. 
O gerente de projetos deve também ter algumas habilidades como as 
técnicas, liderança comportamental e gestão estratégica e de negócios. É 
preciso que o gerente ou responsável pelo projeto sempre se certifique 
de calcular o payback (tempo necessário para o projeto se pagar). 
Outro fator importante no novo modelo de gestão de projetos é criar 
soluções e projetos a partir do ponto de vista do cliente, levando em 
consideração suas dores e reais necessidades. 
3. O manifesto ágil
Os planos elaborados pelas empresas, normalmente, são estabelecidos 
com base no que chamamos de triângulo de ferro (Figura 1), que é 
composto pelas dimensões de escopo x tempo x custos. A empresa 
planeja entregar algo (escopo) em um prazo x, e para tanto deve utilizar 
um orçamento previamente estabelecido. 
14
Figura 1 – Triângulo de ferro
 
Fonte: adaptado de Camargo e Ribas (2019).
Então, o que vemos no mercado são organizações dizendo ser ágeis 
e exigindo flexibilidade de seus colaboradores, para que estes sejam 
capazes de reagir bem às mudanças, gerando valor ao cliente, mas, 
pedindo ainda que o time continue seguindo o plano traçado. Esse 
pedido de seguir o plano, por vezes, vem infelizmente junto com 
penalizações. 
Para solucionar este problema, temos as abordagens ágeis de gestão de 
projetos, as quais estão muito mais adaptadas ao contexto de mundo 
VUCA. E a agilidade é justamente a capacidade que uma organização 
tem de adaptar-se ao contexto de mundo, ao ambiente, de forma rápida 
para sobreviver em um ambiente de incertezas e volatilidade advindos 
das constantes mudanças.
Em agilidade, muitas vezes, usamos o termo mindset ágil, fazendo 
referência à forma de organização de pensamentos edo trabalho, e à 
forma como as pessoas se relacionam entre si e com os projetos, de 
modo a gerar valor aos clientes. Isso quer dizer que, embora existam 
metodologias, frameworks e ferramentas ágeis, devemos considerar que 
não existe uma receita de bolo pronta para implementar em qualquer 
empresa qualquer projeto em qualquer contexto. 
15
Para criar um manifesto que se propagasse com tanta força e que 
mudasse os rumos da gestão de projetos no mundo, era necessário 
mais do que apenas um cérebro pensante. A construção foi coletiva e 
colaborativa, contando com um grupo de especialistas. O surgimento do 
manifesto ágil ocorreu conforme o trecho descrito a seguir:
No ano de 2001, um grupo formado por 17 grandes especialistas em 
desenvolvimento de software se reuniu em Utah, nos Estados Unidos, 
em uma estação de ski, para discutir uma nova forma de gerar melhores 
resultados em seus projetos. Eles buscavam uma alternativa ao modelo 
sequencial de desenvolvimento de software (também chamado de cascata 
ou waterfall) vigente até então, o qual somente dava resultados em 
ambientes extremamente estáveis e sem incerteza. Desse encontro, nascia 
o Manifesto Ágil. (CAMARGO; RIBAS, 2019, p. 101)
Este manifesto é guiado por 4 valores e 12 princípios, os quais veremos a 
seguir, e cujo objetivo é encontrar uma melhor maneira de desenvolver 
trabalhos complexos. O trecho a seguir extraído do próprio manifesto 
ágil, diz que:
Estamos descobrindo melhores maneiras de desenvolver 
software fazendo isso e ajudando outros a fazê-lo. 
Através deste trabalho passamos a valorizar: 
Indivíduos e interações sobre processos e ferramentas, 
Software funcional sobre documentação abrangente, 
Colaboração do cliente em vez de negociação de contratos. 
Responder à mudança ao invés de seguir um plano. 
Ou seja, enquanto há valor nos itens da 
direita, valorizamos mais os itens da esquerda. (MANIFESTO et al., 2001)
A Figura 2 ilustra os valores do manifesto que passam a ser mais 
valorizados em detrimento dos outros. 
16
Figura 2 – Valores do manifesto ágil
 
Fonte: adaptado de Camargo e Ribas (2019).
Vamos entender agora o que o manifesto busca dizer com cada um 
desses valores. 
3.1 Indivíduos e interações mais que processos e 
ferramentas 
Na abordagem tradicional de projetos a comunicação com o cliente era 
escassa, sendo que o escopo era captado em uma conversa primária, 
e o projeto era entregue quando finalizado e só então recebia-se um 
feedback. No modelo ágil, as pessoas produzem em ambiente criativo e 
que busca solucionar problemas por meio da comunicação constante. 
Este novo ambiente de trabalho é também mais aberto e inclusivo, as 
pessoas se sentem mais à vontade para trazer ideias, expor opiniões 
e, desta forma, surge a inovação. Os gerentes passam a assumir um 
papel diferente daquele adotado anteriormente e também comumente 
chamado de comando e controle, a ideia agora é que estes possam 
assumir o papel de facilitadores para que sejam capazes de remover as 
barreiras e impedimentos dos times, ajudando-os a serem cada vez mais 
autônomos e auto-organizados. 
17
3.2 Produto em funcionamento mais que documentação 
abrangente
A ideia é que cada vez mais as empresas passem a desenvolver 
ideias e versões enxutas de seus produtos, lançando no mercado (os 
também chamados MVP). A ideia é de que com essas versões enxutas 
disponibilizadas rapidamente ao mercado seja possível obter os 
feedbacks e retroalimentar o processo, gerando mais valor aos clientes. 
A documentação deixa de ser abrangente para ser apenas suficiente 
para que os envolvidos nas tarefas de desenvolvimento entendam o 
que precisa ser feito. Note que aqui há uma influência do pensamento 
lean em não desperdiçar, ou seja, não documentar aquilo que não é 
necessário.
3.3 Colaboração com o cliente mais que negociação de 
contratos
Embora o estabelecimento de contratos ainda continue sendo 
necessário, a ideia é que a empresa seja adaptável e colaborativa com 
relação às especificações do contrato, considerando que o escopo pode 
evoluir. Estar aberto a tais adaptações facilita o relacionamento entre 
empresa e cliente e entre áreas e departamentos organizacionais. 
3.4 Responder a mudanças mais que seguir um plano
Reforçando o que já afirmava o valor anterior, gerar valor ao cliente 
significa, muitas vezes, ser flexível. O planejamento então muda de 
característica e passa apenas a considerar curtos prazos, dias ou 
semanas, desta forma, é possível aceitar mudanças dentro do processo 
e do projeto. 
Ante a todo o exposto, temos que considerar que as mudanças ocorridas 
na forma de gerenciamento de projetos, fortemente influenciadas pelo 
18
sistema Toyota ou Lean de produção e que, culminaram no manifesto 
ágil, decorrem das mudanças impostas pelo mundo, pela aceleração dos 
mercados e pelos consumidores cada vez mais exigentes. O surgimento 
do manifesto ágil e de tais tendências se desdobrou em uma série de 
metodologias e frameworks que facilitaram o dia a dia das empresas.
Referências 
CAMARGO, R.; RIBAS, T. Gestão ágil de projetos. São Paulo: Saraiva Educação, 2019.
FOGGETTI, C. (org.). Gestão ágil de projetos. São Paulo: Pearson, 2015.
MANIFESTO, Agile et al. (org.). Manifesto ágil. 2001. Disponível em: https://
agilemanifesto.org/. Acesso em: 12 mar. 2023.
SHUTERLAND, J.; SHUTERLAND, J. J. Scrum: A arte de fazer o dobro do trabalho na 
metade do tempo. 3. ed. Rio de Janeiro: Leya, 2018.
https://agilemanifesto.org/
https://agilemanifesto.org/
19
SCRUM
Autoria: Larissa Maria Palacio dos Santos
Leitura crítica: Quinhones de Santana
Objetivos
• Aprender sobre o framework scrum e seus principais 
conceitos.
• Conhecer os papéis do scrum, a formação e 
composição de times.
• Entender quais são as principais cerimônias do scrum.
20
1. A essência do framework scrum
O termo scrum é originário do jogo de rúgbi, fazendo referência a 
uma jogada que consiste em uma organização do time que, unidos, 
se movem para avançar com a bola em campo. Nessa jogada “(...) 
tudo se alinha: posicionamento cuidadoso, unidade de propósito e 
clareza de objetivo. Trata-se de uma metáfora perfeita” (SHUTERLAND; 
SHUTERLAND, 2018, p. 16) para o que se espera que os times façam. 
O framework scrum surgiu em contraposição à gestão tradicional 
de projetos que se preocupa demasiadamente com controle e 
planejamento. Observou-se durante muitos anos que os planejamentos 
das empresas levavam horas, semanas, meses para serem realizados, 
contando uma série de documentações para buscar controle e 
previsibilidade e que após todo esse esforço, em geral, os cronogramas 
não eram cumpridos e essa previsão não era assertiva. A ideia do scrum 
é acolher o caos em ambientes de imprevisibilidade, especialmente no 
trabalho do conhecimento. 
Desta forma, o scrum admite que a incerteza faça parte do projeto 
e usa a experiência dos times de promover aprendizados contínuos. 
Aproveita-se aquilo que o time já realiza e oferece insumos para que 
o trabalho seja auto-organizado e retroalimente seus processos, 
aumentando a rapidez e a qualidade das entregas. 
Para que tudo isso seja possível, é preciso considerar um processo de 
inspeção, no qual em intervalos regulares o trabalho é verificado, ou 
seja, o time realiza pausas para repensar e verificar se está no caminho 
correto e se há algo que possa ser melhorado (aqui nota-se um forte 
viés da melhoria contínua, influência do Lean). “O nome disso é inspeção 
e adaptação” (SHUTERLAND; SHUTERLAND, 2018, p. 17).
21
Embora esse framework tenha se originado no universo do 
desenvolvimento de softwares é possível aplicá-lo em diferentes 
contextos tendo também resultados significativos em melhora de 
produtividade. Há diversas formas de se definir o que é scrum, mas 
algumas delas são mais difundidas do que outras. Uma definição 
clássica do modelo scrum seria um framework no qual um grupo 
de pessoas pode tratar e resolver problemas complexos de forma 
adaptativa e evolutiva, criandoprodutos com o mais alto valor agregado 
possível para o cliente (COUTINHO, 2021, p. 52).
Framework, por sua vez, é uma estrutura composta por práticas, 
conceitos e ferramentas de resolução de problemas ou orientadoras. Ou 
seja, se assemelha a um modelo replicável continuamente. 
A estrutura do framework scrum é composta por papéis, eventos e os 
artefatos (atividades que serão gerenciadas). Dizemos framework e não 
metodologia, pois é algo adaptável ao contexto da empresa, não existem 
sequências ou passos a serem seguidos. 
Cada time terá a oportunidade de aprender por intermédio de um 
processo empírico de experimentação, a partir do qual estará apto a 
tomar decisões. A aprendizagem no scrum ocorre ao encerramento de 
cada ciclo – as sprints, que serão estudadas mais à frente.
A base de sustentação do scrum possui três pilares que são; a 
transparência, a adaptação e a inspeção, conforme ilustrado na Figura 
1. A transparência se dá também pela gestão à vista, ou seja, quadros 
visuais para organização do trabalho são artefatos que auxiliam a 
implementação e adaptação ao Scrum, com isso, é possível realizar 
inspeção e adaptação diante dos eventos que ocorrem. 
22
Figura 1 – Pilares do Scrum
 Fonte: adaptado de Coutinho (2021, p. 55).
Por ser um framework que se caracteriza como iterativo e incremental é 
possibilitado aos gestores visualizar pequenas partes das entregas, com 
isso, o trabalho de controle de riscos é facilitado e, consequentemente, 
é mais fácil se obter previsibilidade. Não é à toa que um dos pilares seja 
a transparência, e que algumas ferramentas auxiliem nesse pilar como 
a lista de requisitos do produto, o quadro, as reuniões diárias – daily 
-, as retrospectivas, ter uma definição de concluído, dentre outras que 
possibilitam a transparência em um trabalho de equipe multifuncional. 
O termo inspeção, que é o segundo pilar ilustrado na imagem, diz 
respeito a uma checagem rápida e frequente do trabalho que está sendo 
realizado. Se checamos rápido temos a oportunidade de identificar 
problemas ou riscos com a mesma velocidade e o resultado disso é 
minimizar as chances de o produto apresentar um problema para o 
cliente final. São estabelecidas metas e, com frequência, verifica-se como 
está o caminho com relação ao seu atingimento. 
Como dito anteriormente, as origens do Scrum remontam às técnicas 
da indústria japonesa. Um dos grandes nomes da Administração, 
23
que influenciou fortemente o modelo japonês de produção, foi um 
americano chamado W. Edwards Deming. O legado de Deming é 
conhecido como ‘controle estatístico de processo’, que em resumo 
significa mensurar o que está sendo feito, a qualidade com que é feito, 
e buscar sempre o processo de melhorias contínuas. 
Talvez você já tenha ouvido falar sobre esse método criado por ele, que 
popularmente ficou conhecido como PDCA - Plan, Do, Check, Act – que 
em português significa um ciclo realizado por planejar, fazer, checar e 
agir. E é notável a semelhança do PDCA com o ciclo de desenvolvimento 
do SCRUM, que busca a inspeção, como uma forma de checar, e 
a adaptação como a forma de agir quando se identifica qualquer 
oportunidade de melhoria.
Aqui é importante frisar que mesmo bons profissionais e bons 
processos sempre poderão evoluir em algo, a busca pela perfeição e 
aprimoramento é e deve ser contínua. 
Na prática do scrum a inspeção se dá no quadro de gestão à vista, em 
ciclos de feedback com o cliente e stakeholders, na criação de listas de 
requisitos do produto, e no processo de demonstração e validação dos 
entregáveis. Essas práticas fazem parte dos rituais, os quais veremos 
mais à frente. 
Por fim, o último pilar diz respeito à adaptação, que se caracteriza por 
esse processo de melhoria contínua supramencionado e que significa 
dentro do scrum mudar aquilo que o cliente acredita que não funciona 
ou que pode ser aprimorado. 
2. Os times Scrum
Intuitivamente empresas e gestores buscam avaliar os trabalhadores 
de forma individual, inclusive bonificando-os por isso. Mas devido às 
24
multifuncionalidades e especialidades de trabalhos, a maior parte das 
entregas das empresas é feita por times e não por pessoas isoladas. 
Algumas pessoas trabalham melhor em equipe do que outras, e essa é uma 
característica fundamental para se destacar no mercado de trabalho hoje 
em dia, tendo resultados incríveis, enquanto grupo, time, equipe. 
O que determina o sucesso de um time? Pode-se dizer que, após analisar 
equipes no mundo todo, estudiosos identificaram as características 
das equipes de sucesso. Elas são transcendentes, autônomas e 
multifuncionais. 
Transcendente significa que elas possuem uma noção de propósito que 
lhes permite ir além das expectativas. Como time, eles estão unidos 
no propósito de entregar com qualidade, de forma a compreender seu 
potencial. Autônomas significa que esses times são autogerenciáveis, 
e auto-organizados, ou seja, eles são capazes de tomar decisões sobre 
quem e como o trabalho será executado. Por fim, multifuncionais quer 
dizer que as equipes têm funcionários de todas as especialidades que 
são necessárias para completar o projeto. 
O Scrum advém dessas teorias que começaram a ser propagadas por 
Takeuchi e Nonaka e, por isso, um time scrum deve estar organizado em 
um determinado tamanho que seja suficiente para executar a meta do 
produto, mas não tão grande que seja necessário dividir-se em setores 
criando burocratização desnecessária. 
Mas qual o número ideal? 10 ou menos pessoas, seguindo a composição 
de ter um Product Owner, um Scrum Master e os desenvolvedores (para 
times de Software). Esse número é o indicado no Scrum Guide de 2020, 
já havendo no passado recomendações diferentes, como a que segue: 
Scrum envolve grupos de pessoas que, coletivamente, possuem todas 
as habilidades e conhecimentos necessários para fazer o trabalho 
25
e compartilhar ou adquirir essas habilidades conforme necessário. 
(SCHWABER; SUTHERLAND, 2020, p. 4)
Cinco valores regem um time Scrum, são eles: compromisso, foco, 
abertura, respeito e coragem. Compromisso é a forma como um 
membro do time lida com o outro, e como todos estão comprometidos 
a alcançar coletivamente os objetivos traçados. O foco remete ao quanto 
eles estão comprometidos com o trabalho e as metas, sem se dispersar 
para poder alcançar os objetivos. A coragem é necessária para lidar com 
problemas complexos e com desafios que surgem a cada nova sprint. Os 
membros do time scrum se comprometem com um propósito coletivo, 
e garantem um ambiente de respeito mútuo e, por fim, a abertura, que 
está muito relacionada ao ambiente aberto que dá oportunidade para 
aprender com os erros. 
Esses valores são mais fortes ao Scrum do que qualquer uma de suas 
práticas, a ideia é que ao adotar o scrum esses valores sejam reforçados 
pelo framework, e não minados. 
Dentro de um time Scrum não existem subtimes e nem hierarquias. 
Suas habilidades e formações são diversas, o que lhes garante a 
capacidade de se adaptar, desenvolver a multifuncionalidade, e entregar 
valor a cada iteração (ciclo). 
Os times pequenos têm menos problemas de comunicação e menos 
burocratização, por isso, tem maior produtividade e desempenho. 
Caso um time Scrum cresça ultrapassando a recomendação deve-
se considerar dividi-lo em unidades menores ainda que todos sigam 
focados em uma mesma entrega, foco ou produto. Neste caso, eles 
trabalharão com uma mesma meta, por eles definida, e entregarão tudo 
relacionado ao produto, considerando o processo produtivo de ponta a 
ponta dentro da estrutura Scrum. Eles terão ainda que compartilhar um 
backlog de produtos, que é o escopo de trabalhos a serem realizados – 
tema que veremos a seguir.
26
O trabalho dos times é organizado em sprints, ciclos de iterações, os 
quais lhes oportuniza cadenciar o trabalho em um ritmo sustentável, 
mantendo seu foco e constância. 
Ao final de cada iteração – sprint – os times devem entregar um incremento 
valioso do pontode vista do cliente. Mas quem são os elementos deste 
time? Vamos conhecer um pouco mais de cada um deles:
Os desenvolvedores: pessoas dos times que desenvolvem os 
entregáveis ou, como dito na linguagem do scrum, um incremento, a 
cada sprint. Esse incremento deve ser valioso e utilizável. Em um time 
de desenvolvimento de software eles podem ser os desenvolveres 
especializados em diferentes linguagens de programação, em backend, 
front-end, desktop, web, mobile. Mas vale lembrar que o Scrum é 
aplicável a qualquer contexto, de qualquer produto, sendo assim, 
podemos ter times formados por professores, em uma escola, times de 
advogados em um grande escritório, time de RH, entre outros.
Os desenvolvedores são os responsáveis por criar o planejamento da 
sprint, detalhando quais itens do backlog (escopo) serão produzidos no 
próximo ciclo de iteração (uma semana, dez dias, 15 dias, dependendo 
da definição que a empresa atribuir à Sprint). São eles também que 
entregam a qualidade, conferindo se o item está atendendo aos 
requisitos preestabelecidos, o qual aqui neste contexto chamamos de 
Definição de Pronto, ou também na linguagem das empresas ouvimos a 
sigla em inglês, de mesmo significado DoD – Definition of Done. 
Caso haja necessidade de adaptação no plano, para que sejam cumpridos 
os objetivos, esse replanejamento deve também ser realizado pelos 
desenvolvedores, pois eles são e devem ser os responsáveis pelas entregas. 
Product Owner – Dono do produto - o segundo papel do Scrum é o 
responsável por maximizar o valor do produto entregue pelo time Scrum. 
Lembram-se do backlog (o escopo do trabalho)? Gerenciá-lo é uma 
27
responsabilidade do Product Owner. Gerenciar o Backlog é: criar uma 
meta de produto e saber comunicá-la ao time de forma clara. Saber dar 
ao time a noção de meta, e de priorização, mantendo os itens do backlog 
organizados. E, lembrando do pilar da transparência, garantir que os itens 
do Product Backlog estejam visíveis e compreensíveis a todos.
Quando se trata da figura do product owner emergem algumas dúvidas, 
como: ele tem que realizar todos os trabalhos acima descritos? A resposta 
é não em pessoa, ou seja, ele pode delegar que outra pessoa o faça, mas 
ainda será responsável. Além disso, é importante salientar que o product 
owner não é um grupo de pessoas ou comitê e sim, sempre, uma única 
pessoa. Essa pessoa é responsável por representar muitas outras como 
o cliente e os stakeholders e, por isso, ele deve ter sua responsabilidade 
respeitada pelos demais membros da empresa. Não quer dizer que os itens 
do backlog não possam ser alterados ou negociados, mas que sempre isso 
deve ser feito considerando o aval do product owner, ou seja, qualquer 
mudança deverá partir do seu prévio convencimento. 
Por fim, e não menos importante, temos a figura do Scrum Master, cujo 
papel é apoiar o estabelecimento do scrum nos times, ajudando que 
todos compreendam tanto a teoria quando a prática do framework. Ele 
é o responsável pela eficácia do time e, para tanto, deve auxiliar o time 
na melhoria contínua de suas práticas. 
O Scrum Master exerce um papel de liderança, mas um tipo de 
liderança que dizemos como líder servil, porque ele serve ao Scrum 
Team e à organização como um todo. Dentre suas responsabilidades 
está o treinamento dos membros do time para que estes consigam 
ser autogerenciáveis e multifuncionais, manter o foco para que sejam 
criados incrementos de alto valor – e que atendam à DoD. Eles também 
auxiliam o time removendo os impedimentos do dia a dia e facilitando 
as cerimônias dos eventos scrum. 
28
Quanto ao papel do Scrum e sua relação com o Product Owner, temos 
que o primeiro é responsável por auxiliar o segundo a encontrar 
técnicas de escritas de histórias do usuário – metas de produto – e de 
gerenciar o backlog de produtos, ajudar o time a entender os itens do 
backlog, ajudar a estabelecer um planejamento empírico do produto, 
considerando a complexidade do ambiente, facilitando a colaboração 
com os interessados. 
3. Os eventos do Scrum
O Scrum conta com algumas cadências que têm por objetivo tornar seus 
valores e estrutura realidade na prática. As cadências do Scrum são: 
Sprint, daily, Sprint review, e Sprint retrospective. Entenderemos um 
pouco sobre cada uma delas, mas iniciaremos com as sprints.
Enquanto abordávamos outros temas, usamos diversas vezes a menção ao 
termo Sprint. Chegou a hora de entender o que exatamente é uma Sprint.
Sprints são os ciclos de desenvolvimentos estabelecidos pelo time, que 
têm duração fixa de um mês ou menos, e uma nova sprint sempre se 
inicia ao término da anterior. Todas as outras cerimônias do Scrum 
ocorrem dentro de uma sprint.
Ao planejar uma sprint é definida sua meta e, durante o decorrer da 
sprint, não deve ocorrer nenhuma mudança que coloque em risco esta 
meta. Além disso, é preciso um cuidado com a qualidade, que não deve 
ser reduzida para que a sprint seja cumprida. 
É durante o decorrer da sprint que os itens do backlog são 
desenvolvidos, mas também durante eles são refinados. Refinar um item 
do backlog significa procurar entendê-lo e buscar soluções técnicas mais 
adequadas para realizar determinada entrega. 
29
Se o time entender que o proposto para a sprint é trabalho em demasia 
e, considerando que a qualidade não pode cair, o que ele deve fazer é 
negociar com o product owner. Aliás, os desenvolvedores e o product 
owner devem estar em constante negociação, enquanto aprendem com 
o trabalho que está sendo realizado a cada iteração. 
Trabalhar com sprints traz a vantagem de ter uma previsibilidade e, 
como é estabelecida uma meta temos ainda que durante as demais 
cerimônias é possível inspecionar o progresso em relação a ela, e 
adaptar-se quando necessário. 
A cerimônia chamada de planning inicia a sprint e trata-se do 
planejamento do trabalho que será realizado dentro da sprint. Dessa 
cerimônia participa todo o time Scrum, e podem ser convidadas outras 
pessoas para fornecer conselhos. O objetivo da planning é discutir 
porque uma sprint é valiosa, por meio da definição da meta da sprint. 
Também define o que será realizado dentro da sprint e pode ocorrer 
uma etapa de refinamento para que o time compreenda detalhes do 
trabalho a ser realizado. Por fim, ainda a cerimônia deve definir como o 
trabalho será realizado, criando-se o plano de execução. 
 A daily scrum é uma reunião rápida de no máximo 15 minutos, que 
serve para inspecionar o progresso do time em relação à meta proposta 
e da qual participam scrum master e time de desenvolvedores.
Outra cerimônia é a sprint review cujo propósito é inspecionar o 
resultado da sprint e decidir quais as adaptações que serão feitas para 
o futuro. O time Scrum apresenta o trabalho realizado durante a sprint 
aos stakeholders e a partir disso repensam o product backlog. 
A sprint retrospective ou retrospectiva é uma reunião em que os 
integrantes do scrum team realizam uma inspeção mapeando como 
foi o seu trabalho com relação aos indivíduos, interações, processos e 
30
ferramentas. A partir dessa reunião encontram-se oportunidades de 
melhorias a serem consideradas no próximo planejamento.
Para finalizar, deve-se ressaltar que o Scrum Guide faz uma ressalva 
sobre a necessidade de se implementar o Scrum tal qual o guia explica. 
O guia adverte que caso uma parte do scrum seja suprimida, então o 
que se está implementando deixa de ser scrum e pode não apresentar 
os mesmos resultados. 
Referências 
COUTINHO, C. Resiliência ágil. [S.l Editora Alta Books, 2021. E-book. ISBN 
9786555206081. 
SCHWABER, K.; SUTHERLAND, J. Scrum guide. 2020. Disponível em: https://
scrumguides.org/scrum-guide.html. Acesso em: 25 fev. 2023.
SHUTERLAND, J.; SHUTERLAND, J.J. Scrum: A arte de fazer o dobro do trabalho na metade 
do tempo. 3. ed. Rio de Janeiro: Leya, 2018.
https://scrumguides.org/scrum-guide.html
https://scrumguides.org/scrum-guide.html
31
Kanban
Autoria: Larissa Maria Palacio dos Santos
Leitura crítica:Quinhones de Santana
Objetivos
• Trazer à luz a essência do Método Kanban.
• Apresentar as formas de aplicação do kanban e as 
vantagens em adotá-las. 
• Apresentar as cadências Kanban.
32
1. Kanban
Em comunidades de agilidade e no universo do gerenciamento de 
projetos, recentemente levantou-se o debate sobre o método Kanban 
ser ou não um método ágil. Polêmicas à parte, o que se observa nas 
empresas é a utilização do Kanban combinado com outros frameworks 
e métodos de gerenciamento ágil como uma forma de potencializar 
resultados. 
A discussão é ampla, mas na prática, áreas de agilidade se utilizam 
do método e há ainda quem combine Scrum com Kanban de forma 
bastante satisfatória. Mas o que é o método Kanban afinal? 
O método Kanban visa identificar e resolver problemas, entregando 
resultado para as empresas. Usualmente as pessoas associam o 
termo Kanban com um quadro visual (Figura 1) e, por isso, muitos 
equivocadamente, ao fazer gestão visual em ferramentas como Jira, 
Trello, Azure, acreditam estar aplicando Kanban. 
Figura 1 – Quadro Kanban
Fonte: Shutterstock.com.
33
O método Kanban vai muito além da gestão visual e pode ser aplicado 
em empresas de diferentes portes e seguimentos. Com ele você poderá 
identificar as fragilidades e os chamados ‘gargalos’ do seu sistema produtivo. 
Ao tornar visíveis os problemas por meio das suas ferramentas de gestão 
visual, a jornada da implementação kanban tem início, mas não se encerra 
por aí. Na realidade, o Kanban prevê a melhoria contínua, por isso, é 
fundamental se aprofundar nos problemas explicitados e encontrar sua 
causa raiz, daí em diante é preciso refletir e encontrar as mudanças que 
são necessárias para solucionar os problemas identificados.
É comum que em ambientes empresariais quando falamos em mudança 
causamos a sensação de medo e de resistência. Primeiro porque somos 
humanos, e assim como nossos colegas de trabalho temos medo de 
perder nossos papéis, nossos empregos e de sair da nossa zona de 
conforto. Como o método Kanban propõe mudanças, a solução que ele 
dá a esse medo e resistência que se criam é embasada pela seguinte 
máxima: “comece pelo que você faz hoje”. 
Isso quer dizer que o método Kanban respeita os papéis, as 
responsabilidades e que ele não julga o que já existe na empresa ou 
departamento. Por isso, para iniciar a jornada Kanban pouco importa 
se a empresa adota uma gestão de projetos tradicional, uma gestão 
ágil, uma gestão orientada a produtos, Scrum ou outro framework ágil. 
Ainda há que se ressaltar que não interessa também se a empresa é 
de tecnologia, pois o princípio do Kanban é respeitar o que é feito e 
potencializar os resultados. 
Para engajar pessoas e envolvê-las no processo de mudança, contudo, 
é fundamental proporcionar clareza e mostrar os benefícios que podem 
ser obtidos com as mudanças propostas. 
34
1.2 Kanban: a origem do método
O termo kanban tem origem japonesa e significa cartão de sinal (conforme 
Figura 2) em português. Ele tem sido amplamente adotado há muitos anos 
nas fábricas em ambiente de produção. Um cartão sinaliza à etapa anterior 
do processo que esta já está apta a receber mais trabalho, ou seja, que 
ela pode produzir mais. Cada trabalhador entendendo essa linguagem de 
cartões sabe quando ele poderá produzir mais. 
Figura 2 – Exemplo de cartão kanban
Fonte: Shutterstock.com.
O grande ganho do uso do Kanban adotado nas fábricas, por exemplo, é 
proporcionar um ritmo sustentável de produção. Além disso, o método é 
capaz de conduzir um processo de melhoria contínua. Por isso, adotá-lo 
é essencial para os processos de lean manufacturing, conhecidos como 
“Sistema Toyota” de produção. Adotá-lo faz com que o sistema Toyota 
funcione e continue evoluindo. 
Por tudo isso é que se pode afirmar que o Kanban é um sistema de 
produção do tipo puxado, ou seja, só se inicia o trabalho quando há um 
pedido ou solicitação por parte do cliente. É produzido o que é necessário, 
35
no momento necessário e na quantidade requerida. Assim, esse tipo de 
sistema de produção não gera estoque, o que em outras palavras podemos 
dizer também que se trata de um sistema que evita o desperdício. 
O método Kanban não prevê um passo a passo para realizar a mudança, 
pois cada organização é única, por isso, não existe uma receita de 
bolo aplicável a qualquer contexto. Para evitar a resistência uma dica 
fundamental é manter o foco no ambiente e respeitar as pessoas, assim 
cada uma terá tempo de assimilar as mudanças de acordo com a sua 
própria percepção e aceitação. O grande trunfo do método é que ele 
primeiro torna os problemas visíveis, explicita cada um deles, a partir 
disso, é possível envolver as pessoas que sofrem com os problemas para 
que elas se tornem também agentes de mudança. 
Vamos entender um pouco mais sobre o conceito e o surgimento do 
método: como dito, o método Kanban tem origem no sistema Toyota 
de produção, mais especificamente em 1953, por Taiichi Ohno. Nesse 
momento ele despontava como fundamental para a implementação do 
conceito just-in-time (produção puxada). 
Ao visitar os Estados Unidos para conhecer a Ford e realizar um estudo 
sobre a produção, Taiichi Ohno teve e a percepção de que o sistema 
fordista tinha por característica ser empurrado. Em outras palavras, 
produção empurrada significa que era produzido mesmo antes de ter 
a demanda, assim gerava-se estoque e depois buscava-se escoar a 
produção. Os sistemas de produção do tipo empurrado geram muito 
desperdício. Imagine que a matéria-prima é comprada antes de se ter 
um potencial cliente. E que no estoque de matéria-prima haja alguma 
perda. Depois disso, temos ainda que ao final da produção é bem 
possível que nem todos os itens sejam vendidos, resultando então em 
uma perda significativa de investimentos e capital imobilizado. 
Taiichi Ohno então percebeu que era possível produzir mais com menos 
recursos, ou seja, ser mais eficiente na produção. A ideia por trás do 
36
sistema Toyota era produzir estritamente aquilo que era necessário, 
pois naquele momento, o Japão vivia um período de profunda recessão 
econômica originada pelo pós-guerra. 
Em sua viagem Taiichi Ohno visitou então um supermercado e 
conseguiu ter um insight que mudou a história da produção industrial 
no mundo. O que ele observou? Os mercados repunham os estoques 
em prateleira quando estes eram vendidos. Uma vez que um item era 
vendido, outro era reposto em seu lugar para que se mantivessem os 
níveis de estoque e a estética das prateleiras. Foi daí que surgiu a ideia 
do sistema Kanban e que posteriormente foi difundido em todo o Japão.
Ao final da década de 1970, os produtos japoneses começaram a 
dominar o mercado americano. Como possuíam alto nível de qualidade 
e bons preços, então, começaram a fazer muito sucesso. Foi a partir daí 
que o Lean Manufacturing passou a fazer muito sucesso. 
Fora do universo de produção industrial, o método Kanban adotado 
no desenvolvimento de software, e com K maiúsculo, foi criado a partir 
do primeiro, por David Anderson e Don Reinersten. O método também 
levou em conta a teoria das restrições e o primeiro sistema Kanban 
implementado na indústria de software data de 2004, na Microsoft. 
Como abordagem para a mudança, o método começou a ser divulgado 
a partir de 2007, após a conferência Agile 2007 que ocorreu em 
Washington. Em seu livro David Anderson relata que o insight para a 
adoção do Kanban em um contexto fora do ambiente industrial surgiu 
em uma viagem à Tóquio, ao perceber que um parque no qual foi fazer 
um piquenique com sua família usava cartões como uma forma de 
identificação para saber quando havia novamente espaço ocioso no 
parque e liberar novos visitantes.
Mas, em suma, dito tudo isso, o que é de fato um sistema Kanban? Os 
kanbans são os cartões que equivalem aos trabalhos. Em um sistema 
37
Kanban um certo número de cartões corresponde à sua capacidade. 
Esse número de cartões corresponde à capacidade que pode ser 
colocadaem circulação. Cada cartão é um sinalizador, e um novo 
trabalho só pode ser iniciado quando o cartão está disponível. O limite 
de trabalho é ditado pelos cartões, em suma, quando não há mais 
cartões livres nenhum trabalho pode ser iniciado. Assim, o novo trabalho 
entra em uma fila de espera, e aguarda que um cartão seja liberado para 
poder iniciar o trabalho. 
2. Método Kanban
No desenvolvimento de software, os kanbans (cartões sinalizadores) 
representam itens de trabalho e não trabalho a ser puxado. Para puxar 
mais trabalho o método Kanban utiliza indicadores e métricas de 
capacidade. O quadro Kanban pode ser físico e muitos utilizam os post-
its para representar os cartões. Os quadros físicos normalmente são 
montados nas paredes de empresas, utilizando-se diferentes materiais. 
Com a propagação do trabalho remoto, no entanto, os quadros 
passaram a ser cada vez mais visuais e usados online. Esses quadros são 
sistemas de gestão visual e não sistemas Kanbans propriamente ditos. 
Fazer gestão visual é observar os itens de trabalho em progresso e 
conseguir a partir dele realizar uma gestão e organização das atividades 
de trabalho. O que torna um sistema Kanban é a capacidade de 
equilibrar a demanda e o rendimento do trabalho entregue atingindo o 
que chamamos de ritmos sustentáveís. 
Ao fazer isso o sistema Kanban também resolve um problema grave que 
é a estafa dos desenvolvedores de software, que vivem sobrecarregados 
e beirando à chamada Síndrome de Burnout. 
38
Os problemas que surgem no sistema de produção ficam visíveis e, com 
isso, os times se desafiam a resolvê-los para manter um fluxo constante 
de trabalho. É comum se usar o termo WIP em sistemas Kanban, 
onde WIP significa Work In progress, que traduzido para o português 
é “trabalho em progresso”. O Kanban trabalha limitando o WIP e com 
isso consegue melhorar a qualidade e melhorar o desempenho. Em 
consequência o lead time – tempo de produção – é reduzido. 
Outro efeito positivo da adoção do método Kanban é tornar o sistema 
mais previsível. Com ele é possível ter mais segurança ao estabelecer 
prazos de entrega. Os benefícios são inúmeros. Diante desses resultados 
cria-se um fluxo de valor de ponta a ponta.
Todos os tipos de projetos podem utilizar e ter benefícios com a 
implementação do método Kanban. No universo do desenvolvimento 
de software não importa se o projeto é de evolução, sustentação 
ou suporte. As demandas podem surgir com prazo específico ou 
simplesmente não terem uma data limite estabelecida previamente. 
Também podemos considerar a implementação do Kanban em 
contextos fora da indústria e fora da área do desenvolvimento de 
software. O método é bastante flexível e é possível realizar adaptações 
em sua aplicação. 
Para a corporação, o Kanban propõe uma mudança cultural, estimula a 
colaboração e a confiança entre pessoas e times. E o que tudo isso tem 
a ver com a gestão ágil de projetos e a polêmica acerca de kanban ser 
ou não um método ágil? Bem, sendo ou não um método ágil, como dito 
anteriormente, os benefícios de sua adoção tornam a empresa mais ágil, 
os projetos se tornam mais ágeis e esse é o ponto principal. 
O lean manufacturing é a raiz do método Kanban e tem por objetivo 
provocar mudanças lean dentro das organizações. E para tanto, segundo 
Anderson (2022, p. 32), ele se vale de cinco propriedades: 
39
[...]1 – Visualize o fluxo de trabalho.
2 – Limite o trabalho em progresso.
3 – Meça e gerencie o fluxo.
4 – Torne as Políticas do Processo Explícitas.
5 – Use Modelos para reconhecer Oportunidade de Melhoria.
Para iniciar o Kanban é importante que exista algum modelo ou fluxo de 
gerenciamento prévio a ser redesenhado e alterado incrementalmente. 
O Kanban não cria um fluxo de processo do zero, ele remodela de forma 
evolutiva e incremental. 
David Anderson afirma que o modelo Kanban auxilia o mercado à 
medida que lhes dá permissão para recriar processos sob medida, 
tornando-os cada vez melhores. Ele não é uma abordagem prescritiva, 
ao contrário, ele empondera líderes e agentes de mudanças a 
encontrarem soluções próprias para seus contextos. 
Cada empresa, cada processo, cada time possui características próprias 
que devem ser respeitadas. Assim, a solução para cada uma delas pode 
ser bastante diferente. Não precisamos adotar abordagens ao pé da 
letra do que lemos em livros e podemos combinar Kanban com outras 
ferramentas e métodos. Além disso, o Kanban embasa as justificativas 
do porquê cada uma das decisões é diferente provando seu valor. 
Assim, vale reforçar que o método Kanban pode ser usado em qualquer 
situação em que há a necessidade de limitação dentro de um sistema. 
A limitação se dá pelo número de cartões sinalizadores, kanban com 
k minúsculo, dentro do sistema, que limitam o trabalho em progresso 
(WIP). Um novo trabalho se inicia assim que um cartão é liberado. 
40
Como iniciar o Kanban? Existe uma abordagem indicada para o início 
de um sistema Kanban que é chamada de Statik – Systems Thinking 
Approach to Introduce Kanban – que consiste em mapear a situação atual 
da empresa, do trabalho, do projeto ou da equipe e que irá auxiliar o 
redesenho do sistema e auxiliar a implementação do Kanban. 
Outra dúvida recorrente no campo do gerenciamento ágil de projetos, 
e que advém das polêmicas mencionadas no início desse texto é a 
utilização de Kanban em times que já adotam o Scrum. É possível 
combinar Scrum com Kanban? A resposta a esta pergunta é sim! 
Existe até um termo chamado Scrumban, que é a combinação do 
método Kanban ao Scrum para potencializar os resultados e auxiliar o 
time a ser mais auto-organizado. 
Há times que após iniciar o uso de ferramentas Kanban junto do 
Scrum acabam sim migrando para utilização apenas de Kanban. 
Mas a utilização de ambos é também benéfica e provoca mudanças 
evolucionárias e constantes nos sistemas de produção. 
Dentre as vantagens desta combinação estão: aumento da qualidade, 
pensamento de melhoria contínua amparado, inspeções mais 
constantes, respeito ao ritmo de trabalho, criação de cadência não 
apenas embasada em sprints. 
Como o Kanban e o Scrum podem ser combinados no que tange ao 
planejamento? Os papéis do Scrum devem ser respeitados pelo Kanban, 
no entanto, no planejamento deve haver espaço para mudanças, as 
quais farão parte do escopo. É preciso ainda definir regras de um 
sistema de produção puxado. 
No planejamento considere realizar pequenos atos de planejamento 
durante os dias, você pode aproveitar o momento da daily para isso 
ou fazer em outro momento. Ao pensar em um sistema de produção 
41
considere fazer inserções de etapas intermediárias no quadro Kanban 
e incluir raias de atividades, categorizando-as. Vale ainda a utilização 
de regras de priorização explícitas no card, por raia, por cores, ou outro 
critério que o time queira adotar. 
Quanto ao monitoramento utilize o tempo da daily, mas lembre-se 
também de analisar itens bloqueados no fluxo e analisar a questão de 
quantidade de trabalho em progresso. As métricas são grandes aliadas 
no Kanban com Scrum (Scrumban). 
Referências 
ANDERSON, D. J. Kanban: mudança evolucionária de sucesso para seu negócio de 
tecnologia. [Livro Eletrônico]: Blue Hole Press, 2022.
ANDERSON, D. J; CARMICHAEL, A. Kanban essencial condensado. Seattle 
Washington: Lean Kanban University Press, 2016. Disponível em: https://
kanbanbooks.com/essential-kanban-condensed/. Acesso em: 7 ab. 2023.
MUNIZ, A. et al (org.). Jornada Kanban na prática. Rio de Janeiro: Brasport, 2021. 
https://kanbanbooks.com/essential-kanban-condensed/
https://kanbanbooks.com/essential-kanban-condensed/
42
Métricas de agilidade
Autoria: Larissa M. Palacio dos Santos
Leitura crítica: Quinhones de Santana
Objetivos
• Orientar os benefícios da adoção de métricas ágeis 
na gestão ágil de projetos.
• Mostrar como são utilizadas as métricas de 
acompanhamento de Scrum, em especial burndown 
e burnup.
• Apresentar métricas ágeis aplicadas ao sistema Kanban.43
1. Métricas ágeis
Metrificar auxilia no entendimento dos processos e do comportamento 
de times e é a partir dessa metrificação que conseguimos obter insights 
para promover os chamados Kaizens (melhorias). O processo de melhoria 
contínua deve ser fomentado e embasado pelas métricas e indicadores, já 
que esses darão clareza sobre como está a saúde do processo.
Em seu livro, Métricas Ágeis: Obtenha os melhores resultados para sua 
equipe, Raphael Albino (2017) faz um paralelo entre o processo de 
desenvolvimento de software e o método científico relembrando que 
ambos iniciam na observação do fenômeno (problema), e que a partir 
dessa observação são levantadas hipóteses, a partir das quais originam-
se predições e suposições e que posteriormente são testadas. 
Fora do ambiente de software, em outros processos do trabalho do 
conhecimento em geral, e em outros contextos, é possível observar os 
mesmos tipos de processos na criação das soluções. 
Entender os processos e a criação de soluções a partir de dados é a 
melhor forma de criar um processo de melhoria contínua sem que se 
tenha que provocar mudanças radicais. Criar forma de visualizar os 
dados fará com que todos fiquem na mesma página compreendendo os 
porquês das mudanças que estão sendo propostas. 
Quando mencionamos metrificações e adoção de indicadores, muitos 
têm receio de criar uma política de comando e controle, mas aqui 
as métricas propostas trazem uma perspectiva diferente, voltada ao 
processo e não às pessoas.
As métricas não devem ser instrumento de práticas de 
microgerenciamento, cobranças, comparação de performance e 
hipercontrole, mas sim utilizadas para compreender contextos, 
44
gerenciar riscos, analisar tendências, tornar o processo mais previsível, 
entre outros fatores voltados à evolução do processo. 
Também é importante, antes de iniciar os estudos sobre métricas, 
reforçar que as métricas não devem ser utilizadas como instrumento de 
comparação entre times, pois cada time atua com produtos diferentes e 
em um contexto diferente. 
Use as métricas como uma forma de avaliar a saúde do processo, pois 
fica claro que equipes que utilizam métricas conseguem amadurecer 
seus processos e, portanto, podemos utilizá-las em momentos de 
retrospectivas.
2. Métricas em Scrum
Uma das métricas mais usadas no Scrum é o acompanhamento de 
sprint pelo gráfico de burndown, que na realidade é uma ferramenta 
de gestão visual da produtividade da sprint. 
O gráfico de burndown apresenta o trabalho concluído por dia em 
relação ao que foi planejado. É uma forma de comunicar o andamento 
da sprint, pois traz transparência ao andamento do processo. Além 
disso, por mensurar a questão tempo, é extremamente útil ao 
gerenciamento de projetos ágeis, uma vez que no cotidiano vivenciamos 
inúmeras situações nas quais o fator tempo é uma das principais 
restrições. 
Neste gráfico existem dois eixos (x, y), conforme Figura 1. No eixo 
vertical representa o trabalho que precisa ser realizado e o horizontal 
representa o tempo para a conclusão da sprint. A unidade de medida de 
tempo pode ser em dias, horas, ou quantidade de trabalho. 
45
Figura 1- Gráfico de burndown da sprint
 
Fonte: elaborado pela autora.
A imagem mostra um exemplo de um burndown criado dentro do azure 
devops, uma ferramenta muito utilizada na gestão de projetos ágeis. E 
mostra o quanto de trabalho ainda falta para concluir a sprint. É possível 
verificar antes da data de finalização da sprint um aumento de escopo 
ou que, se o time continuar no mesmo ritmo, as demais planejadas para 
a sprint não serão concluídas.
É possível criar burndown da sprint, da versão da entrega, ou do produto 
e todas essas visões são igualmente úteis a depender do contexto. O 
gráfico pode trazer o esforço estimado em story points ou a quantidade 
de cards (kanbans) ainda em progresso.
No caso da Figura 1, temos o andamento da sprint, acompanhando o 
quanto ainda falta de trabalho a ser realizado (trabalho remanescente) 
para que a sprint possa ser concluída. Pode ocorrer no andamento 
da sprint algo parecido com o que ilustra a imagem, veja que a linha 
amarela que representa o escopo aumentou, isso significa que por 
alguma razão foi solicitado ao time um esforço adicional. Pode ser que 
46
no andamento de alguma atividade o time tenha descoberto um esforço 
adicional para entregar alguma demanda. Pode ser ainda que tenha 
surgido alguma demanda não planejada e que precisou compor a sprint. 
O ideal, todavia, é que esse tipo de comportamento não ocorra. Uma vez 
estabelecido o escopo planejado para a sprint ele deveria, em tese, ser 
mantido. 
Quando usamos a versão do burndown de produto, estamos 
acompanhando a evolução ao decorrer de várias sprints, portanto, essa 
proposta é a de um olhar mais macro. 
Similar ao gráfico burndown, temos o gráfico burnup, mostrado na 
Figura 2, no entanto, traz uma perspectiva um pouco diferente. Ele exibe 
o quanto a equipe já progrediu com relação ao que foi planejado, ao 
contrário do primeiro que mostra o quanto de trabalho ainda falta para 
ser realizado. 
Figura 2 - Gráfico de burnup
Fonte: elaborado pela autora.
A ideia deste gráfico é mostrar o progresso e o andamento com relação 
à finalização do projeto, da sprint, ou do produto. Nesse caso a linha irá 
47
subindo. A ideia é que as linhas do planejado e do real se encontrem. 
Quando isso ocorrer significa que o projeto foi concluído. Nos gráficos 
de sprint burnup o trabalho pode ser representado em esforço-horas ou 
como storypoints. 
Ao analisar esses gráficos, conseguimos identificar rapidamente se é 
necessário ter um plano de ação para que a conclusão do projeto não 
seja comprometida. 
3. Métricas em Kanban
É comum que em times de desenvolvimento de software haja uma 
sensação constante de trabalho em excesso. Aliás, mais comum ainda 
é que os desenvolvedores façam horas extras com alta frequência para 
que consigam cumprir com as demandas que lhes foram incumbidas. 
No entanto, quase sempre, por ser um trabalho de conhecimento, é 
difícil demonstrar essa sobrecarga de trabalho e os impactos negativos 
que elas trazem à qualidade de vida do colaborador, mas também à 
qualidade do software. Além disso, uma grande quantidade de trabalho 
em progresso simultaneamente configura uma situação de paralelismo 
de trabalho, o que por consequência aumenta o tempo de entrega. 
Neste contexto, a métrica de WIP – Work In Progress – se faz relevante e 
seu significado é “trabalho em progresso” no português. Para facilitar 
o entendimento vamos utilizar a sigla WIP. Wip é todo aquele trabalho 
que ainda não foi concluído, mas que já foi, de alguma forma, iniciado. 
Aquele trabalho em andamento, aquele estudo, os cards do board, 
todos eles representam WIP. 
Essa demanda em andamento ainda não foi entregue ao cliente, 
portanto, ainda não gera valor. Para que possamos entender a partir 
de qual momento um trabalho é considerado iniciado, ou seja, em 
48
progresso, temos que ter uma definição de onde se inicia o processo 
produtivo ou de desenvolvimento. Existem etapas no fluxo de 
desenvolvimento que não necessariamente representam que esse já 
está em andamento.
Por exemplo, em times scrum, os itens de um backlog de produto, 
que ainda não foram selecionados para o backlog da sprint, embora já 
tenham sido mapeados pelo product owner ou gerente de produtos, 
são itens que ainda não estão em progresso, embora estes possam 
existir já dentro dos quadros de gestão visual. Já nos times Kanban, 
normalmente esse ponto de comprometimento corresponde a uma 
etapa do processo explicitado como uma coluna no board. Assim como, 
nos times Scrum o ponto de saída corresponde ao momento da review, 
e nos times que adotam Kanban temos necessariamente uma coluna 
correspondente representando o fim do processo. Ou seja, qualquer 
coisa que seja iniciada entre a cerimônia de planejamento e a review 
pode ser considerada o WIP em scrum. E qualquer coisa dentro dos 
limitesde início do desenvolvimento e fim do desenvolvimento em 
Kanban também representam seu wip.
Agora, você já sabe o que é WIP, mas para nós o importante é trabalhar 
com limitação de WIP. Por que gerenciar o WIP? Controlar WIP, como 
dito anteriormente, auxilia os times a terem uma cadência de entrega, 
isto é, manterem um ritmo constante. Além disso, estudos provam que 
quanto menor a quantidade de trabalho em progresso, menor o tempo 
de desenvolvimento.
Ao estabelecer um limite de WIP, ou seja, um número máximo de 
trabalho em desenvolvimento, seja para o fluxo como um todo, seja para 
etapas do processo em específico, temos algumas vantagens:
• Tornar o time mais previsível. 
• Incentivar o término de tarefas.
49
• Promover uma cultura de trabalhar focado, pois o paralelismo é 
um ofensor à velocidade de entrega.
• Explicitar gargalos e bloqueios no processo.
• Melhorar a qualidade.
Limitar WIP tem um valor que, por vezes, é contraintuitivo para os times, 
pois, ao limitar trabalho em progresso é possível que seja criada certa 
ociosidade no sistema. Além disso, temos uma forte influência da gestão 
tradicional que perdurou por muito tempo pedindo produtividade e 
associando esta com a quantidade de trabalho que uma pessoa assumia.
No entanto, resista à tentação de pensar desta forma e compreenda que 
ao limitar o trabalho em progresso os membros de um time ágil terão a 
oportunidade de se desenvolverem atuando conjuntamente em algumas 
atividades, sendo multifuncionais, atentando-se aos bloqueios do fluxo, 
e promovendo uma cultura de apoio. Se um determinado membro está 
com ociosidade, é a hora de ele se oferecer para ajudar outro colega 
que esteja mais sobrecarregado ou que talvez esteja precisando de uma 
ajuda para eliminar um problema, bloqueio ou dependência. 
Vale dizer, que ao estabelecer uma sprint, ou seja, um tempo fixo de 
desenvolvimento, o Scrum analisa a capacidade do que irá entrar no 
sistema e trabalha indiretamente uma limitação de WIP. Por outro lado, 
o Kanban estabelece uma política explícita exibindo visualmente nos 
quadros as limitações de quantidade de itens sendo desenvolvidos. 
Albino (2017, p. 87), conclui que: 
[...] o wip representa um esforço e energia que ainda não foram validados, 
pois estão envoltos em uma caixa chamada processo. Quanto mais tempo 
você passar carregando o WIP, menos feedback você estará recebendo, 
mais lento será o processo de validação de hipóteses por detrás das 
iniciativas que originaram o trabalho e maior será o risco de você estar 
perdendo uma oportunidade de mercado.
50
Vamos agora entender sobre o tempo que uma demanda leva para ser 
concluída. Saber mensurar o tempo de desenvolvimento é fundamental 
para que se crie um ambiente com previsibilidade de entregas, isto é, 
que aquele que esteja negociando com o cliente consiga passar uma 
perspectiva factível de entregas, sendo fundamental para que o cliente 
esteja satisfeito. Também evita ruídos entre áreas e desconfianças.
Sabemos que diferentes tipos de trabalho levam mais ou menos tempo 
para serem desenvolvidos. A ideia é que cada vez menos tenhamos essa 
variabilidade para que o time possa ser cada vez mais previsível. 
A previsibilidade está atrelada ao conhecimento do lead time, uma 
métrica oriunda do ambiente industrial, e que representa o tempo que 
as demandas passaram pelo fluxo de desenvolvimento – de ponta a 
ponta. Essa métrica está bastante atrelada ao lean manufacturing, o qual 
estabelece políticas e práticas para diminuí-la e considera que, desta 
forma, estará diminuindo o desperdício. 
No contexto do desenvolvimento de software essa métrica passou a 
ganhar fama a partir da promulgação do método Kanban, quando seu 
criador, David Anderson, ressaltou a importância de sua utilização. 
Quais são as vantagens de medir o lead time?
• Compreender quanto tempo a equipe tem levado para 
desenvolver o trabalho.
• Entender se há muita discrepância de tempo de produção entre 
diferentes tipos de itens, ou entre itens do mesmo tipo para 
entender a saúde do processo. 
• Compreender gargalos no processo à medida que analisa um item 
que demorou mais para ser concluído e busca-se entender as 
causas.
51
• Identificar se há um padrão comportamental de tempo de entrega 
por tipos de itens.
• Auxilia na contabilização de custos como elemento norteador.
Outra métrica bastante utilizada nesses contextos é o chamado cycle 
time que, muitas vezes, por equívoco é confundido com o lead time. O 
cycle time é na verdade a razão entre o número de horas disponíveis 
para o trabalho e a quantidade de demandas solicitadas por dia. 
Um exemplo hipotético é que em um período de 10 dias, um time x 
entregou 5 incrementos completos. Dizemos que o lead time foi de dez 
dias, pois esse foi o tempo entre o início da execução da tarefa e sua 
finalização, no entanto, o cycle time foi de 5 demandas incrementos. 
Há discussões sobre o termo cycle time, pois alguns autores consideram 
que esse seria o tempo total do desenvolvimento do item. Por exemplo, 
considerando o tempo em que a demanda ficou parada em backlog sem 
fazer parte do conjunto de demandas já iniciadas. 
Por isso, a utilização desse termo é menos comum, já que carrega uma 
série de polêmicas e dúvidas sobre seu sentido. Há ainda, como dito 
anteriormente, aqueles que consideram ambos como sinônimos. 
A última métrica que estudaremos aqui, e não menos importante, é o 
chamado throughput, que significa vazão. Essa métrica permite analisar 
a quantidade de entregas em um período de tempo, o aumento ou 
diminuição no número de entregas, a existência de bloqueadores ou 
impedimentos no trabalho. 
De maneira bastante simplista, pode-se dizer que o throughput mede 
a quantidade de itens entregues em um determinado período de 
tempo. Essa métrica determina os limites de capacidade do time. Cada 
time poderá eleger uma unidade de tempo que lhe faça sentido para 
mensurá-la. Além de compreender o quanto o time entrega por período 
52
de tempo, ao medir o throughput será possível identificar tendências. 
Existem inúmeras formas de visualização gráfica do throughput, 
podendo ser um gráfico de barras ou colunas. 
Além das métricas ágeis aqui apresentadas existem outras que podem 
ser utilizadas, destacamos aqui aqueles que terão mais efeitos positivos 
de bem utilizadas no seu processo, fluxo de trabalho. A ideia é que você 
busque utilizá-las de forma combinada, para analisar os processos e tirar 
insights que promovam a melhoria contínua. Lembre-se, mais uma vez, 
de não comparar contextos, não comparar desempenho de pessoas, e 
pensar sempre em comparativos de métricas de evolução, desta forma, 
você estará criando uma cultura positiva na sua organização.
Referências 
ALBINO, R. D. Métricas Ágeis. [Livro Eletrônico]: Casa do Código, 2017.
ANDERSON, D. J. Kanban: mudança evolucionária de sucesso para seu negócio de 
tecnologia. [Livro Eletrônico]: Blue Hole Press, 2022.
CRUZ, Fabio. Scrum e Agile em projetos Guia completo: conquiste sua certificação e 
aprenda a usar métodos ágeis em seu dia a dia. 2. ed. Rio de Janeiro: Brasport, 2018.
SCHWABER, K.; SUTHERLAND, J. Scrum guide. 2020. Disponível em: https://
scrumguides.org/scrum-guide.html. Acesso em: 25 fev. 2023.
https://scrumguides.org/scrum-guide.html
https://scrumguides.org/scrum-guide.html
53
	Sumário
	Apresentação da disciplina
	Da gestão de projetos tradicional à agilidade
	1. Novo mundo, nova gestão
	2. Do modelo tradicional ao novo modelo
	3. O manifesto ágil
	Referências 
	SCRUM
	Objetivos
	1. A essência do framework scrum
	2. Os times Scrum
	3. Os eventos do Scrum 
	Referências
	Kanban
	Objetivos
	1. Kanban
	2. Método Kanban
	Referências
	Métricas de agilidade
	Objetivos
	1. Métricas ágeis
	2. Métricas em Scrum
	3. Métricas em Kanban
	Referências