Product Backlog Building

Concepção de um product backlog

efetivo

Paulo Caroli e Fabio Aguiar

Esse livro está à venda em http://leanpub.com/pbb

Essa versão foi publicada em 2018-09-25

Esse é um livro Leanpub. A Leanpub dá poderes aos autores e

editores a partir do processo de Publicação Lean. Publicação Lean
é a ação de publicar um ebook em desenvolvimento com
ferramentas leves e muitas iterações para conseguir feedbacks dos
leitores, pivotar até que você tenha o livro ideal e então conseguir
tração.

© 2014 - 2018 Paulo Caroli e Fabio Aguiar

Conteúdo

Sobre Fabio Aguiar . . . . . . . . . . . . . . . . . . . . . . . . i

Sobre Paulo Caroli . . . . . . . . . . . . . . . . . . . . . . . . ii

Sobre a Editora Caroli . . . . . . . . . . . . . . . . . . . . . . iii

Motivação do PBB . . . . . . . . . . . . . . . . . . . . . . . . 1

O que é Product Backlog Building? . . . . . . . . . . . . . . 2

Um Overview do Scrum . . . . . . . . . . . . . . . . . . . . 3
As reuniões do Scrum . . . . . . . . . . . . . . . . . . . . 3
A Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
A equipe Scrum . . . . . . . . . . . . . . . . . . . . . . . . 5
Trabalho em Equipe, Alinhamento Cadenciado e Clareza 6

PBB e Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Backlog, a única fonte de requisitos . . . . . . . . . . . . 8

O canvas PBB . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Features e Histórias de Usuário . . . . . . . . . . . . . . . . 15

História de Usuário . . . . . . . . . . . . . . . . . . . . . . 15
Critério de Aceite . . . . . . . . . . . . . . . . . . . . . . . 16
Tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Um exemplo . . . . . . . . . . . . . . . . . . . . . . . . . . 17
CONTEÚDO

Escrevendo Histórias de Usuário com o PBB . . . . . . . . 19

PBB e SAFe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

PBB e a Inception Enxuta . . . . . . . . . . . . . . . . . . . . 22

Exemplo de resultado da Inception Enxuta . . . . . . . . 22
 Sobre Fabio Aguiar
Fábio Aguiar é especialista em gerenciamento de produtos com
mais de uma década e meia de experiência profissional em de-
senvolvimento de software, tendo focado nos últimos anos em
ajudar times e organizações a melhorar suas entregas produtos de
valor constante, combinando com Scrum, Lean e UX, bem como
energizando e impulsionando organizações na transição e adoção
Ágil. Atua como Agile Coach & Trainer na Adapt.Works, ICAgile
Authorized Trainer, Learning 3.0 Facilitator pela Happy Melly, Tá
Safo Community Team Member e Agile Alliance Brazil Board
Member.

Fabio Aguiar

Acompanhe Fabio Aguiar no seu site e nas redes sociais:

 Sobre Paulo Caroli
Consultor principal da Thoughtworks Brasil e cofundador da Agi-
leBrazil, 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 ThoughtWorks 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 ” Direto Ao Ponto; Criando Produtos
de forma enxuta” , 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.
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, apro-

ximando 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
 Motivação do PBB
Scrum é o framework ágil mais utilizado para a construção de
produtos digitais. Scrum tem como ponto de partida o Product
Backlog, entretanto nã há no mercado respostas claras para as
seguintes perguntas:

• Como chegar ao Backlog?

• Como construir algo que tenha valor?
• Como encontrar a real necessidade do cliente?
• Como definir o que é prioridade para o cliente no primeiro
momento?

Tentando responder essas perguntas, depois de diversas experiên-

cias em vários clientes, Fábio Aguiar documentou a forma mais
efetiva de criar o Product backlog, e passou a compartilhar o PBB
–- abreviação de Product Backlog Building.
Este E-book compartilha o passo a passo para a utilização efetiva
do PBB.
 O que é Product Backlog
Building?
Product Backlog Building (PBB) é o processo de construção do
Product Backlog utilizando o Canvas PBB como ferramenta. Essa
dinâmica leva todos os envolvidos do negócio a uma experiência
prática de elaboração e definição de um Product Backlog efetivo,
totalmente consistente, e alinhado com os valores de negócio do
cliente.

Um overview do PBB
 Um Overview do Scrum
Scrum é um framework Ágil para a conclusão de projetos comple-
xos. Scrum foi inicialmente formalizado para projetos de desenvol-
vimento 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. O desen-
volvimento de software com Scrum progride através de uma série
de iterações chamados de Sprints, que duram, tipicamente, de uma
a quatro semanas.

As reuniões do Scrum
O modelo Scrum sugere que cada Sprint comece com uma breve
reunião de planejamento, e termine com uma reunião de revisão
do trabalho realizado na Sprint. Estes são os princípios do gerenci-
amento de projetos Scrum: ciclos curtos e cadenciados com reuniões
de alinhamento, acompanhamento do trabalho, e melhoria do time.
Um Overview do Scrum 4

as reuniões do Scrum

Alam das reuniões de (1) planejamento e (4) revisão, Scrum sugere

mais duas reuniões que acontecem a cada Sprint. Essa são: (2)
retrospectiva, a reunião que promove o momento kaizen, onde o
time busca a melhoria continua em relação ao processo, entrega,
e interação entre as pessoas; e (3) refinamento, a reunião onde
o backlog do produto é revisitado buscando o entendimento dos
próximos requisitos, candidatos ao próximo Sprint.

A Sprint
A Sprint promove uma cadencia, tipicamente de uma a quatro
semanas, dependendo da preferência do time. Mas diariamente o
time realiza uma reunião para verificar o andamento das tarefas de
trabalho. Esta reunião é a Daily Sprint. Nesta, 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
Um Overview do Scrum 5

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.
No mundo Ágil Scrum, evitamos descrições completas e detalhadas
sobre como tudo deverᡠser feito na Sprint. Muito é deixada para
o time de desenvolvimento decidir. Isso porque o time vai saber a
melhor forma de resolver o problema em questão.
É por isso que a reunião de planejamento do Sprint é descrita em
termos das metas e do resultado desejado. O resultado desejado é
um compromisso com um conjunto de funcionalidades ou histó-
rias 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 revisão.

A equipe Scrum
Scrum fomenta uma equipe multifuncional e com auto-organiza-
ção. A eficiência do time depende da capacidade dos membros
trabalharem em conjunto, e fazer o melhor uso das habilidades dos
indivíduos: multifuncionais. 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ãos 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 primeiro
é um Scrum Master, alguém experiente com o framework que
pode ajudar o time a usar o processo de Scrum 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
Um Overview do Scrum 6

ao desenvolvimento a sua equipe.

O segundo papel específico é o Product Owner (PO). O PO repre-
senta 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.

Trabalho em Equipe, Alinhamento

Cadenciado e Clareza
A equipe Scrum –o Scrum Master, o PO e todos membros do
time (com suas variadas formações– participa ativamente de todas
reuniões com um alto nível de autonomia, transparência e com-
prometimento. Na reunião de planejamento da Sprint, a equipe
decide o Sprint backlog, o qual é acompanhado diariamente e
reavaliado na reunião de revisão da Sprint. Através da busca de
melhoria continua (principal objetivo da reunião de retrospectiva),
tipicamente o time Scrum alcança níveis elevados de rendimento.
Muito disso é alcançado pelo trabalho em equipe, pelo alinhamento
cadenciado via Sprints, e pela clareza de cada papel e cada reunião.
 PBB e Scrum
tem um gap no Scrum… PBB veio para ajudar….
PBB e Scrum 8

Backlog, a única fonte de requisitos

O Backlog do Produto é uma lista ordenada de tudo que deve
ser necessário no produto, e é uma origem única dos requisitos
para qualquer mudança a ser feita no produto. O ProductOwner
é responsável pelo Backlog do Produto, incluindo seu conteúdo,
disponibilidade e ordenação.
K Schwaber & J Sutherland, The Scrum Guide, 2016.
 O canvas PBB
PBB é representado por um canvas que tem um fluxo bem simples e
de fácil compreensão, principalmente para facilitar o entendimento
do cliente, pois sua participação é de suma importância nesse
processo de construção.

o canvas PBB

Veja abaixo o fluxo de construção do Backlog:

• PRODUCT NAME: A primeira etapa é identificar o produto

O canvas PBB 10

que será construído.

• PROBLEMS: Nesta etapa o ponto de partida é identificar e
compreender o Estado Atual pontuando um conjunto de pro-
blemas, neste momento as pessoas de produto e envolvidos do
negócio buscam de forma colaborativa a mesma compreensão
do estado atual, pontuando os problemas que desejam que
sejam resolvidos. É importante conhecer o problema antes de
criar a solução.

• EXPECTATIONS: Nesta etapa é importante identificar o Es-

tado Desejado, alinhando suas expectativas aos problemas do
estado atual, para que, de uma forma compartilhada, todos os
envolvidos possam alinhar suas expectativas.
O canvas PBB 11

• PERSONAS: Nesta etapa saiba quem são os usuários, papéis e

responsáveis envolvidos no produto e saiba o que faz e o que
espera sobre o produto.

• FEATURES: Em seguida, identifique as FEATURES que cada

persona realiza no produto, mapeando na sequência de uso
da esquerda para a direita. Descreva a feature com uma breve
descrição, sempre pontuando os “Problemas” e os “Benefícios”
de cada feature.
O canvas PBB 12

• PBIs: Finalizando as etapas, para cada passo da FEATURE,

escreva os PBI’s que satisfaça, no primeiro momento como
sugestão, escreva no o modelo ARO e em seguida podemos
representar como história de usuário. Construindo a lista de
itens do backlog, podendo organizar(priorizar) verticalmente
o que é mais importante. A quebra de feature é feita através
do Steps Maps, mapear os passos de uma feature. No primeiro
momento, defina o fluxo de trabalho passo a passo, e no
segundo momento, evolua com perguntas, comentários e
idéias, lembrando que um questionamento pode eliminar um
passo desnecessário, um comentário pode melhorar um passo
útil e uma idéia pode fazer nascer um passo novo. No final
cada passo representará um item do backlog.
O canvas PBB 13

Essas são as etapas de forma resumida do “PRODUCT BACKLOG

BUILDING”. Etapas que compõem o Canvas:
[Product Name > Problems > Expectations > Personas > Features >
PBIs]
O canvas PBB 14

O fluxo de uma forma linear ajuda a organizar a visão produtizada,

o compartilhamento tácito de negócio e o que o produto irá agregar
ao final, junto com a ferramenta “PBB Canvas” que ainda deixa
toda a concepção do produto organizado de forma visual.
 Features e Histórias de
Usuário
As features são tipicamente descritas em um nível mais elevado do
que as histórias do usuário. Portanto, antes de começar a trabalhar
em uma feature, a mesma deve ser analisada e detalhada em suas
respectivas histórias de usuário.
Feature é a descrição de uma ação ou interação de um usuário
com o produto. Por exemplo: imprimir nota fiscal, consultar extrato
detalhado, e convidar amigos do facebook. A descrição de uma
feature deve ser o mais simples possível. O usuário está tentando
fazer uma coisa. O produto dever ter uma feature para isso. Que
feature é essa?
Exemplo de Funcionalidade: Consultar partidas sem geo-localiza-
ção
Tipicamente, as equipes de desenvolvimento trabalham com his-
tórias de usuários. Portanto, você deve detalhar um pouco mais, e
realizar o mapeamento de features para histórias.

História de Usuário
História de usuário é um formato textual para a descrição concisa de
um requisito que busca responder a três indagações básicas: quem?
o que? e por que? Tipicamente uma funcionalidade de alto nível
(feature) é desmembrada em algumas histórias do usuário.
Como um PERFIL DO USUÁRIO / PERSONA
Eu quero FUNCIONALIDADE ESPECÍFICA DO PRODUTO
Features e Histórias de Usuário 16

Para que VALOR DO NEGÓCIO

O acrononimo INVEST [ref] ajuda a escrever boas histórias. Esta
história é… Independente? Negociável? Valiosa para o negócio?,
Estimável? Pequena (em inglês, Small)? Testável?
Outro acrônimo que auxilia é o 3Cs [ref]. Em ingles, os três Cs
são: card, conversation, and confirmation. Histórias de usuários têm
três aspectos críticos. O cartão da história deve seguir um modelo
simples ( como um … Eu quero .. para que …). A partir deste modelo
simples (card), teremos conversas colaborativas (conversations)
para melhor entender e detalhar a história, até que, quando pronta,
recebemos a confirmação (confirmation), geralmente pelo dono do
produto (PO, do inglês Product Owner).

Critério de Aceite
Critério de aceite é um formato textual que descreve como testar
uma funcionalidade. Tipicamente uma história do usuário terá
alguns critérios de aceite.
Dado que CENÁRIO INICIAL
Quando AÇÃO REALIZADA
Então ESTADO ESPERADO
Os critérios de aceite (ACs, do inglês Acceptance Criteria) definem
os limites para uma história de usuário. A partir deles, todos os
envolvidos irão saber se a história está completa, dado que haja
confirmação do PO sobre a mesma.

Tarefas

É muito comum quebrar uma história em pedaços ainda menores

sobre o trabalho que deve ser feito. Essas são as tarefas. Ao listar as
Features e Histórias de Usuário 17

tarefas necessárias para construir uma história, a equipe de desen-

volvimento entra em detalhes técnicos de como os pedaços menores
da histórias serão implementados. Diferente das histórias, as tarefas
não seguem um formato textual definido. Essas são mais diretas,
com uma linguagem bem técnida, da equipe de desenvolvimento
para a equipe de desenvolvimento.
Uma tarefa identifica algo que precisa ser feito, algo necessário
para alguma história. Como tal, a tarefa não será necessariamente
independente, ou irá demostrar o valor de negócio. A maioria das
tarefas tendem a ser para programadores, descritas com termos uti-
lizdos pelos mesmos. Alguns exemplos de tarefas: alterar campos da
tabela de partidas, criar contas de teste para usuários, automatizar
os scripts de geração de dados, e assim por diante.

Um exemplo
Segue abaixo um exemplo de feature que foi dividida em três
histórias, com alguns critérios de aceite e tarefas.
Funcionalidade: Consultar partidas sem geo-localização

História 1
Como um peladeiro não-cadastrado
Eu quero consultar partidas próximas a um endereço informado
Para que eu encontre um jogo próximo ao meu local atual

História 2
Como um peladeiro cadastrado
Eu quero consultar partidas próximo ao meu trabalho
Para que eu encontre um jogo próximo ao meu trabalho
Features e Histórias de Usuário 18

História 3
Como um peladeiro cadastrado
Eu quero consultar partidas próximo a minha residência
Para que eu encontre um jogo próximo a minha residência

Critérios de aceite da história 2 (exemplo 1)

Dado que existe uma partida a menos de 10 kilometros do meu
trabalho
Quando procuro por uma partida próxima ao meu trabalho
Então encontro tal partida

Critérios de aceite da história 2 (exemplo 2)

Dado que não existe nenhuma partida a menos de 10 kilometro do
meu trabalho
Quando procuro por uma partida próxima ao meu trabalho
Então não encontro nenhuma partida

Tarefas da História 2
• criar UI para mostrar partidas próximas ao local de trabalho
(com dados hardcoded)
• criar lógica no backend para busca por proximidade (hardco-
ded 10 km)
• alterar parâmetro hardcoded para campo de configuração
• criar dados de teste para buscar partida nas proximidades do
trabalho
• alterar DB para incluir endereço de trabalho
 Escrevendo Histórias de
Usuário com o PBB
Não é fácil escrever as histórias de usuário. Ou melhor, não era fácil.
Mas após preencher o PBB, essas são escritas naturalmente. Perceba
a ilustração a seguir.
O Scrum não fala como podemos representar cada item no Backlog,
podemos escrever de várias forma, inclusive de forma textual. A
User Story é a forma mais usadas hoje pelos times ágeis para
representar um item no Backlog. História de Usuário é uma breve
descrição do que é necessário para o cliente ter no produto, que
pode representar uma necessidade do usuário ou uma descrição de
um item do backlog.

A escrita de uma História de Usuário basicamente responde 3

perguntas: QUEM? O QUE? POR QUÊ?

O PBB nos ajuda na escrita das User Stories. Como podemos notar
no PBB temos o “QUEM?” que é a persona, o “O QUE?” que nesse
caso são os PBI’s já representadas em modelo ARO e por último,
o “POR QUÊ?” que está nos benefícios que o persona destacou na
feature. A figura abaixo exemplifica de uma forma bem simples
como fica fácil escrever as User Story com ajuda do Product Backlog
Building.
Escrevendo Histórias de Usuário com o PBB 20

Como podemos perceber o grande poder do PBB é a facilitação e

a colaboração que provoca com todos os envolvidos na construção
de um Backlog, sempre levando todos a um entendimento compar-
tilhado do contexto de negócio e a descoberta de itens do Backlog
totalmente alinhado com o valor de negócio do cliente.
Pronto! Seja colaborativo e efetivo na criação do Product Backlog.
PBB e SAFe
PBB e a Inception Enxuta
A Inception enxuta ajuda no entendimento do MVP e suas prin-
cipais funcionalidades. O PBB ajuda na criação de um backlog de
histórias. A combinação das duas técnicas tem se apresentado como
uma forma muito efetiva de alinhar estratégia e entrega de produtos
digitais para equipes Scrum.
Criar um backlog de histórias sem compreender o MVP pode ser
arriscado: o time pode trabalhar muito, entretendo com baixa efi-
cácia, já que não está alinhado sobre o mínimo viável para verificar
o direcionamento do produto. Por isso recomendamos fortemente
que antes de aplicar o PBB, que seja realizado as atividades da
Inception enxuta, segundo o livro Direto ao ponto: criando produtos
de forma enxuta.
Ao terminar uma Inception Enxuta, o time Scrum sabe o que
fazer, mas ainda precisa definir o backlog de histórias. O PBB é
a ferramenta para ajudar o time a detalhar o que fazer em histórias
do usuário, o item d trabalho do dia a dia da equipe.

Exemplo de resultado da Inception

Enxuta
A foto e a tabela a seguir (cortesia do livro Direto ao ponto)
mostram as funcionalidades para o easy-bola (app exemplo do livro
Direto ao ponto).
Segue abaixo a foto com o resultado do sequenciador de features.
PBB e a Inception Enxuta 23

o sequenciador de funcionalidades do easy-bola

Segue a transcrição do sequenciador de funcionalidades do easy-

bola apresentado na foto, com seus MVPs identificados e suas
respectivas funcionalidades.

Funcionalidades MVP
cadastro da pelada 1
cadastro do peladeiro 1
consulta de peladas sem geolocation 1
confirmação de presença 2
detalhamento da pelada (local, horário e data) 2
cancelar presença 2
cancelar pelada 3
módulo de notificação 3
notificação de pelada confirmada 3
notificação de pelada cancelada 3
detalhes financeiros da pelada 3
convidar amigo para pelada 4
ranking dos jogadores (visualização) 4

Note que a Inception Enxuta gera um plano para a criação e

evolução do produto digital via MVPs. Note que a Inception Enxuta
PBB e a Inception Enxuta 24

do easy-bola gerou um planejamento da criação de 4 MVPs.

Sugerimos que o PBB seja aplicado somente para um MVP, no caso,
o MVP que o time vai começar a trabalhar. Seguindo o exemplo
do easy-bola, após a Inception enxuta, a equipe provavelmente vai
passar por uma Sprint 0, onde todas a s atividades preparatórias
para o início do trabalho na criação das funcionalidades do produto.
Uma das atividades da Sprint0 deve ser o PBB.
Além do sequenciador de funcionalidades, a Inception enxuta
também gera outro artefado importante: o Canvas MVP. Segeu o
Canvas MVP do MVP1 para o easy-bola

Canvas MVP – EasyBola MVP1

Segue a transcrição do canvas MVP apresentado na foto, com o

conteúdo para cada um dos sete blocos do canvas.

Visão do MVP

• MVP1: anúncio de pelada no Android

PBB e a Inception Enxuta 25

Personas & Plataformas

• gordinho bom de bola

• o jogador solitário
• o dono do time incompleto
• Android

Jornadas

• gordinho cadastra uma pelada

• jogador se cadastra e procura uma pelada

Funcionalidades

• cadastro de pelada
• cadastro do peladeiro
• consulta de peladas sem Geolocation

Resultado Esperado

• 200 usuários em até um mês

• 50 peladas em até um mês
• 300 downloads em até um mês

Métricas para validar as hipóteses de negócio

• número de usuários cadastrados no banco de da-

dos
• número de peladas cadastradas no banco de dados
• número de contagem de downloads no play store

Custos & Cronograma

• 1 onda
• 2 semanas
• R$5.600,00
PBB e a Inception Enxuta 26

Aplicando o PBB para o Easy Bola

Vamos usar o Easy Bola como exemplo e criar o PBB para o

mesmo. Note que a Inception ajudou a entender e alinhar sobre
o MVP. Mas o PBB vai retomar algumas conversar importantes
sobre expectativas e personas, a e ajudar a detalhar o MVP com
suas funcionalidades em histórias do usuário. …