De quem é a responsabilidade de criar o Backlog priorizado do produto?

Para ter ideia de tudo que você precisa saber sobre Product Backlog neste primeiro artigo, vamos contextualizar e balizar nossos conhecimentos um pouco.

    • O que é um Product Backlog? Definição
    • Quem é responsável pelo Product Backlog?
    • O que é Sprint Backlog? E como ele é planejado?
    • Documentação de projeto e o Product Backlog
    • O que mais existe no backlog do produto?
  • Entregas do usuário
  • Entregas de TI
  • Defeitos e correções de bugs
    • Como são escritas as histórias no backlog?
    • Se o Product Owner é dono do Backlog, como fica o time?
    • Itens chave para um bom backlog

O que é um Product Backlog? Definição

Uma das características importantes do Scrum é que há um, e apenas um, backlog de trabalho aguardando para ser priorizado, desenvolvido e concluído.

Um Backlog é uma lista de requisitos e requisitos de negócios que ainda não foram implementados. Um Backlog ajuda a entender melhor o produto, além de garantir que cada recurso necessário seja listado.

No desenvolvimento de software, um Product Backlog é uma lista abrangente de tudo o que pode ser necessário no produto. Ele inclui todos os recursos que serão implementados, bem como todos os bugs e problemas que devem ser corrigidos.

Um Product Backlog eficaz ajuda o gerenciamento de produtos e a equipe de desenvolvimento a priorizar tarefas e colaborar.

O objetivo de usar um backlog de produto é garantir que os recursos desenvolvidos sejam priorizados em termos de tempo e importância de valor para o usuário final.

Quem é responsável pelo Product Backlog?

O Product Owner é o responsável e mantenedor do backlog do produto. Além disso, é responsabilidade do Product Owner entender, avaliar e selecionar os itens de backlog individuais que serão adicionados a um sprint ou release atual.

É o PO que  deve receber informações de todas as partes interessadas, incluindo clientes, membros da equipe, executivos, tendências atuais e outras funções internas, mas, em última análise, ele é o tomador de decisão final.

O Product Owner é a pessoa que determina o trabalho que será realizado em cada iteração . O trabalho real atribuído à iteração requer um diálogo colaborativo entre o Product Owner e a equipe ágil.

O PO geralmente pede que a equipe assuma mais trabalho, e a equipe do projeto – deve se comprometer apenas com o nível de trabalho que pode ser totalmente concluído durante a iteração. Em última análise, a equipe Agile é responsável por decidir sobre o trabalho exato que compõe a iteração.

O que é Sprint Backlog? E como ele é planejado?

Em um projeto ágil, a carga de trabalho é determinada no início de cada iteração (sprint). O Product Owner avalia e prioriza o trabalho que precisa ser feito, enquanto a equipe determina a quantidade de trabalho que pode ser concluída e a meta da sprint.

A reunião de planejamento de iteração (Sprint Planning) define o cenário e deve ser executada como um diálogo colaborativo,.

Um dos aspectos exclusivos de um projeto Agile é que a carga de trabalho é determinada no início de cada iteração. Ao contrário dos projetos tradicionais, a carga de trabalho não é definida com meses e meses de antecedência.

Há apenas a necessidade de um planejamento detalhado para a próxima iteração. (O  Product backlog pode ser mapeado em alto nível para iterações futuras, mas o planejamento detalhado ocorre uma iteração por vez.) Isso permite que um projeto ágil seja flexível em sua carga de trabalho e sensível às mudanças nas necessidades e prioridades do cliente.

No início de cada iteração, o Product Owner e a equipe do projeto se reúnem para determinar a carga de trabalho para essa iteração. Durante a reunião, o Product Owner avalia o backlog do produto e simplesmente extrai o próximo conjunto de histórias de usuário que são de maior prioridade.

Esse nível de esforço para concluir a história do usuário pode já ter sido estimado quando a história foi adicionada. Caso contrário, a equipe estima o trabalho na reunião de planejamento.

Essa estimativa pode assumir a forma de horas de esforço real, mas é mais provável que a estimativa seja baseada em “pontos da história” – vamos falar sobre eles depois – A estimativa inclui o trabalho necessário para implementar totalmente a história do usuário, incluindo a análise, design, construção, teste e integração.

Essa separação de histórias, para um pedaço do projeto é chamado de Sprint Backlog.

Legal! até aqui você já entendeu que o Product Backlog (backlog do produto) é a lista de tudo que consta dentro de um produto com os desejos e regras de negócios, enquanto o Sprint Backlog é uma lista priorizada que vai ser executada já na próxima iteração.

Documentação de projeto e o Product Backlog

Em um projeto ágil, você não cria documentos grandes para atender aos requisitos do usuário; na verdade, você não precisa de um documento tradicional. A técnica preferida é usar um backlog do produto, que representa uma coleção priorizada de trabalho restante no projeto em um determinado momento.

Em um projeto Agile, você não cria documentos grandes para atender aos requisitos do usuário. Na verdade, você não precisa de um documento tradicional. A técnica preferida é criar um backlog do produto.

O backlog não é um documento tanto quanto é simplesmente a coleção priorizada de trabalho que permanece em um projeto. Pode ser uma planilha ou tabela que contém uma lista de histórias de usuários. Também pode ser uma pilha de cartões de índice, cada um contendo uma história de usuário ou um item exclusivo de trabalho.

O backlog inicial do produto é gerado no início de um projeto Agile. O tempo pode coincidir com uma fase de iniciação do projeto ou durante uma iteração inicial de configuração (às vezes chamada de iteração 0). O backlog inicial do produto consiste em todo o trabalho facilmente identificado que é conhecido quando o projeto é iniciado.

À medida que cada iteração começa, uma reunião de planejamento é realizada entre o proprietário do produto e a equipe do projeto. O proprietário do produto identifica o trabalho no backlog do produto que ele gostaria que fosse concluído na iteração.

A equipe do projeto valida que pode concluir o trabalho. As negociações são realizadas se houver uma diferença de opinião sobre o trabalho que pode ser concluído durante a iteração. O trabalho mutuamente acordado é então retirado do backlog do produto e implementado durante a iteração.

O que mais existe no backlog do produto?

O backlog do produto representa a totalidade do trabalho restante no projeto em um determinado momento. A maior parte do backlog consiste em histórias de usuários que implementam funcionalidades de benefício para o usuário. No entanto, outros trabalhos também estarão na lista de pendências. Isso inclui.

Entregas do usuário

Nem todos os itens do backlog do produto requerem codificação de software. Por exemplo, o proprietário do produto pode querer um Manual do Usuário, conteúdo de treinamento, perguntas frequentes etc. Se as entregas devem ser criadas pela equipe do projeto, o trabalho precisa ser priorizado e incluído na iteração apropriada.

Entregas de TI

Essas são entregas exigidas pela organização de TI. Isso pode incluir um Manual de Recuperação de Desastres, documento de retenção de registros, documentação de controle de alterações, etc. Alguns deles podem ter valor para o usuário, mas às vezes são necessários para a organização de TI.

Quem cria Backlog priorizado do produto?

O Product Owner é o único responsável por gerenciar o Backlog do Produto. Ou seja, ele é responsável por criar, atualizar, reordenar e dar visibilidade a ele.

Quem prioriza o Backlog?

Como funciona o backlog? Geralmente, o time e o “dono do produto” responsáveis pelo projeto escrevem e priorizam os itens iniciais do backlog de produto. A premissa, aqui, é que tais itens bastem para que a equipe inicie a primeira iteração (sprint) – que é o ato de repetir, de tornar a fazer.

Quem faz o Backlog?

O único responsável pelo Backlog do Produto é o Product Owner (PO) e, embora ele possa delegar a ordenação do Backlog para alguém do Time de Desenvolvimento, ele continua sendo o responsável por ele. Portanto, a fim de evitar conflitos de interesses, todo Backlog deve mantido por apenas um Product Owner.