Agile UX

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.

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.

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.

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.

Conclusion

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.