Product Backlog, tudo que você precisa saber #1

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

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.

Defeitos e correções de bugs

Se erros críticos e bugs surgirem durante uma iteração, eles precisam ser resolvidos para que o código do produto seja viável no final de uma iteração. No entanto, muitos bugs se enquadram na categoria de incômodos.

Eles precisam ser corrigidos, mas há discrição quanto ao momento das correções. Esses tipos de correções podem ser colocados no backlog e priorizados em uma iteração subsequente. Em alguns casos, a equipe espera até o final do projeto para uma limpeza final de bugs e erros.

Como são escritas as histórias no backlog?

As histórias de usuários são escritas de forma vaga e não contêm necessariamente muitos detalhes. As histórias devem conter detalhes suficientes para que tanto o cliente quanto a equipe do projeto se lembrem a que a história se refere.

A história também pode incluir outras informações, como uma estimativa do trabalho necessário para implementar a história. Quando a história é priorizada para uma iteração específica, deve haver informações suficientes para que o proprietário do produto e a equipe possam lembrar o contexto e possam trabalhar juntos para definir os requisitos detalhados.

Na iteração de configuração, o proprietário do produto cria quantas histórias de usuário ele conhece no momento. Não é necessário descobrir todas as histórias de uma só vez. As histórias podem ser adicionadas, modificadas e excluídas continuamente durante o projeto.

Em um projeto tradicional, as mudanças nas histórias de usuários seriam adicionadas usando o gerenciamento de mudanças de escopo. Em um projeto Agile, o proprietário do produto pode adicionar, alterar e remover quaisquer histórias.

O conceito de fluência de escopo não ocorre durante uma iteração. A quantidade de trabalho em uma iteração é fixada pela velocidade da equipe. Se o proprietário do produto continuar a adicionar novos itens à lista de pendências, pode ocorrer aumento de escopo exigindo iterações adicionais para implementar o trabalho em áreas que não faziam parte do escopo original do projeto.

Esse tipo de desvio de escopo deve ser controlado para garantir que o projeto Agile não se desvie.

Se o Product Owner é dono do Backlog, como fica o time?

Embora a equipe de desenvolvimento possa certamente expressar suas opiniões sobre o que deve ser trabalhado, eles não podem realmente agir de acordo com essas opiniões sem o consentimento do Product Owner.

Isso pode levar a uma sensação de desempoderamento por parte da equipe de desenvolvimento. Embora uma equipe de alto desempenho deva ser muito colaborativa e permitir que todas as vozes sejam ouvidas, a equipe pode sentir que as necessidades da tecnologia ou os sistemas não estão sendo suportados, ou talvez até valorizados.

Isso pode causar a sensação de “nós contra eles”, que é exatamente o cenário que Scrum e/ou  Agile deveriam evitar. Na verdade, algumas organizações tentam dividir o backlog entre “produto” e “tecnologia” e, às vezes, dão a cada um seu próprio Product Owner. Esta é a maneira errada de resolver este problema.

Dividir ou separar as pendências só causará confusão e interrupção, e não fornecerá transparência sobre o que está sendo trabalhado pela equipe.

O processo funciona melhor quando há um único backlog de trabalho priorizado contendo tudo o que deve ser desenvolvido e há uma maneira altamente visível (física ou eletrônica) para qualquer parte interessada ver o que está em andamento em uma iteração atual.

De qualquer forma, fazer qualquer outra coisa não é necessário – o Agile possui mecanismos para impedir que esse tipo de desempoderamento aconteça, embora o ônus seja da equipe de desenvolvimento para usá-los.

Usar esses mecanismos é a abordagem certa para manter a equipe se sentindo capacitada.

Itens chave para um bom backlog

Há seis itens-chave para procurar em uma história de backlog saudável. Ao classificar cada história nessas facetas, você pode ter uma noção fácil de quão pronta a história está para ser escolhida e desenvolvida. Os seis são prioridade, requisitos, estimativas, dependências e definição de pronto e definição de feito.

No próximo artigo vamos ver mais sobre eles.

2 Comments

Leave a comment

Your email address will not be published.

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.