This is why I like to estimate on a more macro level. Define features loosely, with a few lines of text about what they are and how they relate directly to a bu

This is why I like to estimate on a more macro level. Define features loosely, with a few lines of text about what they are and how they relate directly to a business goal (how will it make money, make the product better etc), then as a dev, you should be aligning the work to that (which is a piece of cake because they're still flexible). You should still have more granular planning, but it should serve the purpose of aiding the dev in completing the feature. You decide to do more granular planning when, as a dev, you look at a feature and go "The implementation is still ambiguous or I still have questions about how it relates to business goals". Basically, invert the communication channels and shift responsibility to the devs. They have some loose business goals to hit, and the other staff provide support when they need it. This solves so many problems I run into in enterprise dev. It kills Parkinson's Law (since the team members that are in the bottleneck are now responsible for the bulk of work generation within the team), it also gets rid of a whole class of poor decisions that are made without the proper context (since now you have a closer relationship between business goals and development).