The Product Owner vs. the Service Level Agreement


One organ­isa­tional con­struct that often proves dif­fi­cult to solve with Scrum is the Service Level Agreement. The Product Owner should pri­or­it­ise all stor­ies that are on the product back­log, so each sprint deliv­ers the most busi­ness value to the com­pany. He is, how­ever, unable to do so when he is con­stantly thwarted by sup­port tick­ets that have to adhere to a strict Service Level Agreement. These sup­port tick­ets cause dis­turb­ances dur­ing sprints, and because they are auto­mat­ic­ally high pri­or­ity, the Product Owner is help­less in this regard. What can we do about this?

The Product Owner’s role

According to the Scrum Guide, the Product Owner is “the sole per­son respons­ible for man­aging the Product Backlog”. As such, he is the only one who can pri­or­it­ise the items that are on the back­log. The Scrum Guide clearly states: “No one is allowed to tell the Development Team to work from a dif­fer­ent set of require­ments, and the Development Team isn’t allowed to act on what any­one else says.”

The Service Level Agreement

Enter the Service Level Agreement. This is usu­ally a con­tract sold to cus­tom­ers that guar­an­tees that any out­age or bug will be fixed within a spe­cified amount of time. For the com­pany, it is a tool to make money, so in that regard it really is useful.

It basic­ally ignores the Scrum Guide’s defin­i­tion of the Product Owner’s role, and also tells the Development Team what to work on. Moreover, it com­pletely bypasses the Product Owner in doing so. The rules that are in the Service Level Agreement might be so strict that it is neces­sary to change the sprint back­log dur­ing the sprint.

The ideal solution

A Service Level Agreement tailored to the sprint length and to the cadence of the Scrum team would be ideal. This would allow the team to fin­ish their cur­rent sprint and add the new sup­port ticket to the next sprint. This way, the sup­port ticket gets the same treat­ment as any other story, except for the fact that it has a high pri­or­ity and must be planned in the next sprint. It also allows the Product Owner to keep an eye on the sup­port tick­ets that get put into each sprint, and to invest­ig­ate when a sprint gets over­whelmed with sup­port tickets.

Unfortunately, such an SLA is not always possible.

Alternative solution 1: a dedicated support team

You could keep all work that has to adhere to an SLA away from the Scrum Team and have them worked on by a ded­ic­ated sup­port team. This allows the Scrum Team to keep its sprints unin­ter­rup­ted. The sup­port team could use Kanban to solve sup­port tick­ets and cre­ate new releases faster, without hav­ing to wait for the end of a sprint.

This has sev­eral dis­ad­vant­ages, though. First of all, most developers do not like work­ing solely on sup­port issues. The mor­ale of developers could suf­fer. Furthermore, since many bugs are now handled by the sup­port team, the Scrum Team is less often “pun­ished” for lower qual­ity code, which means they may be inclined to pay less atten­tion to code quality.

Alternative solution 2: the buffer story

Another way to solve this prob­lem is to acknow­ledge that emer­gen­cies will hap­pen, and alloc­ate time for them in advance. This can be done by adding a buf­fer story to the sprint. This is actu­ally one of the Scrum Patterns called “Illegitimus Non Interruptus”.

The ideal buffer story

At the start of each sprint, make sure that a buf­fer story is in place that has story points asso­ci­ated to it. The amount of story points you should alloc­ate to this buf­fer story depends on the velo­city of the team and the amount of sup­port tick­ets that are usu­ally generated.

The Product Owner can assess how urgent an emer­gency is, and decide which emer­gen­cies are added to the sprint and which ones can wait. These stor­ies are then estim­ated, and their estim­ate is sub­trac­ted from the buf­fer story’s story points. When the buf­fer story is empty, no more stor­ies can be added to the sprint.

When someone still insists on hav­ing a story added to the sprint, the team needs to abort the sprint, plan a new sprint, and inform man­age­ment that the dead­line will shift. Since this is dis­astrous for team pro­ductiv­ity, the idea is that no one in an organ­isa­tion wants this to hap­pen, and the per­son try­ing to change the sprint scope will reas­sess how crit­ical their emer­gency is. Maybe it can wait until the next sprint.

In prac­tice, though, I have seen sup­port depart­ments that couldn’t care less about the sprints of the team. All they want is to stay within the time lim­its imposed by the Service Level Agreements. If abort­ing a sprint is what it takes to achieve their ser­vice level, then just do it!

A more realistic buffer story

When the pres­sure on solv­ing sup­port tick­ets is so high that the com­pany doesn’t care about abor­ted sprints, we need to think of another solu­tion. When these kinds of emer­gen­cies occur very fre­quently, the team may be in danger of hav­ing to abort every sprint. Of course it’s always bet­ter to con­vince man­age­ment that abor­ted sprints are very, very bad, but it may take time to accom­plish this. In the mean­time, you can use a dif­fer­ent approach.

The idea is mainly the same as the ideal buf­fer story dis­cussed above. The only dif­fer­ence is that we don’t abort the sprint when the buf­fer story is empty, but we remove the stor­ies with the low­est busi­ness value from the sprint, until enough story points have been removed so that the sup­port ticket fits in the sprint.

When this hap­pens a lot, this is an indic­a­tion that your ini­tial buf­fer story should have more story points.


The dis­crep­ancy between the Product Owner and the Service Level Agreement is one that’s dif­fi­cult to solve. You can try to have the SLA match with your sprint length. If that isn’t pos­sible, you can use a ded­ic­ated sup­port team, which I would advise against, or cre­ate a buf­fer story that caters to emergencies.

Do you use any of these prac­tices to work with Service Level Agreements in your com­pany? Do you have other ideas to solve these prob­lems? Please let me know in the com­ments below.