Wrongly estimated stories normally create more pressure on team which in turn impacts the quality, velocity and off course targets.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:
Is there any way to handle this issue? It is ok to pop out some stories in between sprint?
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!).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.
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.