Exemplo: “São necessários 4 dias de trabalho para concluir aquela rotina de importação de pedidos do sistema.”
Quando medimos o tamanho de uma atividade em dias ideais, ainda estamos atrelados à noção de tempo. Essa é uma boa estratégia, mas apresenta alguns pontos negativos. Por ser associada ao tempo, diversos fatores podem influenciar as estimativas ao longo do projeto. Com a evolução da experiência do time, competências adquiridas, mudanças de frameworks, por exemplo, o mesmo time agora entende que uma nova importação similar àquela anterior pode ser concluída em 3 dias. A base de estimativa mudou, e com isso o histórico fica prejudicado.
Uma outra forma de se estimar esforço é através da atribuição de pontos para as funcionalidades de um sistema. Essa técnica é muito utilizada com Histórias de Usuário, mas pode ser utilizada com outras práticas de especificação de requisitos também.
Nessa estratégia se atribui uma pontuação para o tamanho de cada funcionalidade. O valor que se atribui é pouco relevante. O que importa é que as pontuações das funcionalidades sejam coerentes entre si, quando comparamos cada funcionalidade às demais.