Como estimar uma história de usuário usando uma tabela de afinidade automatizada

Pontos de história ou dias, ou ambos?

As pessoas frequentemente discutem se devem usar pontos de história ou horas (ou dias) na estimativa de histórias. Algumas pessoas acreditam que não precisamos calcular pontos de história e velocidade da equipe de forma alguma. Bem, equipes diferentes podem ter opiniões diferentes, mas, no entanto, a maioria dos projetos Ágeis realiza a estimativa de histórias e a considera uma das ferramentas muito úteis para entregar projetos no prazo e dentro do orçamento.

Tabela de Afinidade para Estimativa de Histórias

Em Visual Paradigm, não consideramos a estimativa de histórias como um processo conflitivo ou de negociação, mas sim como um processo de construção de equipe que torna a colaboração em tarefas e a carga de trabalho claros e transparentes para todos na equipe. A ferramenta de histórias de usuário capacita a equipe com a Tabela de Afinidade para automatizar o processo de estimativa de histórias junto com a eliminação de spikes. Além disso, a Tabela de Afinidade visual suporta a estimativa em tempo real com pontos de história e horas de história ao mesmo tempo. Quando você arrasta uma história ao longo da tabela, tanto o ponto de história quanto a hora serão exibidos simultaneamente enquanto a história ainda está se movendo. Basta soltar a história na grade onde sua equipe considerar a estimativa adequada.

Como a Tabela de Afinidade calcula?

Para entender como os pontos de história e os dias são estimados automaticamente na Tabela de Afinidade, precisamos compreender que as grades horizontais representam os esforços de trabalho, aumentando da esquerda para a direita, e a complexidade do desenvolvimento da história (como tecnologia nova, domínio novo, etc.) aumenta de cima para baixo.

Como o número máximo de dias para o desenvolvimento de uma história de usuário deveria ser no máximo igual ao comprimento do sprint (caso contrário, a história é muito grande e precisa ser dividida, ou o sprint está definido muito curto, exigindo uma extensão), o número de dias da grade inferior direita também deverá ser igual ao comprimento do sprint. Com base nessa suposição, a estimativa da história pode ser calculada automaticamente.

Afinidade de Histórias de Usuários para Estimativa

A estimativa de uma história de usuário nunca poderá ser 100% precisa, e de fato nenhum método consegue alcançar isso. Para melhorar a precisão da estimativa, começamos definindo o comprimento do sprint (por exemplo, duas semanas ou 10 dias úteis) e realizamos a estimativa em algumas histórias de usuário com as quais nos sentimos mais confortáveis em termos de estimativa (por exemplo, 5 dias e certeza média). Nesse caso, você colocará a história no meio verticalmente (nível de certeza ou risco) e horizontalmente (esforço de trabalho igual a 5 dias, ou metade do comprimento do sprint, que é de 10 dias). Em seguida, você pode usá-la como ponto de referência para estimar as outras histórias de usuário. Pergunte a si mesmo se esta história de usuário exige mais esforço do que a referência, ou menos, e tem mais incerteza ou menos. À medida que você colocar mais histórias na Tabela de Afinidade, poderá comparar várias histórias para verificar se a distribuição é lógica ou não, e então ajustá-las para torná-las justas. O processo é um pouco mais uma arte do que uma engenharia. Faça isso e discuta na reunião da equipe, em vez de provocar confrontos. A precisão geralmente melhora conforme a equipe se torna mais madura.

Elimine Riscos com o Spike do Projeto

De acordo com o Dicionário Ágil, a definição de Spike é:

“Uma tarefa voltada para responder a uma pergunta ou coletar informações, em vez de produzir um produto entregável. Às vezes, uma história de usuário é gerada que não pode ser bem estimada até que a equipe de desenvolvimento realize algum trabalho real para resolver uma questão técnica ou um problema de design. A solução é criar um ‘spike’, que é algum trabalho cujo propósito é fornecer a resposta ou solução.”

Ao estimar uma história de usuário, não consideramos apenas o esforço de desenvolvimento, mas também levamos em conta os riscos e incertezas envolvidos. Muitas vezes, um spike é criado antes do início formal de um sprint para gerenciar o trabalho necessário para que outras histórias de usuário possam ser estimadas de forma justa.