We have used one estimation method that has helped, but also has a downside. We use “ideal days” for estimation and define it as six productive hours. The other two hours of a typical eight hour work day are used up in breaks, hallway discussions and interruptions from other unplanned things. This seems to be reasonable.

The downside is that this hides up to 10 hours of interruption per week, per developer. That is a lot of time lost. It also defines an moderately interruptive environment as acceptable. In other words, it’s a way of hiding a problem that could be hurting productivity more than we know.

Another idea to handle larger interruptions is to create a temporary, special Scrum team. This team focuses on the special issue, solves it and then dissolves its members back to the normal teams. I described this idea in more detail at http://blog.dayleyagile.com/2009/03/20/minimizing-bad-effects-of-special-projects/. We have only used it once so far with a two person special team. It worked fairly well. I’d like to get more experience with it except the need for a special temporary team is also an indicator of other problems that I’m glad we don’t have!

On a side note, I suppose the other benefit of estimating scope creep/BAU and counting it as part of your velocity is that you get a better sense of the team’s actual capacity/output and how they progress and/or improve over time – e.g. are they becoming more efficient and effective as a team or are they simply being less disrupted.

Rod Claar