Nos grupos de discussão de gestão de produtos dos quais eu participo, muitas pessoas compartilham suas dores a respeito da comunicação entre times de negócios e tecnologia em dois pontos centrais: o primeiro deles se refere à falta de clareza dos requisitos de negócio; o segundo é sobre a dificuldade de transmissão desses requisitos para times de desenvolvimento por meio de User Stories.
O primeiro depende da colaboração entre Product Manager e Stakeholders para o entendimento das necessidades do negócio, e isso realmente pode ser um problema às vezes, não porque os Stakeholders não querem ajudar, mas pode ser que eles estejam tão presos às suas rotinas operacionais que criem silos (recomendo a leitura do artigo sobre zumbificação de times).
Para lidar com esse primeiro problema, se faz necessário entender bem o fluxo informacional entre agentes da organização, boas práticas incluem documentações com mapas de processos com o uso de ferramentas visuais como BPMN, Value Stream Mapping, Blueprint de Serviços, Mapas da Jornada do Cliente, Diagramas do Modelo Mental e outras. Vale a pena conferir o livro Mapeamento de Experiências, de Jim Kalbach.
Já o segundo ponto é sobre a clareza dos requisitos transmitidos pelas User Stories. No próprio Product Oversee nós temos artigos que apontam formas de escrita para User Stories; no entanto, neste artigo iremos um pouco além disso e vamos nos aprofundar oferecendo templates e tipologias para Product Backlog Items (PBIs). Ao longo deste artigo eu irei compartilhar algumas práticas que se baseiam em vários materiais sobre o assunto e conversas com agile masters de várias empresas pelas quais passei. Eu mesmo já utilizei essas práticas e posso dizer que elas trouxeram bons ganhos em termos de eficiência interna do time.
Tipificando os PBIs para gerenciar o Backlog
De acordo com o livro Scrum: A Arte de Fazer o Dobro do Trabalho na Metade do Tempo, de Jeff Sutherland, o Product Backlog é definido como uma lista dinâmica e priorizada de todas as funcionalidades, melhorias, correções e itens de trabalho necessários para desenvolver um produto. Trata-se de um artefato ágil que ajuda a capturar e gerenciar os requisitos em constante evolução de um produto. Dito isso, lidamos frequentemente com duas dimensões do backlog: o backlog do produto e o backlog da Sprint.
O backlog do produto consiste basicamente na sistematização de todas as funcionalidades e dependências que foram pensadas para fazer parte do produto. Já o Backlog da Sprint se refere à lista de requisitos que foram pensados para ser desenvolvidos naquela Sprint.
O backlog da sprint é configurado de acordo com a ideia de incremento e do objetivo da Sprint. É interessante que essa ideia de incremento tenha passado por algum racional de priorização; para isso, podem ser usadas ferramentas como Matriz RICE, MoSCoW, Valor X Esforço, Matriz CSD e outras. Não irei falar aqui sobre elas porque há um vasto material sobre isso na internet e em livros. Passemos para a parte de confecção de artefatos ágeis então.
