Já ouviu falar em story points? Peça para um desenvolvedor de software adivinhar quantas jujubas há em um pote. Você provavelmente vai ouvir algum raciocínio algorítmico e uma resposta frustrantemente exata.
Fazer uma “guesstimation” sem um raciocínio não é o forte da maioria dos desenvolvedores.
É por isso que estimar o tempo necessário para cuidar dos projetos a fim de se planejar para a semana seguinte costuma ser o projeto com mais chance de fazer todos enlouquecerem.
Conheça os story points. A resposta quantitativa para essa pergunta ambígua.
O que são story points ágeis?
Enquanto a maioria das equipes estima a dificuldade de uma tarefa pelo tempo (metade do dia, uma semana ou um mês), os story points são um método para medir o esforço em uma escala relativa. Atribuir tarefas com base na dificuldade relativa permite uma representação mais precisa do esforço esperado. Isso porque, diferentemente das estimativas de tempo, eles se referem apenas à tarefa em questão (e não a e-mails, reuniões ou atrasos inesperados que podem afetar o tempo necessário para concluir a tarefa).
Para fazer uma estimativa precisa, mantenha em mente alguns aspectos:
Como medir story points: sequência de Fibonacci
Os desenvolvedores usam uma sequência de Fibonacci (0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40, 100) como métrica para mensurar story points e forçar as equipes a chegar a decisões claras. Por exemplo, se você tem um projeto para fazer, e alguém pergunta se ele levará 3 ou 4 horas, você poderá hesitar em responder, pois a diferença é tão pequena que fica difícil estimar. Por outro lado, se alguém perguntar se o projeto levará 3 ou 6 horas, a resposta provavelmente será muito mais clara.
Questões a ser consideradas
- O projeto é similar a algum outro no qual trabalhamos anteriormente? Se sim, qual foi o esforço envolvido para concluí-lo?
Como os story points são uma forma relativa de mensuração, o processo sempre irá mudar e se refinar. Porém, principalmente no início, pode ser útil comparar projetos anteriores similares para fins de perspectiva.
- Existe algum potencial entrave despercebido que possa causar atrasos?
É importante considerar toda a jornada entre equipes pela qual o produto deverá passar até que seja concluído.
- Dependeremos de terceiros para a conclusão?
A dependência de outra equipe ou contratante externo pode causar mais atrasos e burocracia, o que deve ser considerado.
Quem deve planejá-los: planning poker e seus jogadores
Planning poker é uma atividade voltada a ajudar na criação de estimativas precisas de story points de forma rápida e em equipe. No planning poker, cada membro da equipe possui uma pilha de cartas contendo um story point diferente. Uma pessoa lê os diferentes projetos que a equipe tem pela frente. Depois de revisar todos os detalhes que conhecem sobre um projeto, cada membro da equipe exibe a carta que acredita representar o esforço necessário para concluí-lo.
Esse é um processo rápido, eficaz e transparente para a equipe se reunir em torno do planejamento de sprints.
Então, quem deve ser convidado para se sentar à mesa de pôquer? É importante considerar o panorama completo ao estimar o esforço envolvido na conclusão de um story. E também concordar em uma DdC (ou “definição de concluído”). Convidar toda a equipe e equipes adjacentes, como garantia de qualidade e testes com usuários, pode garantir que você não deixe passar batido nenhuma área problemática oculta.
Erros comuns e o que evitar fazer suas estimativas
Existem alguns erros que você e sua equipe podem evitar facilmente enquanto trabalham nas estimativas. Preste atenção neles e oriente sua equipe na direção certa, caso vocês comecem a desviar do rumo.
- Não tente igualar story points a horas
- Não se contente com a média
Ao planejar story points, caso metade da sua equipe escolha 2, e a outra metade escolha 4, parece natural concordar com 3. No entanto, apenas aceitar uma média pode fazer você ignorar uma conversa importante que talvez possa melhorar o entendimento da sua equipe sobre estimativas no futuro.
- Não os estime para tarefas muito grandes ou pequenas
Estimar story points para pequenos bugs ou projetos gigantes poderá começar a obstruir o sistema e dificultar a alocação de esforços relativos.
- Não deixe de manter os pontos de referência atualizados
É importante que seus IBPs (ou elementos do backlog de produto) de referência sejam sempre relevantes e atualizados. Se os elementos da tarefa usados como referência para definir story points ocorreram há 3 anos, quando 70% da equipe não estava na empresa, provavelmente é hora de atualizá-los e garantir que todos estejam alinhados.
Como gerenciar story points com templates
Gerenciar todos os elementos do backlog de produto e os story points alocados em cada um deles, bem como quem está atribuído a qual, pode sair de controle muito rápido. Possuir um local compartilhável e flexível onde sua equipe possa junto gerenciar todos os story points torna o processo mais simples e claro.
Este quadro da monday tem tudo o que você e sua equipe precisam para gerenciar o planejamento de sprints e a alocação de story points. Neste template, você encontra uma barra de progresso para acompanhar a evolução do elemento, colunas de status para nomear o tipo de elemento do backlog de produto, e quantos story points foram atribuídos a cada elemento. Com o quadro compartilhável, sua equipe pode permanecer sempre alinhada e continuar a usá-lo como referência em planejamentos futuros.
Baixe o template de story points da staging-mondaycomblog.kinsta.cloud
Pode levar algum tempo até que você se acostume com uma mudança tão drástica na forma como pensa nos projetos da sua equipe e planeja sprints. Reunir-se com sua equipe para explicar o significado de story points, como eles afetarão a equipe e analisar algumas práticas recomendadas básicas pode ajudar você a implementar story points e gerenciar seus sprints facilmente.
Comece já!