[matwood]

In retro we would have asked 'what happened and could we have avoided this?'. Then we would have broken up the now expanded unfinished work, and asked the PM if they want to continue knowing it is 10x more work than expected. If yes, cool we pull in the tickets next sprint and keep going. If no, we wrap up anything in progress and maybe come back to it later.

Shit happens. The end of a sprint is there to highlight issues like this so the business side can re-evaluate if continuing is still a good idea.

I don't want anyone on my team working nights and weekends to finish a sprint task (system going kaput is the only time I would reach out for help). Anyone letting their team work normal sprint tasks on nights/weekends is not going to keep their team very long. They will either quit or burn out and stop working.

[jboy55]

I've had to give estimates for my entire 20 year career, half of which wasn't 'Agile'. So first, Agile has nothing to do with this, in fact, Scrum tries to over come this by splitting up tasks into smaller chunks with frequent demoing, re-prioritization etc. It was much worse before this.

But to everyone, if management is going to beat you up with your estimates, maybe find a place where management doesn't? The pathological thing described in all of these situation isn't Scrum, Agile, or giving estimates... Its the managers who beat up employees.

[matwood]

> Its the managers who beat up employees.

Agree completely. There is a difference between management pushing and beating up though. Sometimes I wonder if people get upset at normal pushing/asking for clarification. I've seen both from management, but have also seen engineers get unreasonably upset at simple questions around an estimate.

[jboy55]

What I've found is that when engineers are sensitive to giving estimates its a symptom of some sort of insecurity around their work. They're probably also feeling that they are 'outside' the decision making/power structure.

What helps is first identifying why an engineer is feeling insecure about their job, imposter syndrome, some sort of life events you may not know about. If the engineer hasn't been having issues delivering, then you want to really talk with them and find out what it is. Why do they feel they're going to get in trouble or 'beat up' if they don't hit the estimate. If they have been having issues, then you should be identifying why those issues have been having, but that is a whole different set of issues than what I think this thread is talking about.

If they are feeling outside, this is probably evidence that this engineer feels that they've been shut out giving input for the 'how' or 'why' questions surrounding the design of the project. They also maybe having resistance to opting into what the goal/product is. Perhaps the goal isn't clear, perhaps the goal isn't well defined, or there is some bigger issues.

Finally, if you as a manager aren't constantly getting estimates as the project is progressing, especially if you aren't using an agile framework, then you need to. If you are using it, have you pointed your backlog without input of the team? Are the scores stale and if you repointed, with new info the scores would be much different?

If you (anyone reading this) are a manager and you think your job is to get an estimate and drive your engineers towards that, then you are only doing only a superficial part of the job.