The Ultimate Scrum Guide for UX Designers
Scrum and user experience (UX) are considered to be opposites. Like fire and water, they do not go very well together. However, with both Scrum and UX getting more and more mainstream every day, the only thing you can do as a designer is work together regardless of your differences.
- Updated on August 14, 2022
But why? Why do a lot of people think Scrum and UX are so hard to combine? Let’s take a closer look.
Table of Contents
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. At most companies, PBIs are also know as user stories. The states user stories are given are the following.
- Ready
- In progress
- Done
Once the development team agrees the work on a user story is complete, you cannot edit or update your work during the next sprint or any future sprint. Your work is done. It is not the way a UX designer typically works. In UX we have a different process.
As a UX designer or researcher, you’re most likely working in increments too. The only difference is that you, based on one of the many, many design thinking process variations you might use, can revisit work you previously set as ‘done.’
Your design is never done. You only have to decide on a moment where you’re going to 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. 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 crux of the matter. In Scrum, you have to label your work as ‘done’. In UX, you do not have to label your work as ‘done’. This can conflict when Scrum and UX work together
Differences between Scrum and UX
How you manage your time is just one of the ways Scrum and UX differ from each other. There’s more. Some are Scrum related while others originate from outside of everything Agile and Scrum-related.
How UX fits into Agile and Scrum
For starters, 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 suggests 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 is something you will see a lot. Stakeholders pay attention to how long it takes to develop their product. In most cases, a good design is considered to be an 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. I remember a product owner once telling me that he didn’t need a ‘fancy UX screen since the product wasn’t client-facing.’ That’s the view on design I encounter more often than I would have liked.
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. As it now seems, Scrum and UX are not getting along that well. That is a problem since they have to get along. That’s because UX designers are everywhere, and everywhere you go, you will find an agile (Scrum) way of working.
By the way, I don’t think it should be a problem since the Scrum Guide does not recognize roles within a Scrum team. In other words, there shouldn’t be a UX person, a back-end, or a front-end person. All three of them should be considered skills the entire team possesses. That’s the way Scrum works. Or is supposed to work according to the Scrum Guide. Sadly, that is not always the case just yet.
Scrum and UX are more alike than you might think
There is good news as well. I believe that Scrum and UX go together a lot better than most people think. Most of the issues I’ve mentioned before are not Scrum or UX related problems per se. They 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 a new way of working, as well, just like we learned how to be agile via Scrum.
To create a shared mindset we first need some basic level of understanding. I want to start by pointing out some ways in which Scrum and UX are very much alike.
Getting to know these points will help you use them to your advantage. Here we go.
Adaptability
Scrum allows you to adapt to new insights very quickly by working in short sprints. Every new sprint can be adjusted 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. Maybe even during the current sprint if your discovery turns out to be an obstacle in achieving the current sprint’s goal.
Iterative way of working
I’ve mentioned it before at the start of this post. 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 each iteration to improve your design work continuously.
You could say that 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. That doesn’t mean you can’t add another user story or PBI about design refinements to the next sprint 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’.
It’s an excellent way of combining adaptability and working iteratively.
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 to home from a UX perspective since UX isn’t only about users. It is about creating value for users. A well-developed product will not succeed if it does not create value for someone. It is up to you to make the product valuable.
Let’s call it value-centered, as a nice mix of both Scrum and UX.
Putting it all together
There you have it. Adaptable, iterative, and value-centered. Scrum and UX aren’t that different after all. I hope you agree. Knowing your common ground is only step one to getting to a shared mindset. We’re going to take a look at best practices when working as a UX designer in a Scrum environment.
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 come across 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.
Do your UX design work one sprint before the development team needs your design work
Scrum uses a few definitions to help the Scrum process. The most well-known one is the definition of ‘done.’ Some teams use a definition of ‘ready’ as well. Albeit being mentioned in the Scrum Guide, it is not an official Scrum term. Scrum teams use this term to identify several criteria to see if a product backlog item (PBI or user story) is ready to be picked up for an upcoming sprint.
Commonly used user story criteria are description, order, estimate, and value. 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.
It is up to you to add a few UX related requirements. These could be all or any of the following. The user story has been…
- …user tested and validated.
- …designed (UI/UX) based on company or design system standards.
- …discussed with the development team to determine technical feasibility.
- …considered to be ‘ready’ by the development team.
A product backlog item can only be added to an upcoming sprint if the criteria as mentioned earlier are met. By defining UX requirements, you make sure UX is part of the Scrum team’s process.
Since you can only pick user stories of which all requirements have been met, you are forced to work on product features before the development team can pick it 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 a couple of times, and it was a disaster every time.
I remember when I was working on a feature for a startup I was a part of many years ago. I had to rush my design process since the feature had to be delivered this sprint. Research, design, and development had to be completed during the same sprint. The team was under a lot of pressure from the stakeholders and the product owner.
Somewhere halfway through the sprint, one of the developers asked me to take a look at something he was developing based on a design draft I had to provide 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. I was working on the same functionality as the developer during the sprint. 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 manage to 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 when I had involved the Scrum Team more during my design work. I am very sure that the problems we have faced wouldn’t have happened. And if they did, they would have occurred earlier. 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. That’s a time-capped meeting 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 for you to ask questions you might have for the development team.
By organizing this meeting one sprint before the actual development starts, you still have time 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.
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 aren’t that bad either. A little bit of effort goes a long way.
Design sprints are divided into two parts
In my experience, there are always two parts to a design 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. The thing is, something that’s maybe a few hours of design work can be a few hundred hours of development work. Developers know this. Most designers…not so much. 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 be transparent in your design work.
Conclusion
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. And even if it turns out to be accurate, I don’t think we can do anything but work together anyway. That’s why I told you the do’s and don’ts. Use them! What are you waiting for? Go out there and be the best agile UX designer you can be!
About the author
Hi! I'm Nick Groeneveld, a senior designer from the Netherlands with experience in UX, visual design, and research. I have completed a wide range of projects in finance, tech, and the public sector.
