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.
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:
Identificação
Comece batizando o produto a ser desenvolvido.
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.
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.
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.
Á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.
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).
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:
- Elaboração de um Product Backlog Efetivo
- Slideshare do Fábio Aguiar
- No YouTube temos o Fábio Aguiar explicando sobre o PBB
Obrigado pelo conteudo excelente e bem organizado. Parabens!!!