Scrum is the most used Agile framework on the planet, but I continue to run into students and customers who aren’t quite sure how to make Scrum work best in a support environment. “We can’t plan a week of support work,” they say, “We have to use Kanban.”

While Kanban isn’t a bad choice for a support or service team, the reality is that Scrum can easily be used in this case. In this blog post, I’m going to show you how.

Run one day Sprints.

Yes, you can run a one-day Sprint in Scrum. While there is a maximum length for a Sprint (one month), there is no defined minimum. Scrum defines a maximum length because longer Sprints result in greater risk (thus, greater cost and lower return on investment). However, there’s no reason to set a minimum length. The expectation is that Scrum teams set Sprint length based on the work – they wouldn’t set a Sprint length shorter than made sense.

Support teams can’t plan that far in advance. The support queue is emergent – it changes constantly. So planning beyond the volatility of the support queue doesn’t make sense. Think of it like this, if your team KNOWS that a lot of the work they are planning into the Sprint is going to change or reprioritized before they can build it, your Sprint is too long. See the sidebar, “One Day Sprint,” for an example of what to do.

Holding the Daily Scrum

From the end of Sprint Planning until the end of the day, the team members attack the support tickets as they discussed in Sprint Planning. At some point during the day, the team members do a Daily Scrum, discussing which tickets are solved, which are in progress, and which are not started. They also decide whether or not they will finish everything they planned to do (per Sprint Planning) and will adjust their plans if they decide they can’t get everything done.

The Daily Scrum is important, even for a one-day Sprint, because it allows the team to catch errors early (e.g., someone is solving an issue the wrong way or even working on the wrong issue) and provides early warning for the team’s Product Owner (likely the team’s Support Manager) when expectations may need to be reset outside the team. Having been a Support Manager, I would have liked to have an early warning system in place on many of those difficult days.

Red Alert!

It happens all the time. The team has planned out what they want to accomplish and along comes the super hot, criticality one, top priority, sev-1 (you name it) – it has to be addressed RIGHT NOW.

Remember the team’s Sprint Goal (see the sidebar “One Day Sprint”)? It was to “remove all highest severity tickets from the queue.” OK. So, if this new ticket immediately becomes one of the highest severity tickets (if not THE highest severity), the team should address it. The team should establish an easy way for communication outside the daily Scrum (for example, a private Slack or Microsoft Teams chat channel) for events like this. Whomever picks up the hot ticket alerts the rest of the team, asking for help if needed.

If the red alert occurs before the daily Scrum, the team can catch up at that point and make whatever changes to the Sprint content are necessary. If the red alert occurs after the daily Scrum, the team can catch up at the following morning’s Sprint Review.

Coming Up Next

In my next blog post, I’m going to dig a little deeper into this topic with Scrum Teams that have both development AND support responsibilities.

One Day Sprint

What would a one day Sprint look like? Assuming your team has agreed that everyone is available at 9am local time (if your team is scattered across many time zones, you’ll have to work together to decide what your “local time” will be):

9:00am-9:10am: Sprint Review

During Sprint Review, the team reviews

  • what work was completed yesterday and what’s left,
  • any changes in the severity (order) of the work,
  • conversations with customers, and
  • other problems faced by the team yesterday.

The event ends with the team’s Product Backlog (ticket queue) reordered based on the current reality.

9:10am-9:30am: Sprint Planning

The team moves directly from Review to Planning. The Sprint Retrospective is skipped; the team does it once a week or two. On the days when the team holds a Retrospective (from 9:10-9:40), Sprint Planning is 9:40-10:00 instead.

The Sprint Goal is assumed to be to “remove all highest severity tickets from the queue,” though it could change from day to day.

Most of the event is focused on which issues are going to be addressed today. The more complex issues are discussed further, with team members providing thoughts on how to approach them. On some issues, team members might agree to gang-up (swarm) ; others may simply take one person to fix them and someone else’s eyes to confirm.

Sprint Planning ends when the team has figured out what they want to do and, at a high level, how they want to approach it.

12:30pm-12:45pm: Daily Scrum

The rest of the day is about getting the work done, with a daily Scrum somewhere later in the day to make sure everyone is OK.