1. 1
APLICAÇAO DE UMA METODOLOGIA ÁGIL: COMBINANDO SCRUM E
KANBAN NO GERENCIAMENTO DE PROJETOS DE SISTEMAS
Luiz Carlos Monteiro Lopes Filho1
Profa. Dra. Valneide Cabral 2
RESUMO
O surgimento de metodologias ágeis está contribuindo para ajudar equipes de
desenvolvimento de software a responder, de forma eficaz e efetiva, às constantes mudanças
do mercado atual. Uma das possibilidades de uso, neste contexto, refere-se à combinação
Scrum e Kanban para o gerenciamento de projetos de sistemas. Neste sentido, este estudo
explicita as contribuições dessa combinação, apresentando suas diferenças e similaridades,
bem como as probabilidades quanto à sua utilização. Trata-se de uma pesquisa descritiva e
bibliográfica, com abordagem qualitativa. Os entendimentos literários indicam que, as
contribuições do Scrum e Kanban, combinadas, favorecem a melhoria dos processos de
gerenciamento e de desenvolvimento, e podem ser adotadas por equipes, visto que ambos
apresentam características adaptativas e são baseados no desenvolvimento iterativo e
incremental, possibilitando, dessa forma, trazer mudanças consideráveis. Ressalta-se que, ao
combinar Scrum e Kanban, a Organização não estará isenta de todos os problemas, mas,
enfrentá-los passa a ser um desafio, sobretudo de equipes.
Palavras-chave: Engenharia de software. Metodologias ágeis. Combinação Scrum e Kanban.
Projetos de sistemas.
ABSTRACT
The emergence of agile methodologies is contributing to help software development teams to
respond efficiently and effectively to changing market today. One of the possibilities of use in
this context refers to the combination of Scrum and Kanban for the project management
systems. Thus, this study clarifies the contributions of this combination, with their differences
and similarities, as well as the odds for their use. This is a descriptive and literature, with
qualitative approach. The literary understandings indicate that the contributions of Scrum and
Kanban, combined, favor the improvement of management processes and development, and
can be taken by teams as they both have adaptive characteristics and are based on iterative
and incremental development, enabling thus bring considerable changes. It should be noted
1
Graduado em Ciências da Computação pela Universidade Fortaleza
2
Mestre em Informática pela Pontifícia Universidade Católica do Rio de Janeiro, especialização em
Empreendedorismo na Engenharia pela Universidade Federal de Santa Catarina e graduação em Agronomia pela
Universidade Federal do Ceará. Professora da Universidade Federal do Ceará e Coordenadora Adjunta do Curso
de Sistemas de Informação da Faculdade Christus.

2. 2
that by combining Scrum and Kanban, the Organization will not be free of all problems, but
face them becomes a challenge, especially for teams.
Keywords: Software engineering. Agile methodologies. Combining Scrum and Kanban.
Project management systems.
1 INTRODUÇÃO
Para as Organizações, a aplicação exclusiva do Scrum, no gerenciamento de projetos
de desenvolvimento de sistemas, pode não atender às expectativas de sucesso, tornando-se
necessárias, adaptações. Uma destas refere-se à combinação com Kanban.
No contexto do mercado globalizado, em que as Organizações enfrentam crescentes
exigências de produtividade e de competitividade, a busca por processos mais ágeis, e que
agregam maior valor aos produtos, tem sido o foco constante do gerenciamento de projetos.
Portanto, evidencia-se a busca por metodologias que contribuam para superar os
atrasos, os custos, os prazos extrapolados, a baixa qualidade para, consequentemente, ter o
cliente satisfeito.
Tais problemas são a realidade de muitos projetos de desenvolvimento de softwares.
Provavelmente, tais sintomas consistam em reflexos de projetos mal gerenciados, seja na fase
do planejamento, da execução ou, simplesmente, do acompanhamento.
Diante desse quadro, apresenta-se a necessidade de frameworks para auxiliar o
gerenciamento, sendo o Scrum e Kanban demonstrados como opções.
O Scrum se concentra nos aspectos gerenciais do desenvolvimento de software, com
ênfase na autogestão (auto-organização) da equipe, sendo definido como um framework,
capaz de suportar o desenvolvimento de produtos que apresentam mais complexidade,
podendo combinar várias técnicas e processos ágeis.
O sistema Kanban é um método de produção que se baseia em controles visuais do
processo de produção, visando, entre outras funcionalidades, maximizar a frequência e a
rapidez de entrega dos produtos desenvolvidos.
Considerando as possibilidades de realizar combinações e adequações entre Scrum e
Kanban é que surgiu o interesse pelo assunto.
Do contato com a temática, apresentou-se uma possibilidade de utilização prática na
atividade profissional, exercida em uma empresa têxtil, sendo os softwares desenvolvidos
internamente para atender às necessidades da empresa. Vislumbra-se, portanto, a implantação

3. 3
futura da metodologia do Scrum, consciente de que, para tanto, existe a necessidade de
adequação, utilizando como aporte o Kanban.
Diante do exposto, este estudo tem como questão norteadora: quais as contribuições
da aplicação de uma metodologia ágil, combinando Scrum e Kanban no gerenciamento de
projetos de desenvolvimento de sistemas?
É relevante apontar o que consta na literatura, acerca das possibilidades de
adaptações na utilização do Scrum no gerenciamento de projetos de desenvolvimento de
softwares, que, combinado com Kanban, possa solucionar problemas quando da utilização
exclusiva do Scrum.
A pesquisa tem como objetivo geral explicitar as contribuições da aplicação de uma
metodologia ágil, combinando Scrum e Kanban, no gerenciamento de projetos de
desenvolvimento de sistemas; e, tem, como objetivo específico, estudar, para identificar como
a aplicação de uma metodologia ágil, combinando Scrum e Kanban, pode contribuir no
gerenciamento de projetos de desenvolvimento de sistemas.
O pressuposto é de que, a utilização do Scrum e do Kanban promova melhor
transparência do andamento dos projetos desenvolvidos, contribuindo para a motivação e o
maior comprometimento da equipe, favorecendo a inspeção contínua, proporcionando uma
maior facilidade de adaptações durante o processo de desenvolvimento.
Diante do exposto, considera-se que, a estrutura do presente artigo é composta por 5
seções, nas quais, na seção 1, tem-se a introdução, que enfatiza a problematização, as
justificativas, os objetivos gerais e específicos, as hipóteses, bem como, a estrutura do estudo;
a seção 2 trata da fundamentação teórica, que aborda a evolução no gerenciamento de
projetos, sistemas Scrum e Kanban, e as diferenças e as similaridades entre estes; a seção 3
apresenta a metodologia da pesquisa, ressaltando-a quanto aos objetivos, aos procedimentos, e
à abordagem; a seção 4 corresponde à análise dos resultados obtidos, englobando o
repositório Scrum Backlog, iterações em time-box, mudanças dentro de uma iteração, quadro
para acompanhamento de tarefas, equipes multifuncionais, e ainda, estimativas e velocidade
no Scrum e no Kanban; e, a última seção traz as considerações finais da pesquisa, destacando
os pontos significativos, onde são demonstradas as respostas aos problemas configurados,
bem como a confirmação, ou não, dos objetivos.
No final do Artigo em pauta tem-se, ainda, as referências utilizadas para a sua
elaboração.

4. 4
2 REFERENCIAL TEÓRICO
2.1 Evolução no gerenciamento de projetos
O gerenciamento de projetos de desenvolvimento de software baseava-se em
metodologias tradicionais, conhecidas como pesadas ou orientadas para documentação.
Dentre as metodologias tradicionais, está o modelo clássico ou sequencial, que apresenta
etapas, tais como: definição de requisitos, projeto do software, implementação e teste unitário,
integração e teste do sistema, operação e manutenção. Esse modelo dominou a forma de
desenvolvimento de sistemas até a década de 90. (SOARES, 2004)
O autor afirma, ainda, que, a partir desse período, alguns contrapontos foram
levantados por pesquisadores, dentre estes, Brooks (1987, apud SOARES, 2004) que,
defendeu ser impossível especificar totalmente um software antes do início de sua construção,
bem como, Gilb (1999, apud SOARES, 2004) que defendeu o uso do modelo incremental, ao
invés do modelo clássico em grandes projetos de software, por considerá-lo um modelo que
apresenta menores riscos e maiores possibilidades de sucesso.
Conforme Sato (2007, p. 2), os esforços voltados para definição de processos e
métodos mais burocráticos e rigorosos não foram suficientes para resolver a „crise do
software‟, que apresentava, entre outros, os seguintes sintomas: sistemas mal construídos,
software sem garantia e projetos fracassados.
Na última década, as metodologias ágeis de desenvolvimento de software surgiram
para tentar superar esses desafios. Na ocasião, dezessete especialistas em processos de
desenvolvimento de software, entre eles, Schwaber e Beedle (2002), que representavam o
método Scrum, e Beck (1999), com o Extreme Programming (XP), firmaram a Aliança Ágil,
da qual emergiu o Manifesto Desenvolvimento Ágil de Software, Agile Software
Development Manifesto (2001, s.p.), em que alguns princípios passaram a ser valorizados, tais
como: “Indivíduos e interações [...]; Software em funcionamento [...]; Colaboração com o
cliente [...]; Responder a mudanças [...]” sem, no entanto, descartar os processos e as
ferramentas, a documentação, a negociação e o plano.
O Manifesto Ágil (2001) apresenta princípios que estão relacionados à satisfação do
cliente; à flexibilidade para mudanças nos requisitos; com frequência menor nos períodos de
entrega do software; trabalho diário e conjunto de pessoas relacionadas ao negócio e aos

5. 5
desenvolvedores; motivação e confiança na equipe, bem como ambiente e suporte favorável;
comunicação face a face; funcionamento do software como parâmetro de progresso; ritmo
constante e sustentável; agilidade, considerando excelência técnica e bom design;
simplicidade; equipe auto gerenciável, de onde surgem os melhores requisitos, arquiteturas e
design; reflexão da equipe sobre seu próprio trabalho, sistematicamente.
Os princípios citados favorecem mais o dinamismo do processo, conferindo maior
motivação para a equipe e, ao mesmo tempo, fornecendo informações precisas sobre o
projeto, tanto para a equipe como para o cliente.
Os princípios e valores do Manifesto Ágil fazem parte de uma forma de pensar do
desenvolvimento de software, isto é, engloba abordagens específicas, diferentes ideias,
comunidade e lideranças, em que, cada comunidade, mesmo formando grupos distintos, segue
os mesmos princípios, sendo comum a relação de troca de conhecimentos e práticas entre
várias delas. (SATO, 2007, p. 10)
2.2 Sistema Scrum
O Scrum é um método que foi desenvolvido nas décadas de 1980 e 1990, por Ken
Schwaber, Jê Sutherland, e Mike Beedle, tendo como principal característica a capacidade de
se concentrar “nos aspectos gerenciais do processo de desenvolvimento de software, sem
determinar como a equipe executa as tarefas de programação”. Tal abordagem propicia a
auto-organização da equipe, bem como, permite que haja integração com outras metodologias
ágeis. (KATAYAMA, 2010, p. 89)
Os criadores do Scrum o definem como sendo “[...] um framework estruturado para
suportar o desenvolvimento de produtos complexos desde o início dos anos 90”. Acrescentam
ainda que, o Scrum “não é um processo ou técnica para construir produtos, é mais um
framework, dentro do qual se pode empregar processos e técnicas variadas”, tornando “[...]
clara a eficácia relativa das práticas de gerenciamento e desenvolvimento de produtos”,
visando melhorá-las. (SCHWABER; SUTHERLAND, 2011, p.3)
Referidos autores apresentam ainda, componentes e regras, como fundamentais para
o uso do Scrum, que “consiste nas equipes [...], papéis, eventos, artefatos e regras associados”,
entretanto, cada “componente do framework serve a um propósito específico e é essencial
para o sucesso e uso do Scrum”. (idem)

6. 6
Teoricamente o Scrum baseia-se no empirismo, isto é, no conhecimento que advém
da experiência concreta e que, para os autores, orientam a tomada de decisão, bem como, se
utiliza de uma abordagem iterativa e incremental, visando o aperfeiçoamento da
previsibilidade e o controle dos riscos. Enumera, ainda, três pilares de sustentação para “a
implementação de um controle de processo empírico: transparência, inspeção e adaptação”.
(SCHWABER; SUTHERLAND, 2011, p. 3)
No que se refere às iterações do Scrum, estas são propostas, para que ocorram no
espaço de tempo entre 15 e 30 dias, sendo denominadas de Sprints. A dinâmica de Sprints se
configura da seguinte forma: no início, para estimar e definir a meta do Sprint e das tarefas
necessárias (Backlog), ocorre uma reunião de planejamento, depois da qual a equipe inicia o
desenvolvimento do produto, em um período que pode variar entre uma a quatro semanas,
conforme se demonstra na figura1.
Figura 1 - Exemplo de um processo Scrum
Fonte: Agilecoaching (2012).
Visando evitar que instabilidades e fatores externos afetem o desempenho da equipe,
de modo a mantê-la centrada no objetivo, um personagem denominado Scrum Master tem um
papel fundamental na equipe, isto é, ele é o responsável por ensinar e acompanhar a
utilização do Scrum. Para tanto, é exigido dele conhecimentos sobre o processo e o produto,
inclusive, para orientar na tomada de decisão do Product Owner3. Este, por sua vez, deve ter
3
O Product Owner (dono do produto ou cliente) “deve garantir que o produto atenda aos anseios do
patrocinador do projeto, priorizar quais funcionalidades devem ser entregues e quais agregam mais valor ao
projeto. Para exercer tal função, o dono do produto deve possuir a visão do mesmo, sendo responsável pelo
retorno sobre o investimento do projeto”. (KATAYAMA, 2010, p. 89)

7. 7
uma visão geral, acompanhando o desenvolvimento e esclarecendo as dúvidas que porventura
possam surgir, sem, no entanto, alterar o escopo. (KATAYAMA, 2010)
Outro aspecto é que, para assegurar que os itens do backolog não mudem após o
planejado, considerando que alterações no ambiente de negócios podem exigir mudanças nos
requisitos, o dono (ou demandante) do produto tem a opção de cancelar o Sprint e realizar
outra reunião de planejamento. Neste caso, “o Scrum mantém a visão geral da produtividade,
que seria prejudicada caso requisitos pudessem ser modificados e adicionados durante um
Sprint”. Além disso, também provê um mecanismo de adaptação e correção para os
requisitos. (KATAYAMA, 2010, p. 90)
O autor afirma que o acompanhamento diário, durante o Sprint, deve-se efetivar por
meio das nomeadas Reuniões em pé (stand-up meetings), isto é, a equipe se reúne
rapidamente, de modo a sincronizar o trabalho, quando, então, cada membro descreve o que
produziu entre um encontro e outro, bem como, aponta para o que pretende realizar e enumera
os problemas enfrentados, de forma que toda a equipe descubra, de antemão, seus obstáculos
em potencial, ao mesmo tempo em que compartilham conhecimentos.
Concluído o Sprint, na reunião de revisão, o trabalho é apresentado ao dono do
produto, para analisar se os itens atendem suas necessidades e se a meta foi atingida.
Na reunião de retrospectiva, realizada após cada entrega, a equipe deve avaliar seu
trabalho, identificando as oportunidades e os principais pontos de melhoria no próximo
Sprint. (KATAYAMA, 2010)
2.3 Sistema Kanban
Kanban, literalmente, significa “cartão visual”. O Sistema Kanban é um método de
produção, baseado em controles visuais Kanban, usado na metodologia Manufatura Lean,
criando um fluxo contínuo de materiais, com o objetivo de evitar a superprodução de
materiais e de ter um controle visual do que está sendo produzido e em qual sequência.
(SPEAR; BOWEN, 1999)
Os diversos princípios e práticas baseadas nesta metodologia foram absorvidos pelos
Métodos Ágeis, tendo sido criado o método Lean Software Development, por Poppendieck
(2006), que adaptaram e resumiram os conceitos de Lean para o desenvolvimento de software.

8. 8
Kniberg e Mattias (2009, p.25) definem as práticas do Kanban, resumidamente, e
exemplificam, conforme se observa na figura 2:
Visualize o fluxo de trabalho
- Divida o trabalho em partes, escreva cada item em um cartão e coloque na parede.
- Use colunas nomeadas para ilustrar onde cada item está no fluxo de trabalho.
Limite o trabalho em progresso (WIP - work in progress) – associe limites
explícitos para quantos itens podem estar em progresso em cada estado do fluxo de
trabalho.
Acompanhe o tempo de execução da tarefa (tempo médio para completar um
item, algumas vezes chamado de “tempo de ciclo”), otimize o processo para tornar o
tempo de execução o menor e mais previsível possível.
Figura 2 - Exemplo de quadro Kanban simples, com os limites em vermelho.
Fonte: Kniberg e Mattias (2009, p.26)
2.4 Diferenças e Similaridades entre Scrum e Kanban
Para apresentar as possibilidades de uso da combinação Scrum e Kanban no
gerenciamento de projetos, é preciso conhecer, primeiramente, o que ambas têm em comum.
Neste sentido, as similaridades entre Scrum e Kanban, segundo Kniberg e Mattias
(2009) são:
ambos são Lean e Agile;
ambos usam controle de cronograma;
ambos limitam atividades em andamento;
ambos usam transparência para direcionar a melhoria do processo;
ambos concentram-se na entrega de software que funcione, o mais rápido possível
e frequentemente;
ambos são baseados em equipes auto-organizáveis;
ambos exigem que o trabalho seja dividido em partes; e,
em ambos, o planejamento de release é continuamente otimizado, baseado em
dados (velocidade / tempo de execução) empíricos.

9. 9
As diferenças entre Scrum e Kanban, segundo Kniberg e Mattias (2009), podem ser
resumidas, conforme se apresenta no quadro 1.
Quadro 1- Diferenças entre Scrum e Kanban
SCRUM KANBAN
Iterações Timeboxed prescritas. Iterações Timeboxed opcionais. Pode ter
cadência separada para o planejamento,
release e melhoria de processos. Pode ser
orientada para eventos, em vez de
Timeboxed.
Equipe compromete-se a uma quantidade Compromisso opcional.
específica de trabalho para esta iteração.
Usa a velocidade como padrão métrico Usa o Lead time como padrão métrico
para o planejamento e melhoria de para o planejamento e melhoria de
processos. processos.
Equipes multifuncionais prescritas. Equipes multifuncionais opcionais.
Equipes de Especialistas autorizada.
Os itens devem ser divididos para que Nenhum tamanho especial de item é
possam ser concluídos dentro de 1 sprint prescrito
Gráfico Burndown Nenhum tipo específico de diagrama é
prescrito
WIP limitado indiretamente (por sprint) WIP limitado diretamente (por situação do
fluxo de trabalho)
Estimativa prescrita Estimativa opcional
Não poderá adicionar itens à iteração em Pode adicionar novos itens sempre que
uso houver capacidade disponível
O sprint backlog é de uma equipe Quadros Kanban podem ser
especifica compartilhados por várias equipes ou
individualmente
Possui 3 papéis (Product Não discrimina nenhum papel
Owner/ScrumMaster/Team)
Um quadro Scrum é reiniciado entre cada Um quadro Kanban continua
sprint
Prescreve um product backlog priorizado Priorização é opcional
Fonte: Kniberg e Mattias (2009, p.81)
O uso da combinação do Scrum com Kanban pode ser justificado em várias
situações: o cliente deseja nova funcionalidade, porém, o prazo entre um Sprint e outro não
permite, posto que, no Scrum, Sprints ocorrem no espaço de tempo entre 15 e 30 dias. Tal
espera pode levar à insatisfação do cliente. Neste caso, justifica-se a utilização de Kanban,
visto que demanda o mínimo de tempo de espera para que nova funcionalidade seja aceita.
Um cenário, onde o Sprint é constantemente alterado, devido a correções de erros ou
a mudanças de prioridade do projeto, favorece a combinação de técnicas das duas

10. 10
metodologias. Como exemplo, cita-se a observação de Silva et al (2012, s.p), que relatam a
dificuldade de medir a capacidade de atendimento da equipe e respeitar o que foi acertado no
Sprint.
Outro problema encontrado nesta abordagem foi a impossibilidade de se realizar um
acompanhamento efetivo para as tarefas extras. A real capacidade da equipe de
atender essas solicitações e a priorização pelo cliente se tornava complicada, uma
vez que a maioria das demandas chegava com prioridade alta. Sendo assim, a equipe
acabava parando o desenvolvimento do que tinha sido planejado para dar uma
resposta rápida ao cliente que, devido ao sistema estar em produção, não tinha como
esperar uma próxima iteração para a equipe planejar e iniciar essas atividades. Na
maioria dessas demandas extras era essencial a realização do trabalho operacional do
cliente. Diante disso, as metas dos sprints continuavam não sendo atingidas.
Em situações de contingências (eventualidades, tais como doenças, afastamentos,
etc), o planejamento realizado no Sprint pode ser comprometido, levando a ajustes, ou, até
mesmo, inviabilizando os planos, acarretando frustações na equipe e insatisfação do cliente.
No Kanban, o planejamento foca a necessidade mais imediata.
As características dessas duas metodologias residem no fato de ambas serem bastante
adaptativas, sendo possível combiná-los, mesmo considerando que o Scrum é mais prescritivo
que o Kanban. (KNIBERG; MATTIAS, 2009)
3 METODOLOGIA
Este estudo se caracteriza, quanto aos objetivos, como uma pesquisa descritiva;
quanto aos procedimentos, como uma pesquisa bibliográfica; e, quanto à abordagem do
problema, apresenta-se como uma pesquisa qualitativa.
Sobre a conjectura atinente, Neves (1996, p. 1) afirma que a pesquisa qualitativa:
[...] costuma ser direcionada, ao longo de seu desenvolvimento; além disso, não
busca enumerar ou medir eventos e, geralmente, não emprega instrumental
estatístico para análise dos dados; seu foco de interesse é amplo e parte de uma
perspectiva diferenciada adotada pelos métodos quantitativos. Dela faz parte a
obtenção de dados descritivos mediante contato direto e interativo do pesquisador
com a situação objeto de estudo.
Portanto, compreende-se que a abordagem qualitativa é a que melhor se apresenta
para a realização desse estudo.

11. 11
4 RESULTADOS DA PESQUISA
A aplicação de uma metodologia ágil, combinando Scrum e Kanban no
gerenciamento de projetos de desenvolvimento de sistemas, favorece o gerenciamento dos
projetos, na medida em que beneficia o aprendizado, ajudando a superar desafios, motivando
as equipe e contribuindo para a satisfação do cliente.
Percebe-se que, os resultados apresentados mostram variados processos e técnicas no
gerenciamento e desenvolvimentos de produtos, bem como, apresenta o Kanban como um
método baseado em controles visuais do fluxo do trabalho, ao mesmo tempo em que são
apontadas as diferenças e similaridades entre Scrum e Kanban.
Consideram-se as possibilidades de combinação entre ambos, como decorrentes da
característica flexível do Kanban, como alternativa, quando as prescrições do Scrum não são
possíveis. Portanto, a dinâmica do uso combinado Scrum e Kanban facilitam as adaptações no
contexto em que as mudanças são constantes.
No Scrum, os requisitos são escritos como estórias dos usuários, armazenadas em um
repositório chamado backlog. Estas estórias são selecionadas na reunião de planejamento para
formarem o escopo da iteração (sprint), composto por todas as estórias (quebra das tarefas)
que o desenvolvimento deverá entregar ao final da iteração. A figura 3 mostra o
funcionamento do Scrum.
Figura 3 - Ciclo de desenvolvimento no Scrum
Fonte: Autoria própria.

12. 12
4.1 Scrum Backlog
Alguns aspectos relacionados ao Scrum Backlog precisam ser considerados, quando
da quebra de itens, em pedaços menores, para se adequar ao Sprint.
Kniberg e Mattias (2009, p. 57) disciplinam que, uma equipe Scrum se compromete
somente com “os itens que julguem poder terminar dentro de uma iteração (baseado no
conceito de “Done”)”.
Quando o item é grande demais para caber em um Sprint, a equipe e o Product
Owner deverão encontrar formas de quebrá-lo até que ele se encaixe. Quando os itens tendem
a ser grandes, as iterações, consequentemente, tendem, também, a se tornarem maiores (não
maiores do que 4 semanas). A figura 4 mostra esse contexto.
Figura 4 - Itens são quebrados para caberem dentro do Sprint
Fonte: Kniberg e Mattias (2009, p. 57)
Numa equipe Kanban, os membros procuram minimizar o tempo de execução e
buscam equilibrar o fluxo, de modo que, criam, indiretamente, um incentivo para quebrar
itens em partes relativamente menores.
Vale ressaltar que, não há regra explícita que indique quais itens devam ser pequenos
o suficiente para caber em um determinado período de tempo, podendo ocorrer que, “Em um
mesmo quadro nós podemos ter um item que irá levar 1 mês para ser concluído e outro item
que levará 1 dia”. (KNIBERG; MATTIAS, 2009, p. 58). A figura 5 determina essa vertente.
Figura 5 - Exemplo de tarefas de tamanho variado em Kanban.
Fonte: Kniberg e Mattias (2009, p. 58).

13. 13
Apesar de Scrum ter como fundamento essencial a quebra de tarefas, para auxiliar no
seu comprometimento no Sprint, podem existir tarefas que tem uma duração maior que o
tempo de um Sprint, e, nesse caso, a equipe pode optar por usar o Kanban, onde não existe
nenhuma regra que obriga que tarefas caibam em um Sprint, observando os limites de cada
etapa do fluxo e o andamento dessas tarefas.
Ao final de cada Sprint é recomendado fazer um Sprint Review, Sprint Retrospective,
para, a partir daí, ser liberado um Release com as novas funcionalidades. Isso é realizado em
cadência única, caso a equipe tenha como opção aceitar itens com tamanhos diversos. Neste
caso, essa cadência passa a ser orientada a eventos.
4.2 Iterações em time-box
O Scrum baseia-se em iterações de tempo fixo, isto é, a duração da iteração pode ser
escolhida, sendo recomendado, no entanto, manter a mesma duração por algum período, no
sentido de estabelecer uma cadência.
A princípio, é criado um plano de iteração, definido pela equipe, onde um
determinado número de itens do Product Backlog é selecionado, tomando, como base, as
prioridades definidas pelo Product Owner, bem como, fundamentado na quantidade de itens
que a equipe considera possível entregar em uma iteração.
Durante a iteração, a concentração da equipe deve ser a entrega dos itens acordados.
Para finalizar a iteração, o código de trabalho é demonstrado pela equipe às partes
interessadas. “Em seguida, a equipe faz uma retrospectiva para discutir e melhorar seu
processo” (KNIBERG; MATTIAS, 2009, p. 34).
Neste sentido, considera-se que, o “Scrum é uma única cadência de tempo fixo que
combina três diferentes atividades: planejamento, melhoria de processo e (idealmente)
release”. Já no Kanban, “as iterações de duração fixa não são prescritas”, podendo a escolha
das atividades de planejamento, a melhoria do processo e a entrega do produto serem feitas
em períodos regulares („release toda segunda‟), ou por demanda („release sempre que se tiver
algo útil a entregar‟). (KNIBERG; MATTIAS, 2009, p. 34).
Pode-se ilustrar três tipos de cadências: única (figura 6), de três cadências (figura 7) e
orientada para eventos (figura 8).

14. 14
Figura 6 - Equipe Scrum utiliza cadência única
Fonte: Kniberg e Mattias (2009, p. 35).
A figura 7 apresenta três cadências diferentes, para cada quatro semanas:
semanalmente é liberado tudo o que ficou pronto para o release. A cada duas semanas, faz-se
reunião de planejamento. A cada quatro semanas, acontece a reunião de retrospectiva para
ajustar e buscar melhorias no processo. (KNIBERG; MATTIAS, 2009, p. 36)
Figura 7 - Equipe utiliza três cadências
Fonte: Kniberg e Mattias (2009, p. 36).
Na figura 8, o autor apresenta cadência mais orientada para eventos, iniciando-se
com uma reunião de planejamento, sempre que é concluído o trabalho. Na medida em que há
um grupo de funcionalidades finalizadas e prontas para serem entregues, inicia-se um release,
bem como, sempre se inicia um círculo de qualidade quando a equipe se depara com o mesmo
problema por duas vezes. Outra iniciativa é se fazer uma retrospectiva, mais aprofundada, na
quarta semana. (KNIBERG; MATTIAS, 2009, p. 37)
Figura 8 - Equipe com cadência orientada para eventos
Fonte: Kniberg e Mattias (2009, p. 36).

15. 15
4.2 Mudanças dentro de uma iteração
Os autores afirmam que, Scrum resiste às mudanças dentro de uma iteração, ou seja,
se uma atividade precisar ser adicionada, isso não poderá ser feito imediatamente no Sprint
atual, mas, poderá ser adicionada no Product Backlog e, caso seja prioritário para o Product
Owner, deverá ser adicionada no próximo Sprint. Isso justifica o fato de que, “Sprints do
tamanho certo dão ao time tempo focado suficiente para conseguir fazer alguma coisa,
enquanto ainda permitem que o Product Owner gerencie e atualize prioridades com
periodicidade regular”. (KNIBERG; MATTIAS, 2009, p. 51)
No caso de uma equipe de Kanban, a mudança poderá ocorrer, devendo ser posta a
atividade na coluna “não iniciada”, contanto que, obedecidos os limites por coluna (conforme
o caso), devendo a equipe continuar a trabalhar na atividade atual e na medida da capacidade,
e tomar o item que está no topo da coluna “não iniciado”.
Agindo assim, o tempo que demora a responder à mudança de prioridade (tempo de
resposta) é medido pelo tempo de tomar o item inserido. Tal procedimento baseia-se “no
princípio de „um item fora = um item dentro‟ (controlado pelos limites de trabalho em
andamento)”. (KNIBERG; MATTIAS, 2009, p. 52)
O tempo de resposta em Scrum é calculado através da média da metade da duração
do Sprint. “O Product Owner não pode alterar o quadro Scrum quando a equipe já estiver
comprometida com determinados de itens na iteração”, ao passo que, em Kanban, é preciso
“definir as próprias regras básicas sobre quem tem permissão de modificar o que no quadro.
Normalmente, para o Product Owner, é reservada uma coluna do tipo „A Fazer‟ ou „Done‟ ou
„Backlog‟ ou, ainda, 'Proposta‟ à esquerda, onde se pode fazer as modificações que bem
entender”. (KNIBERG; MATTIAS, 2009, p. 52)
Os doutrinadores consideram, no entanto, que:
[...] estas duas abordagens não são mutuamente exclusivas. Uma equipe Scrum pode
decidir por deixar o Product Owner modificar as prioridades no meio do Sprint
(ainda que isto devesse ser considerado normalmente uma exceção). E uma equipe
Kanban pode decidir incluir restrições sobre quando as prioridades podem ser
modificadas [...] [bem como] Uma equipe Kanban pode ainda decidir usar iterações
com duração fixa e compromissos predefinidos, tal como em Scrum. (KNIBERG;
MATTIAS, 2009, p. 52)
Silva et al (2012) afirmam que estavam lidando com sistemas legados, que existiam
muitas incertezas e imprevisibilidade. Nesses casos, não há como evitar demandas não
programadas. O motivo pelo qual o fluxo de Scrum não seguia normalmente era a grande

16. 16
quantidade de demandas extras, urgentes e não planejadas, que surgiam no meio do Sprint.
Com isso, os recursos eram realocados, comprometendo o que havia sido planejado.
4.3 Quadro para acompanhamento de tarefas
Geralmente, no Scrum, usa-se o quadro para ilustrar as tarefas a serem executados no
Sprint, assim como, no Kanban, utiliza-se o quadro Kanban, ambos com o intuito de controlar
o fluxo de tarefas ao longo do processo, como mostra a figura 9 (KNIBERG; MATTIAS,
2009, p. 37).
Figura 9 - Exemplo de quadro Scrum e Kanban.
Fonte: Kniberg e Mattias (2009, p.37)
Kniberg e Mattias (2009, p.38) explicam que, na Figura 6, a diferença está apenas no
algarismo “2”, posto na coluna “andamento” do Kanban, significando que „não pode haver
mais de 2 itens nesta coluna ao mesmo tempo‟.
Na coluna “em execução”, não há, no Scrum, regra que determine quantas atividades
podem ocorrer simultaneamente, no entanto, como a iteração tem um escopo fixo, no exemplo
acima, fica limitado a quatro.
Conclui-se que, o Scrum, indiretamente, limita as atividades em andamento, ao passo
que, o Kanban limita diretamente. A prática tem mostrado às equipes Scrum que não é uma
boa alternativa ter muitas atividades simultâneas na coluna “em execução”, assim como, tem-
se favorecido a cultura de não se iniciar outra atividade antes de finalizar aquelas que estão
em curso. Caso as equipes limitem as atividades na referida coluna, o quadro Scrum passa a se
configurar em quadro Kanban, significando que “equipes Scrum podem usar um quadro
Kanban para gerenciar suas tarefas”. (KNIBERG; MATTIAS, 2009, p. 38)

17. 17
Silva et al (2012) relatam a dificuldade no uso do quadro Scrum, sem limitar a
quantidade de tarefas na coluna “verificar”, que acarretava um atraso na liberação de outras
funcionalidades, comprometendo, assim, o ritmo e a frequência de entregas. Quando a equipe
passa a limitar um determinado estado do fluxo, equipes de Scrum passam a usar o quadro
Kanban.
4.4 Equipes multifuncionais
Quanto às equipes, estas podem ser multifuncionais, sendo esta uma característica do
Scrum, ao passo que é opcional, no Kanban. As características de uma equipe multifuncional
requer que todos os membros tenham as habilidades necessárias para completar todos os itens
constantes na iteração. (KNIBERG; MATTIAS, 2009)
A visibilidade do quadro Scrum, conforme se apresenta na figura 10, é recomendada,
pois permite que seja visto por qualquer pessoa na Organização, porém, a edição do mesmo
somente poderá ser feita por membros da equipe, haja vista que se trata de uma ferramenta (o
quadro) que orienta o gerenciamento do compromisso assumido pela equipe no Sprint
Planning, diferentemente do Kanban, em que o quadro de atividades não é “propriedade
exclusiva” de uma única equipe, estando relacionado, não especificamente às atividades de
uma equipe, mas, ao fluxo de trabalho que envolve várias equipes. (KNIBERG; MATTIAS,
2009, p. 55)
Figura 10 - Exemplo de quadro Scrum, Kanban, multifuncionais ou não.
Fonte: Adaptado de Kniberg e Mattias (2009, p.56)
A figura 10 relaciona dois exemplos, sendo que, o primeiro mostra o quadro de
atividades de uma equipe multifuncional do Kanban, da mesma forma como ocorre no Scrum.

18. 18
No exemplo 2, no que se refere ao quadro Kanban, o Product Owner define prioridades
(coluna 1), a equipe multifuncional de desenvolvedores realiza o desenvolvimento (coluna 2)
e testa (coluna 3), e a equipe especializada é responsável pela entrega (coluna 4). Uma
sobreposição de competências é observada, ao mesmo tempo em que poderá haver um
deslocamento de um membro da equipe de desenvolvimento, objetivando agilizar a entrega.
Pressupõe-se que, em Kanban é necessário estabelecer regras básicas, determinando
quem e como deve ser usado o quadro de atividades. Essas regras devem ser experimentadas
até que o fluxo seja aperfeiçoado. (KNIBERG; MATTIAS, 2009, p. 56)
Compreende-se, portanto, que o papel das equipes, multifuncionais ou não, requer
compromisso, para que o fluxo de trabalho aconteça satisfatoriamente, dentro do previsto e do
que foi assumido.
4.5 Estimativa e velocidade
No que pertine à prescrição de estimativas e velocidades, no Scrum, a primeira é
relacionada à quantidade de trabalho estimada para cada item, com os quais os membros se
comprometem realizar. A segunda (velocidade) é a medida da capacidade (quantidade de
coisas) que pode ser entregue por Sprint, calculada “somando o tamanho de cada item
concluído ao final de cada Sprint”. Os doutrinadores orientam que a equipe deve tomar
conhecimento da velocidade, permitindo, dessa forma, fazer previsões de entregas mais
próximas da realidade.
Em Kanban, fazer estimativa é opcional. “Algumas equipes optam por fazer
estimativas e medir a velocidade assim como no Scrum. Outras equipes escolhem pular as
estimativas, mas tentam quebrar cada item em itens menores de aproximadamente do mesmo
tamanho – desta forma eles podem medir a velocidade simplesmente em termos de quantos
itens foram concluídos por unidade de tempo”. (KNIBERG; MATTIAS, 2009, p. 60).
Vale ressaltar que, “Scrum e Kanban não são perfeitos tampouco completos. Eles
não lhe dizem tudo o que você precisa fazer, eles apenas lhes oferecem algumas restrições e
orientações.” (KNIBERG; MATTIAS, 2009, p. 28)
Há, portanto, inúmeras formas e técnicas de planejamento de entregas e de
gerenciamento de compromissos para o modelo Kanban, devendo ser escolhida a que melhor
se enquadre ao contexto, não havendo técnica específica ou obrigatória a ser seguida.

19. 19
CONSIDERAÇÕES FINAIS
Através deste estudo, buscou-se explicitar as contribuições da aplicação de uma
metodologia ágil, combinando Scrum e Kanban no gerenciamento de projetos de
desenvolvimento de sistemas, visto que, tal medida favorece a melhoria no gerenciamento dos
projetos, ao passo que motiva a equipe, trazendo um maior comprometimento de todos para
lograr êxito. Outro aspecto a se considerar, analisado nesta combinação, é que permite a
inspeção contínua, facilitando as adaptações durante o processo de desenvolvimento.
É consenso na literatura consultada que a combinação de Scrum e Kanban vem sendo
relevante para o gerenciamento de projetos de sistemas, uma vez que Kanban se apresenta de
forma muito flexível e, por isso, é uma alternativa, quando as prescrições do Scrum não são
possíveis.
No decorrer deste artigo, foram apresentados aspectos relacionados à evolução no
gerenciamento do projeto, desde quando o desenvolvimento de software baseava-se em
metodologias tradicionais até a utilização de metodologias ágeis para superar problemas no
desenvolvimento de software.
Outro ponto abordado refere-se à apresentação do Scrum, definindo-o como
framework, em que é possível utilizar variados processos e técnicas no gerenciamento e
desenvolvimentos de produtos, bem como descreve as iterações.
O Kanban é, ainda, apresentado como um método que se baseia em controles visuais,
que possibilita visualizar o fluxo do trabalho, limitando-o em progresso e realizando o
acompanhamento do tempo de execução da tarefa.
Ao apresentar tais aspectos, são apontadas as diferenças e similaridades entre Scrum
e Kanban, a partir de quadro comparativo, no sentido de analisar as possíveis combinações,
principalmente pelo fato de ambos apresentarem características adaptativas.
A revisão sistemática das obras citadas está direcionada para compreender como a
combinação pode ser realizada, identificando as possibilidades de melhoria e sucesso para as
equipes, seja de gerenciamento ou de desenvolvimento.
Os resultados apontam que, as exigências atuais do mercado de sistemas, cada vez
mais complexos, em um curto espaço de tempo, e compatíveis com os requisitos, que são
alterados constantemente, levaram as empresas a adotarem combinações que possibilitem

20. 20
reduzir o tempo de entrega e os custos, em um contexto que não está livre de muitos
problemas.
Para que a combinação se apresente apropriada é preciso conhecer o funcionamento
do Scrum e do Kanban, bem como, saber como se deve usar o Scrum com Kanban, admitindo
o Scrum Backlog, as iterações em time-box, as mudanças dentro de uma iteração, o quadro de
acompanhamento de tarefas, as equipes multifuncionais, a estimativa e a velocidade.
A combinação Scrum com Kanban pode ser adotada por equipes, pois ambas
apresentam características adaptativas, e são baseados no desenvolvimento iterativo e
incremental, possibilitando, dessa forma, trazer mudanças significativas, tais como, a
diminuição do número de reclamações, a superação dos pontos de gargalos e a melhoria na
qualidade do serviço.
Ressalta-se que, ao combinar Scrum e Kanban, a organização não estará isenta de
todas as dificuldades, mas, enfrentá-los, passa a ser um desafio, sobretudo de equipes.
REFERÊNCIAS
AGILE MANIFESTO [site]. [S.l.]. Manifesto para Desenvolvimento Ágil de Software, 2001.
Disponível em: <http://agilemanifesto.org/>. Acesso em: 1 fev. 2012.
AGILE COACHING [site]. [S.l.]: Agile Coaching DK, 2012. Disponível em:
<http://www.agilecoaching.dk>. Acesso em: 1 fev. 2012.
BECK, Kent. Extreme Programming Explained: Embrace Change. 2. ed (The XP Series).
Boston, Massachusetts: Addison-Wesley Professional, 1999.
GIL, A. C. Como elaborar projetos de pesquisa. 5. ed. São Paulo: Atlas, 2010.
KATAYAMA, Eduardo Teruo. A contribuição da indústria da manufatura no
desenvolvimento de software. 2010. 114 p. Dissertação (Mestrado em Ciência da
Computação). Instituto de Matemática e Estatística da Universidade de São Paulo, São Paulo,
2010. Disponível em: <http://grenoble.ime.usp.br/~gold/orientados/dissertacao-
EduardoKatayama.pdf>. Acesso em: 1 fev. 2012.
KNIBERG, H.; MATTIAS, S. Kanban e Scrum: obtendo o melhor de ambos. C4Media,
2009. 139 p. Disponível em: <http://www.infoq.com/br/minibooks/Kanban-Scrum-
minibook>. Acesso em: 1 fev. 2012
LARMAN, Craig. Agile and iterative development: a manager‟s guide. Boston,
Massachusetts:Addison-Wesley Professional, 2003.

21. 21
NEVES, José Luiz. Pesquisa qualitativa: características, usos e possibilidades. Cadernos de
Pesquisas em Administração, São Paulo, v.1, nº3, 2º sem./1996. Disponível em:
<http://www.ead.fea.usp.br/Cad-pesq/arquivos/C03-art06.pdf>. Acesso em: 02 fev. 2012.
POPPENDIECK, M.; POPPENDIECK, T. Implementing Lean Software Development:
From Concept to Cash. Boston, Massachusetts: Addison-Wesley Professional, 2006.
SATO, D. T. Uso eficaz de métricas em métodos ágeis de desenvolvimento de software.
2007. Dissertação (Mestrado em Ciência da Computação). Universidade de São Paulo.
Instituto de Matemática e Estatística. São Paulo, 2007. Disponível em:
<www.teses.usp.br/teses/disponiveis/45/45134/tde-06092007-225914/>. Acesso em: 2 fev.
2012.
SCHWABER, Ken. SUTHERLAND, Jeff. The Scrum Guide. [S.l.], 2011. Disponível
em:<http://www.Scrum.org/storage/Scrumguides/Scrum_Guide.pdf>. Acesso em: 2 fev. 2012.
SCHWABER, K.; BEEDLE, M. Agile Software Development with Scrum. NJ: Prentice-
Hall, 2002.
SILVA, Diogo Vinícius de S.; SANTOS, F. Alan de O.; SANTOS NETO, Pedro. Os
benefícios do uso de Kanban na gerência de projetos de manutenção de software. Belo
Horizonte, MG, 2012. VIII Simpósio Brasileiro de Sistemas de Informação (SBSI 2012)
Trilhas Técnicas. Disponível em:
<http://www.lbd.dcc.ufmg.br/colecoes/sbsi/2012/0035.pdf>. Acesso em: 20 jun.2012.
SOARES, Michel dos Santos. Comparação entre Metodologias Ágeis e Tradicionais para
o Desenvolvimento de Software. Unipac - Universidade Presidente Antônio Carlos
Faculdade de Tecnologia e Ciências de Conselheiro Lafaiete. Conselheiro Lafaiete, MG,
2004. Disponível em:<www.dcc.ufla.br/infocomp/artigos/v3.2/art02.pdf>. Acesso em: 2 fev.
2012.
SPEAR, S.; BOWEN, H.K.. Decoding the DNA of the Toyota production system. [S.l.]:
Harvard Business Review, 77:96-108, 1999.