É muito comum ver por aí a dor de estimativas de esforço de desenvolvimento desalinhadas ou que nunca acertam. Times recém-formados ou com pouca experiência costumam ter ainda mais problemas sobre como fazer estimativas de esforço usando story points.
Com meus quase 15 anos de experiência e muito conteúdo consumido, desenvolvi uma um método para ajudar a sua equipe a montar um Modelo de Referência. E com ele é possível acertar ao realizar estimativas.
Esse framework, que estimula a participação dos integrantes do time, remove a abstração e aumenta a precisão das estimativas. Além disso, é um exercício divertido e animado, muito melhor do que montar um simples check-list.
Antes de explicar o framework, incluí dois tópicos para abordar a importância das estimativas e para “nivelar” rapidamente aqueles que ainda não estão tão inteirados sobre os story points. Mas, se você já tem conhecimento sobre esse assunto, pode pular os itens e ir direto para o passo a passo.
Para começar: a importância das estimativas
É quase impossível não precisar das estimativas de esforço. Com elas temos mais previsibilidade e o planejamento de releases se torna possível. As estimativas costumam estar baseadas em dados e informações, o que atribui credibilidade ao cálculo.
É claro, o plano é manter-se próximo às estimativas, mas isso não significa que o processo deva ser congelado. É importante reforçar, ainda, que as estimativas não servem para fazer micro gerenciamento nem para medir performance do time, relacionar tempo de trabalho ou questionar o time de desenvolvimento.
Um pouco de conceito primeiro: Estimativas relativas x estimativas absolutas
Estimativas ajudam, certo? Mas há um problema com elas que precisa ser destacado: seres humanos NÃO TEM HABILIDADE para estabelecer estimativas absolutas.
É impossível prever o esforço de maneira exata. Isso porque há diversas variáveis que podem impactar o processo. Por outro lado, somos ótimos em criar estimativas relativas, e é isso que precisa ser levado em conta na hora de elaborá-las. As estimativas mais viáveis são aquelas baseadas em referências.
Por que usar story points para fazer estimativas de esforço?
Os story points são a unidade de estimativa mais usada pelos times ágeis nos dias atuais. Isso porque eles utilizam a relatividade e englobam aspectos importantes como complexidade e riscos das tarefas. Para quem não sabe, um story point representa a estimativa relativa do tamanho da atividade comparado com outra atividade no projeto.
Para aplicá-lo, você deve escolher uma tarefa simples e atribuir a ela um valor de referência. Depois, para as demais tarefas, você deve estabelecer as estimativas em comparação com a primeira.
Vou exemplificar para facilitar o entendimento:
Se você atribui o valor 5 à tarefa A e entende que a tarefa B é duas vezes mais complexa do que ela, a estimativa relativa da atividade B é 10. Deu para entender? Aqui eu só dei uma pincelada no assunto. Vale pesquisar e se aprofundar mais no tema, ok?
Passo a passo de como fazer estimativas usando story points
Como eu disse na introdução deste artigo, criei esse framework para facilitar o trabalho das equipes na estruturação do Modelo de Referência. Confira a seguir o passo a passo e aprenda a montar o seu:
Passo 1) Esclareça o que é esforço
Muitas vezes, o time pode ter uma ideia abstrata de esforço. Em alguns casos, a equipe até confunde o conceito com prazo. Por isso, o primeiro passo para fazer estimativas consiste em esclarecer essa ideia. Explique para todos que o esforço está relacionado a três fatores:
Complexibilidade: o termo é usado, geralmente, para caracterizar algo com muitas partes, em que tais partes interagem umas com as outras de várias maneiras. Então, ao estimar, leve em consideração a complexibilidade do seu sistema e certifique-se de que você tem as skills necessárias para a atividade.
Habilidade: você se torna mais habilidoso com o treino. Então, pense em habilidade como a quantidade de vezes que você já fez aquilo, ou o tempo de experiência em fazer determinada atividade.
Riscos: quão conhecida é aquela atividade? Temos dependências que precisam ser mapeadas? Corremos o risco de ser surpreendidos por algum escopo que não conseguimos mapear agora ou simplesmente é muito chato de fazer e pode te distrair? Esses são alguns exemplos que podem ser utilizados para mapear riscos.
Passo 2) Crie um mapa de histórias
Depois de garantir que todo o time esteja inteirado sobre os conceitos relacionados às estimativas, é hora de montar um quadro que servirá de base para as histórias, bugs e tasks. Para isso, desenhe o mapa a partir da escala de Fibonacci, deixando o esforço bem evidente, como no exemplo abaixo:
Passo 3) Promova um brainstorming de histórias
No mapa de histórias, o time irá registrar casos reais e atividades anteriores que já tenham sido realizadas. Entretanto, para executar essa tarefa, é preciso, primeiro, fazer um brainstorming. Distribua alguns blocos de notas e canetas tipo piloto para todos os presentes.
Peça para cada integrante do time escrever pelo menos uma atividade real para cada valor da escala de Fibonacci do Mapa de Histórias. Estabeleça um período de cinco minutos para esta entrega. Caso não tenha a quantidade ideal de atividades por valor de escala, repita novas rodadas durante dois minutos até conseguir.
Passo 4) Popule o mapa de histórias
Nesta etapa, peça para que todos coloquem suas anotações no quadro, tentando deixar o mais próximo possível do valor da escala que foi desenhada. Se o time tiver pessoas de especialidades diferentes, como backend, frontend ou design, utilize cores distintas ou algum adesivo para sinalizar as funções.
Feito isso, escolha um voluntário para cada especialidade e dê a ele a incumbência de promover a discussão sobre as anotações. Preste bastante atenção neste momento, pois ele é muito valioso. Na prática, é a etapa em que o time irá calibrar os story points.
Por exemplo: três story points para um ou oito story points para outro. Deixe a conversa acontecer até que eles cheguem em um consenso. Caso o time identifique que determinada anotação deva estar com outro valor em story points, rasure o valor antigo, coloque o novo e posicione-o no lugar correto da escala.
Depois do consenso, pule para a próxima atividade.O time deve passar por todas as anotações até garantir que estão alinhadas ao valor que cada história representa. Membros de diferentes níveis podem discordar, então, se isso acontecer, utilize as mesmas técnicas e conversas do Planning Poker para definir o valor final de uma história.
Passo 5) Faça “Dot Voting” para escolher as histórias
Após cumprir o quarto passo, o time terá mais de uma anotação por valor na escala Fibonacci. Com isso, os membros precisarão escolher qual será a história de usuário, bug ou task que gostariam de registrar no Modelo de Referência.
Deixe que eles votem e se auto-organizem caso tenha ocorrido empate. É necessário que o time escolha, por especialidade, apenas uma atividade real para compor o board do Modelo de Referência.
Passo 6) Monte o board do Modelo de Referência
Após a escolha do que irá representar cada valor da escala de Fibonacci, os membros do time, por especialidade, deverão colocar as anotações no board do Modelo de Referência.
Repare na imagem acima que se trata de uma lista simples, com cada valor da escala de Fibonacci em uma linha. Se você utilizar um board por time, lembre-se de separar cada especialidade por cores ou outros artifícios visuais. Caso prefira, você também pode criar um board por especialidade, ok?
Passo 7) Passe tudo a limpo para garantir uma boa visualização
Os blocos de notas são excelentes materiais para deixar a dinâmica interativa e participativa. No entanto, não fornecem uma boa visibilidade. Sendo assim, ao final da dinâmica, passe a limpo linha por linha para ter um board bonito e visível, como esse:
Obs: neste exemplo, deixei uma folha do bloco de notas propositalmente no lugar de uma linha. Observe como a visualização do item é pior do que os outros que foram passados a limpo.
Passo 8) Defina uma data para revisar o board
É natural que o time evolua e que esse modelo de referência se torne ultrapassado com o tempo.Neste caso, defina com o time uma data viável para que esse quadro seja revisado ou até mesmo refeito. Utilize a dinâmica acima novamente para isso.
Obs: o board também poderá ser revisado caso o time sofra grandes mudanças de membros. A referência pode perder o sentido e, com isso, pode ser necessário refazer a dinâmica.
Passo 9) Mantenha o board de referência em um lugar para fácil consulta
Leve o quadro para um local apropriado, tire uma foto ou até mesmo digitalize. O importante é que o Modelo de Referência esteja sempre disponível para consulta dos membros dos times em qualquer cerimônia que for necessário estimar story points.
Conclusão
Ao acompanhar o artigo até aqui, você deve ter percebido que não basta apenas aplicar os story points para fazer as suas estimativas. É preciso também se dedicar à criação de um modelo de referência. E é exatamente isso o que o meu framework propõe.
Gostou da dinâmica? Espero que ela ajude a nortear o seu time. Se você ficou com alguma dúvida, mande a sua pergunta. Será um prazer respondê-la!
