How to avoid having too much work in progress

Most teams I worked with have at some point had a lot of work in progress. Sometimes virtually the complete sprint back log have been in progress. This is definitely a bad sign. The reasons for this situation to arise are many. It can be bad break down of tasks meaning several tasks need to be worked on simultaneously to get progress. Or it can be that tasks are blocked because of some external factor. It can even be because the team are not focused and works a little bit here and there instead of completing tasks. When the iteration end comes closer it is not probable all tasks will be completed since even if each task only need a small effort to be completed there are too many in the end.

So having too much work in progress at any given time makes it hard for an external observer to see progress and it makes the team unfocused. All teams I worked with have quickly seen this problem and addressed it at a retrospective. And I think the only solution I've ever seen is that the team commits to be more disciplined and completing tasks before taking on a new one and make sure the tasks are things that can be completed by it self. And this is often enough. However there is another thing you can do that also solves other potential problems.

You can use a kanban. A very good description on how to use a kanban with Scrum is available here. What the kanban approach is basically about is to limit the number of items that can be in progress. The Scrum-ban article also adds a few new columns not used in text-book-scrum in order to get more kanban feeling and a sense of pulling in the process. So this is a little more formal than just saying "we'll be more disciplined" and it is also measurable. So what other potential problem does the kanban solve? Well, even though the backlog is prioritized there are times when the team, for efficiency reasons, might change the order they want to work on tasks. Having a ready column between to do and in progress (once again I must refer to the Scrum-ban article) is a very good way of visualizing the difference between the team's decision "what to do next" and each team member's "what to do next". Also having a small preparation queue like this will more likely identify blocking issues even before a team member actually tries to start working on an item. I think this helps the team identify these potential blockers early.