O comentários do Douglas e Edgar são totalmente pertinentes, o exercício de estimar deve ser em equipe e utilizando-se de técnicas modernas. Mas gosto de analisar o lado psicológico deste assunto, ajuda a entender melhor.

… ou não…
(rsrsrs)

Existem diversos fatores para uma estimativa ruim, entre elas, você citou uma, é a falta de experiência. Talvez seja o principal fator sim, seja falta de experiência com programação (no caso da nossa área) ou falta de conhecimento do produto ou negócio.
Assumindo que isso é um problema, e assumindo também que uma boa estivativa é uma das partes mais importantes de um projeto (pois envolve custo, e um projeto com erro de estimativa, dependendo do tamanho, pode fechar uma empresa) vale a pena investir em toda e qualquer ferramenta que tenha como objetivo melhorar a estimativa.

O scrum tem uma ferramenta bem bacana, chamada “poquer do planejamento”. Basicamente consiste em um “jogo”, onde os membros da equipe, munidos de um jogo de “cartas”, fazem as estimativas em conjunto. As “cartas” contém valores (no nosso caso, frações de dias, que variam de 1/4 até 8 dias).
Todas as tarefas (roteiros de usuário) são colocadas em uma ficha, que contém – de forma resumida – o que o usuário solicitou. Todos da equipe tem que ler e entender o problema, propor uma forma de resolver, e, em seguida, estimar, colocar sua carta sobre a mesa (com o valor virado pra baixo) e só então todos desviram a carta. Se não houver concenso no valor, cada um deve explicar o motivo de ter colocado aquele valor. Na sequência, o jogo é feito novamente, até um concenso.

Vale resaltar também que toda estimativa é feito com um computador próximo, para que todas as dúvidas sobre o código sejam sanadas. A estimativa não pode ser feito, em hipótese alguma, se houver dúvida em relação a como implementar, e, em caso de dúvida sobre o solicitado, o time não pode “supor”, mas sim entrar em contato com o product owner (o cliente) e tirar todas as dúvidas, para então voltar ao poquer do planejamento.

Todos os roteiros de usuário devem sem desmembrados em subtarefas, de forma que cada subtarefa tenha um tempo relativamente curto (2 dias no máximo seria um bom valor). Quanto mais detalhada e dividida for, mais fácil será de estimar. Essa divisão em subtarefas deve ser feita antes ou durante o poquer do planejamento.

Enfim, não da pra dizer tudo por aqui, pois não é só o poquer do planejamento que resolve, tem mais detalhes, como por exemplo o uso do task board, do gráfico burndown e etc, mas posso dar um feedback positivo em relação ao XP e scrum.
Lembrando que não da pra aplicar tudo que o XP ou scrum prega, pois depende da estrutura da equipe, quantidade de pessoas.
Se quiser conversar qualquer dia sobre o assunto, só me falar.
abraço.