Construindo o seu backlog – PBB

  •  
  •  
  •  
  •  

Quando inicia um projeto há a necessidade de elucidar, entender, descrever, visualizar os itens de um backlog. O Scrum em si não define uma técnica para a criação do backlog. E no mercado há várias técnicas que ajudam a construí-lo. Hoje vou comentar sobre a dinâmica chamada Product Backlog Building (PBB). Mas antes,  vamos saber o que é esse tal de backlog.

O Scrum define que deve-se ter um product backlog, o qual é uma lista priorizada com os requisitos/itens/demandas necessárias/bugs/melhorias para atender o produto a ser gerado no decorrer do projeto. Essa lista é mutável e deve ser atualizado pelo Product Owner (PO), o qual buscar alinhar os itens do backlog com a visão do produto e maximizar o retorno de investimento do cliente. Essa lista também alimenta as atividades do time.

Conforme Rafael Sabbagh em seu livro Scrum: Gestão ágil para projetos de sucesso :

O Product Backlog é uma lista de tudo o que se acredita que será desenvolvido pelo Time de Desenvolvimento no decorrer do projeto. Em cada momento, essa lista é atualizada, ordenada de acordo com a importância para os clientes do projeto e possui apenas o nível de detalhes que é possível de se ter.

Entendido o backlog, vamos partir para o Product Backlog Building.

Product Backlog Building (PBB)

Product Backlog Building (PBB)

O PBB é um canvas (adoro essa “modinha” de canvas, cada um no seu quadrado rs), de fácil compreensão que, de forma enxuta, ordenada e permite a colaboração de todas as partes interessadas (desenvolvedores, PO, usuários finais, etc) em busca do entendimento para descrever o backlog do produto.

Vamos ver como funciona cada parte do Product Backlog Building:

numero-1

Identificação

Comece batizando o produto a ser desenvolvido.

numero-2

Problemas

Formule uma dinâmica que auxile as partes interessadas a expor os principais problemas existentes que se esperam ser solucionados com o produto. Descreva cada um em post-its.

Lembram do Learning Canvas?! O Fábio Aguiar sugere o uso para explorar essa parte do PBB.

numero-3

Expectativas

Alinhe as expectativas das partes interessadas. Importante que cada problema se relacione com uma expectativa e que todos colaborarem para listar as expectativas desejadas para com o produto a ser desenvolvido.

numero-4

Partes interessadas

Comece a personificar os usuários, papéis e responsáveis envolvidos no negócio.

Dê um nome/apelidos, defina suas principais atividades e/ou objetivos no contexto do negócio que o produto pretende atuar, alinhando as expectativas do persona com as do passo anterior.

Sugiro apelidos engraçados, maximiza a associação das funcionalidade ao usuário final. Também evita constrangimentos quando se coloca o nome real.

numero-5

Áreas de negócio

Agrupe as personas conforme área de negócio que atuam. Isso auxilia o PO a ter uma visão de impacto no negócio e por consequência a começar a priorizar.

numero-6

Atividades de negócio

Descreva as atividades de negócio necessárias para cada área listada anteriormente, associando a parte interessada já identificada. Detecte cada atividade por sua sequência cronológica, mapeando da esquerda para a direita, com uma breve descrição e alinhando os problemas (pontos de melhorias) e as expectativas (pontos que se espera chegar).

numero-7

Funcionalidades

Comece a estratificar as atividades de negócio, gerando as funcionalidades. Pode-se utilizar o formato de User Stories ou o que for de melhor compreensão para as partes interessadas.

Recomenda-se a priorizar as funcionalidades de forma vertical.

Os itens do backlog desmembram-se conforme a interação com cada área do canvas, assim surgindo a evolução de top down do produto de maneira rica e simples.

Para cada etapa do PBB,  identifica-se as prioridades iniciais de acordo com a descrição das expectativas do usuário e o entendimento sobre o produto é equalizado por todos os envolvidos, o que considero um ponto bem positivo para que se possa ter bons resultados no durante o projeto.

Para mim, o PBB é bem sistemático, visual e reflete a ideia de níveis hierárquicos. Por esse fato, acredito ser um ponto positivo para ser utilizada em “ambiente tradicionais” – que ainda não estão aberto aos conceitos de agilidade ou então dando os primeiros passos para agilidade. O PBB deve ser acompanhado com técnicas de design thinking e facilitação de reunião para atingir o objetivo esperado e maior colaboração. O próprio criador do PBB, Fábio Aguiar, enfatiza isso.

Quer conhecer mais, veja também:

Leave a Comment