Como podemos definir um bom backlog?

img_1079

Um Backlog é um ativo importante para qualquer equipe Agile. Torna-se ainda mais importante para uma empresa que entenda o valor que dele pode retirar. Desde requisitos bem organizados, com qualidade, transparencia sobre o produto e o seu estado do produto, um meio de actualizacao para toda a equipa e empresa. Estes sao os maiores outputs que se retiram de um backlog de qualidade.

Um Backlog pode ser definido como uma lista de requisitos que, dependendo da proximidade à estratégia ou à implementação. Pode ser escrito em sagas, epics, stories ou tasks (o requisito mais granular para a implementação).

Um Backlog deve ser independente no sentido em que a equipe de desenvolvimento, o Product Owner, o Scrum Master devem ser totalmente livres para o organizar. Com base nele, criam um entendimento comum sobre o produto, as stories, sua prioridade e contribuicao para o produto.




Mas se estamos numa organização de produtos interdependentes, como pode um backlog ser independente?

Sim! Pode ser independente no sentido em que permita à equipe de desenvolvimento, produzir valor em cada Sprint. Aceitando para implementacao as stories que cumpram a Definition of Ready (DoR). Assim sendo, o Backlog é independente respondendo a questoes de como implementar, mas é dependente no sentido  em que contribui para a realização dos requisitos de um nível superior, orientados para a concretizacao da visão estratégica da empresa.

Negociável & estimado

Um backlog deve ser negociável e para tal, deve ter sido anteriormente estimado. Toda a equipe deve conhecer as dependências para a implementacao, a contribuição individual, para o produto, de cada Epic, Funcionalidade e Story.

Viável e realizável

Um backlog deve ser viável e realizável, no sentido em que a equipa de desenvolvimento, mantendo-se estável na sua capacidade, e dentro do periodo de tempo da release, o consegue realizar.

A equipa de desenvolvimento, para entregar o backlog, durante a estimativa de esforco, deve considerar requisitos funcionais, requisitos nao funcionais, legais e de conformidade em vigor na empresa (incluindo qualidade, seguranca, etc). Este conselho está muito relacionado os conceitos e a relacao entre  Minimum Viable Product e Minimum Possible Product.

Testado e compreensível no idioma do cliente

Devem ser incluídas e estimadas tarefas de teste em todos os níveis do backlog. Como parte da Definition of Done, em cada nível de requisitos (saga, epic, funcionalidade, story e task) tarefas de teste e aceitacao devem ser consideradas.

Um backlog deve ser compreensível no idioma do cliente. Assumindo que o Product Owner expressa os desejos do cliente, ele será a voz de esclarecimento de cada story em frente à equipe de desenvolvimento.

A condição prévia para um bom planeamento de Sprint é que o Product Owner deve ter o backlog preparado/pronto e cada story deve cumprir os critérios de aceitacao e cumprir a Defition of Ready para entrar no sprint.

Resumindo as premissas para um backlog de qualidade:

  • Ter conteúdo de alta qualidade escrito em cada nivel de requisitos conhecido no backlog;
  • Refinar regularmente as stories para que o backlog esteja estimado;
  • Ter o backlog organizado por prioridade para, a qualquer momento, se ter conteúdo pronto para entrar em Sprint.




Benefícios de um backlog de alta qualidade

Há evidentes benefícios em ter um baclog com conteúdo de alta qualidade e bem organizado:

  1. Clareza – em torno do que se tem que construir, mapeando cada requisito na imagem global do produto. Um backlog deve dar essa clareza numa perspectiva de 360 graus: para a equipe e fora da equipe. O que queremos, para onde vamos, onde estamos.
  2. Responsabilização – a equipe deve acreditar que é capaz de entregar, e que os processos montados ajudam à entrega do produto e nao constituem impedimentos.
  3. Progresso mensurável- um backlog estimado, respeitando e repetindo todos os ciclos de cerimónias, corresponde a uma forma credivel de medir o progresso:
  • Tamanho do backlog
  • Velocidade
  • Burn-down
  • Bugs nao corrigidos (Escaped Defects)
  • Commit % Ratio
  • Percentagem de stories aceites pelo Product Owner
  • Percentagem de alteracao de requisitos



Deixar uma resposta

Este site utiliza o Akismet para reduzir spam. Fica a saber como são processados os dados dos comentários.