Making promises you can keep WITHOUT Scrum Sprint Commitment using Classes of Service

So I convinced you that the Scrum Sprint Commitment is not such a great idea. I convinced you it is mainly there for learning. You want to move to a commitment to try to meet the forecast instead of committing to deliver the whole forecast. But your Product Owner has a real problem with this. He understands all this learning rationale but his stakeholders want to know whether he can promise then a certain delivery on a certain date. So can we make promises without the Sprint Commitment?

Sometimes a Scrum team is expected to deliver certain backlog items for a specific sprint. Examples can be stuff other teams need to consume, a fixed date commitment to clients, a regulatory requirement etc. Such backlog items have a very high cost of delay so we want to really make sure when we promise to deliver them we deliver them. One way to make sure that is to put them at the top of the Sprint Backlog. If the team is working down the Sprint Backlog by priority (as they should) there is a higher chance they will deliver these backlog items.

But I believe we should be more explicit. We should have a clearer signal that these are special fixed-date items and clearer policies for what to do to make our promises around them. In Kanban teams use classes of service for this purpose. I recommend Scrum Teams in such a context simply do the same. Mark these items with a special color in the Backlog. Establish policies such as “If they are in danger we make whatever effort needed to deliver. Sustainable Pace will be put on hold”. Visualizing that these items are different will earn them a different class of service by the team. It also means that normal items without this fixed-date commitment might be put aside to make the extra effort to deliver those, even at the price of overall throughput. These items might call for deeper estimation and planning up front than normal items.

One key point is to make sure that these fixed-date items are not the majority of items in the Sprint Backlog, otherwise they cannot rely on preferential service. If you have a case of your whole work being fixed-date driven you need to be extra careful with planning and consider taking a time-buffer to protect against the inherent variability in sprint results.

With time the Scrum Team and Product Owner will learn about their ability to deliver these items and might be able to make promises earlier before the Sprint Planning, knowing that the price will only be the effect on other normal items in the sprint.

Scrum works best when it’s connected to real business outcomes, not just ceremonies. Explore advisory and coaching or let’s talk.