Last updated on | Metodologia Scrum

Product Backlog – Tudo O Que Você Precisa De Saber

by Luís Gonçalves
Product Backlog

Durante as últimas semanas, ao dar formação a alguns dos meus clientes, foi-me constantemente perguntado o que é o Product Backlog. Para responder às vossas dúvidas contínuas, decidi fazer uma pesquisa mais profunda sobre este tópico e escrever este blog post.

A definição mais simplificada de Product Backlog é: ‘é uma lista de todos os trabalhos que precisam de realizados dentro de um mesmo projeto’. Estes substituem os requisitos tradicionais. Os backlogs são desenhados sob a forma de user stories e podem ser de natureza técnica ou centrados no utilizador. O Product Backlog é propriedade do Product Owner.

Scrum Master, a Equipa Scrum e as outras Partes Interessadas são todos colaboradores. Têm uma lista de coisas-a-fazer vasta e completa.

Um típico Scrum backlog compreende os seguintes itens:

  1. Características/funcionalidades
  2. Bugs
  3. Trabalho técnico
  4. Aquisição de conhecimento

Product Owner usa o Backlog durante a Sprint Planning, para descrever à equipa as entradas principais. A seguir, a equipa determina que itens podem ser concluídos durante o sprint seguinte.

O Product Backlog tem certas propriedades que o diferenciam de uma simples lista de coisas-a-fazer:

  • uma entrada no Product Backlog acrescenta sempre valor para o cliente
  • entradas no Product Backlog são priorizadas e ordenadas de acordo
  • o nível de detalhe da entrada depende da sua posição no log – todas as entradas são estimadas/consideradas
  • é um documento vivo
  • não existem itens de ação ou tarefas de baixo-nível

As user stories são a primeira forma das equipas Scrum expressarem características no Product backlog. As stories são descrições curtas e simples da função desejada, contadas a partir da perspetiva do utilizador. Por exemplo, como comprador, posso avaliar os itens no carrinho de compras para ver o que é que já selecionei, antes de ir para o check out.

Bugs e novas funcionalidades descrevem algo diferente daquilo que o utilizador quer. Porque não há diferença real entre os dois, os bugs também fazem parte do Product backlog.

O trabalho técnico e as atividades de aquisição de conhecimentos também pertencem ao Product Backlog. Um exemplo de trabalho técnico seria uma instrução como: “Fazer o upgrade de todas as estações de trabalho dos developers para o Windows 7″.

Um exemplo de aquisição de conhecimento pode ser um item backlog, sobre pesquisar várias bibliotecas de JavaScript, e escolher uma.

Trabalhar com o Product Backlog

O Product Backlog precisa de atenção e cuidado regulares; precisa de ser gerido de forma cuidadosa. No início, a equipa Scrum e o Product Owner começa um projeto pelo brainstorming e a escrever tudo o que vem à cabeça. Os itens aos quais o proprietário e a equipa chegam devem ser mais do que suficientes para um primeiro sprint.

Manter um bom Product Backlog é um processo contínuo que compreende os seguintes passos:

  • Adicionar e descrever novos itens na lista, à medida que estes forem descobertos
  • Mudar ou remover itens existentes quando for apropriado.
  • Mover entradas de alta prioridade para o topo do backlog, em preparação para a próxima reunião de Sprint Planning.
  • Re-estimar as entradas

Embora isto seja um processo colaborativo, o Product Owner é responsável por garantir que o Product Backlog está em boa condições e a funcionar. Quando estiver a usar a Scrum Framework, cerca de 10% do tempo total deve ser reservado para manter o Product Backlog.

A manutenção colaborativa do Product Backlog ajuda a clarificar os requisitos, criar um buy-in da Equipa Scrum.

Armadilhas Comuns

  • O backlog é muitas vezes confundido com o documento de requisitos.
  • Não há nenhum formato obrigatório para representar o backlog: pode ser um documento Excel, um ficheiro de texto, base de dados, uma coleção de cartas índex ou, o que é mais comum, notas Post-It.
  • Criar um backlog em forma física aumenta o risco de criar versões múltiplas e conflituantes; este é um erro terrível porque o blacklog é uma fonte credível do trabalho a ser realizado.
  • Itens do backlog são atómicos em oposição aos documentos de narrativa, o que significa que uma simples frase pode ter vários requisitos distintos ou, de modo inverso, descrever um requisito em vários parágrafos detalhados. A forma física encoraja esta “atomicidade”.
  • O backlog não deve descrever cada item com o mesmo nível de detalhe ou “granularidade”. Funcionalidades e tarefas que estão planeadas para um futuro próximo devem ser divididas em itens mais específicos e acompanhadas de outros detalhes como testes de aceitação, esboços UI, etc. Itens planeados para um futuro mais distante podem ser descritos a nível mais macroscópico.

10 Dicas para Product Backlogs

Trabalhar com o product backlog pode ser desafiante; muitos Product Owners lutam com backlogs extensos e detalhados. As seguintes dicas podem ajudá-lo a trabalhar com o seu product backlog de forma efetiva:

Dica #1: Complementar o seu Product Backlog com um Product Roadmap

Use Roadmap para esboçar a viagem que quer que o seu produto faça. Indique o próximo grande lançamento com as suas metas ou benefícios, e desenhe o seu product backlog a partir desse roadmap.  Use as metas para descobrir os itens backlog corretos e para garantir que está alinhado com a estratégia de produto. Isso ajuda a decidir os itens que devem ser adicionados ao product backlog e aqueles que não.

Dica #2: Concentre o seu Backlog no seu Próximo Grande Lançamento

Use o product backlog como uma ferramenta tática que indica quais os detalhes do produto – incluindo epics e user stories – que devem ser implementados no próximo grande lançamento. Tal ajuda a criar um backlog conciso, que é fácil de atualizar e modificar.

Dica #3: Começar com Product Backlog Curto e em forma de Esboço

Quando cria um novo produto ou funcionalidade, mantenha os itens de baixa prioridade descritos de forma grosseira. Use o feedback dos clientes e utilizadores para decidir que funcionalidades implementar para desenvolver e refinar os itens do backlog.

Dica #4. Colaborar com a Equipa de Desenvolvimento

Envolver os membros da equipa no trabalho de product backlog. Irá beneficiar dos seus conhecimentos e criatividade enquanto descobre riscos técnicos e dependências. Também aumenta a compreensão e o buy-in dos membros da equipa, resultando em requisitos melhores e mais claros.

Dica #5: Dizer Não

Rejeitar ideias e requisitos que não o ajudam a atingir as metas de lançamento ou a aproximá-lo da visão de produto. Isso garante que o seu produto tenha uma proposta de valor clara, ao mesmo tempo que previne que seja inflacionada.

Dica #6: Ver para além das User Stories

Embora as user stories e requisitos funcionais sejam importantes, normalmente não são o suficiente. Quando cria o backlog, também tem de considerar as interações dos utilizadores e a interface do utilizador.

Dica #7: priorizar o seu Backlog

Usar a incerteza e o risco para decidir quão cedo um item deve ser implementado.  Abordar itens incertos permite-lhe testar as sua ideias. Você pode aprender sobre os fracassos à media que dá continuidade ao seu backlog.

Dica #8: Proactivamente Gerir o seu Product Backlog

Regularmente cuidar e refinar os itens com a equipa de desenvolvimento. Analisar o feedback e os dados recolhidos de expor o último incremento do produto ao utilizador, depois aplicar os novos insights no backlog. Eliminar ou atualizar itens antigos já existentes, enquanto adiciona novos. Tal maximiza as suas chances de construir um produto que os utilizadores realmente queiram. Isto também mantém o product backlog conciso de atualizado.

Dica #9: Ter o Backlog Pronto

Partir os maiores itens em itens mais pequenos ao nivelar os insights adquiridos de expor os incrementos do produto aos seus utilizadores. Assegurar itens de alta prioridade é pois, claro, factual e testável, para que estejam prontos para o planeamento do sprint.

Dica #10: Torne o seu Product Backlog Visível e Facilmente Acessível

Tente pôr um backlog em papel na parede. Este tipo de backlog tem vários benefícios:

  • É claramente visível e cria transparência (na sala da equipa).
  • Pode ver quando o seu backlog estiver a tornar-se demasiado grande porque está a ficar sem espaço na parede.

Espero que esta publicação tenha mostrado bem o que é um Product Backlog. Se esta publicação tiver sido útil, partilhe-a com os seus amigos e colegas.

ORGANISATIONAL MASTERY SCORECARD

Desenvolvi um teste grátis que o vai ajudar a identificar que areas da sua organisação precisam de mais ajuda para alcançar excelência no seu processo de Product Development

Faça O Teste
Luís Gonçalves

About Luís Gonçalves

https://plus.google.com/u/0/+LuisGonçalves1979

Luis Gonçalves is an Entrepreneur, Author & International Keynote Speaker. He works with Senior Executives to implement his ‘Organisational Mastery’ system so they can greatly increase the effectiveness and efficiency of their organisations; enabling them to become recognised and highly rewarded Leaders.

Comments

Share your point of view

X