Por que você deveria aprender sobre PBB

Fonte: http://www.productbacklogbuilding.com/

Vale começar este artigo dizendo que eu NÃO SOU DONA DE PRODUTO. Eu já estive no papel de PO (mais imposto do que desejado) e não me reconheço como uma boa PO. Mas me reconheço como uma boa agilista (e eu pensei muito antes de escrever isso, eu ia colocar “regular”, mas daí vocês não iriam ler, rs), e li o livro do Fábio Aguiar e do Paulo Caroli com essa perspectiva: a perspectiva de uma pessoa agilista.

Neste artigo, quero trazer alguns aprendizados que tive com o livro e que podem ser úteis para outras pessoas agilistas e, porque não, para pessoas donas de produto também.

• Fazer a Lean Inception antes do PBB não é obrigatório, até porque pode não fazer sentido, dependendo do escopo/necessidade do time. Mas, quando for feito, a Lean Inception já responde alguns pontos do PBB (personas, problemas, expectativas e funcionalidades). Neste caso, como o PBB vem depois da Lean Inception, pode-se reutilizar o que foi definido.
• Se você está na dúvida sobre qual a relação de PBB e sprints/ciclos de trabalho, basicamente o primeiro PBB acontece após a Lean Inception (caso seja feita) e antes do Sprint 1. O PBB é o momento de refinar o backlog do time.
• E por falar em backlog, este é (ou deveria ser) a única fonte de trabalho do time. Tudo o que o time tem pra fazer deveria estar no backlog, mesmo que nem tudo esteja refinado (ainda). Parece óbvio, mas o que vemos de demanda pastel, que “surgem” no dia a dia, não é brincadeira.
• O autor traz uma proposta de hieraraquia de PBIs ou itens de trabalho que pode ser útil para quem está começando na área: (1) tema, (2) épico/funcionalidade, (3) história de usuário e (4) tarefa (essa última escrita pelos desenvolvedores para os desenvolvedores).
• Ponto importante é que, não necessariamente a pessoa Scrum Master precisa ser sempre a facilitadora do PBB. Inclusive, o autor sugere que seja rotativo, entre as pessoas membro do time (ou seja, a pessoa Scrum Master pode liderar pelo exemplo, mas as pessoas membro do time precisam ser capazes de tocar esse processo, independente da Scrum Master).
• O steps map é uma ferramenta que ajuda a fatiar as funcionalidades em PBIs. Embora possa lembrar a jornada de usuário, não é a mesma coisa. O steps map descreve o passo a passo de uma funcionalidade, enquanto a jornada de usuário descreve as etapas ou passos de um usuário até alcançar seu objetivo.
• O COORG (classificiar, ordenar e organizar) é uma ferramenta que ajuda no sequenciamento e priorização dos PBIs e deve ser periodicamente refeito, tão logo novos PBIs surjam.
• DoR e DoD não são a mesma coisa. Eu mesma me confundia entre quando usar um e quando usar outro. O DoR define se o PBI está preparado para entrar no sprint/ciclo de trabalho do time e o DoD define se um incremento do produto está pronto para ser entregue ao cliente (p.ex. atende os critérios de aceite e mantém o desempenho do produto).
• Ter o refinamento contínuo como prática complementar ao planejamento contínuo, com foco no curto prazo, é uma boa prática para que os times tenham um backlog saudável e atualizado.
• Mas nem só de histórias de usuário um backlog é feito, não é mesmo? É importante que o backlog contenha, também, habilitadores, exploratórios (os famosos spikes) ou técnicos (p.ex. refatorações, melhorias, etc.). Para escrevê-los, o modelo ARO (ação, resultado, objeto) é o mais adequado.
• Os critérios de aceite devem validar a história de usuário e, para isso, cada história deve ter no máximo, 5 critérios. O BDD é uma prática (que inclusive eu gosto muito) para escrita de critérios de aceite que utiliza a perspectiva de desenvolvimento orientado a especificações e é escrito em linguagem natural (não-técnica).
• Por fim, um aprendizado bacana é que existem alternativas ao modelo INVEST (não sei vocês, mas eu tenho dificuldade de usar o INVEST propriamente. Na minha cabeça, nem tudo encaixa). A alternativa mais interessante e aplicável é o TAPAs (tangível, atômica, preciosa e acessível), uma “versão brasileira” do INVEST, criada por Manuel Pimentel (se quiser saber mais sobre o TAPAs, veja este vídeo, clicando aqui)

“Os melhores documentos em métodos ágeis nos ajudam a recordar nossas conversas, e não substitui-las”

Fabio Aguiar

Gostou dos aprendizados? Quer saber mais? Recomendo a leitura do livro Product Backlog Building: Um guia prático para criação e refinamento de backlog para produtos de sucesso, do Fabio Aguiar e do Paulo Caroli.