Criação de um Backlog

O backlog de um produto é uma lista organizada de itens de trabalho específicos de um projeto, seja ele pequeno ou grande, que são candidatos à implementação. Com o uso da terminologia Scrum, esses itens são chamados de histórias de usuários (user stories). O Pega Express™ também utiliza o termo “épicos” (epics) para denotar agrupamentos de histórias de usuários. 

As histórias de usuários e os épicos cobrem uma ampla variedade de tipos de trabalho, como:

• Ideias para novos recursos ou otimizações
• Problemas do aplicativo que exijam atenção
• Trabalho necessário para gerenciar atualizações técnicas  

Para obter mais informações sobre as histórias de usuários, consulte a seção Prontidão nas histórias de usuários da Pega Academy.

Você pode utilizar o backlog de tipos de caso (produzido na fase de Descoberta [Discover]) como ponto de partida para o backlog do seu projeto. Ele já contém a documentação de muitos dos itens que se tornam histórias de usuários e épicos.  

Alternativamente, produtos das sessões de estratégia do seu projeto, como um Sprint de design (Design Sprint), são uma rica fonte de ideias inovadoras. Os resultados do backlog de tipos de caso e das sessões de design compõem os insights necessários para preencher o backlog do projeto durante a fase Preparação (Prepare).

Durante a Preparação, a equipe do projeto (com representação das áreas comercial e de TI) trabalha de forma colaborativa para acrescentar detalhes ao backlog de tipos de caso e criar a versão preliminar dos tipos de caso de alto nível, documentados utilizando as ferramentas da Pega.  Esse esforço colaborativo identifica os estágios e as principais etapas do tipo de caso e associa aspectos detalhados da cada caso, como interfaces e personas, ao tipo de caso. Esse detalhamento adicional permite que a equipe se concentre na funcionalidade necessária para gerar os resultados de negócios e criar uma fundação para priorizar do trabalho.

A imagem a seguir mostra como as informações registradas no backlog de tipos de caso e os resultados de um Sprint de design servem para preencher o backlog com versões preliminares de histórias de usuários e épicos.

O segredo para criar seu backlog é compreender que ele pode mudar com o tempo. Não se espera um detalhamento de 100% na primeira versão preliminar. Sua equipe refina o backlog à medida que reúne mais informações e elabora histórias de usuários com o passar do tempo.Sua equipe reúne as informações do proprietário do produto (product owner), dos analistas de negócios (business analysts, BAs), do arquiteto-chefe de sistemas (lead system architect, LSA) e dos testadores (testers). A criação do seu backlog requer um espectro diversificado de pontos de vista para compreender o que é importante, o que deve ser priorizado e quando entregar cada história de usuário.

Os backlogs estão sempre em evolução e mudam constantemente com o tempo. Certifique-se de que seu backlog inclua histórias de usuários atualizadas e que esteja sendo priorizado de acordo com o valor de negócio que as histórias de usuários proporcionam. Novas histórias de usuários podem ser priorizadas em relação a outras, e algumas podem ser substituídas. As histórias de usuários existentes podem não ser mais necessárias e podem ser removidas. A gestão e priorização de backlogs é uma atividade contínua, que se mantém durante todas as fases do projeto. 

Informações sobre técnicas de priorização podem ser encontradas na Comunidade Pega.

O proprietário do produto (PO, Produt Owner) é o proprietário do backlog. O PO cria o backlog, o mantém atualizado e prioriza as histórias de usuários.No início do projeto, o proprietário do produto e a equipe do projeto devem concordar quanto à abordagem gerencial do projeto e os itens de trabalho do aplicativo.

Ao tomar decisões relativas à priorização, o proprietário do produto conta com uma ampla gama de histórias de usuários. Algumas histórias são elaboradas e bem compreendidas, estando assim prontas para a Construção. Outras ainda estão nos estágios iniciais do ciclo de vida das histórias de usuários. Essa variedade significa que o proprietário do produto deve considerar tanto as metas de curto prazo para planejamento do sprint quanto as metas de longo prazo para planejamento da elaboração, à medida que as histórias são priorizadas no backlog.