There are lots of reasons why it is good or bad to have a Scrum team handle both new development work as well as support work. When an organization determines that the best way is for support and new development to be done by the same team, careful planning and a little bit of discipline during sprint execution can help meet sprint goals and stay on top of issues reported by users.
Planning
During sprint planning, a certain percentage of the team’s time needs to be allocated to support. For an existing system, that percentage can be based on historical metrics from the time tracking system. Of course this requires that people’s time for support and new development be tracked under separate categories. Also, the support allocation may vary sprint by sprint if there are extraordinary events expected in a sprint (e.g. major new features released to production in the previous sprint).
Based on the percentage allocated to support and non-development work such as backlog grooming, company meetings, etc. the team’s capacity to work on user stories is reduced. A sample capacity calculation is show in the diagram below:
During sprint planning, user stories are pulled into the sprint plan, tasks are identified for each story, and task hours are estimated. When the team has reached its hours of capacity based on total task hours, the sprint plan is complete. There is no need to create placeholder tasks for support items unless that helps with time tracking (more on this later).
All concerned stakeholders (including the team!) need to be aware what percentage of the team’s time is going to be allocated to support work. This becomes more important if a team gets hit with a lot of support work and the sprint commitment is jeopardized. This also underscores of the importance of looking at the team’s velocity as an average across many sprints since it will fluctuate depending on support needs in a given sprint.
In Flight
Ground rules must be established and agreed to by team members, product owners, and representatives of the end user community that determine what work is handled as support items to be worked on immediately or as new backlog items for future sprints. One model for this is:
For business stakeholders who previously worked in environments where the support team would jump on any support request as soon as they received it, the ‘4 hours or less’ rule is the most difficult one to get used to. In traditional project organizations with separate development and support teams, some stakeholders viewed support teams as a way of bypassing development teams that were mired in 6 or 12-month long development cycles. When the organization adopts agile and they see that their requests can be considered (of course factoring business value relative to other backlog items) within a few weeks, they are typically much more receptive to these types of guidelines.
Who works on support requests depends on the size and composition of the team. A couple of models are:
- Dedicate one person per sprint to be the primary support person. Other team members focus on sprint backlog items. This works well when the team has a good balance of knowledge and skills.
- Pick up support tickets as they come in. This can work well and fill in some of the time gaps or delays within a sprint. However, a high volume of tickets can make it hard for team members to get traction on sprint backlog items.
Just like it is important to provide high visibility for sprint backlog items and progress, it is just as important to make support work visible. A Kanban board, complete with Expedite lane for high-priority tickets, and sticky notes for each ticket are an effective tool that can help a team stay on top of support work.
Why use a Kanban board when your company already has perfectly good help ticket tracking software? I have found that the extra level of visibility of tickets on the board reminds everyone about outstanding support work rather than letting it fall into the background. This is especially important when the team is focused on user stories and meeting the sprint commitment. Timely resolution of support issues can impact customer satisfaction as much or more than new features so its warrants the same level of visibility as a Scrum taskboard.
It is also helpful to publish the actual percentage of time that the team is spending on support while the sprint is underway. Remember how we told everyone during sprint planning what the support allocation percentage was going to be for the sprint? This is where the team’s progress on sprint backlog items is weighed against the support commitment. With a higher than planned support load, the team may not be able to complete all of the sprint backlog items; with the lower than expected support load, the team should be able to take on more backlog items than planned.
Reflections:
- Adjust team capacity to reflect anticipate support load
- Establish ground rules for what is handled as a support item vs. a new backlog item
- Track and report support effort vs. planned effort so that impact on sprint commitment is understood
Agile Reflections 
So in the above you are assuming 8 hours a day of full productivity? Isn’t that an unproven measure of productivity? And if so, aren’t you already setting your team up for failure. If you have to look at capacity, why don’t you take the same historical data and look at it individually. I have some developers who work full speed and show 6 hours of development, while others with more difficult tasks show 2. This doesn’t mean they’re not working 8 hours, but as an agile project manager / scrum master – I don’t care except when it comes to Sprint planning. At that time I look at historical velocity and make sure we don’t have story points or task hours that go above that. In utilizing this approach my cost and time estimation for a six month project with a $500K cost, came in at two hours under estimate! And, yes, this was a team that was accountable for production hours along with new development. I do like your “In Flight” matrix though. IMHO
Thank you for your comments Patty. This model does not assume 8 hours of productivity. The “Meetings” column in the capacity calculation can also be labeled “Interruptions” and these hours are deducted from the team’s capacity to work on sprint backlog items. Meetings/interruptions could include daily standups, backlog grooming, company meetings, 1-on-1’s with managers, etc. Similarly, an additional column (not depicted above) can factor in each person’s productivity. This can be userful when someone new joins the team and is incurring learning curve.
Capacity-based planning and velocity-based planning can work in concert. Capacity can factor in fluctuations in team size and availability using hours as a transparent measure. Velocity-based planning should factor in historical team performance as you indicated in your comments. The two can also be used as a sanity check against each other to make sure that task estimates and story points line up. If the team has finished sprint planning based on hours of capacity and the total story points for the stories in the sprint plan is out of line with historical velocity it could indicate a number of problems with how the team is estimating or sizing stories.