Porque devemos estimar?

https://onceyougoagile.com/why-should-we-estimate/

Why should we estimate?

Por que devemos estimar? Que variáveis consideramos durante a estimativa? As estimativas tornam-se mais precisas quanto maior a frequencia da prática, mantendo a mesma equipe constante. O que e como podemos estimar? Podemos fazer isso ao longo dos diferentes niveis da hierarquia de requisitos, desde níveis estratégicos até aos deimplementação. Mas um bom planeamento de produto deve ser feito faseadamente, aumentando o valor do produto e introduzindo complexidade ao longo das diferentes fases de desenvolvimento.

O que se considera ao estimar?

Estimar uma user story corresponde a um processo analítico que considera diferentes variáveis:

  • complexidade de implementação,
  • tempo para conclui-lo,
  • dependências de terceiros para reunir todas as informações ou pré-requisitos necessários,
  • leva em consideração quem vai implementá-lo, qual a equipe, qual o membro da equipe, a sua experiência com esse tipo de tarefa e/ ou tecnologia,
  • e outros fatores diferentes, dependendo do caso específico.

A precisão da estimativa é uma questão de prática regular

A estimativa em si pode expressar uma promessa, mas, essencialmente, as estimativas devem deixar a equipe confiante. Significa que aceitam no sprint aquela responsabilidade, acreditam que se encaixa em sua capacidade. Mais uma vez, a capacidade é medida em story points. Se a story é estimada num valor muito alto. entao deve haver um esforco para a simplificar ou especificar o ambito, de forma a que a equipa a compreenda e a possa implementar num sprint.

Quanto mais frequente a prática da estimativa, mais precisa ela se tornará. Estimar regularmente é uma maneira de melhorar a previsibilidade e ajustar as expectativas à velocidade ou capacidade média. É muito importante ter uma base histórica para tomar decisões. Coletar regularmente estimativas dá-nos essa base temporal, para correcao e ajuste, confiando mais ao longo do tempo na capacidade da equipe para estimar.

Recordando de um post anterior: um backlog que nunca foi estimado é uma lista de tarefas que não sabemos quanto custa e quando estará pronto.

O que e como podemos estimar?

A estimativa pode ser feita em todos os níveis de portfólio de produtos: Sagas, Épicos, Histórias, Tarefas e Sub-tarefas.

A prática de estimativa pode ser feita através de diferentes métricas. Story points ou t-shirt sizes são os mais comuns. Mas, na verdade, na minha opinião, podemos usar ambos em diferentes momentos no tempo e para diferentes níveis de requisitos. Por exemplo:

Se eu estiver estimando no nível Saga ou Épico, sem uma profunda e detalhada discussão de refinamento, vou usar t-shirt sizes.

Indo ao detalhe, dividindo o requisito funcional em stories de implementação e sub-tasks, é mais comum,  estimar através de Story points.

Se já estamos executando uma release em sprints, refinando regularmente user stories, tasks e sub-tasks, discutindo opções de implementação, basicamente fazendo um refinamento eficiente, é melhor fazê-lo com story points.

Com base na minha experiência é: usamos t-shirt sizes no nível do portfólio e story points no nível do produto para que possamos estimar user stories, tasks e sub-tasks. Um backlog estimado em story points facilita o processo de estimar outros niveis de requisitos (Epics e Sagas) para o planeamento de futuras releases.

Mas também podemos estimar com outras métricas, baseadas em custos e tempo: custo por hora/ dia. Jira também o permite.

Porque estimamos?

Normalmente estimamos para poder prever mais precisa e correctamente ao longo do tempo, caso se mantenha a mesma equipa.

Precisão na estimativa é importante porque precisamos saber o quanto somos capazes de produzir com os recursos actuais, o que significa que saberemos qual é o nosso MPP (Minimum Possible Product), e podemos compará-lo com o MVP (Minimum Viable Product), identificando se a nossa capacidade é suficiente ou qual o investimento requerido.

Em Agile, a equipe de desenvolvimento compromete-se com o proprietário do produto a entregar um certo volume de user stories. Mas isso não significa que, na primeira release, seja lancado o conceito de produto ideal. Dada a incerteza e pressão para avancar para o mercado, é extremamente importante trabalhar permanentemente com um bom UX designer, dividindo o conceito do produto em pequenas partes, e, ao longo do ciclo de desenvolvimento, adicionar incremental complexidade no produto mas preservando sempre a consistência lógica e funcional para o utilizador.




Deixar uma resposta

Este site utiliza o Akismet para reduzir spam. Fica a saber como são processados os dados dos comentários.