Scrum é um framework 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 com iterações de 1 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:
Como chegar ao Backlog?
Como construir algo que tenha valor?
Como encontrar a real necessidade do cliente?
Como definir o que é prioridade para o cliente no primeiro momento?
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 uma forma compartilhada, construindo um entendimento compartilhado, levando todos os envolvidos ao entendimento colaborativo do domínio do negócio, ou seja, todos compreenderem o contexto do negócio.
A dinâmica do PBB consiste em vivenciar na prática a 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.
Principais benefícios:
- Ajudar na construção de um BACKLOG de um forma efetiva e colaborativa.
- Construir um entendimento compartilhado do negócio do cliente, facilitando a descoberta e compreensão do produto.
- Buscar uma maneira de descrever a experiência do usuário com o produto.
- Facilitar a descoberta e escrita de User Stories.
PBB é representado por um canvas chamado de 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.
Veja abaixo o fluxo de construção do Backlog:
IDENTIFICAÇÃO: A primeira etapa é identificar o 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, seus problemas e dores, necessidades e objetivos.
ÁREAS DE NEGÓCIO: A partir desse momento, identificado as PARTES INTERESSADAS, identifique as suas ÁREAS DE NEGÓCIOS e os principais objetivos de negócio das partes interessadas de cada área.
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” da parte interessada relacionada a essa atividade de negócio.
FUNCIONALIDADES: Finalizando as etapas, para cada passo da ATIVIDADE DE NEGÓCIO, escreva as funcionalidades que satisfaça, podendo representá-las por User Stories ou modelo ARO (<AÇÃO><RESULTADO><OBJETO>). 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]
*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 compreensã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.
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ória 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 uma funcionalidade.
A estrutura 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 Parte Interessada, o “O QUE?” que nesse caso são as funcionalidades já representadas em modelo ARO e por último, o “POR QUÊ?” que está no objetivo e benefício que a parte interessada destacou na atividade de negócio. 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.
Pronto! todas as funcionalidades descobertas representarão os itens do Backlog. Agora é só priorizar o Backlog usando quaisquer técnica de priorização e começar entrar…
__________________________________________________________________________________________________________________
Gostou? Fique ligado no nosso blog que logo logo tem mais!
Não esqueça de deixar seu comentário 😉
Facebook | Twitter | Linkedin | Youtube
Bem explicado, ficou muito bom!
Olá.
Muito interessante o artigo! Todo este processo é bem identificado com Análise de Negócios.
Muito bom. Já fiz um experimento e clareou as idéias aqui. Valeu.
Eu gosto muito dos canvas porque eles são quadros vivos e nunca devem ser escritos a caneta ou a lápis.
Olá,
O link do PDF do Canvas não está funcionando. Alguém consegue me enviar?
[email protected]