Os story points são uma técnica de estimativa usada em metodologias de gestão de projetos ágeis para ajudar a equipe a definir o esforço necessário para concluir uma tarefa. Os story points levam em conta fatores como a complexidade e a incerteza das tarefas, o que os torna mais precisos do que outras técnicas de estimativa, como a estimativa baseada no tempo. Estimar os pontos de história pode parecer complicado, mas não se preocupe: dividimos o processo em seis etapas simples.
Pense na última vez que você fez uma viagem de carro. Demorou tanto quanto você pensou que demoraria ou você se deparou com imprevistos inesperados, como engarrafamentos? Planejar e estimar projetos pode ser muito parecido com isso. Obstáculos inesperados e incertezas podem atrasar o cronograma do projeto e levar a um desvio de escopo. E, assim como na sua viagem, você pode se encontrar em algum lugar inesperado, como acima do orçamento e com baixo desempenho.
É aí que entram as técnicas de estimativa. Com técnicas de estimativa, como os story points, você pode definir com precisão o escopo das tarefas, dando a você e à sua equipe uma visão mais clara de quanto esforço as tarefas exigirão e onde os problemas podem surgir. Vamos nos aprofundar nos benefícios dos pontos de história e em como usá-los.
Os pontos de história são uma forma de estimar a quantidade de esforço necessário para concluir uma história de usuário no backlog do produto. Normalmente, você estimará os pontos de história antes de uma reunião de planejamento de sprint, pois é nesse momento que a equipe determina quanto trabalho pode realizar em um próximo sprint.
Normalmente, os pontos de história levam em conta três fatores que podem afetar o escopo e o esforço de uma tarefa, e o valor do ponto de história aumenta de acordo. Como os pontos de história são relativos, você encontra o seu valor considerando esses detalhes e comparando tarefas semelhantes entre si.
Risco é a quantidade de risco total ou incerteza associada à tarefa. Por exemplo, se a tarefa envolver terceiros, contratados ou partes interessadas do projeto, isso pode aumentar a quantidade de risco.
Repetição é a experiência da equipe com tarefas semelhantes.
A complexidade é o nível de dificuldade da tarefa (e a clareza dos objetivos da tarefa).
É importante saber que os pontos de história são relativos, o que significa que o seu valor relativo e as proporções entre eles são o que importa, não o seu valor numérico real.
Mike Cohn, fundador da Mountain Goat Software e autor de Agile Estimating and Planning, popularizou os pontos de história ágeis como parte da estrutura ágil.
Você pode estar se perguntando: por que não usar o tempo como estimativa para as tarefas? E você não está errado: a estimativa baseada no tempo (ou baseada em horas) é uma maneira popular de definir o escopo do trabalho.
Mas há uma desvantagem: ao contrário dos pontos de história, as estimativas baseadas no tempo não levam em conta a complexidade, o risco ou a incerteza. Elas também dependem da estimativa pessoal de cada membro da equipe, que pode variar de acordo com a senioridade, a compreensão da tarefa e a ser feita e a experiência com tarefas semelhantes.
Os pontos de história ágeis resolvem esses possíveis problemas ao incentivar a colaboração e levar em conta o risco, a complexidade e a experiência. O resultado é um sistema de pontuação universal que mantém os membros da equipe alinhados.
Modelo gratuito de matriz de story pointsAgora que você já sabe o que são os pontos de história, vamos ver como estimá-los para definir o escopo das histórias de usuários.
Uma boa compreensão dos pontos de história é crucial para o sucesso. Para facilitar a entrada da sua equipe no processo, explique os conceitos básicos e os benefícios dos pontos de história. Em particular, certifique-se de que eles entendam que os números dos pontos de história precisam ser dimensionados em relação uns aos outros.
Dica: lembre-se de que as proporções são importantes para os pontos de história, não os números reais. Em outras palavras, uma tarefa com um ponto de história dois deve exigir o dobro do esforço de uma tarefa com um ponto de história um. Uma tarefa com um ponto de história de três deve exigir um esforço 1,5 vezes maior do que uma tarefa com um ponto de história de dois. Você entende aonde queremos chegar.
Em seguida, determine a sequência de pontos de história. Ela se tornará o método de pontuação que a sua equipe usará para atribuir pontos de história na reunião de estimativa (falaremos mais sobre isso a seguir). As sequências são úteis porque forçam a equipe a se concentrar no tamanho relativo entre os números, facilitando a estimativa de tarefas complexas. Então, qual sequência de pontos de história você deve usar? A sequência de Fibonacci, uma série de números em que cada número é a soma dos dois números anteriores, é popular para fazer estimativas no Agile. Mas isso pode ser complicado. Se os valores numéricos sobrecarregarem a sua equipe, experimente o T-shirt sizing. Como o nome sugere, esta sequência divide as tarefas em tamanhos mais gerenciáveis com base nos tamanhos de camiseta: PP, P, M, G, GG e GGG.
Dica: ao estimar no Agile, as equipes geralmente alteram a sequência de Fibonacci para 0, 0,5, 1, 2, 3, 5, 8, 13, 20, 40 e 100 para facilitar o uso.
Uma matriz de pontos de história é basicamente uma versão detalhada da sua sequência de pontos de história. Ela serve como base para a sua reunião de estimativa e dá à sua equipe uma ideia mais clara de como pontuar cada tarefa. Se você nunca usou pontos de história, recomendamos usar o seu conhecimento das tarefas que a equipe normalmente realiza e a complexidade, incerteza e esforço associados a elas.
Como se pode ver, os valores dos pontos de história aumentam à medida que o esforço, a complexidade e o risco da tarefa aumentam.
Dica: a sua matriz de pontos de história evoluirá à medida que você executar sprints e entender melhor o esforço associado às tarefas da equipe. Não se preocupe em deixá-la perfeita na primeira vez: desenvolva-a com base nas tarefas típicas da sua equipe e planeje reavaliar a matriz após cada sprint.
Agora que você já escolheu a sequência de pontos de história e criou a matriz de pontos de história, é hora de chegar ao cerne da questão: estimar os pontos de história com uma reunião de pôquer de planejamento.
A meta do pôquer de planejamento é atribuir pontos de história às histórias de usuários, manter a equipe em sintonia e ter uma ideia de quantas tarefas a equipe pode concluir no próximo sprint. O pôquer de planejamento faz isso ao permitir que todos avaliem o trabalho futuro. Com toda a equipe envolvida, você pode ter certeza de que está atribuindo pontos de história com base em opiniões diversas e evitando vieses inconscientes.
Veja como realizar uma reunião de pôquer de planejamento bem-sucedida.
Dê à sua equipe uma matriz de pontos de história definida para referência, bem como um conjunto de cartões que descrevam a sua sequência de pontos de história. Você mesmo pode criar os cartões ou baixar um conjunto.
Escolha uma história de usuário.
Discuta a história com a equipe, incluindo o que está envolvido e o que é um resultado bem-sucedido.
Peça a cada membro da equipe que escolha, sem mostrar aos outros, o cartão de story point que, na sua opinião, representa a quantidade de esforço necessária para concluir a história.
Peça à sua equipe que revele as seleções de cartões ao mesmo tempo. Se os pontos de história estiverem alinhados, passe para a próxima história de usuário. Se os pontos da história não estiverem alinhados, continue discutindo a história do usuário até chegar a um acordo.
Repita o processo até que todos os pontos de história tenham sido atribuídos a todas as tarefas no backlog do produto.
Usando a matriz de pontos de história como base, determine quantas tarefas a equipe pode concluir no próximo sprint.
Dica: planeje realizar sessões de pôquer de planejamento depois que a sua equipe tiver priorizado o backlog e antes do início do sprint. As sessões de pôquer de planejamento podem levar de duas a quatro horas (e a primeira sessão provavelmente levará mais tempo), portanto, planeje-se adequadamente.
Se esta for a primeira vez que você está usando pontos de história, não saberá exatamente quantos pontos de história pode concluir por sprint (também conhecido como “velocidade do sprint”) até concluir o primeiro sprint completo. Não tem problema. Na reunião de planejamento do sprint, use a sua melhor estimativa de quantos pontos de história incluir no sprint com base na complexidade das tarefas e no valor dos pontos de história.
Dica: o seu primeiro sprint pode incluir um grande número de pontos de história de baixo valor, um pequeno número de pontos de história de alto valor ou uma combinação de ambos. Com o tempo, você aprenderá o que funciona melhor para a sua equipe e melhorará o processo com base no feedback da equipe.
Depois de concluir o primeiro sprint usando os pontos de história, é hora de se concentrar no tema principal da estrutura ágil: a melhoria contínua. Para isso, reúna-se com a sua equipe e discuta o que deu certo e o que pode ser melhorado. Você pode realizar uma reunião separada para isso ou incluí-la na retrospectiva de sprint.
Faça perguntas à equipe, por exemplo, se os pontos da história foram definidos corretamente, quais gargalos inesperados do projeto foram encontrados e outros motivos pelos quais as metas não foram atingidas. Use as respostas para melhorar o processo para o próximo sprint. Se necessário, reavalie a sequência ou a matriz de pontos de história.
Use as suas descobertas para estimar a velocidade do sprint, o número de pontos de história que a sua equipe pode concluir em um determinado sprint. Por exemplo, se a sua equipe concluir quatro pontos de história por dia, a velocidade do sprint será de 40 pontos de história por sprint de duas semanas.
Dica: depois de determinar a velocidade da equipe, use esse número para distribuir os pontos de história e ver quantos sprints a equipe precisará para concluir um projeto inteiro.
Modelo gratuito de matriz de story pointsNão é nenhum segredo: planejar com antecedência é essencial para a gestão de projetos. Não definir o escopo e o cronograma do trabalho de forma adequada pode levar a prazos perdidos, desvio de escopo e falha do projeto. Mas se isso parece assustador, não se preocupe. Os pontos de história podem ajudar.
Para entender melhor os pontos de história, vamos ver como usá-los dentro da estrutura Agile:
Primeiro, escreva uma história de usuário para cada funcionalidade desejada. As histórias de usuário seguem o formato: “Eu, enquanto [persona], quero [meta], para [resultado ou benefício]”.
Adicione as histórias de usuário ao backlog do produto.
Atribua story points a cada história de usuário para estimar o esforço.
Use os pontos de história para selecionar histórias de usuário do seu backlog, garantindo que você esteja escolhendo a “quantidade” certa de trabalho para cada sprint.
Execute o sprint.
Exemplo: digamos que a sua história de usuário seja “Como usuário, quero poder enviar feedback e perguntas pelo site para entender melhor as funcionalidades do produto”. Você atribuiria a essa história de usuário um ponto de história, ou seja, a quantidade de esforço que você acha que é necessária para concluir a história. Você pode então dividir a história em tarefas menores, como definir o escopo e projetar o formulário de feedback, escrever o código para o formulário, preparar a página e testar o formulário e publicar a página.
Há uma razão para os pontos de história serem o MVP das técnicas de estimativa: eles facilitam a estimativa do esforço e simplificam o planejamento do sprint. Mas isso não é tudo. Estes são outros benefícios de usar pontos de história ágeis:
Agilizar o planejamento. Os pontos de história são uma unidade de medida para estimativa relativa, o que significa que você calcula o valor de um ponto de história comparando-o a itens de trabalho semelhantes já estimados. Usar um método de pontuação relativa leva a uma estimativa mais rápida ao longo do tempo, o que é uma grande vitória para a sua equipe.
Levar em conta a imprevisibilidade e o risco. Os pontos de história ágeis são responsáveis por elementos como incógnitas e riscos. Usar esses fatores no planejamento elimina as suposições da estimativa, permitindo que você avalie o esforço com mais precisão.
Elimine o viés de habilidades do seu planejamento e coloque a equipe em sintonia. Confiar nas estimativas individuais dos membros da equipe nem sempre é o melhor. Afinal, um membro sênior da equipe provavelmente dará uma estimativa de esforço muito diferente de um membro júnior. Os pontos de história evitam esses problemas ao incentivar a colaboração na forma de reuniões de pôquer de planejamento.
Crie prazos significativos. Ninguém gosta de prazos arbitrários, mas é isso que geralmente se obtém quando se usa outras técnicas de estimativa com base na quantidade de tempo. Como os pontos de história são mais sutis, eles resultam em datas de conclusão significativas.
Criar estimativas melhores no futuro. Uma das principais vantagens dos pontos de história é que eles são adaptáveis e reutilizáveis. Isso significa que, depois de criar uma matriz de pontos de história e realizar o primeiro sprint, você pode usar os aprendizados para reavaliar os valores originais dos pontos de história e desenvolver estimativas mais precisas.
Colaborar estreitamente com o proprietário do produto é essencial para uma estimativa precisa de pontos de história. O responsável pelo produto fornece informações valiosas sobre o valor comercial, as prioridades do usuário e os critérios de aceitação de cada trabalho. Ao envolver o proprietário do produto no processo de estimativa, as equipes ágeis podem garantir um entendimento compartilhado dos requisitos e fazer estimativas mais bem informadas.
Leia: 10 etapas simples para incentivar a colaboração em equipePara colaborar de forma eficaz com o proprietário do produto durante a estimativa de pontos de história:
Convide o proprietário do produto para reuniões de estimativa e sessões de pôquer de planejamento.
Incentive o proprietário do produto a esclarecer os requisitos, a funcionalidade e a responder a perguntas.
Discuta o valor comercial e o impacto de cada história no usuário com o proprietário do produto.
Certifique-se de que o proprietário do produto entenda o conceito de pontos de história e dimensionamento relativo.
Colaborar com o proprietário do produto para dividir grandes histórias em partes menores e estimáveis.
Exemplo: digamos que a equipe do Scrum, composta pela equipe de desenvolvimento, o mestre do Scrum e o proprietário do produto, esteja estimando uma história de usuário para uma nova funcionalidade em um aplicativo móvel. O proprietário do produto participa da reunião de estimativa e fornece contexto adicional sobre a importância do recurso para os usuários e a funcionalidade esperada. A equipe de desenvolvimento consulta o guia do Scrum para esclarecer os critérios de aceitação e os casos extremos. Juntos, o proprietário do produto e a equipe discutem a complexidade da história e a dividem em histórias de usuário menores e mais gerenciáveis. Ao colaborar estreitamente com o proprietário do produto, a equipe obtém uma melhor compreensão dos requisitos e pode fornecer estimativas de pontos de história mais precisas.
Leia: Asana para Agile e ScrumNem tudo é fácil no mundo dos pontos de história. Os pontos de história agilizam o processo de gestão de projetos, mas apenas se você evitar certos erros ao estimar. Veja a seguir algumas armadilhas comuns que as equipes cometem ao estimar os pontos de história e como evitá-las.
A natureza relativa dos Story points facilita para a equipe entender como as tarefas se comparam entre si. É por isso que você não deve atribuir pontos arbitrariamente. Lembre-se: os pontos de história devem ser escalonados em relação uns aos outros.
Como a estimativa de tempo não leva em conta fatores como complexidade e incerteza, usar estimativas de horas ou dias como story points vai contra a meta deles. Em vez disso, considere os três componentes que analisamos: complexidade, risco e repetição, para determinar os valores dos pontos de história.
A inconsistência na estimativa de pontos de história pode levar a confusão e a um planejamento impreciso. Certifique-se de que a sua equipe tenha uma compreensão compartilhada do que cada valor de ponto de história representa. Sessões regulares de refinamento do backlog e workshops de estimativa podem ajudar a manter a consistência.
Embora a estimativa de pontos de história vise melhorar a precisão, buscar a precisão perfeita é contraproducente. Aceite a incerteza inerente ao desenvolvimento de software e use os pontos de história como uma ferramenta para dimensionamento relativo, em vez de buscar estimativas exatas.
Melhore continuamente a sua estimativa de pontos de história refletindo sobre os sprints anteriores. Compare o esforço real necessário para concluir as histórias com as estimativas iniciais. Use esse feedback para calibrar a compreensão da sua equipe sobre os pontos de história e refinar o processo de estimativa. Envolva toda a equipe de Scrum, incluindo o testador, para reunir insights e métricas para melhorar a sua prática ágil.
Os pontos de história são uma peça importante do quebra-cabeça da gestão de projetos. Mas estimar corretamente o esforço e levar as tarefas até a linha de chegada é muito mais fácil quando os itens do backlog do produto estão bem organizados e correspondem ao trabalho da equipe. A Asana está aqui para ajudar. Organize o seu backlog, monitore os projetos ágeis e comunique-se com a equipe de forma eficiente com um modelo de planejamento de sprint tão colaborativo quanto a sua equipe.
Modelo gratuito de matriz de story points