Hey, @depaula. Essa é a pergunta coringa. Já quebrei muito a cara, e depois de viver a experiência de muitos projetos (trabalhei em Fábrica de Software), de tocar projetos por conta própria e de ler muito Taleb, percebi que tentar prever o futuro de projetos não é muito diferente do que uma "Mãe Diná" faz. Com a diferença que ela ganha por fofoca e a gente por resultado haha
Atualmente tenho um método que é o seguinte:

1. Faço a pergunta: Esse é um problema que já resolvi antes?
   1. Se sim: Vejo quanto isso me custou de tempo no passado e precifico por valor agregado (geralmente isso funciona bem com demandas genéricas e coisas pequenas, tipo corrigir um bug, ou configurar uma infra específica);
   2. Se não: Abro o jogo com o cliente e vendo meu trabalho por horas. Junto com o cliente crio um board e monto um backlog (que vai continuar se alterando, tudo depende da necessidade do cliente. Backlog é vivo), e toda entrega priorizo com ele as demandas mais interessantes de serem feitas e as faço em ciclos pequenos (geralmente de 1 a 2 semanas). Somo o tempo gasto e ele me paga. Com isso, paro de tentar prever o futuro e trabalho com demandas curtas e palpáveis, sem tentar prever nada. O cliente acaba entendendo que o software nunca está pronto e que a ideia inicial dele não é o software e que naturalmente ele vai moldar e aprimorar o entendimento do que ele quer ao longo do tempo (por isso que prever é perigoso).

O legal dessa abordagem que tenho adotado, é que o meu acordo com o cliente é que farei aquilo que fecharmos para aquele ciclo pontual. Isso é muito mais fácil de entregar. E o mais legal é que ele começa a enxergar o valor real de cada funcionalidade.
Vale lembrar que ali tu comentou que os clientes não gostam de pagar pelo trabalho de análise e estimativa, e isso é verdade. Por isso que o preço da minha hora contempla esse tempo que gastarei junto com ele gerenciando o backlog (enriquecendo, etc) e priorizando tarefas.
Geralmente uso para tracking de tempo de trabalho o Clockify.
Espero ter ajudado.