In this article, I describe the intersections between UX process and Agile Scrum as a three-level framework, which can be applied to increase the strategic influence of the UX team within your organization.
I’m periodically asked by colleagues how the practice of UX intersects with Agile Scrum sprints, given that the practice of UX seems to be all about developing a vision for the product…and isn’t that like a spec? And aren’t specs waterfall? And we aren’t waterfall, we practice Agile Scrum. So…how does that fit with sprints and Scrum, and…isn’t there a conflict?
The “Spec”-ness of UX
The goal of a user experience team is to create a product vision, supported by and validated with user research. This vision reduces risk for the organization by defining the right thing to build for customers (vs. the wrong thing, which will miss the mark, be rejected, not sell, etc.).
This vision is often expressed as a visual plan for implementation, which is uncomfortably close to a document known as a “spec.”
Specs show up a lot in waterfall process; they’re meant to be a detailed map that engineers can follow to build the right thing. But markets shift all the time, and big visions take a long time to build. Spec-driven projects often land with an audible thud, because by the time they’re released, the market has already moved on.
This is why waterfall development is mostly out of fashion, and has been replaced with Agile Scrum, which breaks work into small chunks of customer value. These are reordered (or abandoned) periodically, according to what’s going on with the business and the market.
So: if long-range UX vision seems like a spec, how does UX vision fit into sprints? How does a UX team create a coherent vision for a product based on market and user research for an org that practices Agile Scrum? And how can we talk about all of this with our colleagues in a succinct, coherent way?
The way I’ve made sense of this is to talk about the three levels of UX.
Sprint-Level (or Low-Level) UX
“Sprint-Level UX” fits comfortably within a single sprint, or a couple of sprints. It is work that is somewhat reactive, and constrained in scope.
Sprint-level UX can include things like:
- A small enhancement for an existing feature
- A small chunk of planned roadmap work (a valuable piece of a feature)
- A solution to an interface bug
- Anything that is tactical and limited in scope.
At the sprint level, any work that involves the product UI is groomed by the team — which includes a UX designer — just like any other work in backlog. The front-end UI solution is designed by the UX designer embedded with the team, and built by engineers within a sprint or two.
Low-level UX work might require minimal usability testing or customer validation on its own, or could roll into a larger effort (a roadmap item) slated to be tested and validated.
Engineering Exposure to UX
Often, engineers are exposed to working with the UX team only during sprint-level work. This is why engineers tend to be the people who ask questions about how UX designers develop a long-term vision.
Ideally, the UX team actively involves the engineering team in higher-level UX work. In many organizations, unless the engineers in question are leads, this is unlikely to happen (which is bad).
The UX team should push to include engineers — as interested spectators, at the very least — at every level of design work, so that engineers can gain perspective on customer needs and problems, and ultimately become better able to partner with UX.
Feature-Level (Medium-Level) UX
In “feature-level” UX work, UX design leads collaborate with other roles to develop a vision for a strategically important piece of a product based on market observations and user research.
“Feature-level UX” is used specifically in this instance to describe work that is already understood by the business to be worth devoting time to (meaning, the problem to be solved is already on the roadmap).
In feature-level work, UX partners with product management, engineering, and other stakeholders to:
- Sharpen the understanding of the problem to be solved (research)
- Validate hypotheses about how to solve the problem (research)
- Brainstorm and validate solution ideas (ideation and more research)
- Socialize, validate, and iterate on a solution that is appropriate for users and the market
- Where sprint-level UX is tactical, feature-level UX is strategic, in that it affects decisions made by the business.
The outcome of feature-level UX work may be executed in sprints, but is likely to be sprint-agnostic during problem validation and initial research.
Big-Picture (High-Level) UX
Where feature-level UX is sprint-agnostic, “big-picture UX” is project-agnostic, in that it describes the pursuit of foundational insights that could change the direction of the business, but which aren’t yet connected to specific projects on the roadmap.
Big-picture UX work usually takes the form of research and blue-sky ideation.
- The UX team notices recurring customer concerns in feature-level research work, and spins up a roadmap-agnostic research project to explore these themes with customers. Findings are shared with Product, and ultimately influence the roadmap.
- A designer creates a speculative prototype to explore a solution to an issue discovered by UX, outside the boundaries of an officially sanctioned project.
- Quarterly UX-led testing of the company’s product reveals that a long-held assumption about customer behavior is actually incorrect, and has downstream consequences for active projects.
Findings from this kind of work can be piped directly to the product management team to suggest changes in product direction, new features, and (ultimately) additions or adjustments to the roadmap, as well as more granular product improvements.
Findings can also be shared and socialized throughout the organization, in order to educate the company about user needs and pain points, and — as a side benefit — to demonstrate the value of the UX team’s contributions.
Notes on Practical Application
If you’ve noticed that the UX team is focused only on sprint-level work, try moving the most senior person on the UX team (or yourself, if you’re the most senior UX person) to feature-level work. Insert this person in meetings and discussions, and begin to quietly demonstrate the value of research and UX-led ideation.
It‘s essential to form good relationships with the people outside of the UX team to accomplish this. Befriend whoever is currently leading feature definition, and have a conversation about what UX can contribute. UX empathy and experience in leading structured discussions can be stealthily applied to make a case for joining the feature definition process.
Once the UX team is part of the feature definition process, make sure that UX has some small wins to demonstrate value, and build the case for strategic involvement of UX as feature definition moves along.
You may find that when the value of applying UX to strategic concerns is demonstrated, the UX team is then expected to be involved in feature- and big-picture UX work, and a virtuous cycle of UX wins is established.