UX in the Scrum Team — Can it become love?

+++++++++++++++ 2020 Update ++++++++++++++++


Without surprise, Scrum is also our process of choice at our office. The problem was that we never really figured out a good way to include UX in the scrum team. Until now!

History Lesson

In waterfall there is no way back and the feature/software is released when it’s completely done. Any testing can only happen afterwards.

Sounds good? Well, maybe if you are still using Fax as your main communication device.

Scrum to the rescue

And here’s the catch. UX works differently. UX tends to plan ahead and create full-fledged concepts including polished designs that would then be realized by the development team. At least this was how it was done back in the days.

Creating these concepts and designs along the running sprint leads to the development team waiting for input before being able to start working on stories and features.

So we see the issue: UX and Scrum don’t really match up. UX can’t be part of the Scrum process, or can it?


But simply applying the rules of Scrum to the UX process doesn’t work out either:

  1. It’s important to have a conceptional phase, before starting implementing a feature. This consumes sprint time in which the rest of the team has to wait.
  2. Skipping the conceptional phase and simply trying things out and iterating can work out, but you can lose the big picture of your desired UX on the way.
  3. Rushing through concepts and designs to get a feature done in a sprint and accepting a „minimal viable UX“ can harm your product.

Mind the Agile Waterfall when implementing UX in your Scrum Workflow!

The Agile Waterfall?

Well, that’s what is called an Agile Waterfall, or Agilefall. You would use agile methods that are constrained by a process that is more like a waterfall that Scrum wanted to replace in the first place.

Lean UX

Simply take that assumption and run a test on it. As a paper prototype, as a working click dummy, or even a full-fledged feature that is designed and implemented as a working increment during a sprint. Recap afterward and validate your assumption. Iterate over it during the next sprint to make it even better.

Again the problem with Lean UX is that you are risking to harm your user experience and your product by releasing the wrong feature. Sadface.

UX as a Service

This can work out, but we found that it’s not a great idea to not have a UX designer as part of the development team. The key part of the important knowledge and information on the development gets lost and this makes crafting a great product hand in hand pretty difficult. Still #sadface.

Finding the right workflow

It took us almost two years to figure out the right way for us. During that time we’ve talked to a dozen other scrum teams, agencies and user experience designers about their processes and ways of connecting the two worlds.

Not surprisingly it turns out that there is not one single perfect solution. Different teams approach this issue differently. From simply accepting that UX can’t be part of the Scrum process and setting the UX team apart, switching from Scrum back to a more waterfall-like model, to make it work.

We simply did not want to accept that. So we looked further. And finally we found the right combination of tools and methods to achieve our goal!

I’ll go into detail below, but to wrap it up the solution for us is a dual track agile approach, with a discovery and a delivery track, combined with staggered sprints in which the UX designer has different objectives and responsibilities, depending on the stage of the sprint, complemented with design spikes for uncertain UX challenges.

This workflow gives us the option to include UX deep into the scrum workflow without missing on preparing and planning the user experience ahead of the development.

UX & Scrum? It works with Dual Track Agile in Staggered Sprints and Design Spikes.

Dual Track Agile

Discovery Track

This track includes the complete user research, concept of the features as e.g. user story maps, drawing wireframes, etc. and crafting simple to complex prototypes.

The findings and concepts during the discovery track are then continuously given into the delivery track in the form of tickets, user stories, concepts and prototypes including results of stakeholder interviews and user tests.

Delivery Track

If you are running single track Scrum by now this is your only track.

The role of UX in both tracks

Since the objective of the first track is to generate information and concepts during a sprint and then hand it over, there are always details missing that are important to consider during the development. For example details on an animation of an interface component.

So the UX designer is kind of a consultant to the development team in the delivery track.

Staggered Sprints

Those objectives are as following:

  1. Design/Concept for the following sprint (Discovery Track)
  2. Consult on the UX of the current sprint (Delivery Track)
  3. Review the result of the past sprint(s) (Discovery Track)

To make it more clear have a look at the following graphic that shows the role of UX during the given sprints on the given tracks.

Dual Track Agile & Staggered Sprints are key to implement UX into the Scrum Process

Design Spikes

We make use of exactly the same. When we need time to explore and play around we plan a spike in our sprints. With a defined time box and a defined goal that maybe something like „evaluates if empathy mapping can help us to understand the user better“. The result of that spike will then not necessarily be a great empathy map, but the know-how of empathy mapping and the confidence if empathy mapping fits your needs, or not.



UX & Digital Product Designer. Director of UX & Product Marketing at Trusted Shops. Ex-CEO & Co-Founder of Reputami.com.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store