As I’ve said before the most common problem I’ve seen with software development teams is over commitment. If worse comes to worst you get to the end of the spring before realising the problem. But you don’t have to wait until the end of a sprint to take corrective action.

This post was prompted by a comment, by Chris, on the post where I described what to do when tasks in the Sprint Plan are not finished. My assumption in that post was the team only realises they are overcommitted at the end of the sprint. And for first time teams that is often exactly what happens.

What I didn’t mention is that more mature teams are likely to spot what is going on earlier.

The Sprint Plan from Agile Project Planning lists the tasks the team has committed to doing during the Sprint. There are several possible reasons why a team might need to take corrective action:

1. There are just too many User Stories allocated to the Sprint (i.e. over commitment)
2. A task is harder than expected putting the Agile team behind schedule
3. A task is easier than expected putting the Agile team ahead of schedule
4. A particular team member is free but cannot pick up any of the remaining tasks

When the team notices things are going astray it is much better to take corrective action during a sprint rather than wait for disappointment. Chris nicely describes how to take corrective action during a sprint so I thought I’d repeat what he said here:

We now make adjustments throughout the sprint to ensure we hit 0 hours at the end. I mean, if half way through the sprint it is obvious we are way off finishing all the stories we will drop a story from the sprint, likewise if we are ahead we may add one. This isn’t a substitute for better estimation but things never tend to go exactly to plan.

If the team knows it cannot complete all tasks by the end of the Sprint then they must drop Tasks or the Product Owner must drop whole User Stories. More positively the team might get through the tasks faster than expected and the Product Owner might add User Stories to the Sprint to fill the gap. Similarly, if a particular team member can’t pick up any of the remaining tasks in the Sprint Plan, perhaps because they lack the specialist knowledge or someone else is working on the task, the Product Owner can add new Stories into the Sprint. (There are pros and cons to adding to a Sprint: the pro is that it might give you more delivered functionality, the con is that adding these new user stories risks not delivering anything.)

Those adjustments are part of Agile Monitoring and Control and Agile Project Planning.

This post is part of my What do I do When … ? series. Please drop me a line or add a comment if you’ve got a question you’d like answered.