While I agree with Thomas Owens answer, I think this needs a more strongly worded answer. The process you describe is completely missing some of the most important parts of agile management and these are the parts that managers should care the most about. (full disclosure: I'm a manager.)
In order to improve predictions about when work will be done, estimates should be done relative to other work that the team has done in the past. Then empirical data is used to predict how long the work will take. This can done using basic statistical methods and as there is more data, the picture of work throughput (averages, variance) become more clear. The managers should also then be able to detect trends as to whether throughput is increasing or decreasing in a statistically significant way.
The other issue here is the use of hours. There are some big problems with using hours as a metric:
- What's an hour? Is it an hour of 'flow' coding? Is an hour of debugging a head-slapping mistake an 'hour'? If you estimate 8 hours a day, when do you look at your email? What if you help co-worker for 30 minutes. Do you subtract that half-hour from your hours for the day? How do I know that one developer's idea of an hour is the same and another's?
- Who cares about how many hours something takes anyway? What's the precision of the deadline? Surely it's not down to the hour. If someone is trying to calling development that close, they've already failed.
- No developer knows how many hours (regardless of how you define and hour of development) it takes to get things done. Ever notice that when you are really crushing it, you look up and the day has passed? Humans minds suck at measuring time even when they are focused on trying to do that.
I argue that the smallest proper unit for predicting development is a day. Unless you are working in a cave (bunker, casino), everyone can agree on when a day has passed. There's this large bright orb that passes over our heads with amazing regularity. An arguments can be made for weeks depending on the situation but they are less uniform (e.g. vacations and holidays.)
I am not saying that estimates should be given in days (although, it's a huge improvement over hours.) I'm saying days should be the unit of the predictions made by the manager. And to come full circle, when the manager (or scrum master) has the developers estimate in hours, they are usually delegating their job to the developers. And if all they do with that is check whether the developers hit that estimate, these estimates are worse than useless. They are actively disrupting the development process by occupying the developers with a BS game and likely lowering productivity by increasing stress levels.