Delivering Service Design with Scrum - 6 insights

Starting something new is always inspiring and exciting.

Getting the chance to start from scratch designing a new and effective service, together with a team is something I like best in my job as Service Designer at Liip. Immersing myself in customers’ needs, developing great new ideas, making them tangible with prototypes and getting stimulating feedbacks. These parts are definitely the most inspiring and fun of service design projects.

But the delivery can be a really hard landing.

When working on service design projects, we break open existing silos. We align all the different parts involved in the service to create a better and more efficient service experience. For the delivery of the new service, that can also entail a high degree of complexity. In addition to the hard work of developing concrete solutions, we also have to deal with other challenges. For example, changing the habits and behavior of people or clarifying organizational uncertainties. The search for the right decision-makers and sponsors between the different parts of the company and technical restrictions as further examples. After the thrill of the first creative phases, delivery can mean a really hard landing.

Combining service design with agile methods helps facing the challenges of delivering.

Having worked in both Service Designer and Scrum Master roles in recent years, I tried several ways of combining Service Design with Scrum. My goal is to combine the best of the two ways of working to make this hard landing a little softer. Here are 6 learnings that proved to be very helpful:

1. Use epics and user stories to split the service into more “digestible” pieces.

Everyone probably knows the feeling of not seeing the wood for the trees when you’re standing in front of a wall full of sketches and stickies with ideas. Then it’s very helpful to create a list of epics. In the Scrum world, epics are “a large body of work that can be broken down into a number of smaller stories” (see Atlassian). In Service Design, epics can help dividing the entire service into smaller pieces. This reduces complexity, and allows dealing within specific and limited challenges of a single epic, rather than the whole. Also, the ability to clarify one epic gives good clues where to start with this big mountain of work.

2. Use the service blueprint as the master to create the backlog.

In software projects we often use user story maps to create epics and user stories. In service design projects, the service blueprint is a very powerful alternative to do user story mapping. Service blueprints help mapping and defining all aspects of the future service - from the targeted experience to internal processes, systems, people, tools, etc involved. This contains a lot of useful information for user stories e.g.

• The actors involved, eg. the different types of users (as personas), different staff people, systems, tools, etc.
• The required functions, as each step of a service blueprint usually contains a number of functions that will be written in the different user stories.
• The purpose of the function, as you can read from each part of the blueprint what is triggered by this step.

After a first version of the user story backlog is created, you can reassign the user stories to the service blueprint. Mapping all the written stories to the blueprint is also great to determine if some user stories have been forgotten. This helps a lot to have a better overview of what to do and how it affects the service experience in the end.

3. Do technical spikes in an early stage of the project in order to make your service more feasible.

If the service contains digital parts, it’s highly recommended to face the technical crack nuts in the project as soon as possible. Scrum provides us with the so called technical spikes - a great chance to dive deeper into different possibilities of solving technical issues of the new service. Strictly timeboxed, they allow developers to explore different technical solutions and suggest the one that fits best. Furthermore the team can discuss the consequences and adapt the service. In order to still create a great experience but also find a feasible way of delivering it.

4. Estimate the business value of the different aspects of the service.

In Scrum, we use business value poker to prioritize user stories. A business value is a relative comparison of the value of different user stories. It helps to prioritize the delivery and to show where the most time and money needs to be invested. This process is also very healthy (and tough!) for service ideas. Knowing how much value each part of the service brings to the whole service vision is very valuable and allows the team focus on what really matters.

You can also do business value poker in combination with an adaption of the six thinking hats method, e.g. one of the team estimates the business value in the hat of the user, one in the hat of the top manager interested in return on investment, and one in the hat of the staff member interested in delivering a service experience that doesn’t mean additional work.

5. Deliver a “Minimum Viable Service” (MVS) before taking care of the rest.

Once we have the user story backlog rooted in the service blueprint and we know which story brings most value to our service vision, we start step by step to deliver the service. In agile software projects, the team starts by producing the Minimum Viable Product (MVP). Which means, delivering the smallest amount of features necessary in order to create a valuable, reduced product to users. For services, we are doing the same - creating a “Minimum Viable Service” (MVS). This allows the team developing a first basic version of the service in a short time to market. Delivering results in a early stage of the project is not only motivating the team but also allows continuous learning, adapting and evolving of the service.

6. Work in cross functional, self organised and fully empowered teams.

Scrum teams are self organised and include all skills needed. Without having a hierarchy based system. In a service design setting, many different fields of a company are involved and it’s hard to specify decision makers and people responsible. But that’s the key. Including each and every stakeholder of a whole service in the project is never ending and rarely contributing. Therefore dedicate a small and powerful team of experts involved, give them the full competence to decide and to organise themselves but also the responsibility to deliver value.

Scrum provides great ways to deliver complex service projects.

This blogpost highlights a few aspects of how we manage the challenges of delivering a complex service project. By combining service design with scrum - from the the tools and artifacts to the mindset and the way how teams work together.

Yet, also when following all these aspects, delivering a complex service remains a hard piece of work. But definitely an easier one to handle with the structured and well working delivery methods to bring our ideas to life. Step by step - sprint by sprint.