Product Backlog: o ponto de partida

O Product Backlog é o ponto de partida do Scrum. Basicamente, ele é uma lista onde todos os requisitos do produto estão ordenados de acordo com sua prioridade. Uma maneira interessante de construir o Product Backlog, é fazê-lo utilizando o ponto de vista do cliente, como se fosse uma User Story do Extreme Programming.

A regra mais importante aqui é ignorar os detalhes. Enquanto conversa com o cliente, mantenha seu foco no negócio. O que é preciso ser feito para resolver o problema em questão? A emissão de um bilhete, a autorização de uma venda, O registro de um atendimento.

Sabemos que os detalhes podem fazer aquela diferença entre o sucesso e o fracasso. Por isso somos loucos por detalhes: que vendedores têm permissão para liberar o desconto de 7,5%? Em que situações o atendente deve repassar os chamados para o setor B? Como o horário de verão influi na compra de uma passagem para Toronto durante o solstício? Nesse momento, isso simplesmente não importa. Concentre-se nos problemas mais importantes, e deixe o resto para depois.

Não se preocupe em prever todos os casos e fluxos alternativos nesse momento. Apenas escreva o que se deve fazer por enquanto. Daqui a duas ou três semanas, quando você tiver o primeiro demo do seu programa, use-o. Veja se funciona e o que é preciso aperfeiçoar. Os detalhes se revelarão nesse momento. É como andar numa estrada, você saberá que buracos tapar porque será neles que você sempre cairá.

Quase me cansei da atitude “entre nos detalhes imediatamente” depois de tomar algumas aulas de desenho. Se começar a desenhar os detalhes imediatamente pode ter certeza que o desenho será uma droga. De fato, você está perdendo completamente o ponto.

Você deve começar pegando as proporções corretas da cena toda. Então rascunha os grandes objetos na sua cena, indo até os menores. O rascunho deve ser bem vago nesse ponto. Então pode proceder sombreando, o que consiste em dar volume à vida. Você começa com apenas três tons (claro, médio, escuro). Isso dá um rascunho de tons. Então, para cada porção do seu desenho reavalia três tons e os aplica. Faça isso até os volumes aparecerem (requer múltiplas iterações)…

Funciona do grande para o pequeno. Sempre.

Patrick Lafleur, Getting Real: Ignore details early on

Usando uma User Story

Uma User Story pode ser a melhor ferramenta para essa fase do Scrum. Ele vai lhe ajudar a ter a mesma visão do cliente. Ao escrever uma User Story, todos os itens devem ser descritos com a terminologia do cliente, evitando o uso do jargão técnico. Por exemplo, ao invés de descrever um item como “Criar uma classe que implemente o login na aplicação e trate as exceções”, escreve apenas “O usuário deve se autenticar no sistema”.

Alguns autores preferem tabular suas User Stories, por exemplo, usando os seguintes campos:

ID – Apenas um número auto-incremental para referir-se a User Story. Pode servir para manter a trilha da história se precisarmos renomeá-la.

Nome - Um nome curto e auto-descritivo. Deve ser entendido facilmente pelos Product Owner e pelo restante do time. Também deve ser claro o suficiente para não ser confundido com outras User Stories.

Importância - O nível de importância que o Product Owner atribui a essa User Story. Por exemplo: 10. Use números maiores para representar importância maior. É comum o erro de usar o zero para a prioridade mais alta, mas e quando descobrimos que existe algo mais prioritário que a User Story marcada com zero? Teríamos uma prioridade -1?

Estimativa de tempo – É a estimativa inicial que o Scrum Team calcula para completar essa User Story. Geralmente é medida em homens/hora. Não há mágica aqui. Apenas pergunte ao Scrum Team: se vocês tivesses o ambiente ideal (com pessoas e equipamentos a disposição), quanto tempo demorariam para terminar isso? A resposta poderia ser: se fósseos 3, terminaríamos em 4 dias. Isso daria 12 homens/hora.

Como demonstrar – Uma serie de passos para ser seguido no dia da demonstração do demo de um Sprint. Algo como: faça isso, depois faça aquilo, e isso deveria acontecer. Pode ser usado mais tarde como um protótipo de um teste de aceitação.

Notas - Qualquer outra informação adicional. Mas não se esqueça de ser breve.

A User Story pode ser completada mais tarde com outros campos. O importante é não acrescê-la de coisas desnecessárias nessa fase. Talvez mesmo alguns campos que foram sugeridos acima possam ser deixados para um preenchimento futuro, ou adaptados a sua própria realidade.