Baixe o app para aproveitar ainda mais
Prévia do material em texto
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 http://leanpub.com/pbb http://leanpub.com/ http://leanpub.com/manifesto 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 seguemuito 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? Nomundo 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 http://caroli.org 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 desenvolvimentodecidir. 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 sentemmais 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 amesma 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çosmenores 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. Oumelhor, 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 formamuito 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 livroDireto 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 umMVP, 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. … Sumário Sobre Fabio Aguiar Sobre Paulo Caroli Sobre a Editora Caroli Motivação do PBB O que é Product Backlog Building? Um Overview do Scrum As reuniões do Scrum A Sprint A equipe Scrum Trabalho em Equipe, Alinhamento Cadenciado e Clareza PBB e Scrum Backlog, a única fonte de requisitos O canvas PBB Features e Histórias de Usuário História de Usuário Critério de Aceite Tarefas Um exemplo Escrevendo Histórias de Usuário com o PBB PBB e SAFe PBB e a Inception Enxuta Exemplo de resultado da Inception Enxuta
Compartilhar