Pontos da história (story points) e estimativas

No desenvolvimento ágil, o proprietário do produto tem como tarefa priorizar o backlog (a lista ordenada de trabalho que contém descrições breves de todos os recursos desejados e correções para o produto). Os proprietários do produto agrupam os requisitos da empresa, mas nem sempre entendem o que há por trás da implementação. Uma estimativa boa dá ao proprietário do produto uma visão nova em relação ao nível de esforço para cada item de trabalho que, então, embasa uma avaliação da prioridade relativa de cada item.

Quando a equipe de engenharia inicia o processo de estimativa, é comum o surgimento de dúvidas sobre requisitos e histórias de usuário. E isso é bom: essas dúvidas fazem com que toda a equipe entenda o trabalho de forma mais completa. No caso dos proprietários de produtos, dividir os itens de trabalho em estimativas e partes granulares usando pontos de história ajuda a priorizar todas as áreas do trabalho (que podem não estar visíveis). E depois de receber as estimativas da equipe de desenvolvimento, não é incomum que o proprietário do produto reordene os itens no backlog.

Envolver todos (desenvolvedores, designers, testadores, implementadores, etc.) na equipe é fundamental. Cada membro da equipe traz uma perspectiva diferente sobre o produto e o trabalho necessário para entregar uma história do usuário. Por exemplo, se o gerenciamento de produto quer fazer algo que pareça simples, como a compatibilidade com um navegador da Web novo, as equipes de desenvolvimento e assistência de qualidade precisam fazer o ponderamento, pois a experiência demonstra que problemas podem surgir a qualquer momento.

Da mesma forma, as alterações de design exigem não só comentários da equipe de design, mas também das equipes de desenvolvimento e assistência de qualidade. Deixar a maior parte da equipe de produtos fora do processo de estimativa cria estimativas de qualidade menores, reduz o incentivo, pois os principais colaboradores não se sentem incluídos, e compromete a qualidade do software.

Então, não deixe que sua equipe seja vítima de estimativas feitas a partir do nada. É um caminho rápido para o fracasso! Entenda o que significa estimativa e como isso pode ajudar seu time. 

Quer testar os pontos da história? Primeiro, faça sua inscrição ou login no Jira

• Experimente este tutorial interativo para configurar seu primeiro projeto scrum 

• Saiba como configurar as estimativas de pontos da história e monitore as histórias dos usuários

Equipes de software tradicionais dão estimativas em um formato de tempo: dias, semanas, meses. Muitas equipes ágeis, contudo, fizeram a transição para pontos de história. Os story points, também chamados de pontos da história, são unidades de medida para expressar uma estimativa do esforço geral necessário para implementar por inteiro um backlog do produto ou qualquer outro trabalho. Equipes atribuem pontos de história em relação à complexidade de trabalho, à quantidade de trabalho e ao risco ou à incerteza. Valores são atribuídos para dividir o trabalho em partes menores com mais eficácia, para que eles possam tratar da incerteza. Com o tempo, isso ajuda equipes a entender quanto pode ser alcançado em um período de tempo e cria consenso e comprometimento com a solução. Pode parecer nada intuitivo, mas na realidade essa abstração é útil porque faz com que a equipe tome decisões mais difíceis em relação a uma dificuldade do trabalho. Aqui estão alguns motivos para usar pontos de história:

• Datas não levam em conta o trabalho não relacionado ao projeto que aparece inevitavelmente em nossos dias: e-mails, reuniões e entrevistas nas quais um membro da equipe pode estar envolvido.

• Datas têm um vínculo emocional com eles. A estimativa relativa elimina o vínculo emocional.

• Cada equipe estimará o trabalho em uma escala levemente diferente, o que significa que a velocidade (medida em pontos) será, naturalmente, diferente. Isso, por sua vez, torna impossível fazer política usando a velocidade como uma estratégia.

• Depois de concordar sobre o esforço relativo do valor de cada ponto da história, você pode atribuir pontos com rapidez e sem muita discussão. 

• Como usar story points? Os pontos da história recompensam os membros da equipe por resolver problemas com base na dificuldade, não no tempo gasto. Isso mantém os membros da equipe focados em entregar valor, não em gastar tempo. 

Infelizmente, os pontos de história são mal utilizados com frequência. Pontos da história dão errado quando forem usados para julgar pessoas, atribuir cronogramas e recursos detalhados e quando forem confundidos com uma medida de produtividade. Em vez disso, equipes deveriam usar pontos de história para entender o tamanho e a priorização do trabalho. Para uma discussão profunda sobre pontos de história e práticas de estimativa, consulte essa mesa redonda com parceiros da indústria e continue lendo para obter dicas de estimativas mais ágeis.

As equipes que estão começando a usar pontos da história praticam um exercício chamado "pôquer de planejamento". Na Atlassian, o pôquer de planejamento é uma prática comum em toda a empresa. A equipe vai pegar um item do backlog, ter uma discussão breve sobre ele, e cada membro vai formular mentalmente uma estimativa. Então todos levantam um cartão com o número que reflete sua estimativa. Se todos estiverem de acordo, ótimo! Se não, reserve algum tempo (mas não muito tempo — apenas alguns minutos) para entender a lógica por trás de estimativas diferentes. Não se esqueça: a estimativa é uma atividade a ser pensada em termos gerais. Se a equipe estiver muito envolvida em detalhes, respire e traga a discussão de volta para o geral.

Ficou com vontade de testar? 

• Instale o aplicativo Planning Poker

• Saiba mais sobre o Planning Poker

Nenhuma tarefa individual deve ter mais de 16 horas de trabalho. (Se estiver usando pontos de história, você poderá decidir que, digamos, 20 pontos é o limite superior.) É simplesmente muito difícil estimar itens de trabalho individuais maiores do que os com um alto grau de confiança. E essa confiança é especialmente importante para itens no topo da lista de pendências. Quando algo é estimado acima do limite de 16 horas (ou 20 pontos) de sua equipe, isso é um sinal para fazer uma divisão em partes menores e elaborar uma nova estimativa.

Para itens mais complicados na lista de pendências, dê uma estimativa aproximada. Quando que a equipe realmente começar a trabalhar nesses itens, os requisitos poderão mudar, e seu aplicativo certamente terá mudado. Então as estimativas anteriores não serão tão precisas. Não desperdice tempo estimando trabalho que provavelmente será alterado. Forneça ao proprietário do produto um número aproximado para que seja possível priorizar o roteiro do produto adequadamente.

As retrospectivas são o momento em que a equipe pode incorporar os insights coletados de iterações anteriores, como a precisão das estimativas. Várias ferramentas ágeis como o Jira monitoram pontos de história, o que ajuda você a refletir sobre as estimativas e fazer a recalibragem delas com muito mais facilidade. Por exemplo, verifique as cinco últimas histórias de usuário da sua equipe que alcançaram um ponto de história de valor 8. Reflita se cada um desses itens de trabalho exigiu o mesmo nível de esforço. Se não tiver exigido, discuta o motivo. Use esses insights nas próximas discussões de estimativa.

Como tudo no método ágil, a estimativa é questão de prática. Você vai melhorar com o tempo.