In theory, task estimates should be done by developers. Of course, an estimate is not the same as the reality, but if you keep telling the average estimated tim

In theory, task estimates should be done by developers. Of course, an estimate is not the same as the reality, but if you keep telling the average estimated time, you should underestimate about as often as overestimate. That means, you should do at least half of the sprints on time. So if the developers keep underestimating the time consistently for years, something is wrong. I am not saying it is necessary the developers' fault. Often the problem is managers making pressure on developers to provide shorter estimates. But I have also met overconfident developers, who keep believing that "this time it will be different, because this time it is actually easy... as opposed to all the previous times, when it merely seemed easy" over and over again. Or maybe you have a teammate like this, and then you start also underestimating your tasks, to avoid seeming incompetent compared to him during the planning sessions. (Yes, people who provide shorter estimates than you, and then deliver at exactly the same time as you, are usually perceived by the management as more competent. The make a better impression during planning, and not-worse impression on delivery.)