Why this article?
Both Agile software development and user experience (UX) design share common goals: delivering systems faster that are more valuable and widely used by customers. However, these two often miss the mark when they work separately. In this two-part article series, we’ll propose ways to facilitate collaboration between design and development, ultimately improving the value delivered.
In this first article, we’ll explore why adding UX to Scrum is crucial, the resistance that can arise, and two approaches to integrating Scrum and UX. In the second article, which is more Scrum-focused, we’ll discuss adapting the Product Backlog and PBIs to UX, and how to handle "Done."
Common Issues
There are contexts where UX design is more necessary than others.
- In internal projects for organizational users (B2B), we can directly engage with users to understand and validate their needs. Nevertheless, making systems useful and usable remains crucial, and this is where UX specialists may become necessary.
- However, in projects for external customers (B2C), focusing on the user experience (UX) is vital. In these scenarios, we know less about the users (and their needs), it's harder to interact with them, and they have the ability to easily switch to other providers if the products we offer are not sufficiently useful or usable.
Risks of Waterfall Development or Scrum without UX
In Waterfall-based projects, there is a significant risk of missing the mark in terms of user experience. Functional analyses and paper designs (wireframes or mockups) can be developed to understand user needs. Even so, since functional design, programming, and testing are often done by different people at different times, the risk of investing a lot of time and effort in unvalidated designs can result in systems with low usability, which are difficult to fix if done incorrectly.
In Scrum product development, the risk of building an unusable or non-useful system is much lower: we work in short iterations, frequently considering and validating user needs and expectations. However, the risk does not disappear entirely. For example:
- We may try to address needs that users don’t actually have (e.g., users prefer to continue working as they did before the system because they don’t perceive the value of using the product).
- We may provide functional solutions for real needs, but they are hard to use.
Thus, adopting a UX approach in development (with or without design specialists) may be necessary, particularly in complex user environments, to avoid the risk of building unusable (or unused) systems and incurring unnecessary costs for avoidable changes.
This has happened before (e.g., QA)
Introducing Scrum into traditional organizations always raises a challenge: we need to create self-sufficient teams with the ability to make decisions and handle all related work. This requires them to be cross-functional, often pulling people from separate teams or departments. This organizational redesign typically faces resistance for at least three reasons:
- Department managers lose capacity (and power) when they let people join Scrum teams.
- Scrum team members are not released from their departmental work, leading to overwork and tension over job priorities.
- Some individuals within the organization (sometimes justifiably) believe that without departments, quality, control, and common standards for a certain type of work will be lost.
An Agile example: the QA role
A well-known example in Agile adoption is the QA role. Traditionally, quality control (for both product and process) has been planned and carried out by a separate group. However, in Agile organizations, this function has been integrated into the teams, though it may remain partially separate in contexts where quality is critical. Generally, this has not reduced quality, but increased it, due to factors such as:
- Easier adaptation of processes to meet real team needs. Audits are unnecessary since processes remain useful and updated.
- Greater quality education for the rest of the team members, who become more independent and mindful of doing quality work. The QA specialist becomes more of a mentor and coach than a controller.
- More integration into the requirements definition, programming, and technical/functional testing (e.g., TDD and BDD). Errors are discovered earlier and, thus, fixed more often.
Integrating Scrum and UX: (Option 1) Dual-track
When trying to integrate UX and development work, an intuitive option for traditional organizations (with specialized UX and DEV workgroups) is to create alternating Sprints for each type of work. For example:
- Sprint N: designers define the interface.
- Sprint N+1: developers turn it into software.
- Sprint N+2: designers test and collect feedback.
This approach, commonly called "dual-track Scrum," has several problems:
- It’s not Scrum; there’s no potentially deliverable product at the end of the Sprint.
- Delivery is delayed to 3 Sprint cycles, which slows user validation and value delivery.
- Almost all interaction between the user, designer, and developer is lost, which can lead to misunderstandings and wasted work (as Jeff Gothelf points out, at least 50% of design work goes unimplemented).
The origin of this approach lies in Desirée Sy’s 2007 article "Adapting Usability Investigations for Agile User-centered Design," where she describes frequent (daily) collaboration between designers and developers. When she talks about two work streams, she refers to designers and developers working together, not in separate teams or Sprints.
Integrating Scrum and UX: (Option 2) Designers in Scrum Teams
Another approach is to have a single Sprint where designers and developers work concurrently. This approach can raise doubts, especially among designers, regarding aspects such as:
- How to plan design work in short Sprints?
- How to align the pace of design and development?
- Should we have a single Product Backlog, or can we maintain separate Backlogs for design and development work?
- When should interaction between designers and programmers occur during the Sprint?
While the answers to these questions are not trivial, they are also not difficult. Many teams already do Scrum with UX integration regularly.
These Scrum.org courses explain how to implement dual-track within Scrum:
👉 Professional Scrum with UX™ (16 hours)
👉 Professional Product Discovery and Validation™ (new course of 8 hours)
In the next article...
The second article in this series How to Integrate UX and Scrum - Adapting the Framework to UX addresses questions by reviewing the Product Backlog, PBIs, refinement, and events.
References
- Here is how UX Design Integrates with Agile and Scrum
- Curso Professional Scrum with UX
- Dual Track Development is not Duel Track
- Scrum with UX: Moving Beyond Design Sprints, a presentation by Jeff Gothelf and Dave West.
- Customer Kanban – from customer push to customer pull