Para ter ideia de tudo que você precisa saber sobre Product Backlog neste 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.

O processo de refinamento do backlog e consequentemente dos requisitos até o ponto em que eles estejam prontos para serem trabalhados é conhecido como ‘limpeza do backlog’.

Mas essa tarefa realiza mais do que esclarecer requisitos; informa as partes interessadas, contribui para o plano do projeto e reforça os princípios ágeis em geral. Aqui está a orientação sobre como e quando isso deve ser feito.

Uma das inovações mais úteis da família de práticas Agile é o conceito de backlog do produto. No passado, o acúmulo de requisitos existia em um documento – geralmente chamado de Documento de Requisitos de Negócios (BRD – Bussiness Requirements Document) – que continha necessidades totalmente especificadas para o produto com base em qualquer informação que o proprietário da empresa tivesse na época.

O backlog, então, era o que estava no documento que ainda não estava concluído. Isso é realmente muito simples; se o documento contiver 50 itens e três deles estiverem completos, a lista de pendências consistirá em mais 47 itens. É melhor a equipe começar a trabalhar!.

Praticantes ágeis acreditam que duas coisas são verdadeiras: os produtos são melhores quando trabalhamos juntos e devemos abraçar a ideia de que os requisitos estão mudando o tempo todo.

O simples processo de passar semanas ou meses criando um documento enorme que é então entregue aos desenvolvedores não apenas viola os dois princípios, mas perde completamente o objetivo de como criar ótimos produtos. (além de que esse documento enorme acaba na gaveta).

Em vez de despender esforço criando um documento longo que é inferior (devido à falta de colaboração) e desatualizado (devido às necessidades de mudança do negócio), o Agile sugere a criação de algo chamado product backlog.

Esse backlog do produto é uma lista priorizada de requisitos, histórias de usuários, tarefas e atividades que a equipe do produto precisa realizar para levar o produto ao mercado.

Ele difere substancialmente do antigo BRD, pois a lista de requisitos teve diferentes níveis de energia colocados neles, e a lista é fixa e adaptável às necessidades do produto e da equipe do produto.

O processo de transformar esse backlog em algo excelente é chamado de Backlog Refinement (antigamente era grooming) e é um conceito fácil de ser mal interpretado ou usado indevidamente, tanto do ponto de vista do produto quanto do desenvolvedor.

Por que se preocupar com a limpeza no refinamento?

Existem duas dimensões que um backlog de produto Agile traz para o produto que o antigo BRD não trazia: prioridades e a capacidade de alterar ou inserir novos requisitos com o passar do tempo.

No entanto, há mais uma faceta oculta para trabalhar com um backlog priorizado: como algumas das histórias de usuários acabarão no final da lista, não há necessidade de gastar muito tempo com elas.

Acontece que é uma ideia melhor “deixar de lado” essas histórias e reorientar seu tempo nas histórias de usuários que estão no topo da pilha. Em vez de obter os requisitos “suficientemente bons” em geral, o proprietário do produto é responsável por obter os requisitos que estão no topo da pilha “prontos para a iniciar” – mesmo às custas das histórias na parte inferior da pilha.

Um backlog devidamente preparado é o ativo mais importante que uma equipe Agile pode ter. Para que seja o mais útil possível, deve ser capaz de fazer três coisas :

1. Fornecer itens prontos para o trabalho para a equipe de desenvolvimento:
2. Ser flexível e conter todas as informações disponíveis sobre o produto e
3. Fornecer insights para todas as partes interessadas sobre o que está no pipeline a ser trabalhado.

O objetivo principal do backlog é dar trabalho à equipe de desenvolvimento que está pronta para começar. Isso significa que:

• Ele está totalmente especificado,
• Suas perguntas são respondidas,
• O dimensionamento está completo e os critérios de sucesso registrados.

Um membro da equipe deve ser capaz de pegar um item da lista de pendências e começar a trabalhar imediatamente, não importa se é engenheiro de software, testador ou designer.

Isso realmente exige muito esforço do proprietário do produto e da equipe do produto – esforço que foi desviado dos itens na parte inferior do backlog.

Não há nada que um proprietário de produto possa fazer que afete mais a eficiência da equipe do que ter as próximas tarefas prontas para serem executadas.

Se um desenvolvedor de qualquer tipo tiver que passar por um intervalo de até meio dia enquanto espera para começar a trabalhar em algo, isso custará significativamente ao produto no final.

Enquanto isso, o backlog deve ser flexível, tanto em conteúdo quanto em prioridade. Quando o backlog inicial foi criado, ele foi feito com todas as informações, análises e inteligência que o product owner tinha.

Agora que a lista de pendências foi aberta para desenvolvedores, partes interessadas, clientes e outros proprietários de produtos, novas ideias surgirão e uma nova prioridade surgirá.

Por exemplo, trabalhei recentemente em um produto em que o proprietário do produto decidiu intencionalmente não priorizar uma parte inteira do aplicativo em favor de criar uma experiência mais rica nas outras partes.

O feedback foi instantâneo e intenso; sem a funcionalidade que faltava, o produto era inútil. Em vez de esperar um ano ou mais para recuperar essa funcionalidade, o proprietário do produto conseguiu colocar essas histórias de usuários de volta no topo da lista, prepará-las completamente, e levá-los para a próxima versão.

É assim que o Agile deve funcionar!

O backlog também deve ser usado como documentação externa. Todas as partes interessadas querem saber o que está por vir, quando seu caso de uso será criado e o que mais está na lista.

Um backlog devidamente preparado pode servir a essa função. Ao apontar as pessoas para a lista de pendências, elas podem ver o que está perto do topo, o que está na parte inferior e onde sua solicitação está em prioridade relativa.

Eles também podem ter informações ou feedback sobre as prioridades atuais, requisitos futuros ou podem até ter ideias brilhantes que não estão na lista.

Em suma, o backlog pode servir como documento de requisitos, plano de projeto e comunicação com as partes interessadas, tudo ao mesmo tempo. Mas só se for bem feito.

Itens de prioridade de um backlog antes do refinamento

Repare que existem seis itens que são prioridade num product backlog. Os seis são prioridade, requisitos, estimativas, dependências e definição de pronto e definição de feito.

Para criar um backlog saudável, ao classificar cada história em uma escala de zero a três, você obterá uma pontuação total entre zero e 18, permitindo que a equipe saiba, de relance, quais histórias estão em boa forma e quais não estão e, assim, quais a forma do backlog está no todo. Aqui está uma olhada em cada um dos fatores que compõem a “saúde da história”.

1. Prioridade.

Isso parece quase óbvio, pois as tarefas no topo do backlog são as de maior prioridade e as de baixo são as mais baixas. Isso não significa que a razão por trás da prioridade seja compreendida, o que é ainda mais importante.

A equipe de desenvolvimento geralmente prioriza mentalmente o trabalho com base em sua própria compreensão de por que algo é necessário. O papel do proprietário do produto é garantir que a equipe entenda o valor do trabalho; os desenvolvedores não precisam necessariamente concordar com ela, mas precisam entendê-la.

Desenvolvedores trabalhando em algo que não entendem é ruim para todos.

2. Requisitos.

Quase igualmente importante é a compreensão da obra em si, que, mais uma vez, parece óbvia. A parte difícil é que os requisitos nunca são completos; eles só são bons o suficiente por enquanto.

Mesmo depois que um recurso está disponível nas mãos do cliente, ainda há refinamentos, alterações e melhorias que podem ser feitas e provavelmente estão sendo constantemente adicionadas ao backlog.

No entanto, uma vez que uma história de usuário recebe um ou dois sprints de desenvolvimento, é hora de garantir que os requisitos sejam entendidos o suficiente para que um desenvolvedor possa pegá-lo e trabalhar nele.

Os requisitos não precisam ser definitivos – nunca são – mas precisam estar prontos.

3. Estimativas.

Uma parte da preparação do backlog é dimensionar as histórias, usando um mecanismo como pontos de história ou qualquer estratégia que a equipe se sinta confortável em usar.

Histórias que ainda são desconhecidas em relação ao nível de esforço, risco ou complexidade, ou histórias que têm estimativas grandes demais para serem concluídas, trazem muitos problemas para os desenvolvedores.

Quando chega a hora de planejar um sprint, um release ou até mesmo um único dia, é importante saber o tamanho do trabalho que está sendo considerado.

Sem um bom dimensionamento, a equipe fica apenas adivinhando o que pode ser concluído e nunca saberia responder se as coisas estão dentro do prazo ou não.

Estamos trabalhando com um projeto não com adivinhações.

4. Dependências.

Uma das causas frequentes de atraso envolve histórias sendo “bloqueadas” – ou seja, há uma dependência que não foi resolvida que está impedindo o desenvolvedor de progredir.

Se uma história for bloqueada durante o desenvolvimento ou, pior, entrar em um sprint já bloqueado, então é uma história inútil. Essas dependências podem estar em outras equipes de desenvolvimento, equipes fora do desenvolvimento, como criação, marca ou marketing, ou até mesmo o proprietário do produto tomando uma decisão sobre algo.

Como parte da preparação de uma história, é importante descobrir se o desenvolvedor tem tudo o que é necessário para começar o trabalho ou se o terá quando o sprint começar. Alguns podem ser resolvidos da noite para o dia; alguns podem levar vários meses para resolver.

É importante saber onde uma história está quando ela se aproxima do topo da lista de pendências.

5. Definição de Pronto. DoR – Definition of Ready

O que está sendo feito nas tarefas também tem “critérios de aceitação” – ou seja, quais casos de uso e funcionalidades devem existir e poder ser mostrados em uma demonstração para que a história seja considerada completa.

Nesse caso, está associado a cada item de trabalho individual que flui por uma equipe ágil.

Se você estivesse praticando Scrum, então seria no nível do item do backlog do produto (PBI).

Se você estiver operando como uma equipe de programação extrema (XP) ou Kanban (ou simplesmente alavancando histórias de usuários), então seria para cada história que entrasse em uma equipe.

Os critérios de prontidão seriam uma definição clara do que conota uma história de usuário ou PBI que está “pronta” para execução dentro da iteração ou sprint.

Os itens são executados desde a funcionalidade voltada para o usuário até requisitos de latência e desempenho, condições de erro e testes negativos. Quanto mais um desenvolvedor souber o que será necessário para que a história seja aceita, melhor será para todos.

Na verdade, uma metodologia de desenvolvimento requer escrever os testes de aceitação primeiro e depois fazer o desenvolvimento.

6. Definição de Feito. DoD – Definition of Done

Espero que todos estejam familiarizados com a terminologia “definition of done” (DoD), ou “done-ness”, do ponto de vista dos métodos ágeis. É uma frase comum e incrivelmente importante para a saúde e maturidade da equipe ágil. É essencialmente um critério de saída, se você preferir, para o trabalho de sprint das equipes.

No nível da história do usuário, é comum referir-se aos critérios de aceitação de cada história como a verificação de conclusão da completude da história.

Em um nível de sprint completo, é comum se referir ao objetivo do sprint como o ponto de verificação para o que a equipe estava tentando entregar. E o acabamento também permeia a forma como os membros da equipe entregam seu trabalho.

Por exemplo, as revisões de código fazem parte dos critérios de conclusão de uma equipe? Nesse caso, ele planejará e executará revisões de código consistentemente como parte do desenvolvimento e entrega de cada história.

Portanto, a definição de “feito” é um critério de saída, que determina a condição de completude para o trabalho que está sendo entregue. Mas há outro critério que é útil em equipes ágeis na outra ponta do fluxo de trabalho – a entrega a DoR.

Acontece que impedir que histórias mal definidas (ou trabalho) entrem em cada sprint em primeiro lugar é uma maneira incrivelmente saudável de evitar os desafios que descrevi na introdução. Mas vamos explorar a prontidão com um pouco mais de detalhes.

O outro lado do DoD: Descrevendo “Pronto”

Pessoalmente, gosto de uma abordagem de lista de verificação para descrever os critérios de prontidão das equipes para o trabalho. Aqui está um exemplo dos tipos de verificações que eu vi serem valiosas para as equipes aproveitarem ao amadurecer suas histórias:

• A história é bem escrita; e tem um mínimo de cinco testes de aceitação definidos.
• A história foi dimensionada para se ajustar à velocidade das equipes e à duração do sprint; por exemplo, algo entre 1-13 pontos.
• A equipe examinou a história em várias sessões de preparação – seu escopo e natureza são bem compreendidos.
• A equipe tem o conjunto de habilidades e experiência necessários para implementar a história e entregá-la para atender à definição de “pronto” da organização e da equipe.
• Se necessário, a história teve um pico de pesquisa para explorar (e refinar) suas implicações de arquitetura e design; ou para explorar os desafios de testabilidade associados a ele.
• A história descreve o comportamento de ponta a ponta no sistema.
• A equipe entende como abordar o teste dos aspectos funcionais e não funcionais das histórias.
• Quaisquer dependências de outras histórias e/ou equipes foram “conectadas” para que a história seja sincronizada e entregue como parte do “todo maior”.
• A história se alinha com o objetivo do sprint e é claramente demonstrável.

Portanto, não há fases distintas neste caso. Uma nova história de usuário simplesmente precisa atender a todas as verificações acima para que seja considerada pronta para execução.

Como cada história fica pronta depende do proprietário do produto para cada backlog do produto, colaborando com sua equipe. Pode levar um ou 50 passos para chegar lá.

Pode ser rápido ou lento. Mas trabalhando juntos, eles decidem como conduzir uma história até a prontidão para execução.

Criando um semáforo do seu Backlog Refinado

Levando em consideração que vamos utilizar o DAP (Detalhar, Avaliar e Priorizar) para as histórias que serão refinadas, podemos criar também um semáforo com estes Seis itens que falamos acima para seu backlog, dessa forma vamos avaliar as histórias: A, B e C

Neste ponto, as histórias no backlog devem ser avaliadas ao longo dos Seis vetores acima: Prioridade, Requisitos, Estimativas, Dependências, DoR e DoD.

O ideal, para se ter uma boa métrica, fazer a média de até cerca de seis sprints de histórias é suficiente, embora esse número possa ser potencialmente um pouco maior ou menor, dependendo da cadência de lançamento da organização ou do tamanho do incremento de planejamento.

Histórias classificadas entre 11 e 18 estão prontas (verde); as histórias que estão entre 6-10 ainda não estão prontas (amarelo); e qualquer coisa abaixo de seis não está pronta (vermelho). Isso fornece um mecanismo rápido de semáforo para verificar rapidamente o status do backlog da equipe.

Ter algumas histórias vermelhas não é uma coisa ruim, especialmente se elas estiverem mais abaixo na lista de prioridades. Se você estiver três meses antes da chegada dos pintores, há muitos momentos de responsabilidade antes de precisar escolher seu esquema de cores.

No entanto, histórias vermelhas, ou mesmo muitas histórias amarelas, planejadas para inclusão nos próximos dois sprints, podem sinalizar um problema ou uma lista de pendências que não está em boa forma.

Na verdade, eu sugiro que um backlog perfeito tenha principalmente histórias verdes nos próximos dois sprints, principalmente amarelos nos dois seguintes e principalmente vermelhos nos dois seguintes.

Ao fazer essa avaliação, a equipe pode dizer rapidamente quão saudável é o plano e, portanto, quão certo eles estão de que a equipe está “no caminho certo” para entregar.

Nunca haverá um caso em que não haja incógnitas; na verdade, um dos pontos do Agile é admitir que você não pode saber tudo antes do tempo.

Mas quanto mais você conseguir entender as coisas, especialmente as coisas que estão ao alcance da equipe, mais confiante ela poderá começar a investir no caminho para entregar valor ao cliente e à organização.

Expresse o valor do cliente

A primeira maneira pela qual uma equipe de desenvolvimento pode priorizar seu trabalho técnico é expressar o valor do trabalho em termos de benefício para o cliente.

Afinal, se não houver uma boa razão para fazer o trabalho em primeiro lugar, é lógico que ele não deve ser feito.

Mesmo coisas aparentemente mundanas podem ser enquadradas de forma a ajudar o cliente.

Já ouvi gerentes de desenvolvimento dizerem: “A estabilidade e a segurança de nossos sistemas é um recurso que lançamos todos os dias para nossos usuários”. Quando visto por essa lente, não é difícil descobrir quanto valor para o cliente seria criado e como a prioridade se compara a outros itens.

Esse tipo de determinação pode ser feito para muitas melhorias que parecem técnicas por natureza, mas na realidade são voltadas para o cliente.

Isso inclui itens como melhorias de desempenho, correções de bugs, dimensionamento de carga e até itens invisíveis, como a aplicação de hotfixes ou patches de segurança a uma estrutura de aplicativo.

Todas essas tarefas podem ser vistas como boas para todos e, portanto, devem ser priorizadas junto com novos recursos ou novas funcionalidades. Qualquer bom Product Owner seria capaz de entender o valor que está sendo criado e colocar isso em contexto com todo o resto.

O desafio é que esse tipo de cálculo não é natural para a maioria dos profissionais de produtos; embora reconheçam que há boas razões para fazer esses itens, muitas vezes têm dificuldade em quantificá-los.

É aqui que a equipe de desenvolvimento precisa agir como se estivesse na organização do produto, determinando o quanto os tempos de resposta serão mais rápidos ou quantas vezes um determinado defeito e acionado por um cliente ajudará a calcular o valor do trabalho.

As melhores práticas do setor podem ser citadas quando se trata de atualizações de estrutura, assim como eventos nas notícias que expõem vulnerabilidades que devem ser fechadas.

Qualquer que seja o caminho escolhido pela equipe, deve ser em termos de criação de valor; chamar as coisas de “devem ser feitas” sem fundamentação não é uma maneira útil de colaborar.

Refinar como parte da estimativa

Muitas das atividades que compõem um projeto ágil devem ser feitas em equipe, com todos no mesmo lugar. De fato, no Manifesto Ágil, um dos princípios afirma que as interações cara a cara são a maneira mais eficiente e eficaz de se comunicar.

Isso apresenta um problema para um gerente de projeto executando um projeto em que a equipe é distribuída, no todo ou em parte. Embora ter todos na mesma sala possa ser o ideal, não é realista se as pessoas trabalharem a quilômetros ou países de distância, ou se todos forem forçados a trabalhar em suas casas.

E enquanto a tecnologia pode ajudar a nos aproximar e imitar a interação face a face, há outras logísticas, como fusos horários e conectividade, a serem superadas.

Na prática, quase tudo o que pode ser feito em Agile pode ser feito de forma distribuída, desde o Daily Scrum até demonstrações e retrospectivas. É preciso apenas um cuidado extra para torná-los eficazes.

Uma atividade ágil importante que as equipes distribuídas podem realizar sem muita perda é o refinamento do backlog.

É importante para um scrum master, product owner ou mesmo um gerente de projeto que se encontra gerenciando uma equipe distribuída não tentar substituir os processos existentes pelo mesmo usando tecnologia.

Não é “o mesmo, apenas em vídeo”.

O seu objetivo é encontrar uma maneira de obter o mesmo valor de uma atividade sem necessariamente fazê-la exatamente da mesma forma que a equipe fez no passado.

O mesmo vale para o refinamento do backlog. Para uma equipe que costumava se reunir na mesma sala toda quinta-feira à tarde, simplesmente mudar para fazer a mesma coisa por videoconferência não terá os mesmos resultados.

O resultado desejado de uma sessão de refinamento é que os itens do backlog passem de ideias para itens acionáveis ​​que são compreendidos, dimensionados e priorizados.

Isso é possível, mesmo que todos estejam presos trabalhando em seus “escritórios domésticos”.

Na verdade, mesmo que todos estejam trabalhando na mesma mesa, certas partes de uma sessão de refinamento devem ser feitas em particular.

Para garantir que todos entendam um requisito, todos devem passar algum tempo sozinhos, certificando-se de que o entendem e que há informações suficientes sobre a história para que alguém possa pegá-lo e ter uma boa ideia do que precisa ser feito.

O escopo, ou determinar quanto esforço algo exigirá, também deve ser feito em particular. O conceito de “planning pôquer” é uma forma de prevenir o pensamento de grupo, e como uma forma de garantir que os desenvolvedores mais experientes, ou mais falantes, não se sobreponham a todos na sala.

Ambas as partes do refinamento devem ser feitas separadamente e, em um ambiente distribuído, às vezes pode ser feita mais facilmente.

Aqui está um exemplo de como seria uma sessão de refinamento de backlog distribuído.

Cada um analisa o refinamento por conta própria

O refinamento começa com o dono do produto ou a pessoa que possui a história introduzindo os requisitos, objetivos e resultados desejados da história.

Isso pode ser feito ao vivo por meio de discussão ou pode ser algumas linhas escritas dentro da própria história. O dono do produto deve incluir requisitos detalhados, cenários, casos de falha, regras de negócios e outros itens importantes para completar a história.

Cada membro da equipe de produto deve analisar a história por conta própria, para garantir que a história conforme escrita corresponda à compreensão do que estão discutindo.

É muito fácil em uma situação de grupo presumir que outros membros da equipe têm o mesmo entendimento, ou eles entendem ambiguidades ou partes da história que não são claras.

Façam perguntas juntos no refinamento

Ao ler a história, cada desenvolvedor deve fazer perguntas esclarecedoras. Cada membro da equipe terá uma lista de itens que precisam de mais informações ou mais detalhes e devem estar preparados para perguntar ao dono do produto.

Esta parte deve ser feita em grupo, pois haverá perguntas de outros membros da equipe, e uma pergunta provavelmente gerará mais algumas. Os desenvolvedores devem fazer perguntas ao dono do produto até sentirem que entendem bem a história e todos concordarem que todas as perguntas foram respondidas, incluindo novas perguntas que surgiram durante a própria discussão.

Isso não significa que a história seja tão detalhada a ponto de não ter mais nada a ser considerado, mas sim que a história atendeu à “definição de pronto” para a equipe.

Estimar o refinamento separadamente

Uma vez que a história atende à definição de pronto, cada desenvolvedor decide por si mesmo sobre o tamanho da história. Diferentes metodologias usam diferentes mecanismos para decidir como definir o escopo de uma história; a maioria dos projetos ágeis usa pontos de história.

Esses pontos pretendem representar uma visão geral da dificuldade de uma história, incluem complexidades desconhecidas, riscos, dependências e esforço real para completá-la.

Quando as estimativas são feitas ao vivo em uma reunião, cada desenvolvedor as descobre por conta própria, seja usando o planning poker ou por algum outro método.

Cada desenvolvedor terá uma visão diferente sobre o quão difícil será concluir uma história, seja devido à experiência passada, ou usando uma solução da qual apenas alguns membros da equipe estão cientes, ou talvez conhecendo um ponto de discórdia da última vez que a equipe lidou um pedido como este.

Seja qual for a causa, mesmo quando feito ao vivo, cada membro da equipe cria o que pensa por conta própria. Esse valor é então revelado à equipe, de uma só vez, o que leva a uma discussão e a um resultado final.

Fazer isso de maneira distribuída, na verdade, torna essa etapa mais fácil. Cada desenvolvedor pode levar seu tempo para entender o espaço do problema, e sua solução.

Quando todos dizem que estão prontos, a discussão final pode começar e podem chegar a sua própria determinação quanto ao escopo, sem ter uma sala cheia de pessoas olhando para eles enquanto ponderam.

Discutir o refinamento e finalizar em equipe

Uma vez que as estimativas de esforço de todos são conhecidas, a equipe deve se reunir novamente e discutir o resultado. É raro que todos na equipe tenham a mesma opinião; alguns serão mais altos ou mais baixos do que outros, e pode haver um ou dois valores atípicos.

Nesse ponto, a equipe analisa os processos de pensamento uns dos outros e como eles acabaram com seu valor. A equipe pode então voltar a votar em particular ou simplesmente decidir chegar a um acordo que todos possam aceitar.

Uma vez que isso seja resolvido, a equipe pode dividir a história em tarefas que podem ser feitas individualmente. Ser distribuído pode facilitar essa parte; todos precisam estar confortáveis ​​com o valor final por conta própria.

Estar separado pode ajudar a impor isso e evitar que as pessoas concordem simplesmente em concordar ou permitir que uma pessoa domine a discussão.

A pessoa que lidera a sessão de refinamento deve garantir que os pensamentos de todos sejam ouvidos e que todos entendam o resultado final.

Pessoalmente, o líder provavelmente olharia ao redor da sala e tentaria julgar com base em acenos de cabeça ou talvez até mesmo julgando o silêncio.

Como todos estão separados, todos precisarão dizer em voz alta que estão alinhados.

Sobre fazer refinamento remoto

Em vez de tentar ler os rostos das pessoas, fazer com que as pessoas falem tornará os sentimentos das pessoas muito mais claros, o que pode realmente levar a uma equipe melhor coordenada no final.

Mais e mais empresas estão executando seus projetos de maneira distribuída. Isso é especialmente verdadeiro durante uma pandemia mundial, mas também estava se tornando cada vez mais verdadeiro devido à natureza global da indústria e aos avanços da tecnologia.

Algumas das atividades e cerimônias associadas à execução de um projeto Agile precisam de um esforço extra para garantir que ainda possam atingir seus objetivos sem que todos precisem estar na mesma sala.

O refinamento da lista de pendências, no entanto, se presta facilmente ao trabalho com uma equipe que não está reunida.

Certas partes dele, certificando-se de que as histórias sejam compreendidas e chegando a estimativas de escopo e esforço, devem ser feitas individualmente.

Outras partes, como fazer perguntas e elaborar um plano final, podem ser feitas em conjunto, com todos se revezando, tomando os devidos cuidados

Como saber quando realizar o refinamento?

Você já entrou em um sprint assumindo uma história de usuário da qual se arrependeu mais tarde? Por exemplo:

• Uma que você deveria ter dividido um pouquinho mais?
• Uma que a equipe não tinha uma “pista de bola de neve” de como implementar tecnicamente?
• Uma em que o valor não era claro do ponto de vista do negócio?
• Uma onde a estimativa e a realidade não eram iguais?
• Uma que, quando você “fez”, você não tinha certeza de como determinar que foi feito?

Eu estou supondo, é claro que você tem. Eu encontro essas cenas em equipes que estou treinando o tempo todo. E verdade seja dita, não é um evento terrível. Equipes cometem erros… o tempo todo. E eles geralmente aprendem com eles.

O verdadeiro problema, da minha perspectiva, é com as equipes que continuam fazendo esse sprint sobre sprint sobre sprint. Sim, a dinâmica muda um pouco, mas o resultado final é o mesmo. A equipe está aceitando histórias de usuários que realmente não estão prontas para o sprint!

Então a pergunta é: o que pode ser feito para evitar isso? Existe alguma técnica que impeça que isso aconteça, ou essas equipes estão condenadas a continuar repetindo seus erros? Estou feliz que você perguntou.

Relação com o refinamento do backlog

Então, você pode estar se perguntando: como uma história de usuário fica pronta? Do meu ponto de vista, é parte da preparação ou refinamento contínuo e em tempo real do backlog que uma equipe assume como parte natural do amadurecimento de seu backlog.

Reuniões regulares de preparação fornecem um local para essas discussões, e é simplesmente uma parte de preparar seus backlogs suficientemente para uma execução eficaz.

As equipes geralmente agendam até 10% de seu tempo em cada sprint para refinamento do backlog. Cerca de metade disso é focado em reuniões, talvez duas reuniões de 1 hora por semana.

O restante do tempo é gasto em refinamento individual ou em pequenos grupos. O ponto é que a equipe mergulhe continuamente em seus backlogs de produtos.

O refinamento geralmente examina:

• Estimativa de história
• Decomposição da história
• Definição da história
• Investigação da história
• Aceitação da história

Você continua refinando cada história de usuário até que a equipe tenha alcançado um nível sólido de compreensão e a história tenha sido dimensionada adequadamente para caber em um sprint.

Muitas vezes, as equipes estão antecipando vários sprints, de modo que o refinamento não é apenas em torno do que vem a seguir, mas principalmente focando em um fluxo de trabalho para a próxima versão ou mais.

Como eu “Preparo” meu Backlog

Este artigo não pretende ser uma cartilha sobre o processo passo a passo sobre como fazer a preparação do backlog, mas as etapas gerais são as mesmas.

No Agile, existe um acrônimo chamado DEEP que é frequentemente usado. Significa: Detalhado, Emergente, Estimado e Priorizado. Cada um desses quatro poderia ser assunto de seu próprio artigo, mas vamos dar uma olhada em cada um e entendê-los melhor.

O D é para Detalhado

E muitas vezes você verá isso chamado “Detalhado apropriadamente”.

O que isso significa é que cada história de usuário ou item no backlog precisa ser detalhada o suficiente para a posição em que está e que o nível de atenção  esteja pronto para quando um desenvolvedor a pegar.

Dependendo da história, isso pode significar que todos os ativos estão prontos, todos os equipamentos adquiridos ou todos os casos de exceção são conhecidos e descritos.

Se uma história está na parte inferior, pode ser explicada com menos precisão, pois não há necessidade de prepará-la ainda.

O primeiro E é geralmente para Emergente

A ideia é que o backlog mude com o tempo e esse comportamento deve ser adotado, não resistido.

O backlog inicial vem dos pensamentos iniciais do proprietário do produto; é raro que uma pessoa trabalhando sozinha vá acertar tudo na primeira tentativa.

Na verdade, se o backlog mantiver a mesma priorização em todo o projeto, isso é mais um sinal de que algo está dando errado do que um sinal de que as coisas estão dando certo.

À medida que a equipe aprende mais sobre o produto (geralmente chamado de “discovery do produto”), novas coisas serão adicionadas, algumas serão removidas e muitas coisas mudarão de prioridade. Este é um sinal de um backlog saudável.

O segundo E é para Estimativa

Falamos acima que não se espera apenas que o backlog seja uma listagem de requisitos, mas também uma ferramenta para o planejamento do projeto.

Para que isso funcione, os itens precisam ser estimados adequadamente. A estimativa ágil é uma arte e também uma ciência, mas a mesma coisa vale tanto para a estimativa quanto para o detalhamento.

Quanto mais próximo um item estiver do topo da lista de pendências, mais detalhadamente ele deve ser estimado. Os itens na parte inferior podem ter estimativas como “grande” ou “muito grande”.

Mas para fazer um planejamento adequado, os itens no topo devem ter estimativas que ajudem a fazer um plano que funcione. Cada equipe usa um mecanismo diferente, de pontos de história a dias de esforço ou qualquer outra coisa.

O mecanismo real não importa, o que importa é que o que é usado realmente ajuda a criar um plano útil.

Finalmente, o P é para Priorizado

Embora já tenhamos falado sobre isso, o conceito de criar uma lista priorizada pode ser difícil para novos proprietários de produtos. Às vezes, os proprietários de produtos dividem os recursos em listas que não alteram o comportamento, como “obrigatório”, “crítico” e “bloqueador de lançamento”.

Dependendo do seu ponto de vista, todas essas três coisas são as mesmas. 

O Agile propõe uma classificação literal da pilha de prioridades, de um ao infinito, o que ajuda a responder às perguntas sobre o que fazer a seguir, o que está no próximo sprint e o que está fazendo o lançamento.

Se um proprietário do produto não puder priorizar, ou pior, criar várias prioridades principais, a lista de pendências se tornará inútil.

A preparação adequada do backlog o torna DEEP; os itens são devidamente detalhados, novas ideias e novos pensamentos podem surgir, estimativas são criadas e definidas e as prioridades são claras e comunicadas. Sem isso, a equipe terá um desempenho inferior.

Resumo e Conclusão

O backlog deve ser preparado constantemente; histórias de usuários devem ser esclarecidas, especificadas e preparadas para o trabalho. E os itens que estão em desenvolvimento ativo devem ficar o mais estáveis ​​possível.

Isso significa que o ato de preparar o backlog nunca deve parar; muitas equipes reservam tempo para fazer isso semanalmente, incluindo todos da equipe.

O impacto dessa preparação deve ser sentido em intervalos regulares, seja a cada sprint, a cada lançamento ou em algum outro intervalo especificado. Aderir a um cronograma beneficiará a equipe e o produto, que é a essência do Agile.

O backlog do produto serve a muitos propósitos. É a lista canônica de requisitos que são totalmente especificados, em ordem de prioridade, e estão prontos para um desenvolvedor pegar e trabalhar.

Ele também serve como uma ferramenta de planejamento que mostra quais itens estão sendo trabalhados, quais são os próximos itens e fornece algumas informações sobre os recursos que estão em baixa na lista de prioridades.

As partes interessadas podem visualizar a lista de pendências e entender para onde o produto está indo e quando podem esperar ver a funcionalidade pela qual estão esperando. É uma ferramenta poderosa.

Mas além de ser um artefato útil para executar um projeto, também é uma boa maneira de incorporar os princípios do Agile.

Ter a equipe de desenvolvimento como atores completos na preparação dos requisitos e ter o proprietário do produto envolvido no design e na estimativa ajuda a unir a equipe e remove a situação “nós contra eles” com a qual todos lutamos no passado.

A preparação adequada ajuda o produto, a equipe e a organização.

Embora pareça sem importância, pode ser a coisa mais importante que você precisa para acertar.

Estes não são tipicamente parte da definição do “core Scrum”. No entanto, como histórias de usuários e preparação de backlog, são práticas incrivelmente úteis para muitas equipes.

Se você refletir de volta à introdução, essas equipes em dificuldades perderam de vista como pré-definir adequadamente seu trabalho.

Mas, para ser muito mais sucinto: é sempre uma boa prática para equipes ágeis garantir que suas histórias estejam prontas antes de colocá-las em um sprint.