Mike Cottmeyer from VersionOne has written an interesting blog post about the problem of handling support in agile software development teams. Mike highlights three potential approaches for handling this problem. Personally I think there is a fourth approach, as follows…
If it does have to be handled in this sprint, respond accordingly without estimating the work and without trying to break it into tasks.
Allow it to impact your team’s velocity as naturally it will.
When you do your next round of Sprint Planning, plan based on the velocity you achieve, so an allowance for support is naturally incorporated into your level of commitment. Do not allocate any specific time for support.
If your velocity is unstable and fluctuates significantly, try calculating standard deviation on your average velocity. Standard deviation will give you an objective way to understand the level of risk you are taking if you plan on your average.
If your standard deviation is high, the risk of not delivering is high. In this case, commit to a lower velocity and prepare some stretch tasks to be included if you have time.
- Make sure one person (probably a manager of some description) is responsible for triage – that is, deciding whether or not a support issue is really priority enough to interrupt the current sprint, or whether it should be deferred and scheduled in the next or a future sprint.
Of course if you are running a project across multiple sprints, this will still affect your release plan. But it should give you better predictability, and allow you to take action or manage expectations accordingly.