A well-prioritized agile backlog not only makes release and iteration planning easier, it broadcasts all the things your team intends to spend time on—including internal work that the customer will never notice. This helps set expectations with stakeholders and other teams, especially when they bring additional work to you, and makes engineering time a fixed asset.
O que é uma lista de pendências de produtos?
O backlog do produto é a lista priorizada de trabalho para a equipe de desenvolvimento, derivado do roteiro do produto e seus requisitos. Os itens mais importantes são mostrados na parte superior do backlog do produto para que a equipe saiba o que entregar primeiro. A equipe de desenvolvimento não trabalha no backlog no ritmo do proprietário do produto, e o proprietário do produto não encaminha trabalho para a equipe de desenvolvimento. Em vez disso, a equipe de desenvolvimento pega o trabalho do backlog do produto de acordo com a capacidade, em ritmo contínuo (kanban) ou por iteração (scrum).
Keep everything in one issue tracker–don’t use multiple systems to track bugs, requirements, and engineering work items. If it's work for the development team, keep it in a single backlog.
Comece com os dois "Rs"
A team's roadmap and requirements provide the foundation for the product backlog. Roadmap initiatives break down into several epics, and each epic will have several requirements and user stories. Let's take a look at the roadmap for a ficticious product called Teams in Space.
Como o site Teams in Space é a primeira iniciativa no roteiro, a gente vai dividir essa iniciativa em epics (mostrados aqui em verde, azul e azul-petróleo) e histórias de usuários para cada um desses epics.
O proprietário do produto organiza as histórias dos usuários em uma lista única para a equipe de desenvolvimento. O proprietário do produto pode decidir oferecer um epic completo primeiro (esquerda). Ou pode ser mais importante para o programa testar reservar um voo com desconto, o que exige histórias de vários epics (direita). Veja os dois exemplos abaixo.
O que pode influenciar a priorização do proprietário do produto?
- Prioridade do cliente
- Urgência no recebimento de feedback
- Dificuldade de implementação relativa
- Relações simbióticas entre itens de trabalho (por exemplo, B é mais fácil se fizermos A primeiro)
Apesar do proprietário do produto ser incumbido de priorizar o backlog, essas prioridades não vêm do nada. Proprietários de produtos eficazes procuram comentários e feedbacks dos clientes, designers e da equipe de desenvolvimento para otimizar a carga de trabalho e a entrega do produto para todos.
Como gerenciar um backlog do produto com eficácia
Depois que o backlog do produto for criado, é importante trabalhar com ele para acompanhar o ritmo do programa. Os proprietários de produtos devem revisar o backlog antes de cada reunião de planejamento de iteração para garantir que as prioridades estão corretas e que o feedback da última iteração foi incorporado. A revisão regular do backlog costuma ser chamada de "revisão de tarefas" nos círculos ágeis (alguns usam o termo refinamento do backlog).
Once the backlog gets larger, product owners need to group the backlog into near-term and long-term items. Near-term items need to be fully fleshed out before they are labeled as such. This means complete user stories have been drawn up, collaboration with design and development has been sorted out, and estimates from development have been made. Longer term items can remain a bit vague, though it's a good idea to get a rough estimate from the development team to help prioritize them. The key word here is "rough": estimates will change once the team fully understands and begins work on those longer term items.
O backlog serve como a conexão entre o proprietário do produto e a equipe de desenvolvimento. O proprietário do produto tem a liberdade de alterar as prioridades do trabalho no backlog a qualquer momento de acordo com o feedback dos clientes, redefinindo as estimativas e novas exigências. No entanto, quando o trabalho estiver em andamento, faça o mínimo de alterações, pois elas interrompem a equipe de desenvolvimento e afetam o foco, o fluxo e o ânimo.
Se o backlog crescer além da capacidade de longo prazo da equipe, não há problema em fechar itens que a equipe nunca vai conseguir fazer. Sinalize esses itens com uma resolução específica como "fora do escopo" no rastreador de itens da equipe para usar em pesquisas futuras.
Antipadrões que devem ser observados
- O proprietário do produto prioriza a lista de pendências no início do projeto, mas não a ajusta à medida que o feedback passa pelos desenvolvedores e pelas partes interessadas.
- A equipe limita itens na lista de pendências àqueles que estão voltados ao cliente.
- A lista de pendências é mantida como um documento armazenado localmente e compartilhado com pouca frequência, impedindo que as partes interessadas recebam atualizações.
Os backlogs do produto deixam as equipes ágeis
Os proprietários de produto inteligentes organizam rigorosamente a lista de pendências de produto de seu programa, tornando-a uma ferramenta de destaque confiável e compartilhável dos itens de trabalho de um projeto.
Stakeholders will challenge priorities, and that's good. Fostering discussion around what's important gets everyone's priorities in sync. These discussions foster a culture of group prioritization ensuring everyone shares the same mindset on the program.
O backlog do produto também serve como a base para o planejamento de iteração. Todos os itens de trabalho devem ser incluídos no backlog: histórias do usuário, bugs, alterações de design, débito técnico, solicitações de clientes, itens de ação da retrospectiva etc. Assim, os itens de trabalho de todos são incluídos na discussão geral para cada iteração. Os membros da equipe podem fazer concessões com o proprietário do produto antes de começar uma iteração com conhecimento completo de tudo que precisa ser feito.
Os proprietários de produto ditam a prioridade dos itens de trabalho no backlog, enquanto a equipe de desenvolvimento dita a velocidade de trabalho no backlog. Isso pode ser uma relação tênue para os novos proprietários de produto que querem "empurrar" trabalho para a equipe. Saiba mais em nosso artigo sobre fluxo e limites do trabalho em andamento.
Tudo pronto para começar? Saiba como criar o backlog no Jira.
Priorize o que importa com o template de scrum do Jira
Obtenha visibilidade total de todo o trabalho a ser feito, para que você possa se concentrar no maior impacto.
Recursos relacionados
