O refinamento do backlog do produto (PBR) é o processo contínuo de melhoria da lista de trabalhos (de software) a serem realizados. A PBR é a pedra angular para decidir o que deve ser feito e em que ordem. Neste artigo descrevemos as principais atividades de refinamento do backlog do produto e como elas podem ser aceleradas com o analisador de requisitos inteligente ScopeMaster®.
Refinamento do Backlog do Produto
O Refinamento do Backlog do Produto é a atividade regular realizada pela maior parte ou por toda a equipe em uma reunião com o objetivo de preparar atividades para as próximas iterações. As principais atividades são:
- Esclarecendo histórias de usuários, para que a equipe tenha um entendimento comum sobre eles.
- Dividindo histórias que são grandes demais para caber em uma iteração.
- Criando novas histórias de usuários e removendo outros de acordo com novos conhecimentos.
- Atribuindo estimativas para histórias
- Atribuindo prioridades para histórias
O refinamento do backlog do produto é uma atividade muito demorada e cara, normalmente consumindo de 5 a 15% de todo o tempo de trabalho das equipes. No entanto, é absolutamente essencial, pois é o passo fundamental para garantir que a equipe trabalhe nas coisas certas. Se não for gasto tempo suficiente nisso, a equipe perderá tempo em atividades erradas, o que pode custar ainda mais.
Vejamos cada uma dessas atividades de PBR com mais detalhes e vejamos como a automação pode ajudar.
O que entra no backlog do produto?
Um backlog de produto geralmente contém histórias de usuários (que descrevem funcionalidades), épicos de alta granularidade e histórias de usuários mais detalhadas. O backlog do produto deve excluir outras tarefas que possam estar envolvidas, mas que não entreguem diretamente a funcionalidade do usuário.
Atividades de Refinamento do Backlog:
1. Esclarecendo histórias de usuários
A língua inglesa é imensamente flexível. Temos muitas palavras alternativas para a mesma coisa. Podemos mudar a ordem das palavras para alterar o significado e mudar a forma como a história será interpretada. As variações são quase infinitas, mesmo uma história de usuário de 12 palavras tem 87 bilhões de permutações de ordem de palavras. Com cada variação, a interpretação do leitor provavelmente será ligeiramente diferente. E mesmo assim, a interpretação individual de uma história de usuário depende de seu próprio vocabulário e habilidade linguística. É mais do que provável que duas pessoas que leiam uma história de usuário tenham interpretações diferentes.
Se os membros da equipe não compartilham um entendimento comum sobre um item do backlog, é provável que aqueles que posteriormente trabalharem nele percam tempo construindo/testando a coisa errada. Um entendimento consistente por toda a equipe é, portanto, essencial para minimizar o desperdício de esforço.
De acordo com scrum.org “Normalmente, um item do Backlog do Produto passa por três reuniões de refinamento antes de ser considerado pronto.” Para tornar esta discussão frutífera, quanto melhor for a qualidade da história que entra na reunião, menos tempo será perdido.
A maioria dos itens do backlog descreve a intenção funcional, o Quem e O que da história do usuário. É aqui que o ScopeMaster pode eliminar completamente a ambiguidade numa fração do tempo, eliminando longas discussões.
2. Dividir histórias para caber em um sprint
As histórias de usuários ágeis devem ser concluídas em uma única iteração ou sprint (normalmente duas semanas). A conclusão de uma única história não deve abranger dois sprints. A conclusão também deve incluir todos os testes unitários. Se uma história for muito grande, ela precisará ser dividida em pedaços pequenos. Normalmente, um desenvolvedor será capaz de construir (incluindo testes unitários) cerca de 8 pontos de função COSMIC (CFP) por sprint. Essa estimativa de produtividade individual varia significativamente, mas se uma única história exceder 8 CFP, ela deverá ser compartilhada entre mais de um membro da equipe e/ou dividida em “pedaços” menores, cada um dos quais pode ser concluído em um sprint/iteração.
A capacidade do ScopeMaster de detectar o tamanho funcional fornece uma estimativa imediata sobre se uma história precisa ser dividida.
3. Criação de novas histórias de usuários e remoção de outras
As equipes de software precisam se adaptar às novas demandas dos negócios. Durante o refinamento do backlog será necessário dividir algumas histórias, criar novas e remover outras. Isso garante que o trabalho que está sendo realizado atenda às necessidades do negócio como são conhecidas atualmente. Criar novas histórias para atender às demandas em constante mudança é bom, mas as mudanças devem ser contidas sempre que possível, pois níveis excessivos de mudanças perturbam a equipe. Muitas “incógnitas” são de fato “cognoscíveis”. As mudanças devem ser limitadas às coisas que eram inicialmente incognoscíveis. Sempre que possível, é útil antecipar os requisitos globais o mais cedo possível. Isso ajuda a planejar o trabalho da equipe com mais eficiência.
A capacidade do ScopeMaster de analisar um conjunto de histórias de usuários em busca de funcionalidades ausentes ou duplicadas permite que a equipe obtenha uma melhor compreensão do escopo geral muito mais cedo.
4. Atribuindo estimativas às histórias
Estimar histórias é talvez um dos aspectos mais demorados do refinamento do backlog do produto. Normalmente, isso envolve jogar jogos de “pôquer de histórias”, onde os participantes da equipe adivinham o esforço necessário para contar a história em tamanhos de camisetas ou, posteriormente, em pontos de história (arbitrários). Não só é demorado, mas também cansativo, subjetivo, inconsistente e de pouca utilidade para o gerenciamento de projetos, especialmente em projetos de grande escala. Além disso, as estimativas de pontos da história são geralmente “jogadas” para alcançar um resultado específico.
A capacidade do ScopeMaster de estimar instantaneamente o tamanho funcional das histórias de usuários (em pontos de função COSMIC) significa que a equipe precisa gastar muito pouco tempo nas reuniões discutindo o tamanho da história. O tamanho funcional da história refinada é um valor consistente, padronizado e imutável. Isso libera tempo da equipe para discutir as melhores maneiras de como para contar a história de forma mais eficiente.
5. Atribuir prioridades às histórias
Priorizar histórias é uma consequência de quão importantes elas são para o negócio, de quais outras histórias dependem delas e de quanto esforço serão necessárias para serem entregues. Se as outras atividades de refinamento do backlog já tiverem sido parcialmente ou quase totalmente automatizadas, a equipe poderá passar mais tempo discutindo isso nas reuniões de refinamento do backlog. Isso ajudará a garantir que a equipe faça o mais importante as coisas na ordem certa.
