What should a project do about time underestimation?

Question

Project management

I have some dead end in thinking and decisions on the topic of time estimation.
Suppose you plan a sprint, then it turns out that when estimating the time of one of the tasks, a number of features were not taken into account, and instead of two days, it actually takes five.
What should the project do in this case? Understanding the reasons why they could not take into account this or that problem is understandable, but in the end it is almost always either the programmer's inexperience in solving such problems, or forgot / found out during the development process. In fact, you simply agree "Well, yes, we have a jamb here, yes, we understood why," and when you are asked why it is not ready by the deadline, as if you are justifying that you could not correctly estimate the time for development, as if you yourself underestimated it
At the same time, the feeling that I am missing some part as a project does not leave me all the time. Who is not difficult, share your experience with such underestimation of tasks?

Answer 1

Agile technologies work well in an experienced team. Therefore, over time, both team leads and you should better cope with the assessment.
* On the part of the leads - better forecasts, better evaluation of the work of subordinates
* On your part - adjustment of the agile process itself - the size of sprints, the number and time for rallies, the size of the buffer.
It's one thing if such a task falls out 1 in 10, it's another matter if there are half such errors. In the first case, it's easy to fix the buffer size that you allocate for "unforeseen circumstances" in the sprint, which should cover sick days, sudden dayoffs, underestimated task complexity. By the end of the sprint, if there is still a buffer, you can take some little things from the backlog
If there are tasks that the developers are not sure about, agree that whenever this uncertainty exceeds a certain percentage, an additional investment task is simply created for the developer so that the developer can officially spend time digging the task deeper and issue a correct forecast.
In general, always in complex tasks, they should be divided into smaller ones, this is the level of this fragmentation and is selected in each project on experience.

Answer 2

Representatives of Yandex said how they evaluate. Take the planned time for the task, multiply by two and add two weeks.
Who will guess why they add two weeks :D ? Because if nothing has been done for all the time, then in two weeks you can manage to do anything)))) It was said in Yandex itself at the conference.
But seriously, take your entire estimate and multiply by two. It is obvious that you will be assessed based on past experience.
I evaluate and add 30%, but there is already experience, and these 30% are more likely to force majeure associated with liability on the client's side.

Answer 3

That is why you can’t name which you think you can meet, the system is simple - multiply by 2, and don’t forget to add a couple of days for force majeure.
And about this: "ultimately, it is almost always either the programmer's inexperience in solving such problems"
Well, work with experienced ones! Yet simple. I think you have answered your own question.
UPD. Clarification on terms, time multiplied by 2, call the customer, the programmer what you originally intended. Since he will do everything on the last day anyway :)

Answer 4

The FFF principle
It is better to underpromise :
- promised in 2 weeks and done in 2 weeks - ok, we agreed after all
- if you promised to do it in 3 weeks, but did it in 2 - this is very cool, because the expectations were different, that is, he did better than he promised (wow effect)
First charge, then do

Answer 5

I will specially write one more answer, almost repeating the previous one. Because in real life, no one believes that this is so, despite countless confirmations.
You listen to the customer, then ask the performers - how long will it take? We multiply the received initial time by one and a half - this will be real time. And we inform the customer of a period equal to twice the original time.