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.
Is there no room in a Dev team to manage operations items?
Should the scrum team be looking at their app telemetry to uncover issues that need to be addressed?
Is this only the responsibility of the support/operations team?
Hey Jim,
very interesting idea. There is one thing I am missing here.
How would you handle Refinement and Story Point evaluation in these one day sprints?
kind regards Marvin
Hi Marvin! Chances are, if you’re running one day Sprints, that your backlog items are probably already small and don’t require much in the way of refinement. Honestly, you could likely get away with sizing backlog items in terms of “small enough” and “not small enough.” If any kind of refinement is necessary, it could be done once a week. Lastly, if a LOT of backlog items are too big, it’s likely that your Sprints don’t need to be one day in length. Try lengthening the Sprint to 3-5 days instead.