I've read your original post again to try and understand what you mean. I guess it would be helpful if you could elaborate on "relative productivity". Do you me

I've read your original post again to try and understand what you mean. I guess it would be helpful if you could elaborate on "relative productivity". Do you mean the difference in productivity between an experienced vs junior dev? Or perhaps someone that knows the codebase and someone that's new to it? And what do you gain from having a notion of "velocity" - what do you use it for? In my experience, you can perhaps throw a rough idea of complexity at a task (easy/medium/hard). Even then you may be wrong around a third of the time. How well complexity correlates with implementation effort depends on such a large number of factors (novelty of task, team size, dev experience, communication overheads, unseen dependencies...) that it's pointless to fine-grain any project or large feature estimates to an accuracy greater than something like "this will take about 2 months, but it could be 3 or 4".