Agile UX

September 7, 2015

I work in a very strict agile environment where the small size of the UX group means we have to straddle product teams and be creative in allocating our time and effort. For User Experience, working within an agile environment is often fraught with challenges. When priorities align and a UX designer is fully embedded in a product team, agile can be that designer’s best friend—helping in prioritizing deliverables and organizing cross-functional efforts. However, when a UX designer must work across product teams and juggle multiple sprints and priorities, an agile development process can seem both chaotic and rigid at the same time.

My UX team has been developing and testing a model in which UX designers work across agile teams within our organization. So far, we are seeing some fairly positive results. In this article, I’ll share how we do it, so you can try out our approach or modify it to suit your needs.

Champion Advertisement
Continue Reading…

The Problem

Since the problem in my organization is that User Experience is a small group and UX designers must straddle multiple projects and balance multiple priorities, we’ve encountered one major roadblock time and time again: how to rank the priorities of one agile team against another’s to determine what stories to complete first. Because there was no good answer out in the world, we realized in fairly short order that we would need to design a method internally to resolve the problem.

The Solution: A Kanban Board

While discussing this issue during one of our backlog grooming sessions, an engineer suggested that we might be able to use multiple Kanban boards as part of a solution. Kanban is a workflow-management system that uses a board and sticky notes to prioritize and manage workflow debt. In its most basic form, a Kanban board comprises three columns: Backlog, In Progress, and Completed. A team writes tasks on sticky notes, then places them in the appropriate column. Generally, there is a limit to the number tasks that can be in the In Progress column at any given time, so you can add new tasks to it only as you complete other tasks.

Overall, this is a simple and elegant way to get team members on the same page and make them accountable to each other, because it enables people collaborate and internalize priorities as a team.

Many Kanbans, One Board

Getting back to how we use Kanban boards at my workplace… Since User Experience is a separate department within my organization, using other teams’ Kanbans would not work. After much scribbling on whiteboards, we came up with a simple solution: Let’s create one big Kanban board that consists of other teams’ Kanbans, as shown in Figure 1. That way, their backlog becomes our collective UX debt.

Figure 1—UX Kanban board consisting of UX stories from other projects’ Kanbans
UX Kanban board consisting of UX stories from other projects' Kanbans

To accomplish this, it made more sense to use a digital Kanban rather than the traditional analog method, so we could tag other teams’ stories for UX in our Kanban. The tool we decided use for this is Jira’s Kanban board. Because we were already using Atlassian collaboration tools in our shop, we could easily import projects’ existing boards into our own. In truth, though, any system that can import stories from one board to another would do—even something as simple as an Excel spreadsheet.

Grooming and Prioritizing the Backlog

All the awesome tools in the world don’t mean a thing if you don’t plan and groom your backlog. To do this, we follow a pretty traditional grooming approach, meeting before each sprint to capture the stories for which we need to create UX design solutions.

Where things diverge, however, is in the cadence of the sprint itself: in my shop, we do two-week sprints. However, no two project timelines ever align cleanly, so the answer was not to shoehorn our workflow into other team’s sprints, but to create and follow our own sprints. We came up with this rule, an example of which is shown in Figure 2:

Rule 1: If the duration of a story exceeds the number of days remaining in a sprint, it has to wait until the next one.

Figure 2—Project A’s stories fit in the current sprint, but Project B’s do not
Project A’s stories fit in the current sprint, but Project B’s do not

The reason we did this is fairly obvious: we wanted to control the workflow—not force ourselves to prioritize existing stories arbitrarily.

Planning It Out

Planning is also a standard part of the agile process. What is different about our planning sessions is that we invite product owners (POs) from all of the projects that are currently utilizing UX design resources to attend planning meetings. We hold these meetings monthly—covering two sprint cycles—to accommodate all of the stories they’ve given to us.

In the meetings, we review the stories from all of our backlog grooming sessions and place them onto the UX Kanban board. This brings us to our second rule, which is illustrated in Figure 3:

Rule 2: Only other Kanbans’ in-progress stories can go into our Kanban’s backlog.

Figure 3—Project A’s stories are part of the current sprint, but Project B’s are not
Project A’s stories are part of the current sprint, but Project B’s are not

This may seem somewhat counterintuitive on the surface, because it might appear that there is no backlog, so everything is a priority. However, this is not the case.

Instead, we groom priorities during a planning session in terms of their absolute value relative to one another, placing the top three to five stories in the In Progress column. Then, we place the rest of the stories that we intend to complete before the next four-week planning meeting into our backlog.

So how do we determine the absolute priority of something? Two words: horse trading. This may not sound simple or elegant, but the reason we hold these large planning sessions with all POs present is because it lets us set priorities as a group. The UX team could easily do this in isolation, locking ourselves away for four weeks and deeming what stories are most worthy on our own, but this would contradict some very fundamental agile principles. So, instead, we opt for transparency and discourse and prioritize stories as a group  This accomplishes two goals:

  1. It lets us share UX resources fairly.
  2. We can manage expectations for each sprint as a group.

Despite the rather messy appearance of this process, it has actually made us more efficient because we have to make the tough decisions together. But what if you hit an impasse?

Rule 3: You need a tie-breaker when you hit a prioritization impasse.

Yes, we do need a referee from time to time. This person should be someone who has some sort of role that straddles all of the projects in question because they need to have both impartiality and a working knowledge of what we’re prioritizing.

In our shop, a product marketing person who has a stake in nearly all of our projects is the ideal referee, taking into consideration that person’s temperament, prior knowledge, and understanding of our products’ challenges. But anyone who has some impartiality and familiarity with the projects could work. For instance, a scrum master from an external project could serve in this role as well, provided you give them the proper knowledge download.

Maintaining Office Hours

Since four weeks would be a long time between stakeholder meetings, it is important to designate a regular time for discussing progress, doing impromptu grooming of a story, or following up on a question. Which brings us to Rule 4:

Rule 4: Maintain UX office hours to address product teams’ ad-hoc needs.

For our team, this just means booking a conference room for one hour every Wednesday and waiting around for product owners to drop by. Sometimes, we spend just 15 minutes working with one product owner, but in other cases, we go overtime and have to book another room to handle the demand. However, in general, spending just an hour a week to touch base and discuss whatever needs discussing is very helpful. Obviously, in your shop, this might not work perfectly right out the gate, but with adequate collaboration and finesse, it will work.


Although this process is a work in progress for us, we have been able to use it across several projects with promising results. I feel confident that we’ll continue using it, perhaps making some small modifications as we go.

For many UX folks, it’s easy to grouse about having to fit UX design into an agile development process, but it is important to remember that the reason agile exists is to facilitate communication and collaboration. These are principles that UX values as well. While UX design and agile may not be a perfect fit, marrying the two can deliver some outstanding results if you work at it. Just be mindful of the rules I’ve provided in this article:

  1. If the duration of a story exceeds the number of days remaining in a sprint, it has to wait until the next one.
  2. Only other Kanbans’ in-progress stories can go into our Kanban’s backlog.
  3. You need a tie-breaker when you hit a prioritization impasse.
  4. Maintain UX office hours to address product teams’ ad-hoc needs.

If you decide to give our system a try, please be sure to drop me a line in the comments and tell me how it’s going for you and what you’ve tried to improve the process. 

UX Designer and Strategist

Portland, Oregon, USA

Jacob HarrisJacob specializes in designing large-scale, SaaS solutions. At CDK Global, he led UX strategy and design for a suite of mobile and SaaS communications applications and communications-intelligence products. He is particularly interested in business-model validation through UX research. Jacob is a NN/g certified UX Designer.  Read More

Other Articles on Agile UX

New on UXmatters