No planejamento da sprint, uma das maiores dificuldades que enfrentei (e enfrento) é como estimar o trabalho que faremos em cada unidade de trabalho.
Ter conhecimento do projeto de antemão, familiaridade com a lingaugem e tecnologias usadas, e até mesmo a interação entre os membros da equipe influenciam na estimativa de uma determinada feature.
Mas, o que é uma feature?
Para o Scrum, uma feature é um item do backlog. Algo que deve ser feito e que foi identificado em algum momento, e foi registrado para posterior priorização.
Para o XP, uma featura é uma story (Apesar de que dificilmente encontraremos um lugar que aplica scrum ou XP puramente. Então o pessoal da sua empresa pode chamar o pedaço de trabalho de srotory tranquilamente).
Simplificanto, uma feature deve ser:
um pedaço de trabalho que contribui com valor de negócio: pode ser algo novo, correção de algum defeito ou modificação de uma funcionalidade, desde que possua valor para o negócio (o usuário vai fazer algo com isso, possui valor para ele);
estimável: conseguimos dizer de alguma forma o quão difícil/demorado/complexo ela é;
testável: possuir formas de ser testada.
Tipos de Estimativa
Existem várias formas de estimar o trabalho que faremos no contexto ágil, mas as mais comuns são:
T-shirt sizing (método do tamanho das camisetas): dividimos as features entre P (pequenas), M (médias) e G (grandes). É uma forma mais simplista e menos granular de ser estimar os tamanhos do que deve ser feito.
Story points: consiste em dar pontos para as histórias, de acordo com sua complexidade. Considero essa forma uma das mais legais – por poder ter mais granularidade, e mais opções de tamanhos. Mas também é uma das que mais geram discussões – porque precisamos “ignorar” a noção de tempo e focarmos na complexidade ao darmos os números para cada história. Assim, uma história que contenha 1 story point é menos complexa do que uma que seja dada 5 story points.
Observe que em cada uma dessas formas, não é uma pessoa sozinha quem classifica as histórias, mas a equipe é quem chega num consenso sobre isso.
Em geral, isso é feito ou no refinamento do backlog ou no planejamento da sprint em uma reunião que tenha os donos do produto, testers, developers, etc.
