Na Invillia, toda quarta-feira, ao meio dia, paramos uma hora para nos nutrir com as dicas, how-tos, boas práticas e tendências selecionadas por nossos especialistas em Product, Agile, Back e Front, Mobile, Quality, Security e Data. Uma troca de experiência vital para quem adora o novo. E essencial para que a inovação nunca pare. Se a tecnologia está no sangue, a gente faz questão de deixá-la circulando cada vez mais_

NA VEIA_ Construção de “backlog” efetivo e colaborativo para o desenvolvimento de produtos: organizando as prioridades no SCRUM

5 minutos de leitura

No artigo de hoje, compartilhamos os principais aprendizados da incrível edição sobre a ferramenta “Product Backlog Building (PBB)”, apresentada por Guilherme Mendes, nosso especialista no assunto.

Histórico

O Product Backlog Building (PPB) surgiu em 2010, através do conhecimento do desenvolvedor Fábio Aguiar, que viu a necessidade de se ter um profissional que se aproximasse e se relacionasse com o cliente – o Product Owner (PO) –, descobrindo novas funcionalidades e traduzindo o desejo do cliente no contexto do framework SCRUM.

Na ocasião, o PO possuiria um caderno e uma caneta para descrever as percepções e estruturar o backlog acerca do produto, relacionando problemas e expectativas de pessoas afetadas.

Com a evolução do conteúdo do caderno, desenvolveu-se o Product Backlog Building (PBB) desdobrado na ideia de um Canvas – ferramenta visual que ajuda na elaboração e construção de todo backlog de produto de forma totalmente colaborativa.

Como resultado, o cliente passou a ter o sentimento de “dono” da construção do backlog por meio do envolvimento e colaboração. Ou seja, os envolvidos têm uma visão clara de tudo o que precisa ser construído. E esta ferramenta utilizada para facilitação ganhou a denominação de “PBB Canvas”.

A partir de 2013, o modelo foi utilizado por uma comunidade ágil e, a partir de 2015, foi difundido no Brasil e em eventos, sendo hoje, bastante disseminado na comunidade.

Mais recentemente, em 2017, a ferramenta foi apadrinhada pelo criador do Lean Inception, Paulo Caroli, que junto de Fábio Aguiar, viu a oportunidade de unir as duas ferramentas, descrevendo um método completo em livro publicado em 2021.

Product Backlog Building (PPB) – o que é

Product Backlog Building é um método cujo objetivo principal é ajudar na construção e refinamento do product backlog de forma colaborativa – construindo um entendimento compartilhado e levando todos os envolvidos à compreensão do produto – e na preparação do backlog para o time começar a trabalhar de forma de modo ágil e eficaz.

Fonte: Product backlog building: Um guia prático para criação e refinamento de backlog para produtos de sucesso. Fábio Aguiar e Paulo Caroli

A facilitação

Apesar de ter sido originado em times que utilizavam o framework SCRUM a fim de resolver o Product Backlog, trata-se de uma ferramenta que também pode ser complementar para times que utilizam outros frameworks e metodologias ágeis, sendo considerada base para o desenvolvimento da facilitação por meio de um fluxo linear de trabalho. Através da proposição de elaboração e criação de backlog efetivo e colaborativo, a ferramenta reúne pessoas que trabalham direta ou indiretamente no produto.

O que é o PPB Canvas

É um board intuitivo em formato de tela ou quadro (o template está disponível no site do PPB), que possui um fluxo de trabalho simples e de fácil compreensão, principalmente para facilitar o entendimento do cliente, pois sua participação é de suma importância no processo de construção.

O fluxo mapeia as seguintes informações:

1. Product Name
2. Contextualização do produto (visando o estado atual e o estado desejado do produto em quatro pilares: problemas; expectativas; personas; e features)
3. Mapeamento dos passos de uma feature (funcionalidade) – Steps Maps Product Backlog Itens (PBI’s) são classificadas como histórias de usuário
4. Método de priorização do Backlog – Classificar, ordenar e organizar (COORG) – acrônimo para os PBIs originados de uma funcionalidade

O PBB e a escrita de User Stories

O PBB Canvas, enquanto fluxo ou maneira linear de pensar, faz conexão desde a identificação dos problemas até as expectativas e definição das personas que utilizam o produto, relacionando as funcionalidades a partir de sua utilização, e descrevendo um passo a passo que define os itens de trabalho do time.

A maneira com que o PPB propõe que sejam convertidas as histórias de usuários, ou seja, basicamente o que se vê nos times, se baseia nos três W’s – Who, What e Why? (no português Quem, O que e Por quê?), e nos três C’s – cartão, conversa e confirmação – como espaço pra promover a discussão visando diálogo, aceite e validação.

Em outras palavras, o time se basea em “quem” (persona) e “como” (caminhos para o desenvolvimento desmembrado da funcionalidade) e “por quê” (destaque que traduz o benefício a ser entregue ao cliente). Além disso, na história de usuário, é utilizado o termo “para” e o formato faz destaque ao “invest” – termo bastante utilizado no mercado –, que corresponde a uma orientação para a escrita da história de usuário, visando classificá-la como: independente, negociável, valiosa, estimável, pequena e testável.

Para organizar a visão geral do negócio e alinhar seu valor com a compreensão e o que o projeto irá agregar ao final – que junto com a ferramenta PBB Canvas deixa toda a concepção do produto organizado de forma visual –, o fluxo linear resulta em um Product Backlog totalmente alinhado com o valor do negócio e cliente, sendo descrito na seguinte ordem: Product Name > Problemas > Expectativas > Personas > Funcionalidades > PBI’s.

A orientação é aplicar a metodologia por sessão, registrando, em primeiro lugar, a compreensão do produto e entendendo os problemas e expectativas, descrevendo sequencialmente as personas e, por último, mapeando o passo a passo da funcionalidade para chegar aos PBBs, evoluindo o que pode ser eliminado com perguntas, comentários e ideias em determinada funcionalidade, basicamente como um fluxo linear que reúne tudo no PBB Canvas.

Percepções após aplicação na Invillia

– Necessidade de formar parceria com PO, UX e UI disponíveis e que contribuam para a construção de determinado produto;

– Necessidade de estar atento às estratégias do produto, à missão e objetivos do time (OKRs) que nem sempre estão relacionados às estratégias empresariais, mas como “facilitador”, definindo funcionalidades e interpretando todo o conteúdo;

– Garantia de que todos tenham entendido o todo para que compreendam as definições de personas, funcionalidades, o que resolver como problema, criar como expectativa, oferecendo uma visão macro sobre onde o produto vai chegar, aumentando a confiança e geração de valor;

– Utilização de indicadores atuais dos produtos antes da aplicação para potencializar a necessidade da aplicação do PBB, mostrando a evolução sua aplicação (antes e depois) e o quanto aquilo interferiu nos indicadores, fazendo um paralelo do quanto cada fase pode contribuir para a maturidade do produto e time, além de promover o engajamento e a interação e contribuição das pessoas para a construção do backlog;

– Geração de indicadores de maturidade entre uma sessão e outra, expondo o ganho e a visão do time, e aumentando a credibilidade na aplicação e continuidade;

– Explicação breve sobre o conteúdo antes de cada sessão (não utilizar a obviedade) para a compreensão do time e entendimento sobre sua aplicação;

– Entendimento sobre o momento e reação do time sobre a aplicação do PBB.

Em resumo, a visão geral do PPB para a construção do backlog fica resumida no quadro, desde problemas, identificação, datas, facilitadores, personas, funcionalidades e até a orientação para criar as histórias de usuário. Tudo isso está disponível no site do Fábio Aguiar para ser utilizado e aplicado com qualquer time, visando a contribuição e interação, e deixando de lado a construção única, independentemente da figura do PO. O PPB se propõe a confrontar a maturidade de produto, processo e visibilidade daquilo que está sendo desenvolvido no que diz respeito a qualidade do produto, e não aos seus problemas.