Skip to content

O Backlog do Produto é uma lista ordenada de todo trabalho a ser feito para construir ou manter um produto de software. Conhecido também como Backlog, Feature List, Backlog Priorizado, ou Itens de Trabalho, dependendo da metodologia ágil utilizada, é uma ferramente essencial para alinhar a execução do desenvolvimento com as expectativas do cliente e as metas do projeto.

A Gestão de Backlog refere-se ao processo de gerenciar e organizar essa lista de tarefas e funcionalidades prioritárias. Como analista, você deve garantir que as informações do Backlog estejam claras, priorizadas e prontas para serem trabalhadas pela equipe de desenvolvimento.

Na DB1, o Scrum é a metodologia mais utilizada, então, se estiver trabalhando com Scrum, é importante compreender os conceitos:

  • O Backlog do Produto é uma lista que reúne todos os requisitos necessários para o produto final do projeto, que pode conter funcionalidades, melhorias e correções. Ao longo do processo, o Backlog pode mudar e crescer conforme se aprende mais sobre o produto e seus usuários.
  • O Backlog da Sprint é uma lista de atividades priorizadas a partir do Backlog do Produto, que serão realizadas em uma Sprint específica. Essa lista é elaborada conforme as prioridades definidas nos Refinamentos e no Planejamento da Sprint.
  • O Incremento é a soma de todos os itens do Backlog do Produto completados durante uma Sprint. É como a versão "melhorada" do software após cada Sprint, ou seja algo novo e funcional que podemos entregar e apresentar para todos.

Estrutura do Backlog.

No gerenciamento de backlog, diversas ferramentas podem auxiliar na organização e acompanhamento de projetos. Essas plataformas geralmente oferecem recursos que possibilitam a categorização em diferentes Tipos de Itens de Trabalho (WITs) que variam conforme a metodologia e o processo de trabalho configurado.

A hierarquia desses itens, bem como o tempo de desenvolvimento também pode variar de acordo com o contexto e complexidade do projeto. Aqui estão algumas das principais categorias e suas definições:

  • Initiative (Iniciativa ou Projeto): representa um esforço ou conjunto de atividades mais amplo, muitas vezes associado a metas estratégicas de alto nível (OKRs organizacionais).

  • Epic (Épico): refere-se a uma história grande, tema de alto nível ou um grande marco, que pode ser dividido em histórias menores e mais gerenciáveis. É frequentemente associado a objetivos estratégicos.

    • Feature (Recurso): refere-se a uma funcionalidade ou capacidade específica que agrega valor ao produto. Pode ser associado a um Épico.
    • Story (História): corresponde a uma funcionalidade ou requisito específico descrito do ponto de vista do usuário e que pode ser implementado em uma única sprint ou ciclo de desenvolvimento curto. Geralmente associada a um Épico ou Feature.
    • Product Backlog Item (Item do Backlog do Produto - PBI): representa um item no backlog do produto que pode incluir requisitos, melhorias ou qualquer trabalho planejado para o produto.
    • Requirement (Requisito): refere-se a um requisito específico que deve ser atendido para satisfazer as necessidades do usuário ou do sistema.
  • Bug (Erro): refere-se a problemas identificados durante o desenvolvimento ou testes que precisam ser corrigidos para garantir a qualidade do software. Bugs podem ser categorizados de acordo com suas características, abrangendo funcionalidades quebradas, erros lógicos, problemas de desempenho, segurança, usabilidade, entre outros.

  • Subtask (Subtarefa) ou Task (tarefa): geralmente, representa o nível mais granular ao qual um Item Backlog ou História pode ser decomposto. Essa categoria engloba tarefas menores ou subtarefas que contribuem para a conclusão de uma necessidade mais ampla. Cada subtarefa representa uma ação específica e o conjunto de subtarefas visa resolver uma História, Bug, Feature ou Requirement específico.

Essas categorias são comumente utilizadas e proporcionam uma estrutura hierárquica que permite a organização clara e eficiente das atividades. No entanto, em alguns contextos, pode ser necessário incluir outras categorias e itens, como: Dívida Técnica, Pesquisa, Protótipos, Melhoria, Tarefa Técnica, entre outras. A flexibilidade na definição de categorias adicionais contribui para uma gestão mais abrangente e adaptável do backlog.

Além do Jira e do Azure DevOps (VSTS) exemplificados acima, outras ferramentas de task manager também podem ser utilizadas como o Trello, TFS, Basecamp, Asana etc. A escolha da ferramenta dependerá das necessidades do projeto, preferências da equipe e complexidade das tarefas a serem gerenciadas.

Definindo o Backlog.

O backlog do produto pode ter diversas origens, seja a partir de um processo de descoberta, uma lista de melhorias e correções, dinâmicas de ideação para a evolução ou mesmo devido a mudanças externas, como alterações na legislação. Independentemente da sua origem a aplicação do framework INVEST é recomendada:

INVEST é um acrônimo para guiar a criação de histórias de usuário (ou itens de backlog) de maneira eficaz. Proposto por Bill Wake, cada letra representa um critério importante:

  • Independente: cada história deve ser independente, permitindo que seja desenvolvida e entregue de forma isolada.
  • Negociável: histórias devem ser negociáveis, adaptando-se a mudanças ao longo do tempo.
  • Valiosa: cada história deve agregar valor ao usuário ou cliente.
  • Estimável: a história deve fornecer informações suficientes para uma estimativa de alto nível.
  • Sob medida: histórias devem ser pequenas o suficiente para serem concluídas em um curto período, geralmente um ciclo de desenvolvimento.
  • Testável: deve ser clara o suficiente para que testes sejam executados a partir dos critérios de aceitação.

Priorização e ordenação

Na gestão do backlog, além da criação inteligente dos itens, é fundamental estabelecer um processo eficiente de priorização e ordenação. O backlog deve ser priorizado de forma que sempre maximize o valor entregue ao usuário final. Dessa forma, os itens mais prioritários ocuparão as posições superiores da lista de desenvolvimento, garantindo sua inclusão nos próximos ciclos. Esta prática assegura que a equipe se concentre inicialmente nos elementos que geram maior impacto e retorno.

Um backlog organizado é mais fácil de gerenciar e rastrear, então durante o processo você deve:

  • Criar e descrever itens no backlog: inclua e detalhe os itens do backlog que estão no topo da lista, definindo critérios de aceitação em colaboração com o time e stakeholders. Novos detalhes devem ser adicionados até que o item esteja claro o suficiente para ser desenvolvido. Falaremos mais sobre esse detalhamento no tópico sobre documentação.
  • Manter a priorização dinâmica: altere a ordem dos itens conforme a necessidade dos usuários e do negócio, você pode utilizar técnicas como Matriz de Valor x Esforço, Buy a Feature Game, MoSCoW, etc.

  • Quebrar itens para facilitar desenvolvimento: considere a divisão de itens complexos em unidades menores para viabilizar o desenvolvimento em ciclos curtos, garantindo que cada requisito seja estimado considerando a implementação.
  • Remover obsoletos e adicionar novos itens: mantenha o backlog relevante removendo itens obsoletos ou já atendidos, e adicione novos itens quando surgirem novas necessidades.
  • Rastreabilidade requisitos e artefatos: estabeleça uma relação de rastreamento entre requisitos e os artefatos de design, arquitetura e desenvolvimento, garantindo que cada requisito seja implementado e testado adequadamente.
  • Gerenciar mudanças nos requisitos: desenvolva um processo para lidar com mudanças nos requisitos ao longo do projeto, avaliando o impacto, riscos e comunicando alterações relevantes aos stakeholders.
  • Validar a funcionalidade desenvolvida: realize a aprovação da funcionalidade desenvolvida de acordo com os critérios de aceitação, apontando pontos que não foram desenvolvidos em acordo com o especificado no requisito.
  • Acompanhar a entrega e uso da solução: acompanhe a entrega da solução aos clientes/usuários, avaliando o real impacto e melhorias no negócio. Isso permite ajustes contínuos conforme o contexto e as necessidades mudam.

Todas essas atividades fazem parte da Gestão de Backlog e são executadas continuamente de acordo com a execução do projeto.

O refinamento do Backlog do Produto é o ato de dividir e definir ainda mais os itens do Backlog do Produto em itens menores e mais precisos. Esta é uma atividade contínua para adicionar detalhes, como descrição, ordem e tamanho.

Conceito de refinamento do backlog - Scrum Guide

Métricas de gestão de backlog

As principais métricas para saúde do backlog são aquelas que permitem avaliar a qualidade, o estado e o progresso do backlog. Através das métricas, é possível identificar processos que precisam de melhorias e tomar medidas para corrigi-los. Isso ajudará a garantir que o backlog esteja saudável e que o produto esteja sendo desenvolvido de acordo com as necessidades dos usuários e do negócio.

É importante que as métricas sejam escolhidas de acordo com as necessidades específicas do projeto. As métricas mais comuns e utilizadas incluem:

  • Lead Time (Tempo de Execução): o Lead Time representa o intervalo total necessário para concluir uma tarefa, desde sua criação e inclusão no backlog até a entrega final. Este indicador é fundamental para compreender a eficiência do fluxo de trabalho, fornecendo uma visão abrangente do tempo médio de entrega de ponta a ponta. Através dos dados de Lead Time, é possível identificar se os prazos das atividades estão alinhados com as projeções, e caso contrário, elaborar planos de ação para otimização.
  • Cycle Time (Tempo de Ciclo): o Cycle Time é o tempo médio de entrega de uma fração específica do fluxo de trabalho. Diferentemente do Lead Time, o Cycle Time abrange o período desde quando uma atividade é considerada "em progresso" até o momento em que ela atinge seu estado final e concentra-se no tempo efetivo de desenvolvimento, excluindo períodos de espera. Esta métrica permite uma análise mais detalhada do tempo efetivamente dedicado à execução de uma tarefa.
  • Customer Lead Time (Tempo de Atendimento ao Cliente): Este indicador mede o tempo decorrido desde o momento em que identificamos minimamente a necessidade, geralmente do cliente, até a entrega final. A contagem do Customer Lead Time inicia no estágio de descoberta (ou Upstream), quando há alguma clareza (ou suspeita) sobre o item que decidimos implementar. Essa métrica é importante para compreender e melhorar o processo de atendimento ao cliente.

  • Throughput (Taxa de Produção): é uma métrica que demonstra a quantidade de atividades entregues em um determinado período de tempo (semana, mês). Com essa métrica, podemos mensurar a quantidade de trabalho que poderá ser entregue pelo time. Uma taxa de conclusão baixa pode indicar que o backlog está crescendo mais rápido do que está sendo concluído, o que pode levar a atrasos no projeto.
  • Backlog Grooming Effort (Esforço de Refinamento do Backlog): avalia o tempo e os recursos dedicados ao refinamento contínuo do backlog. Uma boa prática para manter os itens do backlog prontos para implementação.
  • Percentual de Itens Prontos (Ready Items Percentage): essa métrica indica a proporção de itens do backlog que estão prontos para serem desenvolvidos. Itens bem refinados e prontos ajudam a manter um fluxo de trabalho mais eficiente. Um backlog com poucos itens prontos pode indicar que o processo de planejamento não está sendo eficaz ou que o backlog está desorganizado.
  • Backlog Age (Idade do Backlog): embora não seja uma métrica padrão, você pode considerar medir quanto tempo um item permanece no backlog antes de ser priorizado ou desenvolvido. Isso pode destacar itens que podem estar ficando obsoletos ou esquecidos. Um backlog com itens muito antigos pode indicar que o processo de priorização não está sendo eficaz.
  • CFD (Cumulative Flow Diagram): É uma ferramenta que permite visualizar o fluxo de trabalho através dos status das atividades (backlog, aguardando desenvolvimento, em desenvolvimento, bloqueado, aguardando revisão de código etc.). Através do CFD é possível identificar problemas que possam estar ocorrendo no time, como gargalos ou impedimentos.
  • Velocity (Velocidade): mede a quantidade de trabalho que uma equipe pode completar em uma única iteração (normalmente uma sprint). A velocidade ajuda na previsão de entregas futuras.
  • Percentual de Cumprimento de Critérios de Aceitação: avalia a conformidade das histórias desenvolvidas com os critérios de aceitação definidos. Através desta métrica é possível avaliar a qualidade do trabalho e alinhamento entre o solicitado e o que foi efetivamente desenvolvido.
  • Taxa de Bug pós-Liberação: calcula a porcentagem de problemas identificados após a liberação do produto. Uma alta taxa pode indicar problemas de qualidade da análise ou do desenvolvimento.
  • Taxa de Aceitação de Histórias (Story Acceptance Rate): representa a porcentagem de histórias que foram aceitas após a revisão pelos stakeholders. Indica a eficácia na entrega de funcionalidades desejadas.

Ferramentas de visão

Ferramentas de gestão ágil, como Jira Agile ou Azure DevOps, oferecem dashboards com métricas e diversas formas para visualização do backlog. A prática da gestão à vista é valiosa para manter transparência e um entendimento claro da situação do projeto, incluindo o backlog. Três ferramentas úteis para a gestão à vista do backlog são:

  • Roadmap: é uma representação visual e estratégica que descreve as principais etapas, marcos, metas e direção de um projeto, produto ou iniciativa ao longo do tempo. Ele fornece uma visão geral das prioridades e da sequência de atividades planejadas, ajudando a equipe a alinhar esforços e stakeholders a entenderem o progresso.

Fonte: Tutoriais para planejamento no Jira

User Story Mapping (Mapeamento de Histórias de Usuário): é uma técnica que visualiza as histórias de usuário em um mapa, organizando-as de acordo com as necessidades dos usuários e as funcionalidades do sistema.

Fonte: User story mapping: o que é e como aplicar

  • EAP (Estrutura Analítica do Projeto): é uma ferramenta visual que desmembra o projeto em partes menores, oferecendo uma visão hierárquica e estruturada das tarefas envolvidas.

Fonte: Modelo EAP para projetos - template editável no Miro

Cada uma dessas visões pode ser escolhida com base nas necessidades específicas do projeto. A apresentação do backlog por meio dessas técnicas facilita a compreensão e ajuda na comunicação eficaz com as partes interessadas.