Scrum for Services

Scrum is valuable not only in development, but also in service environments, as the complexity of sustaining services is at least as significant as that of developing new products. Therefore the benefits to be gained by services teams are similar to those in development teams. Based on our experience we developed a Scrum for services framework which has been used successfully for years.


Our article is also published on the Scrum Alliance web site.

wibas as a company

As a consultancy firm, we support clients world wide in implementing changes in their processes and structures to successfully achieve their strategic goals. The majority of our staff are consultants, but we also have head office teams which provide marketing, administrative and IT infrastructure services as well as developing software solutions for the business. (We have a Shared Services team which plans and organizes client missions, as well as developing and supporting infrastructure and software for our consultants and customers.)

Our challenge

As a company, we made our first steps with Scrum with our software development projects where we were able to reach significant improvements. Development, however, is only a minor part of our head office teams’ work; service activities are a far larger part. But until now there was no clearly defined Scrum framework to manage such service tasks as opposed to development tasks. We were therefore confronted with the challenge to form a new „Scrum for Services" framework for our head office teams.

In the meantime, we have managed to shift our entire organization to agile techniques; and Scrum for Services played a major role. In this article we describe how we developed the Scrum for Services framework, and what this framework looks like.

What is different with Services?

There are two main differences:

  • Source of tasks: During a Sprint, development teams have a scheduled flow, a firm Sprint goal and only one Product Backlog as input. Service Teams on the other hand have two sources of tasks to manage: planned tasks and incidents – e.g. customer inquiries. One of the typical challenges for any Service Team is to balance both sources.
  • Type of complexity: Service tasks are substantially more repetitive than development tasks. The complexity of projects lies in the uniqueness of the task. The complexity in services lies in a fast, reliable and repeatable service – hence more in the system and fewer in the single task.

Our idea

Our intention was to develop a Scrum for Services framework based on the foundation of Scrum values. We assumed that the Scrum values that apply for development would also represent a valid basis for services as well. Some Scrum techniques would have to be adapted and some new methods would need to be developed to manage services teams.

values_de.jpgFigure 1: Our premise: Scrum for Services and Scrum for Development share the same values, but have different frameworks with many commonalities.

The Scrum values are:

  • Deliver early and regularly
  • Transparency
  • Inspect & Adapt
  • Timebox
  • Self-organization

Our attempt toward implementation

In the spirit of „Inspect & Adapt” we began with a first approach for a Scrum for Services framework. We were aware that many iterations would be necessary, until the basic structure emerged and stabilized. Our assumption was correct, 12 Sprints (of 30 days each) were necessary to reach a stable framework.

For this initial approach, several steps were necessary: First of all we needed to map the typical practices of a service organization to the basic Scrum values (see picture below). Next we collected and allocated specific techniques of a Service organization to the Scrum values. These techniques were either derived from Scrum, Kanban or were entirely new ideas.

In the following pages, we illustrate the framework that resulted from this first concept and many Inspect & Adapt iterations.

020DesigningtheScrumforServicesframework.1000_de.jpgFigure 2: The path to the first Scrum for Services framework: Ideas for the implementation of service practices based on the Scrum values.

From the idea to implementation

Before we explain the framework more closely, let's have a brief look at the process of organizational change within our company. How did we manage the steps from the initial concept to the broad implementation within our company?

  1. The first Service Team and the responsible manager worked together to draft the initial concept.
  2. The team tested the concept in practice and optimized it by several Inspect & Adapt iterations.
  3. Subsequently the pioneers (out of the first team) transferred their knowledge of the framework to another team. Thus further practical experience flowed into the framework.
  4. Once the framework had been successfully implemented in two teams, we extended the use of the framework to all other Service Teams. At this stage, we also adapted the management activities to follow the Scrum rules.
  5. All Service Team members – and today every colleague in the organization – received training in Scrum.

How do we handle the different sources of tasks?

The most significant difference in Scrum for Services is the fact that there are different sources of tasks: as well as the planned tasks there are unplanned tasks, the so-called incidents. The daily work of a Service Team has two sources: the Sprint board and the incident queue.

Planned tasks are:

  • recurring tasks to sustain the services at their current level and
  • activities to further develop the services.

Incidents are:

  • All service inquiries from the customers.

To guarantee the stability of the Scrum for Services framework, we defined clear criteria: on the one hand, incidents can be placed only by our customers and, on the other hand, only the Product Owner is allowed to organize the Product Backlog items (including the service level items).

040SprintBoardinServices.web_de.jpgFigure 3: Illustration of a Scrum for Services board. On the left are the input sources for the tasks: the Sprint backlog and the incident queue. On the right is the Kanban board for processing all of the tasks.

To process all tasks, we combined the classic Scrum board with Kanban techniques. The „today" column contains those tasks from the Sprint backlog and the incident queue that the team plans to process today. The „in work“ column contains tasks that are in processing. The „done" column contains tasks that are already completed. The „waiting" column contains those tasks, for which the team is waiting for answers from others (e.g. customers). At the end of each daily Scrum, we remove from the board all the cards that are in the „done" column.

4.ild_de.jpgFigure 4: Photograph of a Scrum for Services board. The product backlog items are orange, the sprint backlog tasks are green, the incidents are white and the recurring tasks, needed to sustain the service level, are yellow.

Events in Scrum for Services

Scrum for Services uses the same cycle and the same events as those of Scrum for Development.

In the Sprint Planning meeting the service team forecasts the Product Backlog items it will deliver in the Sprint; formulates the sprint goal, and plans the tasks for the Product Backlog items. The team calculates its Velocity (the amount of story points that a team is able to deliver in one Sprint) including the quantity of incidents. In this manner the forecast also takes into consideration the probable quantity of customer inquiries during the Sprint.

During the Daily Scrum meeting the Service Team synchronizes the activities and plans for the day. Each Service Team member explains:

  • What has been accomplished since the last meeting?
  • What will be done before the next meeting?
  • What obstacles are in the way?

Every Sprint closes with a Sprint Review meeting. As in Scrum for Development, this meeting is a demonstration of the concrete work that has been „done“. In this context it is important to understand services as products. The Product Backlog items are the tangible characteristics („features") of these products. Each Product Backlog item has its own Definition of Done. In addition there is a general Definition of Done which defines the agreed service level. The Sprint Review meeting has established itself as the time to jointly discuss the further development of the services products within the team. This is invaluable for the strategic development of the services.

The Sprint Retrospective is performed immediately after the Sprint Review meeting and is the session in which the Scrum team reflects on its way of work and initiates improvements for the next Sprints.

Sprints in the Scrum for Services framework tend to be longer because only part of the day’s working hours is available to process the Product Backlog items. Nevertheless the length of the Sprint is never longer than one month.

5.bild_de.jpgFigure 5: The Scrum flow and events in Scrum for Services are identical to those in Scrum for Development.

Artefacts in Scrum for Services

Scrum for Services has three artefacts:

  • Product Backlog: is an ordered list of all features that might be needed to deliver or extend the service product.
  • Sprint Backlog: is the set of Product Backlog items selected for the Sprint plus all tasks necessary for delivering the increment and achieving the Sprint Goal.
  • Increment: is the service system provided to serve the customer (encompasses people, technologies and processes).

The artefacts in Scrum for Services differ from those in Scrum for Development merely in their form. The Product Backlog, for example, contains completely different items and the increment is something tangible. However one must understand the functioning service as a product.

Sprint Burndown and Velocity

As Scrum for Services has two sources for tasks, we adapted the Sprint Burndown to have two quadrants. In the upper quadrant, we register the number of remaining tasks in the Sprint Backlog (at the time of the daily Scrum). In the lower quadrant, we register the number of incidents (at the time of the daily Scrum).

060ScrumforServicesBurndown.web_de.jpgFigure 6: Example for a burndown graph in Scrum for Services

The „ideal burndown" shows the linear completion of all tasks. The „ideal incident level" is a horizontal line that shows the number of incidents in the incident queue that there should be, based on our agreed service level.

The Services Velocity graph also consists of two quadrants. In the upper quadrant, we track the backlog items’ velocity. We use this velocity to determine the forecasting of the Product Backlog items during the next Sprint Planning meeting based on facts. In the lower quadrant, we track the velocity for the processing of incidents. In addition we mark also the combined velocity that shows how the team’s efficiency evolves, e.g. whether improvement measures from Retrospectives are having an effect.

070VelocityinServices.web_de.jpgFigure 7: Example for a velocity graph in Scrum for Services

The Scrum for Services Team

The Scrum for Services Team consists of a Product Owner, the Service Team, a Scrum Master, and customers. The team model in Scrum for Services is the same as that for Scrum for Development.

  • Product Owner: is responsible for maximizing the value of the service and the work of the Service Team. The Product Owner is responsible for managing the Product Backlog; this includes e.g. prioritizing the items in the Product Backlog to best achieve goals and missions.
  • Customer: is the only person who can raise incidents.
  • Service Team: consists of professionals who deliver the service.
  • Scrum Master: is responsible for ensuring that Scrum is understood and enacted; serves the Product Owner, the Service Team, and the organization; removes impediments hindering the Service Team’s progress.


Scrum for Services is a framework for developing and sustaining complex services that has been well proven in the past several years in wibas. For us, Scrum for Services is a tangible competitive advantage.

Scrum for Services:

  • increases effectiveness and efficiency,
  • implements strategic decisions quickly,
  • enables changes at services quickly,
  • fits to a modern work culture.

Scrum is valuable not only in development, but also in service environments, as the complexity of sustaining services is at least as significant as that of developing new products. Therefore the benefits to be gained by services teams are similar to those in development teams.

Scrum for Services shows us that the Scrum values and framework are transferable to Services Teams. However many of the techniques and contents are different to those in Scrum for Development. With our experience, we have developed a Scrum for Services framework, which we have successfully applied for several years and are continuously developing further. For instance, we recently linked our company strategy to our Scrum Backlogs and integrated it into the Scrum for Services framework.

With our broad and long-time Scrum experience, we are pioneers of Scrum. We are happy to make this experience available to you.

Icon This article as PDF (3.5 MB)

Do you have questions?
Malte Foegen


+49 6151 503349-0

[protected email]

[protected email]

Do you have questions?
Malte Foegen


+49 6151 503349-0

[protected email]

[protected email]