Gerenciar o backlog é um aspecto importante para uma equipe funcional, pois ajuda a manter um ritmo sustentável de entregas relevantes e de boa qualidade.
Porém às vezes você percebe que seu backlog virou uma versão em estórias de usuário da grande bola de lama. Talvez não seja tarde demais para voltar aos eixos, então vamos ver algumas maneiras de você fazer isso.
Siga o Valor
Quem já viu o filme Todos os Homens do Presidente deve lembrar da dica do Garganta Profunda: siga o dinheiro. No desenvolvimento de software a dica é parecida: o foco deve estar nas coisas que vão agregar valor de negócio ao produto.
Então, se algo pode adicionar valor ao produto, vamos capturar isso em uma estória no backlog para jogá-la depois, certo? Bem, não tão depressa!
Empilhar estórias em um backlog unidimensional assumindo que elas irão de forma independente adicionar valor ao produto é uma das grandes fontes de aumento descontrolado do escopo (o temido scope creep. Isso é o princípio INVEST sendo levado muito ao pé da letra, algo que não funciona a longo prazo. Qualquer coisa que você incluir no backlog deve estar ligada a um objetivo claro e mensurável.
Organizando o Backlog
Em um projeto recente, nós tinhamos apenas um objetivo em alto nível descrito na forma de um Discurso de Elevador e onde as estórias de usuário eram criadas dentro de épicos. À medida que o projeto avançou, a equipe perdeu a noção de propósito das estórias no backlog. Os épicos apenas listavam coisas a fazer em vez de nos guiar rumo a uma direção planejada.
Planejar as iterações estava se tornando cada vez mais difícil e logo percebemos que havia mais estórias para jogar do que iterações para comportá-las.
Para resolver esse problema, planejamos um workshop de ajuste de backlog com quatro simples passos:
1. Identifique e priorize objetivos
No primeiro exercício do workshop, a equipe mapeou jornadas de usuário para identificar o que eles buscavam alcançar ao interagir com a aplicação. Nós então agrupamos essa informação na forma de objetivos para o produto.
Figura 1 - A jornada de usuário que mapeamos
Com base no que aprendemos com o exercício, foi fácil ver o potencial impacto de cada objetivo, o que nos ajudou a priorizá-los adequadamente.
2. Agrupe estórias por objetivos e usuários
Em seguida criamos uma matriz onde os objetivos foram dispostos no eixo horizontal, ordenados por prioridade, e os usuários no eixo vertical, organizados do mais ao menos impactado pelo produto.
Nós percorremos o backlog e, para cada estória de usuário, identificamos o usuário impactado na matriz e associamos a estória a um objetivo.
Figura 2 - Estórias agrupadas por objetivos e usuários
Após completar o exercício, conseguimos ter uma visão mais clara daquilo que queríamos alcançar, para quem e por quê. Foi possível então deixar para trás as estórias associadas aos objetivos menos prioritários, aqueles que não eram cruciais para o sucesso do produto.
A segunda decisão que tivemos de tomar foi como impactar nossos usuários. Podíamos dividir o trabalho em fatias verticais (buscando atingir um único objetivo por vez e impactando diversos usuários), ou fatias horizontais (buscando dar a um único usuário as funcionalidades que ele necessita para atingir diversos objetivos relevantes para ele).
Como esse produto implementava alguns workflows, fazia sentido focar em apenas um objetivo por vez, dando a todos os usuários envolvidos as funcionalidades que eles necessitavam para realizar sua parte do trabalho.
3. Escolha o que é mais importante
Ainda assim, isso não era o suficiente. O backlog continuava com mais estórias do que seria possível jogar no tempo restante do projeto.
Por isso dividimos as estórias restantes em três níves: Necessidades Básicas, Necessidades Negociáveis e Necessidades Incertas.
Figura 3 - Estórias sendo agrupadas por níveis
No nível das Necessidades Básicas, agrupamos as funcionalidades que deveriam ser implementadas para garantir que a mecânica básica do workflow era atendida. Eram experimentos pequenos o suficiente que podiam ser validados logo e nos dizer quão perto estávamos de atingir o objetivo.
No nível das Necessidades Incertas, agrupamos as estórias que eram claramente "interessantes de ter", no sentido de que não eram necessárias para permitir aos usuários atingirem seus objetivos. Elas cobriam possíveis melhorias (ou casos extremos) acerca de coisas sobre as quais ainda tínhamos de aprender mais para determinar seu real valor.
4. Negocie e foque nas partes mais importantes
Nesse momento já tínhamos certeza de duas coisas: as estórias que tínhamos de implementar e aquelas que poderíamos remover do escopo.
No nível do meio (Necessidades Negociáveis), agrupamos todas as estórias restantes. Para cada uma delas, tínhamos de nos perguntar o seguinte:
- Em relação ao objetivo, quanto valor essa estória representa?
- Podemos isolar a mecânica básica em outra estória (extraíndo a funcionalidade básica e deixando as partes restantes como "interessante de ter")?
Ao fazer essas perguntas, movemos uma quantidade razoável de trabalho para o nível acima de forma a não nos preocuparmos com ele por enquanto. Os itens restantes, as partes mais importantes, foram movidas para o nível das Necessidades Básicas.
E Agora? Sua Vez!
Através desses simples passos conseguimos chegar a um conjunto bem menor do backlog original para trabalhar, que nos permitiu experimentar e aprender bem mais depressa, ao mesmo tempo que garantia que os objetivos mais importantes estavam sendo focados.
Em vez de construir tudo aquilo que o backlog ordenava, focamos nas estórias de usuário que nos ajudariam a validar nossas premissas, desta forma adicionando mais valor em menos tempo. O tempo restante no projeto poderia então ser usado para revisitar (ou mesmo criar do zero) estórias que sabidamente trariam valor ao serem jogadas, uma vez que agora estávamos desenvolvendo o produto a partir dos objetivos.
Se você está passando pela mesma situação, por que não tenta esses simples passos? Eles nos ajudaram um monte e temos certeza de que mudar seu backlog para um orientado a objetivos irá trazer grandes resultados para você também!
Aviso: As afirmações e opiniões expressas neste artigo são de responsabilidade de quem o assina, e não necessariamente refletem as posições da Thoughtworks.