I always found a strong disconnect between what the business side thinks is meaningful and what an engineer and his technical manager finds meaningful. Typically the detailed granularity just isn't there and the data is really noisy as well.
More of late I've thought it'd be better to look at the rate features are added and ignore 'hours' completely. As in Bob seems to be able to complete one hard feature a month, or three medium features. You got to ask, do you care how many hours bob worked? Not really.
Heh, presuming management knows what a hard feature looks like.
Or understands the reason why it is hard. They sometimes conflate a patch, a hairy patch or writing correct code from start.
Bonus points if said manager does not understand that writing tests makes one go faster rather than plugging the code and trying to run scenarios manually...
One of the things I now always do is tell my boss both how much work work somethings going to be and how 'hard' something is going to be. Features/changes that are hard have very unreliable estimates. A lot of that has to do with how difficult it is to reason about and debug the feature. And how much other stuff needs to be changed.
More of late I've thought it'd be better to look at the rate features are added and ignore 'hours' completely. As in Bob seems to be able to complete one hard feature a month, or three medium features. You got to ask, do you care how many hours bob worked? Not really.