Iteration Planning for the Unplanned

On any project, you will have both planned and unplanned tasks. Planned are those tasks that you knew ahead of time and scheduled some of your work towards those efforts. Unplanned are everything else. In many software shops including mine, the people doing the development work also help internal operations with ongoing technical support for internal and external customers.

Though Agile helps adapt to change by accommodating unplanned tasks in future iterations, there is still a challenge of what happens in the current iteration. If you are doing Scrum, it is expected that at the start of each iteration that the team commits to the scope of that iteration and that any additional work requested by customers should be considered in future iterations. Sounds good, but most technical support is needed on a much frequent basis and turnaround must be at a minimum. Therefore, you can have support issues to resolve on an hourly basis at times and you must respond within the next 12 - 24 hours. So, how do teams address these issues? Mishkin Berteig from Agile Advice has identified a few in his latest post:

1) The part-time allocation to the iteration's work is most common. There are a couple things that need to be done to make this work well in the long term. The main thing is to make the allocation of time inflexible: if you allocate 50% to the iteration and 50% to support, then you should never be flexible about that allocation. This is necessary in order for the team to make a commitment at the start of each iteration.

2) Another common method is the "fluorescent note card" method which requires stakeholder negotiation around the impact of interruptions. With this method, any time a stakeholder comes to the team with a request, the Process Facilitator writes the request on a bright colored note card. The team then does a task breakdown on the card and using their normal process (whatever that is) estimates the work. The requesting stakeholder then has to negotiate with any other stakeholders about what work to remove from the iteration in order to make room for the new work. The trick here is that the team has to be involved because they have already started on some of the work and it might be difficult to dis-entangle things enough. This process works well primarily because it makes the tradeoffs visible. It does not work so well with letting the team make their commitments.

3) A third common method is to form two separate teams: one doing new work, one doing support work. This is simple, effective, and annoying for the people on the team doing the support work! Please don't consider a rotation system since this destroys the process of team development and makes it nearly impossible for the team doing new work to learn their capacity for the purposes of commitment.

4) A less common, but fourth method is to have extremely short iterations. In this method, choose your iteration length to be so short that you can always start work on urgent interruptions before anyone gets impatient! This can be exhausting, but it is one of the best ways to get the team and the organization to understand the large toll that these interruptions take.

We have tried both #1 and #3. The problem with #3 is that developers that are put on the support work would love to do some development work. Plus, it is often difficult to have the knowledge (at least in our organization) to have a select few people who can address all of the support issues. However, if you try and combine support issues with ongoing development, you will find yourself trying #1 next. Unfortunately, it is very difficult to estimate what percentage of time should be put towards Support vs. Development as Support issues will come and go at an expected rate.

I don't think we can manage one week iterations (idea #4) effectively at this point at least until we become more mature at Agile and have the right infrastructure in place to turnaround iterations this quickly.

This leaves us with #2, which is what we are trying to do at this point. On our current Iteration Schedule board, we will have a Story called Issues that will be at the top of the list. Then, every issue will be identified as a Task and will have a color designation to help it stand out against "Planned" tasks and stories. I like this idea because it helps the team address what is reality but also balance the priorities of the Issues against Development stories. It also makes since that the Development team OWN the support issues since they have the most knowledge and skills to address issues in their own product and technical domain.