Lean Delivery

Lean Product Development:
Guiando a Construção do MVP

com Scrum e Kanban
Paulo Caroli
This book is for sale at http://leanpub.com/lean-delivery
This version was published on 2019-11-13
This is a Leanpub book. Leanpub empowers authors and

publishers with the Lean Publishing process. Lean Publishing is
the act of publishing an in-progress ebook using lightweight tools
and many iterations to get reader feedback, pivot until you have
the right book and build traction once you do.
© 2019 Paulo Caroli

Contents
Sobre Paulo Caroli . . . . . . . . . . . . . . . . . . . . . . . . i
Sobre a Editora Caroli . . . . . . . . . . . . . . . . . . . . . . ii
Sobre esse e-Book . . . . . . . . . . . . . . . . . . . . . . . . iii
Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv
A série Lean Strategy . . . . . . . . . . . . . . . . . . . . iv
O ciclo PDCA do Lean Strategy . . . . . . . . . . . . . . . . 1

Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Act . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Lean Inception . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Conhecimento, relacionamento e comprometimento . . . 8
Calculando esforço, tempo e custo . . . . . . . . . . . . . . 12

O sequenciador . . . . . . . . . . . . . . . . . . . . . . . . 12
Template do sequenciador . . . . . . . . . . . . . . . . . . 14
As regras do sequenciador . . . . . . . . . . . . . . . . . . 15
Detalhando a amostra de funcionalidades em tarefas . . 16
Dimensionamento de tarefas . . . . . . . . . . . . . . . . 19
Entendendo custo e tempo . . . . . . . . . . . . . . . . . 21
Tirando a média . . . . . . . . . . . . . . . . . . . . . . . 22
CONTENTS
Somente Devs estimam? . . . . . . . . . . . . . . . . . . . . 27
Estimativa cascata ou ágil . . . . . . . . . . . . . . . . . . . 28

Time multi-funcional . . . . . . . . . . . . . . . . . . . . 29
Teste Antes, valide depois . . . . . . . . . . . . . . . . . . . 31
Puxe, não Empurre . . . . . . . . . . . . . . . . . . . . . . . . 33
Escopo funcional do MVP . . . . . . . . . . . . . . . . . . . 34

MVPs são pequenos . . . . . . . . . . . . . . . . . . . . . 37
MVP e o Fluxo de trabalho . . . . . . . . . . . . . . . . . 37
Construindo MVP com Scrum . . . . . . . . . . . . . . . . . 38

Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
O MVP nas cerimônias do Scrum . . . . . . . . . . . . . . 42
Construindo MVP com Kanban . . . . . . . . . . . . . . . . 44

Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
O MVP no Kanban . . . . . . . . . . . . . . . . . . . . . . 47
MVP, Kanban e bugs . . . . . . . . . . . . . . . . . . . . . . . 57

Capacidade para lidar com os bugs . . . . . . . . . . . . . 58
Radar de Débito Técnico . . . . . . . . . . . . . . . . . . . . 60
Acompanhamento Lean . . . . . . . . . . . . . . . . . . . . . 63
O entendimento da iniciativa via MVP . . . . . . . . . . 63
O planejamento do produto e seus MVPs . . . . . . . . . 64
O acompanhamento da criação do produto via MVP . . 66
Status report do MVP . . . . . . . . . . . . . . . . . . . . . . 70

Nome do time e ID do MVP . . . . . . . . . . . . . . . . . 71
Nome do MVP . . . . . . . . . . . . . . . . . . . . . . . . 71
Estado atual . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Data atual e data prevista . . . . . . . . . . . . . . . . . . 71
Lista de features do MVP . . . . . . . . . . . . . . . . . . 71
CONTENTS
Nível de incerteza da funcionalidade . . . . . . . . . . . . 72

Estado e % de completude da funcionalidade . . . . . . . 72
Detalhamento e texto descritivo . . . . . . . . . . . . . . 73
Burn-up de Features do MVP . . . . . . . . . . . . . . . . . 74

Os eixos do burn up . . . . . . . . . . . . . . . . . . . . . 76
O ritmo da construção do MVP . . . . . . . . . . . . . . . 76
Verificando o progresso . . . . . . . . . . . . . . . . . . . 78
A linha de escopo do MVP . . . . . . . . . . . . . . . . . 80
Diagrama de Fluxo Cumulativo . . . . . . . . . . . . . . . . 82

Interpretando o CFD . . . . . . . . . . . . . . . . . . . . . 84
A fazer / Fazendo / Feito . . . . . . . . . . . . . . . . . . . 86
Quando estará pronto? . . . . . . . . . . . . . . . . . . . . 87
Mudança no escopo . . . . . . . . . . . . . . . . . . . . . 88
Trabalho em Andamento (WIP) . . . . . . . . . . . . . . 89
Tempo de atravessamento (Lead Time) . . . . . . . . . . 90
Taxa de transferência (Throughput) . . . . . . . . . . . . 91
Lei de Little . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Tempo de Ciclo (Cycle Time) . . . . . . . . . . . . . . . . 96
Estabilizando o sistema . . . . . . . . . . . . . . . . . . . 98
Sistema Puxado . . . . . . . . . . . . . . . . . . . . . . . . 99
Sistema Estável . . . . . . . . . . . . . . . . . . . . . . . . 100
Estabilidade no sistema . . . . . . . . . . . . . . . . . . . 101
Mantenha o CFD simples . . . . . . . . . . . . . . . . . . 104
Sobre o jogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Objetivos do jogo . . . . . . . . . . . . . . . . . . . . . . . 106
Objetivo 1: planejar as entregas . . . . . . . . . . . . . . . 107
Objetivo 2: entregar o MVP e seus incrementos . . . . . 108
Sobre o Scrum no jogo . . . . . . . . . . . . . . . . . . . . 109
Sobre o Kanban no jogo . . . . . . . . . . . . . . . . . . . 110
Prep for Dev . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Sobre Paulo Caroli
Consultor principal da Thoughtworks Brasil e cofundador da Ag-
ileBrazil, Paulo Caroli possui mais de vinte anos de experiência em
gestão e desenvolvimento de software, com passagem em varias
corporações no Brasil, Índia e EUA . Em 2000, conheceu o Extreme
Programming e, desde então, tem mantido seu foco em processos e
práticas de gestão e desenvolvimento ágil. Ingressou na Thought-
Works em 2006 e ocupou os cargas de agile coach, treinador, e
Gerente de Projetos. Possui os títulos de Bacharel em Ciência da
Computação e MS em Engenharia de Software, ambos da PUC
-Rio. Autor dos Livros ”Lean Inception: Como alinhar Pessoas e
Construir o Produto Certo” , e “Fun Retrospectives; activities and
ideas for making agile retrospectives more engaging”.
Paulo Caroli
Acompanhe Paulo Caroli no seu site e nas redes sociais:

Sobre a Editora Caroli
A Editora Caroli nasceu em 2017, quando Paulo Caroli decidiu
realizar todos os passos desde escrever um livro a impressão e venda
do mesmo. Este livro é O Mistério do Colégio Alipus, um livro de
ficção juvenil escrito por Paulo Caroli e sua filha Duda Chaieb —
na época com doze anos—; o livro foi premiado como destaque na
categoria na feira do livro de Porto Alegre em 2018; confira em
www.MisterioDoColegio.com .
Paulo Caroli segue muito do seu aprendizado no Vale do Silício para
a criação de conteúdo e publicação de livros. Com um estilo Lean
StartUp (construir fazendo) nasceu a Editora Caroli.
Caroli constituiu uma editora para publicar seus livros e para ajudar
a publicar livros de amigos.
WIP (Writing In Progress)

A Editora Caroli apresenta uma nova proposta de trabalho, aprox-
imando autores dos seus leitores desde o início da geração do
conteúdo. Porque esperar o autor terminar de escrever para ver se o
conteúdo é bom? No mundo atual isso não faz mais sentido. Então a
Editora Caroli promove o compartilhamento (gratuito sempre que
possível) do WIP (Writing In Progress) através dos formatos eBook
(pdf, mobi e epub). Desta forma, leitores tem acesso rápido as novas
ideias, e podem fazer parte da evolução da obra. Para os autores,
esse é uma forma efetiva de feedback e motivação para a geração
de conteúdo.
Este e outros eBooks estarão disponíveis no site http:

//caroli.org
Sobre esse e-Book
Esse e-book foi criado para complementar o treinamento de mesmo
nome. Saiba mais sobre o treinamento em https://caroli.org/treinamento/
lean-product-development
Depois de muitos anos facilitando Lean Inceptions, senti a necessi-
dade de esclarecer alguns assuntos correlacionados e demonstrar a
forma como times de sucesso trabalham.
As empresas e equipes que usam Lean Inception, geralmente se
utilizam de uma estratégia mais lean, planejam e acompanhas seus
MVPs com boas práticas de fluxo e interações.
Este e-book faz parte da série Lean Strategy, com o foco em
entender e melhorar o processo na etapa DO.
Se você busca algo mais técnico, com práticas de engenharia
de software (código, DevOps, trunk único, feature toggles, etc),
procure pelo e-book Lean Engineering.
Se você ainda não leu, confira o primeiro livro desta série, o Lean
Inception.
Disclaimer
Estou tratando esse E-Book como um MVP. Se já tem algo minima-
mente viável para passar a ideia, o conceito, então está disponível.
Por isso neste E-Book você vai encontrar erros de ortografia,
imagens em versões iniciais, e texto por escrever.
Mas como um bom MVP, estou muito interessado no seu feedback.
Abraços,
Paulo Caroli
A série Lean Strategy

Este e-book faz parte da série Lean Strategy, a qual é formada pelo
livro Lean Inception (best-seller na Amazom.com.br, publicado em
novembro de 2018) e outros livros e e-books correlacionados.
Dado que alguns desses e-books são WIP –Writing In Progress, você
pode encontrar textos repetidos entre esses e-books. Com o tempo
e a evolução dessa série, eu irei adicionando, alterando e revendo o
conteúdo dos livros e e-books.
Confiram em www.caroli.org/serie-lean-strategy este e os outros
conteúdos desta série.
O ciclo PDCA do Lean
Strategy
O PDCA do Lean Strategy
Esse é o ciclo do PDCA: Tudo começa a partir de um workshop

de OKR (em Inglês, Objectives and Key Results) para a Unidade de
Negócio (UN).
Então várias iniciativas (candidatas) da UN são consideradas em
um workshop de priorização relativa, onde essas são avaliadas
quantitativamente, considerando o valor e o esforço de cada uma
(PLAN).
O próximo squad disponível puxa a iniciativa priorizada (sistema
puxado) para um workshop de Lean Inception, onde todos juntos
(negócio, tecnologia e UX) compreendem e criam o plano para a
criação do MVP. Seguindo as práticas Scrum, Kanban e DevOps, o
squad constrói o MVP (DO).
Assim que o MVP está pronto, este é liberado para os seus usuários
O ciclo PDCA do Lean Strategy 2
finais. Os dados de uso são coletados e compilados como métricas

a serem analisadas (CHECK).
Comparando o resultado obtido com o resultado esperado do MVP,
decidimos como prosseguir com a iniciativa: pivotar, prosseguir,
ou cancelar. Esta decisão é realizada perante os resultados ap-
resentados por todas as iniciativas em andamento, seus MVPs,
a capacidade, o budget, os investimentos, e o alinhamento com
os OKRs da UN (ACT). Com base nesses parâmetros, decidimos,
estrategicamente, quais iniciativas começar, quais continuar, quais
pivotar, e quais cancelar.
O modelo Lean Strategy traz disciplina para priorizar, construir,
medir, e coordenar esforços para alcançar os objetivos estratégicos
do negócio.
Plan
Vamos planejar as ações estratégicas organizacionais para alcançar
nossos objetivos. Para tanto, vamos manter um portfolio dinâmico,
que nos permita compreender e agrupar as iniciativas, permitindo
tanto (1) uma priorização inicial quanto (2) o redirecionamento
baseado no feedback de cada iniciativa.
Do
Dado uma iniciativa priorizada, vamos compreendê-la, e executá-la
de forma enxuta, ágil e centrada no feedback dos nossos usuários.
Para tanto faremos entregas rápidas e frequentes.
O ciclo PDCA do Lean Strategy 3
Check
Medimos o uso de cada MVP. Essas métricas são essenciais para
validação de hipóteses e ajustes na evolução de nossas iniciativas,
baseado no feedback de uso.
Act
Decidimos como proceder com cada iniciativa: pivotar, prossegir,
ou cancelar. Vamos rever as hipóteses iniciais (PLAN) e os dados
de uso dos MVPs (CHECK). Iremos também comparar as diversas
iniciativas perante o orçamento da Unidade de Negócio (UN) e os
OKRs, os nossos direcionadores de negócio ativos, atualizados e
acionáveis.
Lean Inception
Lean Inception é um workshop colaborativo para alinhar um grupo
de pessoas a construir o produto certo.
Tipicamente um grupo de pessoas vai começar a trabalhar em um
produto digital. Vários podem ser os motivos para se trabalhar em
um produto digital:
• Alguém investiu na sua startup e você vai colocar a sua ideia

em execução
• A sua empresa está modernizando algo e vai refazer um
produto já existente
• Um grupo anterior fracassou para criar o produto, agora é
segunda tentativa, com mais pressão e menos dinheiro
• Pesquisas indicam um bom direcionamento de negócio, agora
o grupo busca o product-market fit
Antes de sair fazendo, o grupo participa de um workshop colab-

orativo com uma sequência de atividades para alinhar e definir
objetivos, estratégias e escopo do produto. Um workshop que usa
técnicas de Design Thinking com uma abordagem de Lean Startup:
o workshop de Lean Inception.
A forte influência de Lean StartUp é um dos dois motivos para

a palavra Lean no nome do workshop, Lean Inception.
O nome Inception vem do RUP (Rational Unified Process), um

processo de engenharia de software criado pela Rational** nos anos
90 para o desenvolvimento orientado a objetos, baseado no UML
(Unified Modeling Language).
Lean Inception 5
A Rational foi comprada pela IBM em 2003. E, nessa época, o

RUP era considerado um dos métodos ágeis, com sua proposta
de ciclos de entrega mais curtos (apesar de iterações atual-
mente consideradas longas, como três meses) e incrementais.
Inception é a primeira de quatro fases do RUP: Inception, Elabora-

tion, Construction e Transition. Na fase de Inception era realizado
a análise sobre os objetivos, a arquitetura e o planejamento do pro-
jeto. Isso acontecia via entrevistas com os stakeholders, convertidos
em requisitos descritos no formato de casos de uso.
Os casos de uso caíram em desuso e o povo dos métodos ágeis
adotou o formato de histórias do usuário, o que, como dizia o
próprio nome, era para os usuários. Isso aconteceu entre os anos
de 2006 a 2010.
O nome inception continuava a ser usado, mas o seu foco e
estilo alterou: foram adicionadas atividades sobre os usuários e
suas jornadas (influencia de design thinking e user-centric design);
muitas histórias dos usuários eram escritas, estimadas, arquitetadas
e colocadas em um plano: o plano de release do produto.
Eu participava de muitas inceptions. Eu adorava essa fase, esse
início de projeto, essa etapa, essas várias reuniões (muitas vezes,
ao longo de quatro semanas) para, enfim, chegar a um plano de
release do produto.
Mas em 2011 nasceu meu filho.
Daí você se pergunta; mas o que isso tem a ver com Lean Inception?
Tudo. Ele nasceu e eu nunca consegui ficar longe dele por mais de
uma semana. Mas eu era o facilitador de inceptions mais experiente
do meu escritório. Eu era chamado para facilitar inceptions em
outros países. E essas duravam algumas semanas, tipicamente de
Lean Inception 6
duas a quatro semanas, com reuniões no escritório do cliente que

contratava a Thoughtworks para a criação do produto digital.
Eu precisava reduzir o tempo de duração das inceptions, deixá-
las mais enxutas (Lean), para voltar para casa depois de uma
semana de trabalho no escritório do cliente, longe de casa.
E nesse mesmo ano, Eric Ries publicou o livro, agora o best-seller,
The Lean StartUp. Nesse livro eu encontrei a desculpa ideal para
voltar para casa em apenas uma semana: o MVP, o produto mín-
imo viável, engrenagem fundamental do ciclo Construir-Medir-
Aprender.
o ciclo Construir-Medir-Aprender
O produto mínimo viável, em Inglês Minimum Viable Product

(MVP), é a versão mais simples de um produto que pode ser
disponibilizada para o negócio. O MVP determina quais são as
funcionalidades mais essenciais para que se tenha o mínimo de
produto funcional que possa agregar valor para o negócio (produto
mínimo) e que possa ser efetivamente utilizado e validado pelo
usuário final (produto viável).
Lean Inception 7
Pronto. Na inception, o foco era em gerar o plano de release do

produto, muitas vezes bem completo. Mas na Lean Inception o foco
é no MVP, no mínimo viável do produto. Pensamos no produto, mas
somente alinhamos e planejamos o MVP. Cansamos daquela época
que criávamos muita funcionalidade que não era usada (nossa,
como desperdiçamos tempo, e dinheiro!)
Esses são os dois motivos para o nome Lean Inception: (1) fazer a
inception mais rápida – enxuta ou Lean – para voltar logo para casa,
e (2) pela foco no MVP, peça-chave do movimento Lean StartUp.
O resultado de anos de experiência prática –a receita da Lean
Inception– está descrito no meu livro Lean Inception: Como Al-
inhar Pessoas e Construir o Produto Certo.
Conforme informado no capítulo Sobre este E-Book, este livro é
específico para a etapa DO do Lean Strategy, que começa com uma
Lean Inception.
Conhecimento,
relacionamento e
comprometimento
Conhecimento, relacionamento e comprometimento. Essas são os
três principais benefícios oriundos da semana da Lean Inception.
Quem participa da semana da inception adquire um alto nível de
conhecimento sobre o produto a ser criado.
Também cria uma aproximação e um bom relacionamento com
as outras pessoas envolvidas com a criação do produto.
Além de assumir um alto nível de comprometimento com as
datas e entregáveis acordados na inception.
Entretanto, a negativa também é verdadeira. Imagine alguém que
não participou da semana da Lean Inception. E , depois de algum
tempo – dias ou semanas, entra para o time que está trabalhando
na criação do MVP.
Esse novo integrante do time não tem o mesmo nível de con-
hecimento, relacionamento e comprometimento que aqueles que
participaram da semana da inception.
É muito importante ressaltar esse aspecto. Por mais que esse
novo integrante entenda rapidamente os detalhes do MVP a ser
construído, ele vai precisar de ajuda e tempo para consolidar
conhecimento, relacionamento e comprometimento, assim como os
outros integrantes do time (que estão juntos desde a inception).
Conhecimento, relacionamento e comprometimento 9
exemplo de artefatos, resultado de uma Lean Inception
A foto acima demonstra um resultado tangível da inception: o plano

de liberação do produto via MVP. Isso tem muito valor. Esse plano
está visível na foto (o sequenciador de features e o canvas MVP). O
novo integrante do time vai ver essa foto e entender esse plano.
Mas tem algo que não aparece na foto, no Jira, na planilha Excel,
ou nos flipcharts com post-its coloridos: conhecimento, relaciona-
mento e comprometimento. E esses também são resultados da
inception. Veja abaixo algumas fotos da interação entre as pessoas
durante a Inception:
um time numa Lean Inception
outro time numa Lean Inception
Cuidado. Uma inception bem sucedida é somente o começo dessa

jornada. Saindo da inception precisamos considerar outros aspectos

para assegurar o sucesso dessa empreitada.
Em relação aos integrantes do time:
• Evite grandes mudanças no time original, mas se isso for

inevitável, tente amenizar (quanto menos mudança, melhor).
• Apoie cada novo integrante para elevar o seu nível de con-
hecimento, relacionamento e comprometimento.
Os capítulos a seguir compartilham mais detalhes sobre como guiar

a entrega enxuta com fluxo e interações.
Calculando esforço,
tempo e custo
*Este capítulo contém conteúdo do livro Lean Inception, adaptado
e organizado para este livro.
A maioria das empresas que conheço está muito interessada em
responder a duas perguntas simples e diretas: O que devemos
construir? E quando estará pronto?
O sequenciador de funcionalidades responde à primeira pergunta.
Ele mostra o MVP e seus próximos incrementos. É um artefato
incrível gerado na Lean Inception. Muitos stakeholders ficarão
satisfeitas com a informação clara e direta sobre as funcionalidades
do MVP e os incrementos do produto.
Mas quando estará pronto? Algumas pessoas farão essa pergunta.
Quando o MVP vai estar pronto? E o próximo incremento? E quanto
a todas as funcionalidades no sequenciador?
Este capítulo compartilha uma técnica que tem ajudado muitas
equipes a responder esses questionamentos.
O sequenciador
Conforme descrito no livro Lean Inception, o sequenciador auxilia
na organização e na visualização das funcionalidades e da sequên-
cia de liberação de entrega incremental do produto mínimo e viável,
o MVP. O sequenciador organiza e planeja entregas do produto,
deixando claro as funcionalidades do MVP e os incrementos subse-
quentes.
Calculando esforço, tempo e custo 13
Além de mostrar os cartões de funcionalidades ordenados, o se-

quenciador mostra claramente o agrupamento de funcionalidades
para cada MVP. Isso é representado por post-its colados no sequen-
ciador, delimitando o MVP1, o MVP2 e assim por diante.
exemplo: Canvas MVP1 e Canvas MVP 2 ao lado do sequenciador de funcional-

idades
Segue abaixo um sequenciador, exemplo de resultado de uma Lean

Inception, que será usado para ilustrar a construção das funcional-
idades do MVP com Scrum e com Kanban nos capítulos a seguir.
Sequenciador
Note no sequenciador apresentado que o MVP 1 é composto pelas

features F1, F2, F3, F4, F5 e F6.
Template do sequenciador
Imagine uma sequência de ondas, uma depois de outra, e elas são,
aproximadamente, do mesmo tamanho. Essas ondas estão numer-
adas: 1, 2, 3 e assim por diante. Esse é o template do sequenciador.
sequenciador de funcionalidades
O intuito é executar o que é mais impactante o mais cedo possível,

logo nas primeiras ondas. E seguir trabalhando nas funcionalidades
do sequenciador, de onda em onda.
Para ajudar a decidir o que colocar em qual onda e normalizar o
tamanho das ondas, siga as regras do sequenciador.
As regras do sequenciador
Essas são as seis regras para adicionar cartões às ondas do se-
quenciador. Elas foram definidas depois de aplicar essa forma de
organização e priorização de funcionalidades inúmeras vezes.
• Regra 1: Uma onda pode conter, no máximo, três funcionali-

dades.
• Regra 2: Uma onda não pode conter mais de uma funcionali-

dade em cartão vermelho.
• Regra 3: Uma onda não pode conter três funcionalidades
somente em cartões amarelos ou vermelhos.
• Regra 4: A soma de esforço das funcionalidades não pode
ultrapassar cinco “E”.
• Regra 5: A soma de valor das funcionalidades não pode ser
menos de quatro “$” e quatro corações.
• Regra 6: Se uma funcionalidade depende de outra, essa outra
deve estar em alguma onda anterior.
A regra 1 limita o número de funcionalidades que estão sendo

trabalhados ao mesmo tempo. Isso evita o acúmulo de itens de tra-
balho parcialmente completos, aumentando o foco para as poucas
funcionalidades priorizadas por onda. As regras 2, 3 e 4 evitam um
período de trabalho desequilibrado, com muita incerteza ou muito
esforço. A regra 5 garante o foco constante na entrega de alto valor
para o negócio e para os usuários. A regra 6 evita problemas de
dependência entre funcionalidades.
Note que essas regras geram ondas de tamanho similar. Isso simpli-
fica a estimativa do MVP e seus incrementos, pois nos permite usar
seu tamanho médio de onda baseado em uma pequena amostragem.
Detalhando a amostra de
funcionalidades em tarefas
O tamanho das ondas é parecido. Logo, escolha duas ou três e use-
as para gerar informações detalhadas de esforço, tempo e custo.
Duas ou três ondas são suficientes para dar uma boa noção de tais
parâmetros e gerar uma média efetiva.
Passo a passo da atividade
1. Selecione duas ou três ondas a serem detalhadas.

2. Selecione uma funcionalidade de uma das três ondas de
amostra.
3. Descreva, em outros cartões, os pedaços menores para a
funcionalidade selecionada.
4. Volte ao passo 2 e selecione outra funcionalidade até ter
detalhado todas as funcionalidades das ondas de amostragem.
Ao selecionar as ondas de amostragem (passo 1), lembre-se que

neste momento você está interessado na estimativa do todo e no
tamanho médio de uma onda, e não no detalhamento do tra-
balho em si. Por isso, as ondas a serem escolhidas devem prover
boa combinação do nível de confiança (marcados pelas cores dos
cartões), bem como uma boa variação na soma dos níveis de esforço
(marcados com “E” nas funcionalidades).
O pedaço menor (passo 3) deve ser algo que faz sentido para o time.
Times de desenvolvimento de software que seguem a metodologia
Scrum costumam usar histórias do usuário como tais pedaços
menores. Outros times preferem chamá-los de tarefas, e descrevê-
las sem um formato predefinido. O mais importante é que o time
esteja confortável com o detalhamento desses pedaços menores e,
logo, consiga estimar seu tamanho e esforço.
Segue abaixo o exemplo ilustrativo de uma funcionalidade detal-
hada em tarefas.
funcionalidade detalhada em tarefas
No contexto deste livro, vou chamar de tarefas os pedaços menores

de uma funcionalidade. Normalmente, recomendo que as equipes
sejam muito específicas ao descrever essas tarefas, pois isso aju-
dará a atividade, mas não devem se preocupar em documentá-las
perfeitamente, pois isso deve ser feito depois, e não durante a Lean
Inception.
Durante o passo 3, faça uma marcação tanto no cartão da funcional-
idade, como nos cartões das tarefas de cada uma. Por exemplo,
marque F1 para todas tarefas da funcionalidade 1, F2 para as tarefas
da funcionalidade 2 e assim por diante. Nas atividades a seguir, os
cartões serão movidos, e tal marcação será utilizada para reagrupar
funcionalidades aos seus pedaços menores.
Ao final desta atividade, as funcionalidades selecionadas como
amostra estarão detalhadas com suas várias tarefas.
Dimensionamento de tarefas
Esta atividade é muito simples, mas essencial para entender o
esforço relativo das tarefas.
1. Escreva os seguintes tamanhos de camiseta em post-its: P, M

e G.
2. Coloque os post-its no canvas (normalmente uma mesa), o G
no canto superior esquerdo, o P no canto inferior esquerdo e
o M entre os outros dois.
3. Selecione duas tarefas e faça a seguinte pergunta: Como essa
tarefa se compara (em esforço) a essa outra? Ambas P? Uma
P, a outro M? G?
4. Coloque as duas tarefas no canvas, com suas posições relati-
vas indicando como elas se comparam em relação ao nível de
esforço (pequeno, médio ou grande). Coloque uma ao lado da
outra se ambas exigirem o mesmo nível de esforço; ou coloque
uma abaixo da outra, indicando que uma exige mais esforço
do que a outra.
5. Defina os limites entre os tamanhos e reposicione as tarefas
para tornar seus tamanhos claros. Se necessário, considere
criar um tamanho extra de camiseta (XP ou XG, para extra-
pequeno ou extragrande)
6. Enquanto houver tarefas a serem comparadas, coloque-as no
canvas de acordo com o nível de esforço e repita as etapas 3
e 4.
tarefas dimensionadas em P, M ou G
Ao final desta atividade, cada tarefa será associada a um tamanho

de camiseta: pequena, média ou grande.
As duas atividades anteriores (Detalhando a amostra de funcional-
idades em tarefas e Dimensionamento de tarefas) podem e devem
ser feitas ao mesmo tempo, conforme ilustrado na próxima imagem.
exemplo - detalhando e dimensionando as funcionalidades de amostragem
Nele, as tarefas são colocadas sob sua respectiva funcionalidade de

amostra, e próximo às tarefas de tamanhos similares (post-it com as
marcas P, M e G, respectivamente para pequeno, médio e grande).
Entendendo custo e tempo

Esta atividade é essencial para gerar números para o cálculo de
custo e de tempo para cada onda e para todo o sequenciador.
1. Selecione uma tarefa pequena, e pergunte quanto tempo uma

pessoa leva para completá-la.
2. Selecione mais duas ou três tarefas do mesmo tamanho e
repita a pergunta.
3. Faça a média do tempo e anote-a.
4. Repita os passos anteriores para tarefas de outros tamanhos.
Ao final desta atividade todas tarefas terão uma estimativa de

tempo e custo. Por exemplo, o seguinte resultado foi obtido numa
ocorrência desta atividade: um dia para tarefas pequenas, três dias
para tarefas médias e quatro dias para tarefas grandes.
As respostas de tempo irão influenciar o resultado final. Por isso,
seja bem enfático em relação à pergunta. Se possível, peça para
comparar com trabalhos passados, e tente entender a motivação e
a capacidade das pessoas respondendo a pergunta.
Desenvolvedores não gostam de responder “Quanto tempo leva
para uma pessoa completar tal tarefa?”.
Por isso, é muito importante que todos estejam muito à vontade
com a descrição da tarefa. Caso haja qualquer desconforto em
relação à ela, reescreva-a e considere quebrá-la em pedaços ainda
menores.
Outra forma de fazer tal pergunta é colocá-la no plural:
Considere uma dupla de desenvolvedores. Um sabe

mais do negócio, outro menos. Um mais sênior, outro
mais júnior. Um mais experiente na tecnologia, outro
mais novato. Quanto tempo leva para eles com-
pletarem tal tarefa?
Na minha experiência, todos ficam mais à vontade dando a resposta

quando consideram uma dupla de desenvolvedores atuando em
conjunto para completar uma tarefa.
Tirando a média
A partir do entendimento de esforço da atividade anterior, so-
mamos o tempo estimado para cada tarefa de cada funcionalidade,
e, com isso, somamos a duração prevista por funcionalidades de
cada onda escolhida do sequenciador. Dessa forma, chegamos a

uma média de esforço para cada onda, definido por pessoa e por
unidade de tempo.
As duas fotos a seguir demonstram como o cálculo foi realizado
para um time. As fotos mostram, respectivamente, as ondas escol-
hidas para amostragem e o cálculo realizado para obter a média do
tempo estimado por onda.
ondas e funcionalidades para amostragem
Note na foto anterior que as ondas 2, 3 e 4 foram selecionadas para

amostragem. Com isso, as funcionalidades detalhadas em tarefas
foram: F4, F5 (onda 2), F5, F6, F7 (onda 3), e F9, F10 e F11 (onda 4).
tirando a média
A foto anterior mostra o cálculo realizado para obter a média

do tempo estimado por onda. Cada tarefa foi estimada em dias
para uma dupla de desenvolvedores. Nela, cada linha mostra o
somatório da duração prevista das tarefas de uma funcionalidade.
A medida de tempo estimada para cada tamanho de tarefa foi:
¼ de um dia (pequeno), meio dia (médio), dois dias (grande) ou
cinco dias (extragrande). Realizando a somatório de tarefas por
funcionalidade – e depois de funcionalidades por onda –, o time
alcançou os valores de onze dias, onze dias e meio e nove dias,
respectivamente para as ondas 2, 3 e 4. Após uma boa conversa
entre todas pessoas, aquele time decidiu considerar uma média de
dez dias para uma dupla de desenvolvedores por onda.
A seguir há mais um exemplo de resultado para outro time.
exemplo de resultado
A figura anterior mostra outro resultado de uma Lean Inception

para duas ondas de amostra selecionadas: nove semanas e catorze
semanas. Depois de verificar este resultado, o principal stakeholder
disse: “Então, cada onda leva, aproximadamente, doze semanas
para um desenvolvedor. Como temos seis desenvolvedores nessa
equipe, parece que podemos entregar uma onda a cada duas se-
manas (doze semanas para um desenvolvedor equivale a duas
semanas de seis desenvolvedores), ou uma onda por Sprint, de
acordo com a terminologia do Scrum.” E continuou: “Como nosso
MVP está na onda 5, acredito que preciso ajustar o planejamento”.
outro exemplo de resultado
Na foto acima, há mais um exemplo de outra equipe. Nesse caso, a

média resultante foi de vinte unidades. Note o cálculo em post-its
no lado esquerdo, de três ondas de amostra.
No time em questão, a unidade utilizada era uma dupla de de-
senvolvedores por dia. Com essa informação, ficou fácil calcular
o esforço, tempo e custo de cada onda: “Podemos escolher tra-
balhar com uma dupla de desenvolvedores, e entregar uma onda
de funcionalidades em, aproximadamente, um mês (ou vinte dias
úteis). Outra opção seria dobrar o custo mensal, tendo duas duplas
de desenvolvedores e entregar, aproximadamente, duas ondas por
mês”.
Somente Devs estimam?
No capítulo anterior eu compartilhei uma forma para responder
quando o MVP vai estar pronto.
Alias, tal capítulo é originalmente do livro Lean Inception, já
publicado a bastante tempo. Por tal motivo, compartilho alguns
pontos para tentar responder a uma pergunta de alguns leitores:
só as pessoas desenvolvedoras estimam?
Esse assunto é controverso. Alias, a conversa relacionada a datas e
estimativa é controversa. De qualquer forma, vamos explorar esse
tópico um pouco mais.
Estimativa cascata ou
ágil
Ao final da Lean Inception, o squad realizou um cálculo por
amostragem para estimar a data de entrega dos MVPs. Isso é
necessário para dizer aos stakeholders quando o MVP estará pronto.
Na Lean Inception, as pessoas desenvolvedoras foram bem específi-
cas e te apresentaram a média esperada por onda do sequenciador;
isso “para todas as tarefas que precisam ser realizadas para ter
as funcionalidades em produção” (palavras do facilitador da Lean
Inception)
Mas por que não consideramos o tempo de teste? e o tempo de
análise?
A resposta é direta: Porque não trabalhamos em cascata, mas sim
de forma ágil.
No contexto deste livro, assumidos que o squad trabalha de forma
ágil — ao invés de uma cascata—, por isso o cálculo da data de
entrega do MVP é realizado de forma distinta de projetos em
cascata.
Estimativa cascata ou ágil 29
estimativa cascata versus estimativa ágil
Em projetos cascata, era comum somar todos os tempos das fases,

para, ao final chegar a uma data. Em projetos ágeis, após a Lean
Inception, consideramos o tempo da Sprint0, e realizamos um
cálculo para decidir a data que o MVP estará pronto.
Time multi-funcional
Times ágeis – squads – são multifuncionais. Isso significa que todos
membros do time se ajudam nas variadas tarefas, independente
dos seus conhecimentos e afazeres preferidos e cotidianos (devs
gostam de escrever código, testadores gostam de testar, UX gostam
de refletir sobre usabilidade, etc).
Mas, muitas vezes, uma pessoa que faz testes não necessariamente
sabe escrever código funcional. Assim como um PO, geralmente
não sabe escrever código funcional.
Em contra-partida uma pessoa desenvolvedora sabe ajudar com
análise e entendimento das funcionalidades e seus pedaços menores
(historias do usuário e tarefas), e também consegue ajudar com
testes exploratórios e manuais.
Estimativa cascata ou ágil 30
Pessoas desenvolvedoras em times ágeis ajudam tanto com a preparação

e análise do trabalho quanto com os testes e validação do mesmo.
Aliás, em times ágeis, é muito comum que todos se ajudem (muito)
em relação a preparação do trabalho e a validação do mesmo.
Teste Antes, valide
depois
Test driven development é uma das práticas do eXtreme Program-
ming, uma das metodologias precursoras de métodos ágeis. O livro
de eXtreme Programing é de 2000, um ano antes da criação do agile
manifesto ( e o termo Agile).
Times ágeis fazem TDD. Isso significa que os testes são escritos
antes do código funcional. Ou seja o código está pronto quando
a versão atualizada do produto (com a nova funcionalidade ou
história do usuário) passa por todos os testes do produto.
Todos os testes do produto, nesse momento, são: (1) os testes que
validam que o requisito em questão foi alcançado e (2) os testes
de regressão, aqueles que confirmam que todas funcionalidades
anteriores a essa continuam funcionando.
A grande maioria dos testes de regressão são testes automatizados.
Isso gera uma confirmação, em pouco tempo (minutos geralmente)
de que todo o produto está ok.
Mas, até hoje, eu nunca vi um local com 100% de automação, onde
não exista uma pessoa, um ser humano, realizando algum tipo
de validação mesmo após todos testes automatizados passarem.
Geralmente essas pessoas são chamadas de testadores.
Alguns times não possuem pessoas testadores, e tal validação é
realizada pelas pessoas desenvolvedoras e/ou o PO. Mas, alguns
times possuem pessoas testadores, que além de ajudar a analisar
o trabalho, ajudar os desenvolvedores com os critérios de aceite,
também fazem algumas tarefas de validação manual e exploratória
para confirmar o estado atual desejado do produto.
Teste Antes, valide depois 32
Na Lean Inception, quando o facilitador pede “todas as tarefas que

precisam ser realizadas para ter as funcionalidades em produção”,
o squad considera o tempo de: preparação dos dados de teste,
automação dos cenários de teste, scripts de integração e automação.
Ou seja, muito da preparação e validação do trabalho já está
comtemplado no ˜tempo de desenvolvimento˜
Puxe, não Empurre
Times ágeis não empurram trabalho adiante. Ao invés, o trabalho
é puxado da etapa mais próxima ao fim para a etapa anterior.
Por exemplo, pessoas desenvolvedoras em times ágeis evitam acu-
mular trabalho para ser validado depois. Assim que um trabalho de
desenvolvimento acaba, as pessoas desenvolvedores tentam colocá-
lo para validação. Mas, caso já tenha muita coisa na fila para
validação, ao invés de empilhar mais uma tarefa para validar, as
pessoas desenvolvedoras se oferecem para ajudar com a etapa de
validação. Dessa forma, o time (todos juntos) resolvem o gargalo
de validação, mantendo um sistema puxado saudável.
Ao trabalhar desta forma – time multifuncional e com sistema
puxado –, a etapa de validação puxa o próximo item ao invés das
pessoas desenvolvedoras empurrarem e empilharem trabalho.
Escopo funcional do MVP
O livro Lean Inception, além de compartilhar uma sequência de
atividades para ajudar um grupo de pessoas a alinhar sobre o
MVP, entra em detalhes sobre MVP – Minimum viable Product, em
Inglês –. Nele você encontra o histórico sobre MVP e as diversas
considerações sobre ele nas perspectivas do negócio, da tecnologia
e da experiência do usuário.
Conforme descrito no texto e no próprio título do capítulo anterior:
Conhecimento, relacionamento e comprometimento; esses são os
maiores benefícios da Lean Inception.
MVP, Design Thinking e Lean StartUp
O livro Lean Inception também apresenta o Canvas MVP, que

resume em um único canvas as perspectivas do design centrado no
usuário e do desenvolvimento baseado na validação de hipótese.
Você encontra mais detalhes sobre o Canvas MVP no livro Lean
Inception e no post www.caroli.org/o-canvas-mvp.
Escopo funcional do MVP 35
o canvas MVP
Os Sete blocos do Canvas MVP

O Canvas MVP é dividido em sete blocos. A seguir, as per-
guntas que devem ser respondidas em cada bloco, na ordem
indicada:
1. Proposta do MVP – Qual é a proposta deste MVP?

2. Personas segmentadas – Para quem é esse > MVP?
Podemos segmentar e testar este MVP em um grupo
menor?
3. Jornadas – Quais jornadas são atendidas ou melhoradas
com este MVP?
4. Funcionalidades – O que vamos construir neste MVP?
Que ações serão simplificadas ou melhoradas neste MVP?
5. Resultado esperado – Que aprendizado ou resultado
estamos buscando neste MVP?
6. Métricas para validar as hipóteses do negócio – Como
podemos medir os resultados deste MVP?
7. Custo & Cronograma – Qual é o custo e a data prevista
para a entrega deste MVP?
Antes de prosseguir com o objetivo e escopo deste livro (sinalizado

no título deste capítulo), preciso ser muito claro com os dois pontos
seguintes:
• Times e produtos de sucesso vão além do escopo funcional

do produto; esses dependem do foco nas pessoas, do conhec-
imento, relacionamento e comprometimento compartilhado
entre elas.
• Para elaborar e criar um MVP de sucesso você deve esclarecer
a proposta do MVP, as personas segmentadas, as jornadas, o
resultado esperado, as métricas para validar as hipóteses, o
custo e cronograma; além das funcionalidades a serem criadas
no MVP.
Mas, no contexto deste livro, para guiar a criação do MVP com

Scrum e Kanban, vou considerar somente o escopo funcional de
um MVP.
Jogo do treinamento Este livro possui um jogo que simula

um time trabalhando com Scrum e Kanban para construir um
produto incrementalmente, via MVP. Nesse jogo não é definido
o que é o MVP, tão pouco as funcionalidades e suas tarefas.
Somente é definido MVP1, MVP2, respectivamente para o
MVP e para o incremento seguinte, e F1, F2, F3 e assim sucessi-
vamente para as funcionalidades 1, 2, 3. No jogo e no livro, vou
considerar somente o agrupamento de funcionalidades, suas
prioridades, suas tarefas e o fluxo de trabalho.
Confira a página do jogo em http::/caroli.org/jogo-lean-product-
development
Como o MVP promove a evolução incremental de um produto, vou

utilizar o artefato da Lean Inception que demonstra exatamente
isso: o sequenciador das funcionalidades a serem elaboradas.
MVPs são pequenos

O MVP fatia uma iniciativa em pedaços bem pequenos. Isso ajuda
de duas formas: (1) reduz o risco de insistir em uma iniciativa que
não se provou, ou seja, parecia uma boa iniciativa, mas que não
gerou bons resultados, e (2) maximiza o fluxo de trabalho.
MVP e o Fluxo de trabalho

Trabalhar com MVP ajuda na rápida validação do produto e das
hipóteses de negócio. Mas também tem outro grande benefício:
MVP promove um fluxo de trabalho mais eficiente. Um MVP é uma
pequena fatia do produto. Ë como se fosse um pequeno batch size,
quando comparado com o produto completo – um batch size bem
grande.
Em quanto tempo você bebe uma garrafa d’água de 300 ml? E um
garrafão de água de 5 litros?
O tamanho da garrafa representa o batch size. Um MVP é um
batch size pequeno. E isso ajuda com a eficiência do fluxo de
trabalho. Agora, mudando de água par uísque, eu tenho um bar de
uísque. Quanto menor a garrafa de uísque, mais rápido ela termina.
No capítulo Diagrama de Fluxo Cumulativo voce vai ler mais
detalhes sobre parâmetros de fluxo de trabalho e como eles afetam a
percepção sobre as entregas. Vou compartilhar mais detalhes sobre
meu bar de uísque e como isso te ajuda a entender o fluxo de
trabalho.
Construindo MVP com
Scrum
Dado que muitas equipes utilizam Scrum, vamos compartilhar
como temos combinado Scrum com a criação de MVPs. Para tanto,
vamos realizar uma introdução básico sobre o Scrum, e, em seguida
demostrar como encaixar Scum com MVP, features e histórias.
Scrum
Scrum é um framework ágil para a conclusão de projetos com-
plexos. Scrum foi inicialmente formalizado para projetos de de-
senvolvimento de software, mas tem sido aplicado para qualquer
âmbito de projetos complexos, e trabalhos inovadores.
O Scrum é especialmente adequado para projetos com requisitos
que mudam rapidamente ou são altamente emergentes.
A Equipe Scrum
Scrum fomenta uma equipe multi-funcional e auto-organizada. A

eficiência do time depende da capacidade dos membros trabal-
harem em conjunto, e fazer o melhor uso das habilidades dos
indivíduos. O time Scrum é auto-organizado pois não deve existir
um líder de equipe que decide quem vai fazer qual tarefa e como.
Tarefas e problemas são levantados por todos, e essas são questões
decididas pela equipe como um todo. Os times Scrum são apoiados
por dois papéis específicos: o Scrum Master e o Produt Owner (PO).
Construindo MVP com Scrum 39
Scrum Master
Scrum Master é alguém experiente com o framework Scrum que

pode ajudar o time a usar o processo para alcançar seus objetivos
de alto nível. Os melhores Scrum Masters são aquelas pessoas que
sentem mais satisfação de facilitar o sucesso dos outros do que
seus próprios. O Scrum Master deve se sentir confortável e seguro
com o framework a ponto de dar todo controle em relação ao
produto para o Product Owner (PO), e todo controle em relação
ao desenvolvimento a sua equipe.
Product Owner
O Product Owner (PO) representa o negócio, os clientes ou usuários,

e orienta a equipe para a construção do produto certo. O PO deve
liderar o esforço de desenvolvimento, através de esclarecimentos e
priorizações sobre o trabalho.
Tipicamente, o PO trabalha com o Product Backlog, a lista mestre
dos requisitos do produto a ser criado. É sua função priorizar o
backlog com base no valor do negócio, e no alinhamento entre as
partes interessadas, tanto internas quanto externas a equipe Scrum.
Como tal, o PO deve estar disponível para a equipe para responder
a perguntas e direcionar o time a cada momento ou indagação.
Esta combinação de autoridade e disponibilidade para a equipe de
desenvolvimento faz com que o PO seja peça chave do framework.
Scrum valoriza a auto-organização e autonomia do time; portanto,
o PO deve respeitar o direcionamento e a capacidade da equipe para
criar o seu próprio plano de ação.
A Sprint
Sprint é uma iteração, um ciclo de trabalho repetitivo no qual o time

Scrum passa por todas as cerimônias do Scrum: planning, review e
retrospectiva. O tamanho da Sprint é fixo e definido pelo time (ou
pela organização) ao começar a implantar Scrum. Duas semanas é

o tamanho de Sprint mais adotado por times de desenvolvimento
de Software.
Cerimônias da Sprint
A equipe Scrum – o Scrum Master, o PO e todos membros do

time (com suas variadas formações) – participam ativamente de
todas reuniões com um alto nível de autonomia, transparência e
comprometimento.
Cerimônias da Sprint
Na Sprint planning, a equipe decide o Sprint backlog, o qual é

acompanhado diariamente (Daily Scrum) e reavaliado na Sprint
review. Através da busca de melhoria continua (salientado nas
retrospectivas), tipicamente o time Scrum performa em níveis el-
evados de rendimento. Muito disso é alcançado pelo entrosamento
do time, do alinhamento cadenciado via Sprints, e da clareza de
cada papel e reunião.
Daily Sprint
Reunião diária do Scrum, onde basicamente todos os membros

do time ficam de pé (para que a reunião não demore demais) e
respondem a três perguntas, as quais auxiliam o time a se auto-

organizar, buscando o alinhamento diário em relação ao trabalho
da Sprint. As três perguntas são: o que fiz ontem, o que vou fazer
hoje e o que está impedindo o progresso do meu trabalho.
Sprint Planning
Sprint Planning, ou reunião de planejamento do Scrum é uma

reunião de planejamento que acontece no início de cada Sprint. A
reunião de planejamento do Sprint é descrita em termos de metas
e resultado desejado. O resultado desejado é um compromisso com
um conjunto de funcionalidades a serem desenvolvidas no próximo
Sprint. Buscando assim o equilíbrio entre autonomia, flexibilidade
e comprometimento do time. Tal compromisso é revisitado ao final
da Sprint, na reunião de review.
Sprint Review
Reunião realizada ao final da Sprint com o objetivo de apresentar

o estado da arte do produto sendo criado, rever o progresso do
trabalho do time, e comparar com o planejamento apresentado na
Sprint planning.
Retrospectiva
A reunião de retrospectiva Scrum é um momento para a equipe re-

fletir sobre como estão trabalhando, e buscar maneiras de melhorar.
Tipicamente, o time Scrum realiza uma retrospectiva por Sprint.
Confira no site www.FunRetrospectives.com várias ideias e

atividades para deixar suas retrospectivas efetivas e divertidas.
O MVP nas cerimônias do Scrum

Antes da reunião de planejamento, as próximas funcionalidades
devem ter sido analisadas em detalhe e detalhadas em histórias do
usuário. Isso tipicamente acontece na reunião de refinamento.
Sugestão: Durante a reunião de refinamento, use o Product

Backlog Building para criar, de forma rápida e efetiva, as
histórias do usuário.
O planejamento da Sprint
Na reunião de planejamento da sprint, a equipe scrum vai decidir as

histórias a serem trabalhados na sprint, definindo o sprint backlog.
Para fazer tal decisão, a equipe deve consultar o canvas MVP.
Basicamente, a equipe deve selecionar as histórias relacionadas as
próximas funcionalidades do MVP em construção.
Durante o sprint a equipe vai trabalhar nas histórias do sprint
backlog.
Durante a Sprint
Na reunião de revisão do sprint, a equipe scrum irá rever o trabalho

realizado durante o sprint. Neste momento, a equipe deve revisar
e atualizar tanto as histórias do sprint backlog, quanto as suas
respectivas funcionalidades no canvas MVP.
Revisão da Sprint
Com o canvas MVP atualizado, a equipe pode (e deve) verificar

quanto falta para terminar o MVP . E, se necessário, a equipe de
agir (ACT) para ou (1) alcançar, ou (2) realinhar as expectativas
de entrega do MVP. Tipicamente, as reuniões de retrospectiva
geram action items para o próximo Sprint. Assim que todas as
funcionalidades do MVP estiverem completas, o mesmo deve ser
disponibilizado para os usuários finais.
Construindo MVP com
Kanban
Dado que muitas equipes utilizam Kanban, vamos compartilhar
como temos combinado Kanban com a criação de MVPs. Para
tanto vamos realizar uma introdução básico sobre o Kanban, e, em
seguida demonstrar como encaixar Kanban com MVP, features e
histórias.
Kanban
Kanban é um método formulada por David J. Anderson¹ para
gestão do fluxo de trabalho de um processo incremental e evolutivo.
Influenciado pelo modelo Toyota Just-In-Iime², o método se baseia
em visualizar o fluxo de trabalho e, a partir disso, atuar no processo
para não sobrecarregar os membros da equipe.
Através de uma abordagem de gestão visual perante a cadeia de
valor, o processo, desde sua etapa inicial até a entrega do trabalho,
é exposto aos membros da equipe. Tipicamente a cadeia de valor é
representada em quadros brancos com post-it ou ferramentas on-
line. Processo, itens de trabalho, bem como os trabalhadores estão
visualmente representados nesses quadros, comumente chamados
de kanban boards, ou kanban (isso mesmo, o método e o nome do
quadro se confundem). A partir do kanban, fica mais fácil para a
equipe decidir o que, por quem, quando, e quanto produzir.
No desenvolvimento de software, normalmente uma pequena tarefa
¹Kanban: Successful Evolutionary Change for Your Technology Business by David Ander-
son, Blue Hole Press Inc (2013)
²Ohno, Taiichi. (1988) Toyota Production System. Productivity Press
Construindo MVP com Kanban 45
leva de horas à dias para ser concluída. Além disso, você não
consegue visualizar quantos requisitos estão atualmente em análise;
ou quantos requisitos estão atualmente sendo codificados ou tes-
tados. O fato é que não conseguimos “ver” o item de trabalho
relacionado ao software, e como este se move ao longo das etapas
de do processo, até que esteja pronto. Aqui é onde tudo começa:
kanban torna tais itens em construções visíveis!
Visualize o workflow
A ideia principal do kanban é colocar o fluxo de trabalho na frente

de todos. Por exemplo em um quadro branco, ou na própria parede.
Abaixo está uma foto tirada de um kanban de uma equipe de
desenvolvimento de software.
Exemplo de kanban – o workflow visível
Cartões na parede. Simples assim. Cartões (ou post-it) na parede

mostrando o processo e o trabalho da equipe. Uma descrição rápida
do processo e trabalho deste time seria: um item de trabalho está
em etapa In Analysis, cinco itens estão na etapa de Ready For
Dev, três itens estão na etapa In Dev, um outro item está na etapa
Ready for BA, três itens estão na etapa Ready for QA, cinco itens
estão na etapa In QA, e oito itens estão em etapa de Ready for
SAT. Também parece que a equipe usa fotos para representar as
pessoas trabalhando nos itens. Os cartões têm um código de cores

(há três cores diferentes nos cartões na foto). Os cartões também
têm anotações escritas neles, um identificador numérico, e post-it
menores coloridos colados sobre eles.
Como a parede é uma superfície bidimensional, o kanban é apresen-
tado em um formato tabular, onde as etapas de trabalho são títulos
de colunas, e os items de trabalho, as fotos das pessoas, e outras
marcas relacionadas ao trabalho preenchem o espaço na parede.
Estes cartões podem ser organizados em uma linha horizontal ou
não. Tudo depende da equipe e como elas representam e organizam
o seu trabalho na parede.
Limite o WIP
Limitar o trabalho em andamento, ou WIP de work in progress

em Inglês, implica que o kanban segue um sistema puxado. O
trabalho em cada etapa do processo é limitado de forma que
um novo trabalho somente seja “puxado “ para a próxima etapa
quando há capacidade disponível dentro do limite WIP de tal etapa.
As restrições de WIP identificam gargalos e áreas problemáticas
no processo, auxiliando o time a tomar decisões para resolvê-
los. Limitar WIP é o grande diferencial do método Kanban. Tal
artimanha é o divisor de aguas entre task boards, ou quadros visuais
– como eram conhecidos antes da influencia de David Anderson
com a divulgação do método Kanban—e o quadros kanban.
ilustração de kanban com limites
Siga melhorando o fluxo de trabalho

Segundo David Anderson, o ponto principal de implantar um
kanban é criar uma mudança positiva. Antes de criar essa mudança
o time tem que saber o que mudar. O time precisa descobrir isso
olhando como itens de trabalho estão fluindo através do processo,
e analisando as áreas problemáticas em que o trabalho engargala.
Daí sim, realizar no mudanças no processo de trabalho para resolver
tais problemas.
E assim sucessivamente; identificando problemas, e agindo para
resolvê-los. Tudo isso baseado na visualização e limites WIP do
kanban. Melhorando o trabalho e o processo, na busca contínua
de maior eficiência.
O MVP no Kanban
O fluxo de trabalho do MVP é simples. Para cada MVP, temos
as features a serem trabalhadas, as features em construção e as
features prontas. Isso representa o seguinte fluxo, no nível de
funcionalidade: funcionalidade na fila -> funcionalidade em con-
strução -> funcionalidade pronta.
Uma vez que uma funcionalidade entra na etapa de funcionalidade
em construção, primeiro precisamos quebrar esta funcionalidade
em pedaços menores (histórias ou tarefas, dependendo do estilo da

equipe). Desta forma teremos um conjunto de itens de trabalho a
ser realizado para cada funcionalidade, e cada um desses itens passa
pelo seguinte fluxo: a fazer -> fazendo -> feito.
Visualizando o fluxo para MVP, features e

itens de trabalho
O fluxo de trabalho do MVP com suas features, e das features com

seus itens de trabalho é representado no kanban abaixo.
Kanban de Features do MVP
Note neste Kanban os dois níveis de trabalho: (1) features do MVP,

e (2) histórias (ou tarefas) de uma funcionalidade. Este kanban
demonstra o workflow de MVP e features, e o progresso de cada
funcionalidade perante o andamento das suas histórias (ou tarefas,
representados pela letra W na figura).
Sugiro manter o sequenciador de funcionalidade próximo ao kan-
ban de features do MVP. Desta forma, todos podem verificar onde
está cada MVP e cada funcionalidade. Se já estão em construção,
prontos, ou ainda esperam na fila.
O Sequenciador de Features, agora sem os cartões das features que foram para
o kanban
Segue uma sequência de imagens, demonstrando o Sequenciador

de features e o kanban, dia após dia.
Kanban no dia 1 – passo 1

Kanban no dia 2
Kanban no dia 3
Kanban no dia 4


Kanban no dia 6

Kanban no dia 8
Kanban no dia 9

Limite do WIP de Features
O Kanban apresentado tem um limite de três features no WIP.

Isso está explicitado pela quantidade de linhas neste kanban. Estas
imagens representam um kanban utilizado por um time cross-fun-
cional, com 8 pessoas com perfis e capacitações de desenvolvedor,
testador, ops e UX (User eXperience).
Não é intuito deste livro discutir como decidir o limite WIP de um
kanban, mas somente ilustrar como implementas um kanban para
o MVP e suas features.
MVP, Kanban e bugs
O time entregou o MVP, e segue trabalhando nas funcionalidades
do próximo incremento do produto. Mas agora começou a receber
feedback nas funcionalidades entregues: pequenos bugs e melho-
rias. Como lidar com esse feedback perante o que está planejado
como trabalho para o próximo incremento do produto?
Para isso, também sugiro kanban. Segue abaixo um kanban que
demonstra como um time pode lidar com tal situação.
Kanban com faixa para bugs
Note neste kanban que o time decidiu a capacidade alocada para

lidar com os bugs e para trabalhar no próximo incremento do
produto. Isso fica visível pelos limites de WIP das colunas Doing.
Note também que bugs e melhorias passam por uma etapa de pri-
orização antes de entrarem em Doing. Enquanto que as funcional-
idades do próximo incremento do produto (MVP2 na imagem)
seguem a ordem definida na Lean Inception.
MVP, Kanban e bugs 58
Capacidade para lidar com os bugs

O time deve decidir a capacidade alocada aos MVPs já em produção
perante aos próximos incrementos. Por exemplo 20 % / 80%. Esses
são os valores decididos no kanban exemplificado acima. Tal razão
é definida pelos limites WIPs (Work in Progress) identificados em
Doing.
Capacidade para lidar com os bugs
Ao decidir valores de WIP para bugs/feedback e WIP para as

features em construção, o time estará definindo a capacidade entre
pequenas alterações no que está pronto e na criação do que está por
vir.
MVP, Kanban e bugs 59
Exemplo de Kanban com planejamento de capacidade para buga
No exemplo apresentado, o time decidiu 20 % da sua capacidade

para bugs e feedback; ou seja uma de cinco tarefas em desenvolvi-
mento é relacionada a um bug ou feedback do produto já entregue.
Enquanto que quatro de cinco tarefas em desenvolvimento — 80%
da capacidade — é para o próximo incremento do produto, as novas
features.
Radar de Débito Técnico
Voce usa cartão de crédito? Sabe o que acontece quando não paga
toda a fatura no fim do mes?
Debito técnico funciona da mesma forma. As vezes o squad precisa
deixar algum debito para ser “pago”depois. Isso faz parte do dia-a-
dia ca criação do MVP. O foco é em validar logo seu MVP, por isso
algumas coisas vão ficar para depois. Não faz sentido ter o código
maravilhoso, para algo que talvez seja descartado. Usar o “cartão de
crédito” e comum para qualquer projeto de criação de um produto
digital, para um MVP, ainda mais.
Mas, ao mesmo tempo, se acumular débito demais, a conta (com
juros do cartão) fica muito cara. Por voce precisa fazer a gestão do
seu débito técnico.
Meu colega Glauco Vinicius, enquanto trabalhava em um projeto
que começou com uma Lean Inception, criou e utilizou algo que ele
chamou de radar de debito técnico.
Radar de Débito Técnico 61
Radar de Débito Técnico
Glauco Vinicius implementa o “radar de débitos técnicos“ (imagem

anterior) de forma simples e efetiva. Segue abaixo a explicação do
radar:
• Existem dois eixos: valor entregue para o negócio* (y) e

esforço (x).
• Tudo o que entrega pouco valor de negócio e requer muito
esforço, é despriorizado (não quer dizer que não será feito!)
• Tudo o que entrega muito valor de negócio e requer pouco
esforço é priorizado
• Tudo o que entrega pouco valor de negócio e requer pouco
esforço deve ser avaliado com mais cuidado
• Tudo o que entrega muito valor de negócio e requer muito
esforço deve ser avaliado com mais cuidado
Segundo Glauco, o radar deve ficar visível e acessível para que os

Radar de Débito Técnico 62
integrantes do time adicionem os débitos técnicos á medida em que

desenvolvem as histórias de usuário do MVP.
Após a entrega do MVP, o time deve planejar o incremento seguinte
(alguns times chama de incremento, outros de MVP). O resultado
desse planejamento é um canvas MVP. Ao decidir o que construir
nesse canvas MVP, o squad decide (1) as funcionalidades a acres-
centar e (2) quanto da dívida acumulada devem ser “pagas” com o
próximo incremento do produto.
Para (2), os post-its saem do radar da dívida técnica e viram tra-
balho: funcionalidades a serem entregues no próximo incremento
do produto. E o squad segue trabalhando desta forma: ao planejar o
próximo MVP decidem o que vão comprar de novo (novas features)
e decidem quanto pagar de débito técnico. Enquanto trabalham no
MVP, decidem, diariamente, quanto vão deixar acumular para a
próxima fatura do cartão (próximo MVP).
Eu já tinha visto alguns estilos de radar de débito técnico. Mas esse
é diferente dos outros. O Glauco utilizou as mesmas cores propostas
para as features da Lean Inception. Desta forma fica mais fácil
de se conversar sobre o que ficou para depois: verde, amarelo ou
vermelho, respectivamente: mais tranquilo, médio, e mais esforço
para pouco valor.
Acompanhamento Lean
Qual o status atual do seu MVP em construção? Você precisa
responder essa pergunta de forma clara e direta. Você precisa
informar os membros da equipe e as partes interessadas no MVP.
Projetos mais tradicionais usam relatórios e ferramentas de sta-
tus do projeto, mais tradicionais. Como este livro apresenta uma
solução para projetos mais ágeis e lean, apresento neste capítulo
um acompanhamento via um ferramental mais Lean.
O entendimento da iniciativa via

MVP
O workshop Lean Inception³ gerou o sequenciador de features, no
qual está mapeado o que o time estará construindo para a entrega
dos incrementos do produto enxuto, baseado nos MVPs.
³CAROLI, Paulo. Lean Inception: How to Align People and Build the Right Product, Editora
Caroli, 2017.
Acompanhamento Lean 64
exemplo de evolução de produto de forma enxuta
O planejamento do produto e seus

MVPs
Para cada MVP identificado no sequenciador de funcionalidade é
criado um canvas MVP, o qual responde claramente as indagações
de dois aspectos fundamentais sobre produto e MVP: (1) o que são
as funcionalidades, as personas, as jornadas, a proposta, o custo
e cronograma de entrega do MVP, e (2) que resultado é esperado
quando esse for entregue, e como validaremos tal resultado e
aprendizado.
o canvas MVP
O Canvas MVP é dividido em sete blocos:
1. Proposta do MVP – Qual é a proposta deste MVP?

2. Personas segmentadas – Para quem é esse MVP? Podemos
segmentar e testar este MVP em um grupo menor?
3. Jornadas – Quais jornadas são atendidas ou melhoradas com
este MVP?
4. Funcionalidades – O que vamos construir neste MVP? Que
ações serão simplificadas ou melhoradas neste MVP?
5. Resultado esperado – Que aprendizado ou resultado estamos
buscando neste MVP?
6. Métricas para validar as hipóteses do negócio – Como pode-
mos medir os resultados deste MVP?
7. Custo & Cronograma – Qual é o custo e a data prevista para
a entrega deste MVP?
O planejamento baseado em MVPs difere de planejamento tradi-

cional de produtos por aceitar que a entrega somente sinaliza o
momento em que dados de aprendizado começarão a ser coletados.
Exemplo de Canvas MVP – o MVP do EasyBola
Com uma visão mais tradicional, o acompanhamento verifica o

quão próximo estamos de completar a construção das funcional-
idades de tal MVP. Enquanto, com uma visão mais moderna,
o acompanhamento é baseado no aprendizado, na validação de
hipóteses do negócio, em um estilo mais arrojado, digno das start-
ups do Vale do Silício.
Misturando construção com adaptação, convergência com divergên-
cia, controle com experimentação, o planejamento baseado no
Canvas MVP auxilia a criação de produtos enxutos equilibrando
inovação e entrega.
O acompanhamento da criação do
produto via MVP
Devemos fazer o acompanhamento periódico (por exemplo sem-
anal, ou a cada Sprint – para das equipes usando Scrum) em relação
a criação do produto. Tal acompanhamento deve ser realizado

comparando o estado atual com o que estava planejado no canvas
MVP. Para tanto artefatos devem ser apresentados:
1. Status report do MVP

2. Burn up do MVP em construção
3. O Diagrama de Fluxo Cumulativo
Status report do MVP
modelo de status report do MVP
Uma lista pequena com poucas e visíveis informações. Assim deve

ser um status report efetivo. Por se tratar de features de um MVP,
tal status report não somente é possível, como indicado!
Um status report simples auxilia no entendimento comum sobre
o andamento da criação do MVP. Informações simples e diretas:
Qual nome e o que compõe este MVP? Qual data prevista? Quantas
features já terminaram?
Burn up do MVP em construção
o burn-up de MVP
O Burn-up de funcionalidades do MVP ajuda com o gerenciamento

de tempo e escopo de um MVP. Ter o gráfico burn-up visível para
todos constrói a confiança na gestão do tempo e no progresso das
funcionalidades do MVP.
Ao final do planejamento, o gráfico burn-up demonstra a visão
compartilhada do que deve ser alcançado. E isto fica claramente
visível traçando uma linha horizontal de escopo e uma linha
vertical de data de entrega do MVP. A interseção dessas linhas
representa o resultado no tempo esperado.
O gráfico é atualizado conforme as funcionalidades são construídas:
a data atual, e o total de funcionalidades completas são alterados.
Desta forma permite-se identificar possíveis desvios na duração
esperada para a construção do MVP.
Diagrama de Fluxo Cumulativo
o Diagrama de Fluxo Cumulativo
O Diagrama de Fluxo Cumulativo (CFD – Cumulative Flow Dia-

gram, em Inglês) fornece uma representação gráfica do andamento
do trabalho, esclarecendo gargalos, e alertando sobre possíveis
instabilidades do sistema. É uma ferramenta simples, porém muito
informativa, que descreve o trabalho em andamento (WIP – Work
in Progress, em inglês), taxa de entrada, taxa de saída, tempo de
atravessamento , taxa de transferência, tempo decorrido, trabalho
completo, trabalho restante e escopo total do trabalho.
O Diagrama de Fluxo Cumulativo é uma valiosa ferramenta de
gerenciamento para rastrear e prever a realização de todas as fun-
cionalidades planejadas. Ele apresenta uma visão mais abrangente
que o burn-up e o status report do MVP, complementando-os com
a visão de fluxo contínuo.
Após entregar o MVP, muito provavelmente, a equipe continua as
criar os incrementos do produto. O burn-up e o status repost do
MVP podem ter chegado ao fim, mas o CFD não. Nele a equipe
mantém o foco no fluxo de trabalho, antes, durante e depois da
entrega do MVP e os incrementos do produto.
Status report do MVP
Segue um modelo de status report para acompanhamento e moni-
toramento da criação das features do MVP.
modelo de status report de MVP
Neste modelo você pode verificar as seguintes partes, listadas na

figura abaixo.;
modelo de status report de MVP – todos itens

Status report do MVP 71
Nome do time e ID do MVP

O nome do time a identificador do MVP.
Nome do MVP
O nome do MVP é utilizado dentre várias conversas, desde a sua
concepção, passando pela criação, até a entrega, coleta de feedbacks
e validações de hipóteses. Ter um nome claro e específico é essencial
para evitar quaisquer confusão sobre o MVP em questão.
Estado atual
Qual situação atual deste MVP? Tudo ok para o término das features
do MVP na data prevista? Sim (verde), médio (amarelo), ou não
(vermelho).
Data atual e data prevista

Os relatórios de status report de MVP são úteis para o acompan-
hamento e decisões atuais, bem como para o histórico da criação
do produto como um todo. Além disso a demonstração de ambas
as datas (atual e prevista) deixa claro o tempo remanescente para
alcançar a entrega na data planejada.
Lista de features do MVP

Uma tabela contendo a lista de features prevista para o MVP, com
as seguintes informações para cada funcionalidade: descrição, nível
de incerteza, estado, e % de completude.
Nível de incerteza da funcionalidade

Descrição e nível de incerteza da funcionalidade são dados prove-
nientes desde a concepção dos MVPs. O nível de incerteza da
funcionalidade refere-se ao grau em que a funcionalidade é incerta,
a partir do ponto de vista do entendimento de negócio e do
entendimento técnico. Isso é indicado pela cor os quais são verde,
amarelo ou rosa, indicando níveis baixo, médio ou alto de incerteza,
respectivamente.
O nível de incerteza da funcionalidade não é alterado. Tal infor-
mação serve para relembrar a todos o entendimento original sobre
tal funcionalidade. Todos e quaisquer riscos ou ações relacionadas
ao MVP devem ser listadas nos campos de detalhamento e texto
descritivo do status report (item 8 abaixo).
Estado e % de completude da
funcionalidade
O estado e % de completude da funcionalidade representam o
estado atual da funcionalidade em relação a sua completude. Esses
parâmetros devem ser alterados nos relatórios, refletindo o estado
atual de cada funcionalidade.
O estado varia entre: não começou -> em construção -> pronto.
O % de completude varia entre 0 e 100%. É comum que times deci-
dam valores arredondados e pré-definidos como 0%, 25%, 50% 75%
e 100%. Alguns times utilizam fórmulas para calcular tais valores,
enquanto outros decidem tais valores com menos matemática. O
importante é que o racional do valor demonstrado seja o mesmo
entre diferentes features.
Detalhamento e texto descritivo

Todas e quaisquer anotações relevantes sobre o MVP e suas fun-
cionalidade que não foram claramente demonstradas nos itens
anteriores. Por exemplo: dependências externas, riscos, problemas,
e ações realizadas.
Burn-up de Features do
MVP
O Burn-up de Features do MVP ajuda com o gerenciamento de
tempo e escopo de um MVP. Ter o gráfico burn-up visível para
todos constrói a confiança na gestão do tempo e no progresso das
features do MVP. É uma ferramenta essencial para dar visibilidade
ao planejamento e para realizar o acompanhamento da construção
das features do MVP.
A sequência de imagens mostra um exemplo de burn-up em mo-
mentos diferentes. Começando no dia 30/06, quando o burn-up foi
criado com o planejamento de acordo com o ritmo esperado de
construção das features. Seguindo com instantâneos do burn-up
nos dias 08/07, 18/07 e 28/07, quando todas as features do MVP
terminaram, e o mesmo foi entregue.
burn-up de features do MVP no dia 30/06

Burn-up de Features do MVP 75

Os eixos do burn up
O eixo vertical é a quantidade de features para o MVP, e é medido
em unidades, por exemplo 9 features. O eixo horizontal representa
o tempo, normalmente medido em dias ou semanas.
exemplo de burn-up de MVP iniciado em 30/06 e planejado para 30/07
O ritmo da construção do MVP

A vantagem da gráfico burn-up é a visão compartilhada do que deve
ser alcançado. E isto fica claramente visível traçando uma linha
horizontal de escopo e uma linha vertical de data de entrega do
MVP. A intersecção dessas linhas representa o resultado no tempo
esperado.
Ao desenhar uma linha diagonal a partir do ponto de partida (o
início do tempo para a construção da primeira funcionalidade do
MVP) para o resultado no tempo esperado, você tem uma indicação
do ritmo linear de construção do MVP. Na figura abaixo, este
ritmo está representado como a linha diagonal , representando um
planejamento de ritmo linear.
exemplo de burn-up com ritmo linear
Entretanto o ritmo de término de features de um MVP não é linear.

A figura abaixo demonstra uma curva que melhor representa o
ritmo de entrega esperado.
exemplo de burn-up com ritmo não linear
Equipes ágeis experientes lidam com tal curva de duas formas: (1)
Iteração ou Sprint 0, ou (2) entendimento do tempo de atravessa-
mento inicial.
Iteração ou Sprint 0 é um termo comum utilizado para ressaltar
que não haverá entrega de funcionalidade numa primeira iteração
ou Sprint. O gráfico abaixo demonstra como tal artimanha (Sprint
0) alinha a expectativa de entrega de funcionalidade com o ritmo
inicial ainda por começar.
exemplo de burn-up com Sprint 0
A construção de uma funcionalidade tem um tempo mínimo de

atravessamento (ou lead time, em inglês). Por exemplo, o mínimo
que se leva para criar uma funcionalidade são 5 dias. Por tal
motivo é impossível ter o término de qualquer funcionalidade nos
primeiros cinco dias. Esse fato explica a barriga da curva do ritmo
esperado. Após a entrega das primeiras funcionalidades, o ritmo de
entrega vai ser estabelecido, e a curva tende a virar uma reta na
qual o ritmo de entrega fica estabelecido.
Verificando o progresso
De tempos em tempos você deve verificar a quantidade de features
já construídas e a quantidade total de features planejadas para o
MVP. A distância entre as linhas horizontais marcando as features
atualmente prontas e a última funcionalidade a ser construída é a
indicação da quantidade de features restantes.
features construídas e restantes
Quando as duas linhas se encontram, todas features do MVP estarão

completas. A distância entre essas linhas é uma medida poderosa
de quão perto você está de completar o MVP.
verificando progresso
Verificar regularmente o progresso é uma parte importante da

gestão da construção do MVP. Há duas atualizações básicos para
o burn-up de features do MVP: (1) o tempo mudou; a seta que
representa a data atual deve ser movido para a direita até a posição
que representa a data atual, e a linha da data atual deve ser ajustada;
e (2) terminou a construção de uma funcionalidade; o total de
features completas deve ser alterado, e a linha de total de features
completas deve ser ajustada.
atualizações no burn-up: data atual e funcionalidade construída
Este mecanismo de atualizações do total de features construídas e

da data atual permite identificar de imediato, um desvio na duração
esperada para a construção do MVP. Assim que constatado, este
problema deve ser discutido e ações corretivas devem ser tomadas
ainda em um estágio inicial, e não quando é tarde demais.
A linha de escopo do MVP

Uma informação importante do gráfico burn-up é a linha de escopo
do MVP, a linha horizontal contabilizando o total de features plane-
jadas para o MVP. Essa linha define claramente se e quando novas
features foram adicionados ou removidos durante a construção
do MVP. Ela também permite que você visualize a intersecção
desta linha horizontal para a linha vertical, que representa a data
planejada para a entrega do MVP.
Todas partes a serem construídas para um MVP devem ser features.
Se novas features surgem, elas devem ser adicionados à lista de
features e a linha de escopo deve ser ajustada. Dessa forma, a
nova linha permite identificar facilmente quando features estão
sendo adicionadas, o que poderá afetar o tempo de conclusão do
MVP. O ato de adicionar uma nova funcionalidade é um sinal
importante de que o tempo restante para a construção do MVP deve
ser repensado. A linha de escopo também rastreia onde features

estão sendo removidos para cumprir um prazo fixo. Este cenário
é ilustrado na figura abaixo. Novamente, é importante entender
como a remoção de uma funcionalidade do MVP vai afetar as outras
features, e é algo que precisa e deve ser claramente discutido com
todos.
exemplo de burn-up de MVP após redução de duas features

Diagrama de Fluxo
Cumulativo
O Diagrama de Fluxo Cumulativo é uma ferramenta valiosa de
gerenciamento para: 1) rastrear e prever a realização de itens do
trabalho; e 2) indicar a necessidade de agir sobre o fluxo e o processo
de melhoria.
O Diagrama de Fluxo Cumulativo (ou em Inglês Cumulative Flow
Diagram, e por isso abreviado para CFD) fornece uma represen-
tação gráfica do andamento do trabalho no sistema, esclarecendo
gargalos, e alertando sobre possíveis instabilidades do sistema. É
uma ferramenta simples, porém muito informativa, que descreve
o trabalho em andamento (WIP – Work in Progress, em inglês),
taxa de entrada, taxa de saída, tempo de atravessamento , taxa
de transferência, tempo decorrido, trabalho completo, trabalho
restante e escopo total do trabalho.
Abaixo, uma sequência que mostra CFDs nas primeiras nove sem-
anas de um projeto.
CFD na semana 2
Diagrama de Fluxo Cumulativo 83
CFD na semana 5
CFD na semana 7
CFD na semana 10
Interpretando o CFD
Abaixo, está um CFD com muitos de seus parâmetros. Cada um
deles será explicado em detalhes nas próximas seções.
parâmetros de fluxo em um Diagrama de Fluxo Cumulativo
Antes de tudo, você deve entender como o CFD é construído.

O CFD apresentado é construído baseado em uma tabela que
é atualizada semanalmente. Abaixo, está a tabela com seu CFD
correspondente.
modelo em Excel do CFD
Essa tabela descreve o fluxo de trabalho do sistema como: escopo

->WIP -> pronto; ou, em outras palavras, a fazer -> fazendo -> feito.
Muitas ferramentas constroem o CFD automaticamente para você,
poupando o trabalho manual para a criação do mesmo. Entretanto,
para o seu aprendizado, eu recomendo que você construa um CFD
simulando o que acontece em um projeto real. O CFD apresentado
neste artigo foi gerado pelo Excel. Você pode fazer o download deste
modelo em http://www.caroli.org/cumulative-flow-diagram/.
Itens de trabalho
O número em cada célula da tabela apresentada representa a
quantidade de itens de trabalho naquela etapa para tal semana.
É importante esclarecer que o item de trabalho é uma unidade
que faz sentido para quem vai ler o CFD. Exemplos comuns
de itens de trabalho na área de desenvolvimento de software
são: funcionalidades, ponto de função, histórias, ponto de
histórias, bugs, tarefas. Outra consideração essencial é que não

se misture diferentes itens de trabalho em um mesmo CFD.
Ou seja, um CFD de funcionalidades deve conter somente
funcionalidades, enquanto que um CFD de pontos de histórias
deve conter somente pontos de histórias.
A fazer / Fazendo / Feito

Apesar de os CFDs poderem e serem comumente usados para fluxos
de trabalho com muitas fases, eu recomendo começar com um sim-
ples fluxo a fazer -> fazendo -> feito para entender completamente
o CFD. Depois, quando você já tiver dominado o CFD e sentir a
necessidade de mais dados, considere dividir a fase “fazendo” em
um fluxo de trabalho mais detalhado.
A quantidade de trabalho em relação aos itens a fazer / fazendo /
feito é descrita no CFD na imagem abaixo.
A fazer / fazendo / feito no CFD

Quando estará pronto?

Quando todo o trabalho estará pronto? Esta é a pergunta mágica
que todo mundo tenta responder. Ao usar o CFD, há duas maneiras
simples de responder a essa questão: 1) graficamente; ou 2) matem-
aticamente.
taxa de conclusão
Neste momento específico (representado pela seta azul na semana

6), você sabe a quantidade de trabalho que está pronta, e você sabe o
tempo decorrido. Com esses dois parâmetros, você pode desenhar
a linha da taxa de conclusão (a seta amarela na próxima figura).
Você tem que responder a questão estendendo a linha da taxa de
conclusão até que ela alcance o total da linha do escopo de trabalho.
Apesar de você poder fazer isso graficamente, eu prefiro fazer
matematicamente, utilizando a regra de três.
A regra de três:
“A regra de três, na matemática, é uma forma de se descobrir
uma quantidade que tenha para outra conhecida a mesma
relação que têm entre si entre outros dois valores numéricos

conhecidos.” (Wikipédia)
regra de três
Mudança no escopo
A linha do escopo é a linha horizontal que computa o total de
itens de trabalho. Essa linha é claramente definida e deve mudar
apenas quando os itens de trabalho são adicionados ou removidos
do escopo de trabalho.
O escopo total do CFD deve computar todos os itens de trabalho
do sistema, sejam eles já feitos, em andamento, ou a fazer. Se um
novo item de trabalho surge, ele deve ser adicionado no escopo de
trabalho total e a linha de trabalho total deve ser ajustada. Dessa
forma, a nova linha torna fácil identificar quando um trabalho está
sendo adicionado. A linha de escopo também monitora quando
itens de trabalho estão sendo removidos. Este cenário é ilustrado
na figura abaixo.
o escopo foi reduzido
Trabalho em Andamento (WIP)

O trabalho em andamento (WIP – Work in Progress, em inglês),
é o número de itens de trabalho atualmente em andamento. Por
exemplo, o cenário da figura abaixo tem um Kanban com WIP de
um: três itens de trabalho estão na fase “a fazer”, um está sendo
trabalhado (WIP), e quatro itens já estão feitos.
modelo kanban: a fazer / fazendo / feito
No CFD, o WIP em um momento é a altura da linha vertical para a

área WIP em um dado momento. A figura abaixo representa o WIP
na semana 5.
WIP no CFD
Tempo de atravessamento (Lead

Time)
O tempo de atravessamento (Lead Time, em inglês) é o tempo entre
o item de trabalho ser adicionado no sistema (fase “fazendo”) e
ele sair do sistema (trabalho completado; a fase “feito”). Para o
Kanban a fazer / fazendo / feito apresentado anteriormente, o tempo
de atravessamento é o tempo que leva para completar o item de
trabalho (e apenas este dado que o WIP é um) na fase “fazendo”.
Como acontece frequentemente, mais de um item estará em anda-
mento na fase “fazendo”. Por esta razão, normalmente a questão a
ser respondida é: em média, quanto tempo leva para concluir um
item de trabalho?
A resposta para essa pergunta é descrita no CFD. A imagem
abaixo mostra uma linha horizontal representando o tempo de
atravessamento: quanto tempo leva para um item de trabalho
passar pelo sistema? Ou, fazendo a mesma pergunta com outras
palavras: quanto tempo leva para um item de trabalho ir da fase
“fazendo” para a fase “feito” (da área azul para a área verde no
CFD)?
tempo de atravessamento no CFD
Taxa de transferência (Throughput)

A taxa de transferência –Throughput em Inglês– é a vazão (quan-
tidade por tempo) dos itens de trabalho passando no sistema.
No CFD, a taxa de transferência é descrita pelo ângulo da linha
dos itens de trabalho concluídos (a linha entre as áreas verde
e vermelha). Abaixo, duas imagens com duas marcas no CFD,
comparando dois momentos distintos; o segundo tem uma taxa de
transferência bem mais baixa.
taxa de transferência no CFD no momento 1

taxa de transferência no CFD no momento 2
Lei de Little
Lei de Little: O número médio de itens de trabalho em
um sistema estável é igual à sua taxa de conclusão,
multiplicado pelo tempo médio no sistema. ∼ John Little,
1961
O texto acima é de A proof for the Queuing Formula, de John Little

(1961). É conhecido como a Lei de Little.
John Little estudou e provou a relação entre o WIP e o tempo de
atravessamento . Como se vê, é uma simples equação de primeiro
grau. E ao resolver essa equação você é capaz de encontrar o tempo
médio para os itens de trabalho em seu sistema.
Meu bar de whisky mostra um bom exemplo de sistema estável para
ilustrar como você pode aplicar a Lei de Little para entender e mon-
itorar o WIP, a taxa de transferência e o tempo de atravessamento
.
bar de whisky
Eu e minha esposa temos um acordo. O lado direito do bar é meu,

e o lado esquerdo é dela. Eu só bebo whisky. No meu lado do bar,
cabem 12 garrafas de whisky.
Sempre que uma garrafa acaba, eu a removo do bar. Então abro uma
nova, e a adiciono ao bar. Meu bar é um sistema estável: a taxa de
entrada das garrafas é igual a taxa de saída delas.
O número de garrafas de whisky no meu bar é constante: 12
garrafas. Por ano, eu termino, em média, 6 garrafas de whisky.
Então, qual é o tempo médio que uma garrafa de whisky permanece
no meu bar?
Vamos para as contas

WIP = T x L, ou seja, o número médio de itens de trabalho em um
sistema estável (WIP) é igual à taxa média de conclusão (T) x tempo
médio no sistema (L)

Usando os termos do bar de whisky: 12 garrafas (WIP, ou número
de garrafas de whisky no bar) = 6 garrafas/ano (Taxa de transfer-
ência, ou taxa média de conclusão) x Tempo de atravessamento,
ou tempo médio de permanência no bar.
12 garrafas = 6 garrafas/ano x Tempo de atravessamento.
Dessa forma, temos que o tempo médio que uma garrafa fica no bar
é de 2 anos.
É contraintuitivo! Você viu a fórmula e teve a resposta, mas você
tinha em mente 2 meses. Dois meses, e não dois anos!
Essa é uma confusão comum. Quando você lê que uma média de
6 garrafas são terminadas por ano, você deve ter feito um simples
cálculo: 6 garrafas por ano é igual a uma garrafa a cada dois meses.
E seria 2 meses para uma dada garrafa, se no bar coubesse apenas
uma garrafa.
Pense. O consumo de whisky não é apenas de uma garrafa. Todas
estão abertas e sendo consumidas. Se apenas um copo é servido,
uma garrafa tem seu conteúdo diminuído, enquanto as outras 11
não se movem. E o bar tem 12 garrafas abertas.
Então, como funciona isso?

Ter menos garrafas no bar significa que cada garrafa terminará mais
rápido. Como descrito, por ano, 6 garrafas são esvaziadas. Mas o
bar comporta 12 garrafas. Isso certamente afeta o tempo médio de
espera.
Por um momento, esqueça da Lei de Little. Vou contar outro
episódio. Whisky é bom para o coração. Por esta razão, eu bebo uma
pequena quantidade todo dia. Para essa comparação, considere que
o meu hábito de beber é bem constante.
No último verão, eu fui para uma casa de praia, onde passei
dois meses. Eu levei algumas roupas, meu laptop (para trabalhar
remotamente e escrever sobre este tópico) e uma garrafa de whisky.

Como o carro estava cheio, eu não ia levar todo o bar. Eu escolhi
uma garrafa lacrada e a levei comigo.
Na mosca! Aquela garrafa estava vazia em exatos 2 meses. Então, o
que aconteceu?
É simples, e John Little provou isso muito bem. O WIP, ou trabalho
em andamento, na casa de praia era 1; apenas uma garrafa. A taxa
de transferência era a mesma: 6 garrafas por ano. Mais uma vez, em
uma conta simples:
WIP = T x L, ou, em outras palavras, número médio de itens de
trabalho em um sistema estável (WIP) é igual à taxa média de
conclusão (T) x tempo médio no sistema (L)
Usando os números do bar da casa de praia: 1 garrafa (WIP, ou
número de garrafas no bar) = 6 garrafas/ano (Taxa de transferência,
ou taxa média de conclusão) x Tempo de atravessamento, ou
tempo médio no bar.
1 garrafa = 6 garrafas/ano x Tempo de atravessamento
Dessa forma, o tempo médio que uma garrafa fica no bar é de 2
meses (1/6 de um ano).
WIP = T x L; o tempo de atravessamento médio é diretamente
proporcional ao WIP, e esta relação é a taxa de transferência.
Como provado no exemplo do bar de whisky, menos WIP significa
entrega mais rápida de itens de trabalho (garrafas de whisky).
Menos significa mais rápido!
Ok, eu tenho certeza que você já está cansado de matemática nesse
momento. O CFD mostra a mesma coisa. A próxima figura mostra
o CFD tanto com a representação do WIP como com a do tempo de
atravessamento em dois diferentes momentos. Nela, você vai ver a
questão principal da Lei de Little: WIP menor representa tempo de
atravessamento mais curto.
Lei de Little no CFD
Note que o CFD apresentado foi tirado de um projeto real, provando

o ponto: uma vez que o WIP foi reduzido, o tempo de atravessa-
mento médio também o foi.
Tempo de Ciclo (Cycle Time)

O Tempo de Ciclo – Cycle Time em inglês – é a frequência
(intervalo de tempo) de término de item de trabalho. No exemplo do
meu bar de uísque, considere que a cada dois meses eu termino uma
garrafa de uísque. Nesse caso, o Tempo de Ciclo é de dois meses por
garrafa.
Tempo de Ciclo e Taxa de Transferência
No CFD, a Tempo de Ciclo, similar a Taxa de Transferência, é

descrito pelo ângulo da linha dos itens de trabalho concluídos (a
linha entre as áreas verde e vermelha). Abaixo, as mesmas duas
imagens utilizadas no capítulo Taxa de Transferência, comparando
dois momentos distintos; o segundo com tempo de ciclo maior.
<colocar lado a lado imagens similares ao cap Taxa de transferên-
cia>
Tipicamente a Taxa de Transferência é descrita em termos de uma

unidade de tempo (no exemplo do meu bar de uísque, em um ano).
Enquanto o Tempo de ciclo é descrito em termos de uma unidade de
item de trabalho (no exemplo do meu bar de uísque, uma garrafa).
O Tempo de Ciclo e a Taxa de Transferência são parâmetros de fluxo
recíprocos, equivalentes e inversos.
Novamente, eu vou utilizar o meu bar de uísque e a Lei de Little
para demonstrar, matematicamente, esta afirmação.
No capítulo anterior eu apresentei a fórmula da Lei de Little em
termos de WIP, Taxa de Transferência e Tempo de Atravessamento,
como segue:
WIP = Taxa de Transferência x Tempo de Atravessamento
Abaixo está uma fórmula da Lei de Little com o parêmetro Tempo
de Ciclo, ao invés de Taxa de Transferência:
WIP x Tempo de Ciclo = Tempo de Atravessamento
Ambas as fórmulas têm os parâmetros WIP e Tempo de Atraves-
samento. A diferença, na segunda, o parâmetro Tempo de Ciclo
em vez da Taxa de Transferência, posicionado no lado oposto
da equação, demonstrando que o Tempo de Ciclo e a Taxa de
Transferência são recíprocos.
De volta ao exemplo do bar de uísque. Vamos considerar um cenário
mais simples: um bar com apenas uma garrafa de uísque (WIP
= 1). Eu termino uma garrafa de uísque em 2 meses (Tempo de
Atravessamento = 2 meses).
Calculando a Taxa de Transferência:
WIP = Taxa de Transferência x Tempo de Atravessa-

mento
Taxa de Transferência = WIP / Tempo de Atravessa-
mento
Taxa de Transferência = 1 garrafa / 2 meses
A Taxa de Transferência é uma garrafa em dois

meses.
Calculando o Tempo de Ciclo:
WIP x Tempo de Ciclo = Tempo de Atravessamento

Tempo de Ciclo = Tempo de Atravessamento / WIP
Tempo de Ciclo = 2 meses / 1 garrafa
O Tempo de Ciclo é de dois meses por garrafa.
Logo, com os mesmos valores dos parâmetros WIP e Tempo de

Atravessamento, temos os seguintes resultados:
O Tempo de Ciclo é de dois meses por garrafa. A

Taxa de Transferência é uma garrafa em dois meses.
Esses resultados são equivalentes, ou seja:
dois meses por garrafa <⇒ uma garrafa em dois meses
Tempo de Ciclo = 1 / Taxa de Transferência
O resultado obtido também demonstra que a medida de Taxa de

Transferência é o inverso da medida do Tempo de Ciclo. A medida
de Taxa de Transferência é itens de trabalho por período de tempo,
enquanto que a medida de Tempo de Ciclo é intervalo de tempo por
item de trabalho.
Estabilizando o sistema
Sempre que uma garrafa termina, ela é removida do bar.
Então, uma nova é aberta e colocada no bar.
Esta frase descreve como as garrafas de whisky são removidas e

adicionadas ao bar. Nela, encontramos dois conceitos de sistema
importantes: Sistema Puxado e Sistema Estável.
Sistema Puxado
O Sistema Puxado descreve o movimento de itens de trabalho
guiados pela demanda. No exemplo do bar, uma garrafa terminada
abre uma vaga no bar. Assim, cria uma demanda para uma nova
garrafa ser aberta e colocada no bar. Essencialmente, o movimento
dos itens de trabalho (garrafas de whisky) é guiado pela demanda
vigente: uma garrafa é removida do bar, abrindo espaço para uma
nova que será prontamente adicionada ao bar, ocupando o espaço
vazio.
Sistema Puxado
A manufatura lean descreve o Sistema Puxado em relação a um

produto, que é puxado pelo sistema em vez de empurrado por ele.
Um exemplo de um Sistema Empurrado seria adicionar garrafas ao
bar sem que nenhuma garrafa tenho sido removida dele. Basica-
mente, novas garrafas seriam adicionadas sem qualquer demanda
(espaço no bar) ser criada.
Sistema Empurrado
Nos anos 80, a Ford Motors e a Toyota eram grandes exemplos

de sistemas empurrados e sistemas puxados, respectivamente.
Seguindo um sistema empurrado, a Ford produzia grandes
quantidades de carros que ficavam nos pátios das fábricas e
lojas esperando pelos clientes. Por outro lado, seguindo um
Sistema Puxado, a Toyota focava na manufatura rápida de
um carro customizado, assim que uma nova demanda era
requerida por um cliente fazendo uma compra.
Sistema Estável
O bar de whisky é um sistema estável: a taxa de entrada de garrafas
no bar é a taxa de saída das mesmas. Simples assim!
Um sistema estável é um sistema para o qual a taxa de

entrada se iguala à taxa de saída ⁴.
John Little definiu sistema estável em sua pesquisa e trabalhos sobre

medições e melhorias de processos.
Estabilidade no sistema
O CFD é seu melhor aliado para estabilizar o sistema. Nele, você
pode claramente visualizar as taxas de entrada e saída. As próximas
três imagens retratam: 1) a taxa de entrada, isto é, a taxa na qual
os itens estão sendo adicionados ao sistema; 2) a taxa de saída, isto
é, a taxa na qual os itens estão saindo do sistema; e 3) um sistema
estável, em que a taxa de entrada se iguala à taxa de saída.
taxa de entrada no CFD
⁴A Proof for the Queuing Formulaî, por Little J. D. C. (1961)

taxa de saída no CFD
sistema estável no CFD
Enquanto as taxas de entrada e saída não forem iguais, o sistema

estará instável. As próximas duas imagens mostram dois momentos
em que o sistema está instável. No primeiro, a taxa de entrada está
maior que a taxa de saída, fazendo com que o WIP aumente e o
sistema fique em risco de sobrecarga. Na segunda imagem, a taxa
de saída é maior que a de entrada, fazendo com que o WIP diminua
e o sistema fique em risco de ficar sem itens de trabalho.
sistema instável: sobrecarga
sistema instável: pouco trabalho
Nestes CFDs, você pode, mais uma vez, perceber a Lei de Little:
reduzir o WIP reduz o tempo de atravessamento. Note que o
modelo do CFD tem dados de um projeto real. Períodos instáveis
acontecem. O ponto principal é que o CFD é uma ferramenta para
perceber e agir sobre a instabilidade. As duas figuras seguintes
demonstram o projeto-modelo. Ele começou estável, passou por um
momento de instabilidade (no qual o time agiu sobre ele), e então
seguiu para outro período estável.
períodos estáveis no CFD
período instável no CFD
Mantenha o CFD simples

O CFD é uma ferramenta simples e muito valiosa. Nele você con-
segue enxergar vários parâmetros do fluxo de trabalho. E, a partir
da análise e melhoria desses parâmetros, melhorar a eficiência do
seu processo.
Mas, ás vezes, chegar ao simples é complicado. Pelo menos foi
para mim. Levei bastante tempo (e muitas garrafas de uísque) para
elaborar este conteúdo.
Espero que você tenha devorado este conteúdo sobre CFD em

poucas horas, e que o mantenha por perto, para consultá-lo quando
necessário.
CFD é uma dentre várias outras ferramentas que podem te ajudar
com a busca da eficiência e da melhoria contínua. Mas, para ser
coeso e sucinto, decidi compartilhar um CFD para um processo
simples (to do / doing / done). A minha expectativa é que após
você compreender o CFD de um processo simples, você estará
melhor equipado para decidir se e quando usar o CFD para fluxos
e processos mais complicados (por exemplo, com várias etapas de
ação, ao invés de somente uma etapa doing).
Sobre o jogo
Este livro e o jogo vem evoluindo a bastante tempo (desde 2011).
É impressionante quantos experimentos e evoluções acontecem até
que um conteúdo alcance um bom nível de coesão.
Por esse motivo deixo aqui meu agradecimento às várias pessoas
que já participaram do workshops e treinamento do assunto do livro
e me forneceram feedback sobre o mesmo.
Vou manter uma página atualizada com artefatos e links sobre o
jogo: http::/caroli.org/jogo-lean-product-development
Objetivos do jogo
Esse jogo começa após uma Lean Inception (LI) e uma Sprint 0. O
sequenciador apresentado é resultado da LI. Na Sprint 0, a equipe
construiu o set-up inicial de entrega continua num trunk único,
feature toggles, e o esqueleto de uma suíte automatizada de testes
de regressão.
Esse jogo é baseado em dados de um projeto real, onde eu facilitei
a LI, e depois assumi o papel de ScrumMaster da equipe. Eu
apliquei os conceitos compartilhados nesse livro – Lean Product
Development: guiando a construção do MVP com Scrum e Kanban.
Venha me substituir nessa jornada!
Nesse jogo você será o ScrumMaster. Seus objetivos: ajudar as

pessoas da equipe — seis devs, dois testers e um PO — a (1) planejar
e (2) entregar as funcionalidades do MVP e seus incrementos,
conforme o resultado da Lean Inception.
Sobre o jogo 107
sequenciador do jogo
Objetivo 1: planejar as entregas

Os principais stakeholders estão te esperando para uma reunião
onde você terá de dizer em quantas semanas a equipe entrega o
MVP, e quantas semanas mais para os incrementos seguintes.
Considere que a Sprint 0 acabou (tudo ok para começar a trabalhar
no código funcional). Considere também que a equipe trabalha de
forma ágil — ao invés de uma cascata—, logo você não precisa
adicionar tempo de análise e tempo de validação para calcular a
data de entrega do MVP.
Sobre o jogo 108
cascata vs agil
Na LI, a equipe chegou a este resultado no cálculo por amostragem:
• 27 dias para cada onda para 2 Devs
Considerações sobre a capacidade da equipe:

– sem férias ou feriados
– 10% para doenças e afastamentos
– 1 dev alocado para corrigir defeitos (depois do MVP)
Objetivo 2: entregar o MVP e seus

incrementos
Você já prometeu a data; agora é entregar! A equipe — 6 devs, 2
testers e um PO — trabalha no dia a dia, Sprint a Sprint, no fluxo de
trabalho, movendo o trabalho no Kanban. Ajude-os com a gestão
do fluxo de trabalho: jogue com sabedoria e aplique os conceitos
apresentados no livro!
Ao final de cada Sprint, você tem uma reunião com os stakeholders
para apresentar:
• Status report do MVP

Sobre o jogo 109
• Gráfico Burn-up do MVP

• Diagrama de Fluxo Cumulativo
reports do jogo
Sobre a equipe
• Além de você (SM), a equipe é formada por: 1 PO , 6 Devs , 2

Testers
• Atividades em “In Dev” realizados somente por Devs
• Atividades em “Preparing for Dev” são realizadas por PO ,
Dev , e / ou Tester
• Atividades em “Testing” são realizadas por Tester e / ou Dev
Sobre o Scrum no jogo

• Sprints de 2 semanas
Sobre o jogo 110
• Sprint Planning: definir a meta da Sprint

• Durante a Sprint: trabalhar e mover o trabalho
• Fim da Sprint: coletar os dados para a Sprint Review
• Sprint Review: apresentar o Status Report, o Burn-up e o CFD
• Retrospectiva: buscar a melhoria contínua
Sobre o Kanban no jogo

Seguem as dicas para o Kanban durante o jogo:
• Visualise o fluxo de trabalho

• Limite o WIP
• Pense Pull versus Push
As etapas do Kanban
O Kanban do jogo possui o seguinte fluxo: Prep for Dev -> Ready
for Dev -> In Dev -> Read for Test -> Testing -> Release
Neste fluxo, as etapas Prep for Dev, In Dev, e Testing representam
etapas de ação onde os membros da equipe trabalham nas ativi-
dades específicas de cada etapa, enquanto as outras representam
filas de espera para mover o item doe trabalho para uma etapa de
ação, no caso de ready for Dev e Ready for Testing, e para mover o
item a produção, no caso da etapa Release.
Segue um resumo das atividades em cada etapa do fluxo:
Prep for Dev

• Compreensão e detalhamento das features
• Definindo comportamento esperado e os critérios de aceite
• Preparar cenários e dados de teste
Sobre o jogo 111
In dev
• Implementando todas as tarefas para criar a feature

• Automatizando tarefas de infra e de testes
• Trabalhando em DevOps e tarefas de infraestrutura
In Testing
• Verificando os novos cenários de teste, os dados de teste e as

features flags.
• Adicionando, executando, refatorando e mantendo o con-
junto de testes de regressão
• Executando sessões de teste exploratórias
• Verificando a consistência e mantendo os ambientes necessários
para validar o produto
Bom jogo!

Lean Delivery

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Lean Delivery

Enviado por

Direitos autorais:

Formatos disponíveis

Lean Product Development:

Guiando a Construção do MVP

This version was published on 2019-11-13

This is a Leanpub book. Leanpub empowers authors and

© 2019 Paulo Caroli

Sobre Paulo Caroli . . . . . . . . . . . . . . . . . . . . . . . . i

Sobre a Editora Caroli . . . . . . . . . . . . . . . . . . . . . . ii

Sobre esse e-Book . . . . . . . . . . . . . . . . . . . . . . . . iii

O ciclo PDCA do Lean Strategy . . . . . . . . . . . . . . . . 1

Conhecimento, relacionamento e comprometimento . . . 8

Calculando esforço, tempo e custo . . . . . . . . . . . . . . 12

Somente Devs estimam? . . . . . . . . . . . . . . . . . . . . 27

Estimativa cascata ou ágil . . . . . . . . . . . . . . . . . . . 28

Teste Antes, valide depois . . . . . . . . . . . . . . . . . . . 31

Puxe, não Empurre . . . . . . . . . . . . . . . . . . . . . . . . 33

Escopo funcional do MVP . . . . . . . . . . . . . . . . . . . 34

Construindo MVP com Scrum . . . . . . . . . . . . . . . . . 38

Construindo MVP com Kanban . . . . . . . . . . . . . . . . 44

MVP, Kanban e bugs . . . . . . . . . . . . . . . . . . . . . . . 57

Radar de Débito Técnico . . . . . . . . . . . . . . . . . . . . 60

Status report do MVP . . . . . . . . . . . . . . . . . . . . . . 70

Nível de incerteza da funcionalidade . . . . . . . . . . . . 72

Burn-up de Features do MVP . . . . . . . . . . . . . . . . . 74

Diagrama de Fluxo Cumulativo . . . . . . . . . . . . . . . . 82

Sobre o jogo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Acompanhe Paulo Caroli no seu site e nas redes sociais:

WIP (Writing In Progress)

Este e outros eBooks estarão disponíveis no site http:

A série Lean Strategy

O PDCA do Lean Strategy

Esse é o ciclo do PDCA: Tudo começa a partir de um workshop

finais. Os dados de uso são coletados e compilados como métricas

• Alguém investiu na sua startup e você vai colocar a sua ideia

Antes de sair fazendo, o grupo participa de um workshop colab-

A forte influência de Lean StartUp é um dos dois motivos para

O nome Inception vem do RUP (Rational Unified Process), um

A Rational foi comprada pela IBM em 2003. E, nessa época, o

Inception é a primeira de quatro fases do RUP: Inception, Elabora-

duas a quatro semanas, com reuniões no escritório do cliente que

O produto mínimo viável, em Inglês Minimum Viable Product

Pronto. Na inception, o foco era em gerar o plano de release do

exemplo de artefatos, resultado de uma Lean Inception

A foto acima demonstra um resultado tangível da inception: o plano

um time numa Lean Inception

outro time numa Lean Inception

Cuidado. Uma inception bem sucedida é somente o começo dessa

jornada. Saindo da inception precisamos considerar outros aspectos

• Evite grandes mudanças no time original, mas se isso for

Os capítulos a seguir compartilham mais detalhes sobre como guiar

Além de mostrar os cartões de funcionalidades ordenados, o se-

exemplo: Canvas MVP1 e Canvas MVP 2 ao lado do sequenciador de funcional-

Segue abaixo um sequenciador, exemplo de resultado de uma Lean

Note no sequenciador apresentado que o MVP 1 é composto pelas

O intuito é executar o que é mais impactante o mais cedo possível,

• Regra 1: Uma onda pode conter, no máximo, três funcionali-

• Regra 2: Uma onda não pode conter mais de uma funcionali-

A regra 1 limita o número de funcionalidades que estão sendo

1. Selecione duas ou três ondas a serem detalhadas.

Ao selecionar as ondas de amostragem (passo 1), lembre-se que

funcionalidade detalhada em tarefas

No contexto deste livro, vou chamar de tarefas os pedaços menores

1. Escreva os seguintes tamanhos de camiseta em post-its: P, M

Ao final desta atividade, cada tarefa será associada a um tamanho

exemplo - detalhando e dimensionando as funcionalidades de amostragem