Help! Our estimate was off by a lot!

Another LinkedIn discussion, this time the question was along the lines of estimates that turn out to be incorrect. In this case, the person asks what the team should do when something estimated at 6 hrs turns out to actually take 26 hrs.

Wrongly estimated stories normally create more pressure on team which in turn impacts the quality, velocity and off course targets.

Is there any way to handle this issue? It is ok to pop out some stories in between sprint?

Most of the initial responses focused on the fact that estimates are always slightly wrong and that this error will normalize itself out. One person before me suggested mid-sprint correction with reflection during the retrospective. I agree that trends of estimate problems should be reviewed, but the real question was... what do I do right now in the middle of this sprint?! My response:

If you uncover something mid-sprint where your estimate will be 4x greater than originally thought, I would assume you have uncovered an impediment or complexity that was unknown during planning. This will happen from time to time, even on a mature team (otherwise you might not be doing difficult enough work!).

My advice would be to pull the product owner/customer in immediately. They need to understand the issue (and hopefully the cause). They need to decide if that story is still important to them at that cost. They may want to descope it knowing that everything else in the iteration is more important than that one thing. Or... they may tweak the requirement to get the majority of it and work around the problem.

I follow most scrum ideals, but I don't believe that a sprint's scope cannot be changed mid-iteration. (Actually, I'm doing a Kanban/Scrum blend now). It makes sense to re-evaluate when these things happen because the team has to remember that the largest goal is delivering the right business value. Delaying multiple expected items for a single item is a decision that should be left to the product owner/customer.

I'm curious to see what others add to the discussion thread. Unfortunately, I think most people are focusing on pure Scrum (ignoring other Agile flavors) and are assuming this is an immature team. I don't know if that is the case for this person or not.