Monthly Archives: September 2015

Support Sprints

The nature of our support dictates that when our customer calls, we drop what we’re doing to work on the problem.  This keeps our customers happy. And it makes us feel good that we can fix it.

The problem with support is that it cannot be scheduled effectively.  Why?  Because we don’t know how long support will take.

  • The actual time could be more than the allocated time. This leads to sprint leakage as properly estimated work cannot be completed.
  • The actual time could be less than the allocated time, which leads to either: 1) pulling in random work which may not get completed, 2) spending too much time on stories that are really complete, but we’ll write one more unit test, or 3) twiddling our thumbs.
  • Context switching which is hard to do and wastes a lot of time. (cit. Spolsky, cit. Atwood)

A method that I have seen work well in past consultant engagements is to designate a support sprint. In each iteration, one dev team gets the support sprint. That team is essentially “on call”. When not actively engaged in a support call, the team can work on the support backlog (the triaged list of open support/infrastructure/internal bugs). This affords the following:

  • Dedicated feature sprints without interruptions (and hopefully less sprint carryover).
  • A pool of semi-dedicated resources always at the ready to work those critical severity / high priority issues as they arise.
  • A built-in method to whittle down the infrastructure backlog.
  • No single team feeling stuck in a support capacity because the support sprint rotates among the teams.

Have you used support sprints in your organization?  I’d like to hear more about how you implemented them and how well or poorly they worked.