PBB: Product Backlog Building
Product Backlog Building (PBB) é um processo utilizado em metodologias de desenvolvimento de software ágeis, como o Scrum, para criar e manter uma lista de itens de trabalho (ou “backlog”) para um projeto de software. O PBB é realizado pelo Product Owner, que é responsável por definir e priorizar os itens do backlog, com base nas necessidades do negócio e dos usuários. Os itens do backlog incluem histórias do usuário, tarefas técnicas e bugs.
O PBB é um processo contínuo que começa antes do início do projeto e continua durante todo o ciclo de vida do projeto. Ele é usado para garantir que o projeto esteja sempre alinhado com as necessidades do negócio e dos usuários, e para garantir que o trabalho do time de desenvolvimento esteja sempre focado nas coisas mais importantes.
O PBB também é importante para garantir que o trabalho do time esteja sempre alinhado com o escopo do projeto, e que o escopo seja revisado e ajustado conforme necessário. Ele também é usado para garantir que o projeto esteja sempre no caminho certo para alcançar seus objetivos.
Um pouco mais
PBB é representado por um canvas chamado de PBB 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.
Veja abaixo o fluxo de construção do backlog:
Product Name: A primeira etapa é identificar o produto que será construído.
Compreenda o Estado Atual e o Estado Desejado
Problems: Nesta etapa o ponto de partida é identificar e compreender o Estado Atual pontuando um conjunto de problemas, 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 Estado Desejado, alinhando suas expectativas aos problemas do estado atual, para que, de uma forma compartilhada, todos os envolvidos possam alinhar suas expectativas.
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 funcionalidades que cada persona realiza no produto, mapeando na sequência de uso da esquerda para a direita. Descreva a funcionalidade com uma breve descrição, sempre pontuando o “Problemas” e o “Benefícios” de cada funcionalidade.
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 user stories. 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 funcionalidade. 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.
Agora é só priorizar o backlog e dar todo direcionamento de trabalho para o time, aplicando quaisquer técnica de priorização. O PBB tem sua técnica de priorização que ajudar a ter um backlog priorizado e um plano de entregas com definição de metas.
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 fluxo de uma forma linear ajuda a organizar a visão geral do negócio e alinhar o valor de negócio, a compreensão e o que o projeto irá agregar ao final, junto com a ferramenta “PBB Canvas” que ainda deixa toda a concepção do produto organizado de forma visual.
Como resultado teremos um Product Backlog totalmente alinhado com o valor de negócio do cliente.
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órias 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 PBIs já representadas em modelo ARO e por último, o “POR QUÊ?” que está nos objetivos e benefícios que a 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.
Como podemos perceber o grande poder do Product Backlog Building é 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 compartilhado do contexto de negócio e a descoberta de itens do backlog totalmente alinhado com o valor de negócio do cliente.
Para entender de forma completa como funciona uma sessão de PBB recomendo a leitura do Livro oficial do meu professor de PBB, Fábio Aguiar, tive a oportunidade de participar com meu time do treinamento da caroli.org, e conseguimos tirar bastante proveito levando as nossas sessões para o mundo real.
Referências: http://productbacklogbuilding.com/overview.php#:~:text=PBB Overview,PBB Canvas como ferramenta facilitação.
Originally published on March 2, 2022.
