Given a "frozen" iteration plan, what happens if the plan's stories require more work than expected

Question

I am not sure how to phrase this but I'd like to ask how Agile handles this.

My understanding is that in Agile, you freeze the stories that are in the current sprint.

What happens when a developer starts working on a story and realizes it's bigger than expected?

At that point, do you plan ahead by removing something else from the plan?

conversely, if they start working and get it done much faster than expected, can you fit something else in? Or do you just complete the sprint achieving less than you could have.

Specific to my situation, we have 6 week iterations, and the work is estimated upfront to fit into the iteration plan - but sometimes developers realize later that it will take more or less time, and then the iteration plan has to change. It seems that this would be incredibly common even if developers are choosing their stories and estimating/committing to them.

Answer 1

What you basically aim for in time-boxed approaches, like Scrum, is to get by the end of iteration potentially shippable product. It means that the ideal situation is when every story you started working on is completed.

Now it doesn't have be the same set of stories you planned for iteration. There are a few possible situations:

1. You planned to do n stories but for whatever reasons (underestimation, unplanned absence, new information, etc.) you can't. It means you should throw something out of the scope of the iteration so you can still deliver something rather complete, even if completeness means something different than you thought during planning meeting.

   BTW: because of such situations it is generally better to start working on most important stories first, so when you need to throw something out of the scope you choose among least important stuff.

2. You planned to do n stories but you go faster than planned and you can do more. A good practice here is to plan not only must-have features which you need to complete during sprint (taking your velocity into consideration that is), but also add some nice-to-have stories which you can start working on when you have time. It means that you basically agree that it is likely you won't complete those additional stories but if you're lucky some of them can be done.

3. You go exactly according to plan. Congratulations! Nothing to discuss here.

4. You have a combination of 1. and 2. Then you probably first compensate your underestimation with unplanned free time you have and check whether you still have some slack or are still overloaded and react accordingly as described above.

Answer 2

We solve this problem by working with committed and non-committed scope for each iteration.

each work-package (similar to functinality) is estimated with a Most Likely and a Worst Case estimate (by comparing with similar work or expert group estimation techniques).

Based upon business priority, we plan the releases based upon the Worst Case estimates. This is our committed scope of the release.

Next, the difference between worst case and most likely estimates is used to plan additional, but non-committed scope (using the most-likely estimates for this).

This gives us some leeway: there is space if things turn out worse then expected, and we know what to work on when there is time left.

When a work package needs even more time than the worst case estimate, there is usually still some time left from other committed scope. of course, if we think that we cannot even deliver the committed scope, then we need to replan accordingly. This will surely happen a few times in the beginning, but over time your estimates will get better and you'll be able to plan regular releases.

Answer 3

Don't want to plan around a best-case scenario and task out to 100% of the team's capacity, perhaps stop at 70%.

Prioritize and limit your work-in-progress so that if something goes wrong instead of having al your stories 70% complete you will have 70% of your stories 100% complete.

Answer 4

I wouldn't remove stories from a sprint but I would make sure the product owner has them prioritised. That way, so long as they are informed how far over you're likely to go, they'll have a good idea how far through the sprint commitment you'll get.

Equally, if you're getting through stuff quicker, make sure the product backlog is well prioritised and you can pull in stories from there if you get through your commitment.

The key for me is communication with the product owner so they don't get any nasty surprises.

You might want to try shortening your iteration length. The shorter the iteration, the less variation you're likely to have.