O Product Backlog

Se tudo tem alta prioridade, nada é prioritário…

No primeiro artigo "Entendendo o Papel do Product Owner" , com base na leitura do livro “Agile Product Management with Scrum”, de Roman Pichlereu, falei um pouco sobre o papel do Product Owner no desenvolvimento de produtos ágeis. Nesse segundo artigo quero escrever um pouco sobre o Product Backlog no desenvolvimento de produtos ágeis.

Poucos artefatos do Scrum são tão populares quanto o Product Backlog. Por um razão: é simples. Uma lista priorizada de itens pendentes, que darão vida ao produto.

Qualidade…

Um bom product backlog tem 4 qualidades:

• Detalhado adequadamente — Quanto maior a prioridade do item, com mais detalhes ele deve ser descrito. "Quanto menor o a prioridade, menor o detalhe, até que você mal possa redigir o item do backlog", descreve Schwaber e Beedle. Essa orientação ajuda a descobrir os requisitos, decompô-los e refina-los no decorrer do projeto.
• Estimado — As estimativas normalmente são feitas de forma superficial usando pontos de histórias ou dias de desenvolvimento. As estimativas mais acuradas são feitas nos planejamentos de sprint juntamento com o time de desenvolvimento. O tamanho do item também é usado como tomada de decisão na priorização do backlog.
• Emergente — O product backlog é vivo. Ele evolui e se transforma com frequência. Itens novos surgem, são modificados, re-priorizados, refinados ou removidos de forma contínua.
• Priorizado — Todos os itens do backlog são priorizados. Sejam com alta, média ou baixa prioridade. Mas todos são priorizados. Um item sem prioridade pode ser removido, porque não é importante.

Ajustando…

Como um jardim que fica desarrumado quando não sofre manutenção, assim se torna o product backlog quando é negligenciado. A atenção e o cuidado empregado ao product backlog é constante. Podemos usar algumas etapas para gerenciar o product backlog:

• Novo itens são descobertos e descritos, e os existentes são alterados ou removidos, conforme a necessidade.
• O product backlog é priorizado. Os itens mais importantes são remanejados para o topo.
• Os itens de alta prioridade são preparados para a próxima reunião de planejamento de sprint, ou seja, são decompostos e refinados.
• A equipe dimensiona os itens do product backlog. A inclusão de novos itens, a mudança dos existentes e as estimativas corretas tornam o dimensionamento necessário.

Mesmo sendo de responsabilidade do Product Owner ou Product Manager a boa organização do product backlog, o ideal é que a arrumação seja um processo colaborativo. Juntamente com time, os itens são descobertos e descritos, priorizados, decompostos e refinados. O Scrum aloca 10% do tempo disponível do time para arrumação do product backlog.

Um product backlog bem-arrumado é um pré-requisito para uma reunião de planejamento de sprint bem-sucedida.

Descobrindo…

Os requisitos não são mais congelados no início, mas são descobertos e detalhados no decorrer da vida do produto. Conforme vamos aprendendo e entendendo as necessidades do cliente, os requisitos existentes provavelmente mudarão, ou se tornarão redundantes e novos surgirão.

Tente não pensar em todos os itens possíveis, para estocar em seu backlog. Sempre tente focar nas funcionalidades minimas necessárias para dar vida ao produto, e lute pela simplicidade. Para direciona-lo use a ideia ou a visão do produto como bussola para seus esforços.

Sempre que uma funcionalidade for sugerida pergunte por que essa funcionalidade é necessária e como ela beneficiará o cliente. Não cometa o erro de simplesmente copiar e colar o itens sugeridos em seu product backlog. Isso tornará seu backlog em uma lista de desejos inconsistente e intratável.

Conforme entendemos e aprendemos as necessidades de nosso clientes, e mercados e tecnologias mudam, adquirimos mais conhecimentos e formas de como atender melhor as necessidades de nossos clientes.

Priorizando…

É imprescindível decidir sobre a importância de um item. Se tudo estiver com alta prioridade, tudo é igualmente importante. E isso, significa que nada é prioridade. E com certeza, à uma grande probabilidade de não atendermos as necessidades reais do cliente.

Eu escrevi um artigo mais detalhado sobre "Como Priorizar Backlog de Produto?".

Erros…

• Lista de desejos — é como uma lista de desejos de criança para o Papai Noel contém toda e qualquer coisa que acharmos ser necessário. Essa backlog não é mais uma fila de trabalho pendente, é um banco de dados de requisitos. Que dificulta a priorização e limita a capacidade do produto de evoluir com base no feedback de clientes.
• Empurrar requisitos — o product owner ou product manager escreve os itens do backlog sozinho e empurra para o time de desenvolvimento no planejamento da sprint. Isso reforça os sentimentos castas, time de produto e time de desenvolvimento. O Manifesto Ágil prega a colaboração — "O pessoal de negócios e os desenvolvedores precisam trabalhar juntos diariamente no decorrer do projeto".
• Negligência na arrumação — Quando o não está arrumado antes da reunião de planejamento da sprint, essa atividades e executada durante a reunião e consome tempo e resulta em requisitos pobres e pouco comprometimento.

Deixem seus comentários, quero aprender mais…Grande abraço!!!