Product Backlog Building

Product Backlog Building [RESUMO].002

Scrum é uma metodologia ágil para gerenciamento de produtos, baseado em desenvolvimento iterativo e incremental. O seu ciclo inicia com uma lista de funcionalidades desejadas para o produto, priorizada pelo cliente, então o time escolhe as funcionalidades que se compromete em desenvolver, geralmente em uma iteração de 2 a 4 semanas.

Podemos notar que esse ciclo é bem definido, tendo como ponto de partida o Product Backlog, mas o Scrum não tem nenhuma definição de como construir um Backlog. Sempre nos deparamos com as perguntas:

1. Como chegar ao Backlog?
2. Como construir algo que tenha valor?
3. Como encontrar a real necessidade do cliente?

Tentando responder essas perguntas, depois de diversas experiências em vários clientes, nasceu o “PBB – Product Backlog Building”. O PBB tem como principal objetivo ajudar na construção de um Backlog de forma compartilhada, construindo um entendimento compartilhado, levando todos os envolvidos a um entendimento alinhado do domínio do negócio, ou seja, todos compreenderem o contexto do negócio.

Product Backlog Building [RESUMO].005

A dinâmica do Product Backlog Building (PBB) consiste em um processo de construção do Product Backlog utilizando o Backlog Canvas 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.

Product Backlog Building [RESUMO].006

PBB é representado por um canvas (Backlog 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. A dinâmica do PBB ajuda a descobrir novos itens para o Product Backlog, com uma abordagem bem alinhada com o negócio do cliente.

Backlog Canvas.001
IDENTIFICAÇÃO: A primeira etapa é identificar o projeto ou produto que será construído.

PROBLEMAS: Nesta etapa o ponto de partida é identificar e compreender o Estado Atual pontuando um conjunto de problemas, neste momento as partes interessadas 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.

EXPECTATIVAS: 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.

PARTES INTERESSADAS: Nesta etapa saiba quem são os usuários, papéis e responsáveis envolvidos no negócio. Alinhando seu contexto de negócio, suas atividades de negócio e suas expectativas e objetivos.

ÁREAS DE NEGÓCIO: A partir desse momento, identicado as PARTES INTERESSADAS, identifique as suas ÁREAS DE NEGÓCIOS.

ATIVIDADES DE NEGÓCIO: Em seguida, identifique as ATIVIDADES DE NEGÓCIO de acordo com suas respectivas ÁREAS DE NEGÓCIO já identificadas, as atividades que cada PARTE INTERESSADA realiza dentro do negócio, mapeando na sequência de uso da esquerda para a direita. Descreva a ATIVIDADE DE NEGÓCIO com uma breve descrição da atividade, sempre pontuando o “Problema” e a “Expectativa”.

FUNCIONALIDADES: Finalizando as etapas, para cada passo da ATIVIDADE DE NEGÓCIO, escreva as funcionalidades que satisfaça, podendo representa-las por User Stories ou modelo ARO. Construindo a lista de funcionalidades, podendo organizar(priorizar) verticalmente o que é mais importante.

Essas são as etapas de forma resumida do “PRODUCT BACKLOG BUILDING”. Etapas que compõem o Canvas:

[Identificação > Problemas > Expectativas > Partes Interessadas > Áreas de Negócio > Atividades de Negócio > Funcionalidades]

Product Backlog Building [RESUMO].025 *As três últimas etapas são baseadas no conceito do FBS (Feature Breakdown Structure) do FDD.

 

O fluxo de uma forma linear ajuda a organizar a visão geral do negócio e alinhar o valor de negócio, a compreenção e o que o projeto irá agregar ao final, junto com a ferramenta “Backlog Canvas” que ainda deixa todo o levantamento de requisitos organizado de forma visual.

Product Backlog Building [RESUMO].024

 

Espero que tenham gostado e que seja bastante útil para seus projetos.

 

Product Backlog Building [RESUMO].008

 

 

Referência:

Agile Estimating and Planning – Mike Cohn
Agile Software Requirements (Lean Requirements Practices for Teams, Programs, and the Enterpreise) – Dean Leffingwell
User Stories Applied: For Agile Software Development – Mike Cohn
Discover to Deliver (Agile Product Planning and Analysis) – Ellen Gottesdiener and Mary Gorman
Succeeding with Agile – Mike Cohn
Anúncios

4 comentários sobre “Product Backlog Building

  1. Pingback: Os 5 posts mais lidos do ano | Blog do Tá safo!

  2. Show de bola! Mas estou com uma dúvida, o PBB substituí o Product Backlog Tradicional (feito em excel ou em uma ferramenta)? Outra dúvida é, o Sprint Backlog poderia sem em Canvas também? Você tem algum exemplo?

    Curtir

O que tu achas?

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s