Tudo o que você precisa saber para construir um Backlog profundo e produtivo. Um backlog de produto (ou backlog) é uma lista priorizada de recursos, melhorias e correções de bugs que precisam ser desenvolvidos para criar um produto de sucesso. Mas como criar (e manter) um backlog eficiente? Deixe-me apresentar-lhe o DEEP
Pense em um produto digital onde as coisas precisam ser desenvolvidas em uma ordem específica para alcançar a visão do produto: esse é o backlog do produto (também conhecido como backlog).
O product backlog é um artefato scrum que consiste em um documento dinâmico, constantemente atualizado com base no feedback dos stakeholders, mudanças no mercado e novos insights obtidos durante o processo de desenvolvimento. Ele pertence ao proprietário do produto e é usado pela equipe de desenvolvimento para planejar seu trabalho durante cada sprint e entregar valor ao cliente.
Para garantir que o backlog seja eficiente e completo, ele precisa ser PROFUNDO: Detalhado, Emergente, Estimado e Priorizado. Para algumas equipes, a cerimônia de refinamento do backlog do produto pode ajudar (é opcional).
Seguindo essas metodologias é possível criar um backlog eficiente e completo, com histórias claras e tarefas bem definidas. Isso ajuda a equipe de desenvolvimento a trabalhar com mais eficiência e a entregar um produto de qualidade aos usuários.
Pendências PROFUNDAS
DEEP
Um backlog de produto (ou backlog) é uma lista priorizada de recursos, melhorias e correções de bugs que precisam ser desenvolvidos para criar um produto de sucesso. É um documento dinâmico, constantemente atualizado com base no feedback das partes interessadas, nas mudanças do mercado e nos novos insights obtidos durante o processo de desenvolvimento.
Existem algumas técnicas para criar um backlog de produto bem-sucedido, e uma delas é o DEEP Backlog. “DEEP” é um acrônimo para um conjunto de características que um backlog de produto deve ter para atingir um backlog que defina exatamente as necessidades do cliente: Detalhado, Emergente, Estimado e Priorizado.
De acordo com Roman Pichler, cocriador da abordagem DEEP backlog, “para garantir que o backlog do produto seja PROFUNDO e permaneça assim, é necessário prepará-lo ou aperfeiçoá-lo regularmente. Preparar o backlog do produto é um processo contínuo e colaborativo que envolve o proprietário do produto e a equipe.”
Agora, vamos entender cada letra da sigla:
D – Detalhado adequadamente
Isso significa que o backlog do produto deve ter detalhes suficientes para garantir clareza na execução, mas não excessivamente detalhado para evitar desperdícios. Os itens que serão realizados nos próximos sprints (mais urgentes) deverão ser melhor detalhados, enquanto os itens programados para vários sprints posteriormente podem ter menos detalhes.
Uma técnica para atingir esse nível de detalhe é a Regra 20/30/50, introduzida por Bob Galen em seu livro “Scrum Product Ownership”. De acordo com esta regra, os itens do product backlog devem ser divididos em três categorias:
- 20% de itens de alta prioridade: as histórias de usuários mais críticas, detalhadas e valiosas, que serão iniciadas no próximo sprint.
- 30% de itens de prioridade média: as histórias de usuários moderadamente críticas, claras e bem compreendidas, mas não tão detalhadas quanto as histórias de usuários de alta prioridade, que serão lançadas em alguns sprints (4 a 10 sprints).
- 50% de itens de baixa prioridade: histórias de usuários que ainda não estão prontas para trabalho ou discussão, o proprietário do produto deve revisá-las regularmente e decidir se ainda se enquadram nos planos de produtos futuros. Próximos sprints futuros (10+).
E – Estimado
Quando um item do backlog é estimado, significa que a equipe de desenvolvimento forneceu uma estimativa da quantidade de esforço ou trabalho necessário para concluir esse item. O objetivo da estimativa de esforço é fornecer uma compreensão relativa da complexidade e do tamanho de cada item do backlog.
A estimativa de esforço pode estar em várias unidades. Neste ponto, vale citar os mais comuns: pontos da história, horas e tamanho da camiseta.
Pontos da história
Os pontos da história fornecem um método para determinar o nível de esforço necessário para concluir uma tarefa listada na lista de pendências do projeto. Normalmente, essas estimativas são determinadas antes de uma reunião de planejamento do sprint, durante a qual sua equipe aloca trabalho para um período futuro. Esses pontos da história consideram três fatores críticos que influenciam a complexidade e o esforço da tarefa, com o valor dos pontos atribuídos aumentando em resposta a desafios maiores:
- Risco: o nível cumulativo de incerteza associado a uma tarefa. Por exemplo, se a tarefa envolver o envolvimento de terceiros, empreiteiros ou envolvimento com as partes interessadas do projeto, poderá elevar o nível geral de risco;
- Repetição: experiência da equipe com tarefas semelhantes;
- Complexidade: o nível de dificuldade da tarefa.
Ao fazer estimativas no Agile, as equipes usam normalmente a sequência de Fibonacci (0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100) para determinar o nível de esforço. Uma dica para entender melhor o que cada número significa para sua equipe é criar uma Matriz de Story Points que pode ser evoluída conforme a experiência adquirida pela equipe, por exemplo:
Dimensionamento de camisetas
O dimensionamento de camisetas é um método para estimar e planejar a capacidade de um projeto, permitindo avaliar o tempo ou esforço previsto necessário para uma iniciativa. Nesta abordagem, a cada projeto ou tarefa é atribuído um tamanho de camiseta, que varia de Extra Pequeno a XXL, para simbolizar o esforço relativo da tarefa. Dependendo do seu uso específico, esse dimensionamento pode indicar vários aspectos, como escopo da tarefa, esforço, complexidade, horas de trabalho, estimativas de tempo ou uma combinação desses fatores.
Veja como funciona o tamanho da camiseta:
- Tamanhos: em vez de atribuir valores numéricos específicos (como pontos de história na sequência de Fibonacci), os membros da equipe usam tamanhos de camisetas, como Pequeno, Médio, Grande ou Extra Grande, para indicar o tamanho relativo ou o esforço de um item. Esses tamanhos são geralmente escolhidos para serem fáceis de entender e lembrar.
- Comparação: os membros da equipe discutem e comparam o item que estão estimando com outros itens conhecidos no backlog. Por exemplo, eles podem dizer: “Este novo recurso é maior que o ‘Médio’, mas menor que o recurso ‘Extra grande’ que concluímos da última vez”.
- Consenso: Através da discussão, a equipe chega a um consenso sobre o tamanho apropriado da camiseta para o item. Isso pode levar a uma melhor compreensão e alinhamento dentro da equipe.
É claro que o dimensionamento é diferente para cada equipe, mas uma forma de defini-lo é:
E – Emergente
O Product Backlog é dinâmico e passa por mudanças contínuas. À medida que o projeto avança, ele reúne quantidades crescentes de informações e insights, resultando na adição, remoção ou reorganização de histórias de usuários no Backlog do Produto. Isso significa que o backlog do produto não é estático e evolui à medida que o Product Owner aprende mais sobre o produto e recebe feedback do mercado sobre seus lançamentos, como seu Produto Mínimo Viável (MVP).
O objetivo da evolução do backlog é mantê-lo alinhado e no caminho certo com o plano do produto, por isso o backlog do produto deve ter a capacidade de ser atualizado frequentemente, de forma que seja possível incluir User Stories relevantes e remover aqueles que não estão mais alinhados com o objetivo.
P – Priorizado
Para ter um product backlog eficaz e eficiente, é importante priorizá-lo de forma que os itens mais necessários e urgentes sejam indicados no topo (de alto valor para o negócio), enquanto os menos urgentes serão alocados abaixo (menor valor para o negócio). Isso significa que a ordem dos itens do backlog é importante, pois eles serão desenvolvidos nesta ordem. Um acordo claro destaca o nosso caminho para alcançar resultados ótimos e garante que o nosso foco permanece no que melhor se alinha com as nossas metas e objetivos estratégicos.
Existem várias técnicas para priorizar um backlog de produto, como Stack Ranking, Modelo Kano, Método MoSCoW e Custo de Atraso. Todos eles são úteis para priorizar o backlog, mas acho que devo destacar especialmente o método MoSCoW à medida que seu uso está aumentando.
MoSCoW
O método MoSCoW, originalmente formulado pelo pioneiro cientista de dados Dai Clegg, tem suas origens no domínio do desenvolvimento ágil de software. A sigla MoSCoW é uma técnica utilizada em gerenciamento de projetos para priorizar os itens do backlog conforme a criticidade de cada um deles. Esta sigla significa quatro categorias prioritárias:
- Must-Have: Itens classificados como “Must-Have” são requisitos ou recursos essenciais e críticos necessários para o sucesso do projeto. Eles são absolutamente necessários e não podem ser omitidos.
- Deveria ter: Os itens “deveria ter” são importantes, mas não vitais. Contribuem significativamente para o projeto, mas atrasar ou adiar estes itens não prejudicariam imediatamente o sucesso do projeto.
- Poderia ter: Itens “poderia ter” são desejáveis, mas não essenciais. São vistos como bons acréscimos ao projeto, mas podem ser adiados ou excluídos se houver restrições de tempo ou recursos.
- Não-ter: Itens “não-ter” são requisitos ou recursos que não serão incluídos na versão atual do projeto. Eles podem ser considerados para futuras iterações, mas não fazem parte do escopo imediato.
O método MoSCoW é uma ferramenta valiosa para as equipes de projeto priorizarem o trabalho e alinharem as expectativas com as partes interessadas. Ajuda a evitar a inclusão de requisitos desnecessários e concentra esforços nas áreas mais críticas para o sucesso do projeto.
Tudo o que você precisa saber para construir um backlog de produto PROFUNDO e produtivo: considerações finais
Em resumo, a estrutura de backlog DEEP simplifica o gerenciamento de backlog em projetos ágeis. Ao manter as coisas detalhadas, emergentes, estimadas e priorizadas, promove eficiência, colaboração e adaptabilidade. É uma ferramenta valiosa para entregar resultados que realmente importam em um projeto Agile dinâmico.
E se você não sabe o que significa Agile, te convido a ler os dois artigos abaixo sobre esse assunto, tenho certeza que vai esclarecer as coisas e dar uma boa compreensão desse framework.
Você já se perguntou se Ágil significa Rápido? Este artigo pode responder a esta pergunta!
Agora que você é um mestre em Agile e seus conceitos, vamos entender como podemos introduzir esse importante conceito em nossa mentalidade diária !
Fonte: Laís Ortiz – tradução: Google Translate.
