Backlog: O que é?

Figura 1. Backlog (fonte: Aguiar e Caroli, 2021).

Product Backlog Building (PBB)

O PBB é um método e um Canvas para a elaboração e criação de um Product Backlog sendo, o PBB Canvas (Figura 2), a ferramenta que facilita a utilização do método de Product Backlog Building.

Seu objetivo é ajudar na construção e no 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 que o time possa começar a trabalhar de modo ágil e eficaz.

A dinâmica do PBB que consiste em vivenciar, na prática, a elaboração e criação de um backlog, envolvendo todas as pessoas que irão trabalhar no produto, esclarecendo as histórias de usuário e o backlog do time, utilizando o PBB Canvas como ferramenta de facilitação.

Figura 2. PBB Canvas (fonte: Aguiar e Caroli, 2021, adaptado).

Utilização do PBB

O PBB pode ser utilizado, por exemplo, em complemento ao Scrum e do Lean Inception. Quanto ao Scrum, o PBB pode ser utilizado como técnica para construir, refinar e priorizar as histórias de usuários e os primeiros incrementos do produto para o backlog do time ágil, uma vez que o Scrum não aborda como fazer essas atividades. Em relação ao Lean Inception, de acordo com os autores, Aguiar e Caroli (2021), a Lean Inception e o PBB podem ser usados separadamente, mas a melhor opção é fazer o “casamento” dos dois e aproveitar o melhor de cada um.

Além dos exemplos citados, de maneira geral, é possível a utilização do PBB sempre que um projeto ou produto tiver seus requisitos orientados a histórias de usuários.

Benefícios do PBB

• Ajuda na construção e no refinamento de um backlog de maneira efetiva e colaborativa;
• Constrói um entendimento compartilhado do negócio do cliente, facilitando a descoberta e compreensão do produto;
• Descreve a experiência do usuário com o produto;
• Facilita a descoberta e a escrita da história de usuário;
• Define um mínimo de alinhamento e planejamento inicial;
• Produz um Backlog alinhado à necessidade do cliente.

Granularidade do Backlog

Logo no início de cada projeto e/ou desenvolvimento de produto de software, é fundamental que a equipe estabeleça qual será a estrutura de organização de requisitos a ser utilizada. Pois, somente a partir disso, será possível entender a alinhar entre os envolvidos qual será o nível de granularidade utilizado para os itens de backlog.

A Figura 3, apresenta alguns exemplos de estruturas de organização de requisitos. Nota-se que, com excessão de um (FDD), todos possuem em comum os de níveis de "histórias de usuário" (user history) e "tarefas" (task), e que, os demais são em sua maioria distintos. Embora alguns nomes se repitam, conceitualmente, são distintos, a exemplo de "épicos", na estrutura de user story versus o SAFe. Ao observar o nível de "features", percebe-se que há semelhança conceitua e de nomenclatura no SAFe, Lean Inception e PBB.

Figura 3. Granularidade do Backlog (fonte: Aguiar e Caroli, 2021, adaptado).

Construindo o PBB Canvas

De acordo com o método PBB, deve-se seguir quatro passos para a construção do Canvas, sendo:

1. Contextualize o produto: o primeiro passo refere-se ao estabelecimento do nome do produto, os problemas do contexto atual e as expectativas em relação ao produto que será construído.
2. Descreva as personas: o segundo passo diz respeito a identificação das personas e suas atividades. Busque identificar o que a persona faz hoje e o que ela quer fazer com o produto. A Figura 4 ilustra um exemplo.

Figura 4. Descrevendo a Persona (fonte: Aguiar e Caroli, 2021, adaptado).

3. Entenda as funcionalidades: no terceiro passo deve-se identificar as ações e/o interações que cada persona terá no produto. Neste sentido, pense: "O usuário está tentando fazer algo, então o produto deve ter uma funcionalidade para isso. Qual é?". Esse "fazer algo" é derivado do passo anterior, quando identifica-se o que a persona faz e o que ela deseja fazer. Além disso, para cada funcionalidade são definidos os problemas que ela resolve, assim como os seus benefícios. A Figura 5, ilustra um exemplo.

Figura 5. Identificando as Funcionalidades (fonte: Aguiar e Caroli, 2021, adaptado).

4. Identifique os PBIs: por fim, são identificados os PBIs (Product Backlog Items), os quais são elementos que compõem o Backlog do Produto. Para tanto, cada funcionalidade é detalhada em um passo-a-passo, onde cada um deles dará origem a um PBI (uma ação do usuário no produto). Neste sentido, cada funcionalidade irá possuir um conjunto de PBIs. A Figura 6, ilustra um exemplo.

Figura 6. Itens de Backlog (PBIs) (fonte: Aguiar e Caroli, 2021, adaptado).

Qualidade dos PBIs (Product Backlog Items)

A qualidade do PBI está associada a dois importantes conceitos, sendo:

• Definição de preparado (Ready – Definition of Ready DoR)
• Definição de pronto (Done – Definition of Done DoD)

Neste sentido, avalia-se o PBI em na sua entrada e saída de uma Sprint (Figura 7).

Figura 7. Itens de Backlog (PBIs) (fonte: Aguiar e Caroli, 2021, adaptado).

Definition of Ready (DoR)

Em relação a sua entrada (DoR) (Figura 8) do item de backlog, em uma Sprint, deve-se verificar se o PBI está preparado, conforme os critérios estabelecidos e combinados entre a equipe de desenvolvimento e o Dono do Produto (ou Líder da StartUp). Cabe destacar que, logo no início do projeto (ou de cada Sprint) a equipe de desenvolvimento e o Dono do Produto devem estabelecer as condições para que um item de backlog seja considerado preparado, e assim esteja passível de fazer parte de uma Sprint.

Os itens de backlog que não estejam preparados, não devem ser puxados para uma Sprint, pois não cumprem as condições necessárias para entrar em desenvolvimento. Neste sentido, deve ser tratados como spikes, por exemplo.

Figura 8. Definition of Ready (fonte: Aguiar e Caroli, 2021, adaptado).

A seguir, alguns exemplos de perguntas a serem feitas para verificar se o PBI pode ser considerado como “Ready” (preparado):

• O PBI possui informação necessária para ser trabalhado?
• O PBI cabe em uma Sprint?
• O PBI está representado por uma história de usuário?
• O PBI está coberto por critérios de aceite & BDD?
• O PBI está mapeado para uma interface (quando necessário)?
• As dependências do PBI estão identificadas (se houver)?

Definition of Done (DoD)

Já no que se refere a saída (DoD) (Figura 9) do item de backlog, de uma Sprint, precisa ser verificado se ele cumpre com os critérios estabelecidos, comprovando a satisfação de todos com o trabalho realizado. Da mesma forma, como ocorre com a Definição de Preparado, equipe de desenvolvimento e Dono do Produto (ou Líder da StartUp) devem estabelecer as condições para que um item de backlog seja considerado feito. Essa definição pode ocorrer logo no início do projeto, ou no início de cada Sprint. Se um PBI não atende ao “Done”, ele não deve ser liberado ou mesmo apresentado na Sprint Review.

Figura 9. Definition of Done (fonte: Aguiar e Caroli, 2021, adaptado).

A seguir, algumas perguntas que podem ser realizadas para verificar se um item de backlog está "Done" (feito):

• Entrega um incremento do produto?
• Contempla os critérios de aceite estabelecidos?
• Está documentado para uso?
• Está aderente aos padrões de codificação?
• Mantém os índices de performance do produto?

Referências Bibliográficas

- Aguiar, F. e Caroli, P. “Product Backlo Building: Um guia prático para a criação e refinamento de backlog para produtos de sucesso”. Edtora Caroli, RJ. 2021.

- Aguiar, F. Scrum PBB. Disponível em: http://www.productbacklogbuilding.com/slides/ScrumPBB.pdf