Um product backlog eficiente é aquele bem priorizado, que não só torna o planejamento mais fácil, como também contempla os esforços no que se refere ao tempo de consumo e à descrição dos trabalhos internos que entregarão valor ao cliente. Com essas definições, torna-se possível gerenciar melhor as expectativas das partes interessadas e o empenho das equipes, especialmente quando o time está mobilizado na geração de valor agregado em cada uma de suas demandas.

O product backlog contém basicamente uma lista com todos os requisitos em questão, classificados ordenada e atreladamente a outras características que facilitam o planejamento e a devida priorização. Quer entender melhor? Então acompanhe os tópicos seguintes:

Criando a eficiência

Antes de mais nada, é importante dizer que o product backlog é o cerne do Scrum, basicamente onde tudo começa. Consiste em uma lista de requisitos (também conhecidos como estórias) que descrevem tudo aquilo que o cliente deseja com base em suas próprias palavras, sendo responsabilidade do Product Owner definir esse documento. Essas estórias (ou itens do backlog) devem incluir primordialmente os seguintes campos:

ID

Traduz-se como uma identificação exclusiva, um número sequencial, responsável por evitar que se perca o controle sobre as estórias quando os nomes sofrem algum tipo de alteração.

Nome

É importante atribuir um nome curto e descritivo. “Exibir o histórico das operações”, por exemplo. O segredo está em pensar em uma descrição suficientemente clara para que os desenvolvedores e o Product Owner compreendam, sem risco de mal-entendidos, do que se trata. Usar de 2 a 10 palavras é um bom parâmetro a ser usado.

Grau de importância

O grau de importância se refere à pontuação dessa estória para o Product Owner. A lógica é simples: quanto mais pontos, mais importante é a estória. É bom tentar evitar o uso da classificação prioridade, pois uma prioridade 1 é comumente interpretada como prioridade mais alta, por exemplo. E não soaria bem se, mais tarde, surgisse a necessidade de atribuir ainda mais importância a um outro determinado item de backlog. Nesse caso, qual pontuação de prioridade esse item deveria receber? Prioridade 0, -1? Para evitar essa confusão, recomenda-se a classificação por grau de importância.

Estimativa inicial

Trata-se das estimativas da equipe em relação ao tempo que será necessário para implementar uma determinada estória em comparação com as demais. A unidade utilizada é pontos por estória e normalmente diz respeito à relação ideal entre homem por dia.

Descrição

Esse campo se refere à descrição cuidadosa sobre como a estória será́ demonstrada na apresentação do sprint. É um passo a passo.

Notas

Nesse campo devem constar quaisquer outras informações, explicações, referências ou pequenas anotações que sejam interessantes deixar claro a respeito da estória.

Organizando o backlog

A organização do product backlog pode ser feita por meio do Excel ou por ferramentas de gerenciamento de projetos ágeis. Formalmente falando, o Product Owner é o responsável pelo documento. Mas os demais usuários não devem ficar de fora, afinal, um desenvolvedor pode sentir a necessidade de acessar o documento para esclarecer algo ou alterar uma estimativa, por exemplo.

Tendo em vista essa característica, o ideal é que o product backlog não seja arquivado em um repositório de controle de versões, mas sim compartilhado em um drive na rede ou em uma ferramenta online própria para a gestão de projetos. Essa é uma forma extremamente simples de viabilizar múltiplos acessos e edições simultâneas sem causar conflitos.

Mantendo a saúde

Uma vez que o product backlog foi elaborado, é importante monitorá-lo regularmente para garantir o cumprimento do cronograma. Para isso, o Product Owner precisa, antes de cada reunião de planejamento, consultar se existem atrasos, de forma a assegurar a priorização correta e fornecer os devidos feedbacks sobre as últimas estórias incorporadas. Caso o atraso se torne maior do que o tolerado, esse profissional deve agrupá-lo em itens de curto prazo e de longo prazo. Os itens de curto prazo devem ser plenamente finalizados assim que forem organizados. Já os itens de longo prazo podem contar com uma certa latência, intervalo que deverá ser utilizado para a determinar a priorização.

O product backlog serve de conexão entre o Product Owner e a equipe de desenvolvimento, detendo a liberdade necessária para retornar à lista de estórias sempre que preciso para priorizar o trabalho no backlog (seja devido ao feedback dos clientes, ao refinamento das estimativas ou mesmo a novas exigências). Contudo, uma vez que o trabalho está em andamento, deve haver o máximo de esforço para intervir o mínimo possível, de forma a não prejudicar a equipe de desenvolvimento em seu foco, seu fluxo e sua motivação.

Garantindo a agilidade

É bem comum que as partes interessadas desafiem as prioridades definidas. E isso é bom, uma vez que promover o debate em torno do que realmente é importante, equilibrando o que é considerado iminente entre todos os envolvidos. Esses diálogos fomentam uma cultura de priorização de grupo, assegurando que todos compartilhem da mesma mentalidade sobre o programa.

O product backlog também deve servir como um instrumento para o planejamento das iterações. Para tanto, todos os itens de escopo devem ser incluídos no backlog: estórias de usuários, erros, alterações de design, dúvidas técnicas, pedidos de clientes e assim por diante. Isso assegurará que os itens de trabalho estejam presentes na discussão global para cada iteração. Dessa forma, os membros da equipe podem, então, fazer as solicitações ao Product Owner antes de começar uma iteração, tendo o conhecimento completo de tudo o que deve ser feito.

A gestão do product backlog não deve se concentrar apenas na finalização das estórias, mas sim na própria forma de gerenciar! Esse é o ponto em questão. Assim, a organização deve estar constantemente analisando os incidentes, tudo para se antecipar a um eventual problema. Por isso se vê a importância de estudar as tendências, valer-se de métricas de acompanhamento e monitorar os status das iterações. Só assim a empresa terá condições de identificar a necessidade de intervenção e, mais do que isso, gozará de tempo suficiente para eliminar o ofensor.

E então, ficou ainda com alguma dúvida sobre o assunto? Quer saber mais? Pois aproveite para assinar nossa newsletter e ficar a par das novidades!