Como a lista de pendências do produto se encaixa na estrutura do projeto
Primeiro, vamos definir claramente o que é a lista de pendências do produto. O Scrum organiza os projetos em Sprints, uma série de períodos de concentração em trabalhos específicos, que costumam durar em torno de duas semanas. Antes do início do Sprint, a equipe e o Scrum Master (que atua como um orientador) criam a lista de pendências do Sprint, que é uma lista incluindo o que se pretende realizar no próximo Sprint.
A lista de pendências do Sprint é extraída da lista de pendências mais ampla do produto, que é a lista completa de todos os recursos e funcionalidades que precisam ser acrescentados a ele. O proprietário do produto é responsável por priorizar a lista de pendências do produto. (O proprietário do produto também defende as necessidades do cliente e de outras partes interessadas e orienta o trabalho da equipe de desenvolvimento.) A lista de pendências do produto é classificada verticalmente para que as tarefas mais importantes sejam listadas no topo, e a equipe Scrum geralmente seleciona itens da lista de pendências com base na prioridade. A lista de pendências do produto mudará e evoluirá ao longo do tempo com base nas solicitações dos usuários, necessidades empresariais e tendências tecnológicas mais amplas.
Como observação, você também pode fazer uso de uma lista de pendências de produto em outra estrutura do Agile chamada Kanban. Embora o Kanban se proponha a limitar o trabalho em andamento (WIP) em vez de usar Sprints de tamanho fixo (Scrum), as informações neste artigo também podem ser aplicadas a projetos do Kanban.
Uma lista de pendências do produto bem construída garante que o trabalho seja produtivo e valioso, que o produto atenda às necessidades do cliente e que esteja alinhado às metas da organização. Assim como na sua lista pessoal de tarefas, você precisa gerenciar constantemente a lista de pendências do produto. Este processo é muitas vezes chamado de refino ou preparação da lista de pendências do produto. Prioridades mudam, tarefas são realizadas e ideias são descartadas. Se não for atualizada, sua lista de pendências ficará desorganizada, e não ajudará você a se manter em dia.
Como criar sua primeira lista de pendências do produto
Para começar a criar uma lista de pendências, alguns especialistas em Agile recomendam começar com um roteiro do produto. Trata-se de um plano estratégico que oferece uma perspectiva de longo prazo do produto. Roman Pichler, um instrutor especialista em gerenciamento de produtos com o Agile, diz que muitos proprietários e gerentes de produtos se concentram demais em detalhes de recursos em seus roteiros, mas não o suficiente no quadro geral. Ele desenvolveu um modelo de roteiro orientado por metas que enfatiza as metas almejadas pelo produto e os recursos necessários para alcançá-las.
Embora seu roteiro possa incluir metas de longo prazo para vários lançamentos, a lista de pendências do produto deve se concentrar em listar o trabalho para o próximo lançamento de maneira mais aprofundada. Lançamentos futuros devem ser colocados mais abaixo e expressos com menos detalhes. Em seguida, as informações do roteiro devem ser traduzidas em tarefas e itens de trabalho.
Cada produto deve ter sua própria lista de pendências. Se o seu produto é bastante grande ou parte de um conjunto de produtos inter-relacionados, talvez haja confusão ao determinar qual é sua constituição. O especialista em Agile Kenneth Rubin, consultor da Innolution, diz que a meta é minimizar o número de equipes e listas de pendências de componentes, então ele prefere usar uma única lista de pendências sempre que possível. No entanto, em projetos muito grandes com dezenas ou centenas de equipes, isso não é prático e, nesses casos, as listas de pendências hierárquicas podem ser usadas com uma única lista de pendências para recursos de grande escala e uma lista de pendências separada para cada área de trabalho relacionada.
Histórias de usuário estão no centro da lista de pendências do produto
Os itens de trabalho na lista de pendências do produto geralmente são expressos nas chamadas histórias do usuário, uma descrição de como o recurso funcionará do ponto de vista do usuário. Uma história de usuário é pequena o suficiente para que possa ser realizada em um Sprint.
Chuck Kroll, instrutor do Agile que treinou equipes na Fidelity Investments, recomenda uma fórmula tradicional para as histórias de usuários: "Como (tipo de usuário, como cliente), eu quero (meta) para que (razão)", afirma Kroll. "Isso deixa claro quem usará o recurso, o que ele implica e qual valor comercial ele oferece."
História do usuário versus Epic do usuário: o quanto os itens da lista de pendências devem ser detalhados?
Uma história muito maior do que um "epic" e pode se estender por vários Sprints. Os epics precisam ser divididos em histórias antes que o trabalho possa começar.
Mike Cohn, fundador da Mountain Goat Software que oferece treinamento sobre o Agile e Scrum, traz o seguinte exemplo de um epic: uma empresa hoteleira quer um sistema para determinar o valor máximo que pode ser cobrado por um quarto de hotel dependendo de variáveis como tarifas dos concorrentes, temporada etc. "Como operador do setor hoteleiro, quero definir a tarifa ideal para os quartos do meu hotel." Isso gera histórias de usuários como estas: "Como operador do setor hoteleiro, quero definir a tarifa ideal para quartos com base nos preços do ano anterior" e "Como operador do setor hoteleiro, quero definir a tarifa ideal para quartos com base no que hotéis comparáveis aos meus estão cobrando".
Ao preparar histórias de usuários para lista de pendências do produto, os itens de maior prioridade devem ter mais detalhes para ajudar a equipe a executá-los com precisão. Esse detalhamento pode incluir diagramas mostrando o fluxo de trabalho de um recurso ou uma descrição de seus detalhes.
"Na minha visão, a orientação mais importante sendo negligenciada é a de que nem todos os itens da lista de pendências do produto precisam do mesmo nível de detalhamento", afirma Cohn. "Os itens que entram no próximo Sprint exigem um detalhamento moderado. Itens mais distantes devem ser progressivamente menos detalhados."
Imagine a seguinte história de usuário: como visitante de um site, quero poder comprar uma passagem de avião pelo menor preço oferecido à minha primeira opção de aeroporto ou aeroportos próximos. Como essa exigência está praticamente no topo da lista da lista de pendências do produto, você deve adicionar detalhes à história do usuário, por exemplo: a função deve verificar as tarifas de todos os aeroportos dentro de 100 milhas; deve permitir classificar as tarifas por distância ou por preço da minha primeira opção de aeroporto.
Pichler recomenda que o ciclo de vida do produto é importante para decidir qual nível de granularidade a lista de pendências do produto deve ter. Produtos novos devem ter listas de pendências menores e menos detalhadas. Isso permite que você experimente novas ideias e as otimize com alterações frequentes. Por outro lado, produtos mais antigos e estáveis se beneficiam de uma lista de pendências mais detalhada, porque você tem uma maior capacidade de antecipar como eles evoluirão.
O ciclo de lançamento é outro fator na lista de pendências do produto. Há mais incógnitas quando você começa a trabalhar em uma nova versão ou um grande lançamento, e o que você aprende pode resultar em grandes mudanças na lista de pendências. Portanto, uma lista de pendências do produto mais curta e menos detalhada faz sentido no início do ciclo de lançamento, explica Pichler.
Bill Wake, consultor do Agile que agora trabalha com a Industrial Logic Inc, apresentou um modelo amplamente utilizado e mnemônico para as características de uma boa história de usuário usando a sigla INVEST:
I – Independente: as histórias não devem se sobrepor e, idealmente, podem ser implementadas em qualquer ordem.
N – Negociável: a história captura a essência, mas não os detalhes, que são definidos em acordo com os participantes.
V – Valioso: a história oferece um valor claro para o cliente.
E – Estimável: você é capaz de avaliar o esforço envolvido. Isso pode ser uma estimativa de tempo ou aquilo que é chamado de pontos da história, uma unidade arbitrária de medição que classifica a complexidade relativa (como XS, S, M, L, XL ou 1, 2, 4, 8, 16).
S – Pequeno: "boas histórias tendem a ser pequenas", afirma Wake. Isso significa que a história deve ser realizada em (no máximo) algumas semanas de trabalho de 40 horas de uma pessoa dedicada ou dividida entre os membros da equipe.
T – Testável: a história do usuário deve ser mensurável ou acionável de alguma forma, segundo Ulf Eriksson, fundador e proprietário do produto da plataforma de testes de TI ReQtest.
Outros itens que pertencem à lista de pendências de produto
Cohn enfatiza que nem todos os itens da lista de pendências precisam ser uma história de usuário. "Conheço equipes que acham que cada item da lista de pendências do produto deve ser uma história de usuário. As histórias de usuários são ótimas, mas apenas quando existem usuários para as histórias. Mas algumas coisas que pertencem a uma lista de pendências de produto não se destinam necessária e diretamente aos usuários. Esses itens não precisam ser escritos como histórias de usuário."
Isso inclui trabalho no back-end ou outras tarefas que estão distantes dos usuários. Cohn recomenda descrever essas tarefas usando a sintaxe de desenvolvimento orientado por recursos (FDD) (verbo + resultado + objeto, ou seja, "Validar a senha de um usuário").
Os quatro tipos de itens comumente encontrados nas listas de pendências do Scrum são recursos, bugs, trabalho técnico e aquisição de conhecimento. Os recursos geralmente podem ser expressos como histórias de usuário, enquanto os outros itens não.
Se você está bem no início, não se preocupe: você não precisa começar o projeto com uma lista de pendências de produto perfeita. Comece fazendo um brainstorming das tarefas necessárias, o que fornecerá informações suficientes para o seu primeiro Sprint. Em seguida, você pode expandir a lista de pendências à medida que aprende mais sobre o produto, as necessidades do usuário e o feedback.
"Minha principal dica em relação a listas de pendências de produtos seria manter a simplicidade. Ela é apenas uma estrutura analítica de produto ordenada", diz Laurens Bonnema, consultor do Agile na Xebia, nos Países Baixos.
C.J. Boat, líder de uma equipe Agile para o mercado de seguros Ensurem, concorda com isso. "Tenha expectativas razoáveis! Se você deixar a lista de pendências ficar muito grande ou não organizar adequadamente o trabalho, a lista de pendências e os sprints podem ficar tão sobrecarregados que vão desmoronar", disse ele.
Como priorizar e solicitar a lista de pendências do produto
Depois de adicionar as tarefas, é hora de ordenar a lista de pendências do produto. Coloque o trabalho mais importante no topo. Você pode fazer isso com base em sua classificação de prioridade, decidindo como ordenar itens com a mesma prioridade conforme avança.
"À medida que adicionar tarefas à lista de pendências, atribua a elas uma classificação inicial de prioridade", diz Kevin Lonergan, consultor principal de gerenciamento de projetos da PMIS Consulting, na Grã-Bretanha. "Uma prioridade simples de três níveis é o bastante: 1 - fundamental para atingir as metas de negócio, 2 - útil, mas não fundamental, 3 - seria um bônus se esses itens fossem concluídos."
Alguns profissionais dizem que um método melhor é ordenar a lista por outros critérios, como risco, ROI, custo-benefício, um modelo de bucket como MoSCoW (precisa ter, deveria ter, poderia ter, não terá), o impacto que uma história tem em outra, tempo estimado para implementar ou dependências.
Bonnema, da Xebia, prefere o método WSJF (Weighted Shortest Job First, ou menor trabalho ponderado primeiro) descrito por Donald Reinertsen em "The Principles of Product Development Flow" e desenvolvido por Dean Leffingwell, criador do Scaled Agile Framework. É uma fórmula para priorizar a lista de pendências de produto com base na duração da tarefa e uma ponderação para o custo do atraso. "Não encontrei uma maneira melhor de priorizar consistentemente as listas de pendências em todos os níveis corretamente do que o WSJF", disse Bonnema. As tarefas permanecem na lista de pendências do produto até que sejam concluídas ou até que o proprietário do produto decida que não são mais necessárias.
Para determinar quando uma história de usuário está concluída e pode ser removida da lista de pendências, as equipes devem desenvolver uma "definição de conclusão" padronizada. Este é o critério de aceitação de um recurso que garante que todos os membros da equipe saibam o que é esperado do trabalho que eles entregam. Kelly Waters, autor do livro All About Agile, acredita que "concluído" deve significar que algo pode ser entregue. Jeff Sutherland, CEO da Scrum Inc., usa a popular frase do Agile "definitivamente concluído," que significa que, no final do sprint, a codificação foi concluída e o teste de software está concluído no nível de recursos, sem bugs. Quando a definição de conclusão da sua equipe é satisfeita, um item pode ser movido da lista de pendências do produto para a coluna de conclusão.
Passo a passo: como criar uma lista de pendências do produto
Agora que você sabe o que é uma lista de pendências do produto e o que pertence e não pertence a ela, está na hora de ver a lista de verificação para criar sua primeira lista de pendências do produto:
- Um proprietário do produto é responsável pela lista de pendências do produto. Se você for essa pessoa, esteja ciente de que a criação da lista de pendências do produto é sua responsabilidade. Mas isso não significa fazer todo o trabalho. Os membros da equipe do Scrum e outras partes interessadas podem participar.
- Lembre-se de que a lista de pendências é a lista completa de todas as histórias de usuários e outros itens de trabalho do produto.
- Pense em todas as tarefas que puder e anote-as. Seja o mais específico possível e peça opiniões de todas as partes relevantes da sua organização e feedback dos clientes.
- Crie histórias do ponto de vista do usuário e inclua uma ação e um motivo. (Como _, eu quero _, para que_.) Pense em todos os usuários diferentes. Escreva quem são essas pessoas em cartões de índice ou use uma ferramenta on-line. Aplique etiquetas para esclarecer o lançamento planejado.
- Inclua correções de bugs, aquisição de conhecimento e trabalho técnico.
- Como proprietário do produto, você classifica a importância de cada item para a organização, variando de muito alto a muito baixo ou outro método. Você pode questionar os usuários para ter uma base sólida para essas decisões.
- Para cada item de trabalho, dê também uma estimativa de quanto esforço está envolvido.
- Classifique a lista de pendências do produto.
- O trabalho que a equipe se compromete a realizar em um Sprint é a lista de pendências do Sprint, que é separada da lista de pendências do produto. A lista de pendências do Sprint não muda depois que ele inicia. Quando os itens estão "definitivamente concluídos", são considerados concluídos e removidos das listas de pendências do Sprint e do produto.
- Quando um novo trabalho chegar, adicione-o à lista de pendências do produto na posição certa. Ao coletar novas informações, como feedback, você pode excluir ou reordenar itens.
Quando terminar, o resultado deve ser parecido como o seguinte:
Nesse momento, você merece os parabéns se tiver elaborado com sucesso sua primeira lista de pendências do produto e feito a sua equipe de Scrum trabalhar em um lote de histórias de usuários valiosas em um sprint. Mas ainda não é hora de relaxar.
Como manter a lista de pendências do produto atualizada
Uma vez criada, a lista de pendências do produto precisa de manutenção e atualização constante. Esse processo, também conhecido como preparação ou refinamento da lista de pendências do produto, mantém sua lista de pendências atualizada com base nas informações do mercado, dos usuários, da equipe de produtos e da gerência da organização. Ao manter a preparação da lista de pendências em dia, você garante que a equipe de desenvolvimento esteja sempre colocando os esforços nas coisas certas, que tudo esteja pronto para o próximo Sprint, que os recursos estejam sendo bem utilizados e que o melhor produto possível seja entregue ao cliente.
Uma maneira fácil de lembrar o objetivo do processo de refinamento da lista de pendências do produto é pelo uso da sigla DEEP. Sua meta é garantir que a lista de pendências do produto seja sempre DEEP:
D – Detalhada adequadamente para que os itens no topo da lista tenham mais detalhes do que os da parte inferior.
E – Estimada: cada item da lista de pendências do produto, ou pelo menos aqueles envolvidos na próxima versão, deve ser estimado seguindo pontos da história ou uma linha de tempo. À medida que sua equipe for acumulando trabalho, a velocidade (a taxa em que os itens da lista de pendências do produto são terminados) ficará mais evidente, o que facilitará a estimativa.
E – Emergente: significa que a lista de pendências do produto é adaptada a novos itens ou informações que surgem.
P – Priorizada: todos os itens da lista de pendências do produto são ordenados com os mais importantes na parte superior.
As melhores dicas dos profissionais sobre como gerenciar a lista de pendências do produto
Mesmo com os melhores esforços para manter a lista de pendências do produto funcionando sem problemas, falhas podem surgir. Especialistas no Agile que trabalharam com muitas equipes e em uma variedade de projetos têm dicas sobre como solucionar e evitar problemas.
Segundo Kroll, instrutor do método Agile, os problemas mais comuns que ele observa surgem da falta de participação dos patrocinadores do projeto, que precisam estar envolvidos diariamente, e uma tendência de pressionar a equipe a cumprir metas de tempo que não são orientadas pelo rendimento real da equipe. A solução é que os gerentes mudem de uma mentalidade de projeto tradicional "planejada versus real" para uma abordagem Agile.
Jonathan Roger, gerente de projetos e Scrum master da AndPlus, recomenda manter um repositório de espera na parte inferior da lista de pendências do produto para ideias não priorizadas e não preparadas. "Os proprietários de produtos podem monitorar os recursos que são desejados em longo prazo sem a pressão de mantê-los em uma ordem de prioridade, e as equipes podem adicionar suas ideias em potencial para a revisão do proprietário do produto. Esse repositório também serve como um bom ponto de partida para solicitações de recursos de clientes ou partes interessadas."
Lonergan, da PMIS Consulting, recomenda uma criteriosa seleção do proprietário do produto como uma chave para o sucesso. "Apenas uma pessoa deve desempenhar o papel de proprietário do produto, não um comitê", enfatiza. Essa pessoa é responsável pela lista de pendências do produto. Garanta que o proprietário do produto conduza o desenvolvimento da lista de pendências."
"O erro número 1 é, sem dúvida, escolher a pessoa errada como proprietário do produto, ou seja, alguém que não tenha autoridade, conhecimento do domínio, tempo etc.", acrescenta Lonergan.
Use o Smartsheet para manter e gerenciar as listas de pendências de produtos com facilidade
Do gerenciamento de tarefas simples e planejamento de projetos à gestão de portfólio e recursos complexos, o Smartsheet ajuda a melhorar a colaboração e acelerar a velocidade do trabalho — aumentando sua produtividade. Com a plataforma Smartsheet fica fácil planejar, coletar informações, gerenciar e criar relatórios sobre o trabalho de qualquer lugar, ajudando sua equipe a ser mais eficiente e mostrar resultados. Crie relatórios sobre as principais métricas e obtenha visibilidade do trabalho em tempo real, à medida que ele acontece, através de relatórios, painéis e fluxos de trabalho automatizados criados para manter sua equipe conectada e informada. Quando as equipes têm clareza sobre o trabalho que está sendo realizado, elas podem ser muito mais produtivas durante o mesmo período. Experimente o Smartsheet gratuitamente hoje mesmo.