Should I list support activities the Development Team is engaged in as User Stories?

Question

I'm in one of many Scrum teams who are often told to allocate team capacities around 80% and leave the balance for supporting internal and external customers.

This translates to developer "Bob" allocating 10-30% of his bandwidth to weekly support activities. Evidence shows that Bob (and his peers) often blow over this number; this is due to many reasons including too many moving parts, complicated/tightly coupled software products as well as high levels of accumulated debt marching in cadence with low levels of rigorous QA!

Even the best bulldog of a Scrum Master gets pulled into a "this is an exception, the customer needs help NOW" discussion with his leadership chain and has to relent. Each...and..every ... Time!

I'd hate to track this kind of overflow with a separate tool / excel sheet and was wondering how bad of an idea is it to assign the team at 100% capacity (for us, that maps to 6 useful hours of a work day) and include support-based user stories for the 20%, even though the tasks broken down from these user stories are not measurable or quantifiable (bugs you don't know about yet don't exist! :))

I think the best practice answer is a resounding No to this ... Though I can't see any other way to easily AND clearly show (to my managers) (and protect Development Teams) that the support churn is almost always going above the allocated buffers for non-Sprint related activities.

Answer 1

TL;DR

"100% utilization" is a bad idea; agile projects rely on adequate slack in the process. "Ideal hours" can be bad too, although some practitioners can make a successful case for them in certain situations. Agile projects are about empirical team capacity rather than making sure individuals are utilized at 100% of some theoretical capacity limit.

Make sure all support work is a visible cost to the project, and apply the same inspect-and-adapt pattern to that work as you do to any other business-driven features. How requires a bit more explanation, though.

Let Capacity Be Your Guide

No invisible work, ever!
— CodeGnome's Law of Transparency

Because the support work isn't free, it must cost the project somewhere. You basically have two choices:

1. Reduce stories accepted into the Sprint until they fit within your typical velocity range.

   This approach treats support work as a drag on capacity, but doesn't attempt to measure it directly. In other words, leave sufficient slack for all the support work and then vigorously protect the team from support work that starts to cut into actual story commitments—unless the Product Owner feels some unplanned support work is important enough to justify early termination of the Sprint or an adjustment to the current Sprint Goal.

2. Treat support work as a set of user stories with assigned estimates.

   This approach treats support work as a visible cost to the project, and forces the organization to make estimates about how much team capacity they expect it to consume in terms of story points, ideal hours, or manpower. These stories should be routinely re-estimated during Sprint Planning, and any mis-estimated support story that consumes too many team resources should be treated the same way as any other user story. Specifically:

   • It should be flagged in the daily stand-up.
   • It should be escalated to the Product Owner if it puts the Sprint Goal at risk.
   • If the Sprint Goal can't be met because of the support story or its impact on other stories, then the Scrum should be terminated early so the Scrum team (along with organizational management) can inspect-and-adapt.

There are valid use cases for both options. In particular, the first option may be necessary when you can't get buy-in from the Product Owner to add support stories or epics to the Product Backlog. Remember, the PO owns the backlog, but only the Development Team can accept stories into a Sprint! Limiting stories to your team's realistic capacity is a good mechanic for making the cost of support visible to the organization.

The second option is the better of the two, though. It conforms more closely to the Law of Transparency, and makes it easier to prioritize support work against other project deliverables. It also allows the project team to treat variance in support requirements as an estimation issue or resource constraint.

Either way, as long as the organization doesn't treat support work as "free" or unreasonably demand that support and project deliverables be treated as first-priorities simultaneously, you will be in a better position to successfully deliver value. Your political mileage may vary, of course.

Interrupt-Driven Work

A final word on the whole issue of support is in order: Scrum isn't anti-support, but it is firmly against allowing unscoped work into a Sprint. Such work is often disruptive to development flow, and can create a great deal of task-switching overhead that can negatively impact team performance. While some of this can be managed through sufficient process slack and prioritization, it easily gets out of hand.

If you can, try to make your support process respectful of the development flow by applying appropriate service-level agreements. Also, make sure your estimates include a sufficient fudge factor for the inevitable task-switching and cognitive dissonance that are caused when support issues interrupt other active tasks.

A single Scrum Team can provide both features and support, but it's a zero-sum game. Both types of work require time, effort, and resources, and the more you spend on one the less you have for the other. If you keep that fact firmly in mind, and ensure that it remains thoroughly transparent to the organization, the pros and cons of the process will generally speak for themselves.

Answer 2

First of all, you are missing a key point when mixing Agile with plan-driven development. In scrum you don't level team members based on their availability, rather than deliver complete user stories at the end of a sprint.

You really don't care about that, you deliver stories or not, the more, the merrier :).

Having said that, if you want to account for each and every minute of the members' clarification time, you can, and it will probably tell you what you already know. (6 hours on code 2 or more on clarification)

At the end of the day, if you want to produce that awareness to the business team, find a way to measure it, by any means you can think (tickets, excel rows, mails, etc.), and use it as a tool to justify your ability to deliver (velocity), during the retrospective, or even better, during the sprint review.

Do that, if necessary, at least once in the lifetime of the project, let it not be something you complain about, rather than a true fact that is negatively impacting your development process. Once you can tell your PO that you are spending a significant amount of time on clarification/doubts/inconsistencies, with the proper evidence, you are not just complaining about it, you are raising that issue, to the whole team, in other to be better next sprint.

Once they know that, it becomes part of the process, therefore, you can measure it again later, let's say 2 or 3 sprints later, and compare the results, if that even matters to you.

The main thing is that your velocity should talk for your team, rather than some willful metric.