👋 Great designs start with great feedback. That’s what Workflow is built for. Start today.
The Ultimate Scrum Guide for UX Designers
Many people consider Scrum and user experience (UX) opposites. As a result, it is hard for designers to work in a Scrum environment. However, with Scrum’s popularity, UX designers have to learn to work in Scrum. Here’s how to do that.
- Updated on February 21, 2023
But why? Why do so many people think Scrum and UX are so hard to combine? Let’s take a closer look at the differences and continue to discuss ways of overcoming those differences.
Table of Contents
Differences between Scrum and UX
Scrum and UX have their differences. How you manage your time is one of those differences. But there’s more. Some of the following differences are Scrum related, while others only impact Scrum and UX indirectly. Here’s the overview.
Time management and increments
First of all, there’s a different approach to time and status management. Agile and Scrum work with time-capped periods called ‘sprints.’
Each sprint delivers an increment of a ‘done’ product. Tasks, or product backlog items (PBIs), as the Scrum guide calls it, are given a state. Most companies call these PBIs user stories.
User stories can have one of the following states.
- Ready
- In progress
- In review
- Done
Once the development team agrees that a user story is complete, you cannot edit or update your work during any future sprint. Your work is done.
It is different from the way a UX designer typically works. In UX, we have a different process.
As a UX designer or researcher, you’re likely working in increments too. The only difference is that you can revisit work you previously set as ‘done.’
In UX, your design is never truly done. Instead, you decide on a moment where you will agree on the version you want to push.
You have to revisit the work you’ve done before. For every function you add to your product, you have to validate your design as a whole. Or, to put it in Scrum words — you have to either label your ‘done’ work as ‘undone’ or not label it as ‘done’ in the first place.
That’s the short answer to this difference. In Scrum, you have to label your work as ‘done.’ You do not have to label your work as ‘done’ in UX.
How UX fits into Agile and Scrum
Here’s a fun fact. The official Scrum Guide does not mention UX. That says quite a bit about their approach to creating products and experiences, if I may say so.
The Scrum Guide talks a lot about creating value, but there’s no mention of users or what ‘value’ means for users.
It’s challenging to be a UX designer when there’s no definition of UX in an otherwise very well-defined framework.
The consequences of the undefined state of UX are something you will see a lot. For example, your stakeholders’ main focus is to create something as quickly as possible. In most cases, a good design is considered a nice extra at best.
It doesn’t help that design, in general, is seen as something subjective. You like it, or you don’t. It is not scientific. It doesn’t improve your product that much.
An example
I remember a product owner once telling me that he didn’t need a ‘fancy UX screen since the product wasn’t client-facing.’ Unfortunately, that’s a view on UX I encounter more often than I would have liked.
As a designer, you need to show leadership and be proactive in your approach to Scrum (and design skepticism in general).
That’s the situation as it is. Unfortunately, as it now seems, Scrum and UX are not getting along that well. That is a problem since they have to get along. UX designers are everywhere, and you will find an agile (Scrum) way of working everywhere you go.
Scrum and UX similarities
There is good news as well. I believe Scrum and UX can work together much better than most people think. That’s because most of the issues I’ve mentioned before are not Scrum or UX-related problems per se. Instead, these issues are part of a mindset.
A mindset is something that goes from colleague to colleague. It is a part of the company culture. That means we can learn a new mindset, a new process, or even a new way of working.
We went from Waterfall to Agile. Why not do the same for UX?
To create a shared mindset, we first need some basic understanding. To do so, I want to point out some ways in which Scrum and UX are very much alike.
Adaptability
Scrum allows you to quickly adapt to new insights by working in short sprints. Instead of working on something for months, you can adjust your work based on the events of the previous sprint.
That’s of great interest to UX designers. It is common for UX designers to take a step back to evaluate designs. If it turns out you have to change or improve your design, you can do so as soon as the next sprint.
In some cases, you can even do that during the current sprint if your discovery is an obstacle to achieving the current sprint’s goal.
Iterative way of working
As a UX designer, you’ll most likely work iteratively. In other words, you go around in circles (or iterations), repeating a set of steps in each iteration to improve your design work continuously. Common design methodologies like Design Thinking and Double Diamond are built on this idea.
Every circle you make is like a Scrum sprint. This way of working ties in with the previous point on adaptability. Scrum and UX both are very keen on improving the work based on previous increments.
Remember how I mentioned the difference in time management and setting states to user stories before? There’s a fix for that!
Let’s say the initial design work on a user story is complete. Unfortunately, that means you can’t work on it anymore. However, it doesn’t mean you can’t add another related user story to the next sprint’s backlog.
For example, if you have PBI called ‘design login flow,’ it is perfectly acceptable to have another PBI in the following sprint called ‘validate design login flow.’
Creating value
UX is about users (duh). As I mentioned before, the Scrum Guide does not mention UX or users. However, it does mention creating product value.
That’s close enough from a UX perspective since UX isn’t only about users. It is about creating value for users. A well-developed product will only succeed if it creates value for the user. It is up to you to make the product valuable.
As it turns out, both UX and Scrum have the same goal. That’s a very important similarity and an excellent foundation for working together. But we do need a good name for that foundation.
Let’s call it value-centered, as a nice mix of both Scrum and UX.
How to work with Scrum as a UX designer
As it turns out, Scrum and UX aren’t that different after all. That’s not to say it will be easy to work as a UX designer in a Scrum environment.
You will encounter a lot of naysayers in your journey of building a shared mindset for Scrum and UX. It will be hard. You will make mistakes. I know this because I’ve encountered the ‘Scrum versus UX’ discussion on many occasions myself.
To help you out, I have a few tips, tricks, and best practices on how you can incorporate your UX process within Agile and Scrum. These are based on my own experience.
Work one sprint ahead of the development team
Scrum uses a few definitions to help the Scrum process. The most well-known one is the definition of ‘done.’ Some teams also use a definition of ‘ready.’
Although mentioned in the Scrum Guide, the definition of ready is not an official Scrum term. However, Scrum teams use this term to see if a user story is defined well enough to be picked up for an upcoming sprint.
Common user story criteria are:
- A clear description of what to develop.
- An estimation of how long it will take to develop.
- The expected value it brings.
The definition of ‘ready’ is an example of why some say Scrum and UX do not go well together since the user story criteria do not include UX parameters by default.
It is up to you to add relevant UX-related requirements. These could be all or any of the following.
- User tested and validated.
- Designed (UI/UX) based on company or design system standards.
- The design has been discussed with the development team to determine technical feasibility.
- The design is considered to be ‘ready’ by the development team.
You can only add user stories to an upcoming sprint with the criteria mentioned above in place. By defining UX requirements, you make sure UX is part of the Scrum team’s process.
Since you can only pick user stories in which all requirements have been met, you are forced to work on product features before the development team can pick them up in a user story. That’s a good thing. Why? I’ll explain next.
Don't work on the same user story as the development team
I’m serious. Never do that. Keep it completely separate. I’ve made that mistake several times, and it was a disaster every time.
I remember when I was working on a feature for a startup many years ago. I had to rush my design process since the feature had to be delivered this sprint. We had to complete the research, design, and development during the current sprint. The team was under a lot of pressure from the stakeholders and the product owner.
Halfway through the sprint, one of the developers asked me to look at something he was developing based on a design draft I had provided earlier.
“How does this step from your design work?” he asked. I didn’t know because I hadn’t had time to really think through or validate my design. We both had to redo our work a couple of times because we both ran into unforeseen difficulties.
As it turns out, the development team could not develop something I had designed within the current sprint. The result? We failed the sprint goal, the project got delayed, we increased our technical debt, and our team chemistry took a big hit.
What to do instead
Try and work (at least) one sprint ahead of the development team. I’ve mentioned the definition of ‘ready’ criteria before. They will help you immensely.
If you design and validate your feature beforehand, you might make the next sprint goal without issues. Another way is to have a designated design sprint where you complete your base design work before the development team starts their work.
Do your work together with the development team
This one closely ties together with the situation I wrote about just before.
Imagine what would have happened if I had involved the development team more during my design work.
I am sure that the problems we have faced wouldn’t have happened. And even if they did, they would have occurred earlier. Nevertheless, we would still have been able to adjust our planning and make the sprint goal.
Design review meetings
Once again, that’s easier said than done. How can you involve your non-design colleagues in your design work? One way could be to organize agile design review meetings.
Design reviews are time-capped meetings with your developer(s) where you walk them through your design and discuss the feasibility of your design ideas. This meeting is also the moment to ask questions you might have for the development team.
Organizing this meeting one sprint before the actual development starts allows you to adjust if there are any obstacles.
Team building
An additional upside to the design review approach is team building. If you do not involve the entire team, there could grow tension between the developers and the designers within the development team.
I’m sure you know the prejudices developers and designers have for each other. I’ll assure you; designers and developers are not that bad if you try a little harder to get to know each other.
Developers might have suggestions to help you out. They know what’s the best way to build the product. They might have great insights for you to use for the remainder of your design sprint. Developers aren’t that bad. Make sure you show them designers are pretty decent, too. A little bit of effort goes a long way.
Divide sprints into two parts
In my experience, there are always two parts to a sprint when you facilitate a design review meeting.
- Before the design review where you try and set up the foundation of your design. Spending too much time on details is a waste of time since you’re not that clear on the specific goals of your design just yet. You collect your questions for the design review here.
- The second part of the design sprint takes place after the design review. You use the input from that meeting to improve the work you’ve already done. This part of the design sprint is where you add detail and depth to your design. It is okay to have more than one design review per sprint. That’s up to you. I like to have just one per sprint, but that might change depending on the project.
If you take your team along with you on your design journey, they will start to feel like a part of the design.
As a designer, it is easy to let your fantasy run wild and design the most incredible (and complex) solution ever. There’s a catch, though. Something that’s maybe a few hours of design work can be a few hundred hours of development work.
Developers know this, but not all designers do. There’s a bit of frustration there, and rightly so. You can prevent this by taking the developers along with you, showing that you’re willing to collaborate, and being transparent in your design work.
Summary
The generally accepted consensus is that Scrum and UX are opposites. I’m not sure that’s true. I believe it’s a question of getting to know each other better.
Here’s what you can do to run a good project as a UX designer in a Scrum environment.
- Work one sprint ahead of the developers to ensure the design is ready to be developed.
- Involve your team in your design process to build trust.
- Facilitate design reviews to make sure you have a good handover to the development team.
👋 Turn good design to great design, with feedback you actually need. Get it on Workflow.
About the author
Hi! I'm Nick Groeneveld, a senior designer from the Netherlands with experience in UX, visual design, and research. I'm a UX coach that supports other designers and have completed design projects in finance, tech, and the public sector.
☎️ Book a 1:1 mentor meeting or let's connect on LinkedIn and Twitter.
