Integrating UX and Agile

Producing great user experiences in an Agile environment can be a challenge. As a designer who has been working in the User Experience (UX) field for over 20 years and as part of Agile teams since 2006, I have truly come to embrace Agile. Dare I say, often I prefer it. As the product releases move ever faster, Agile, Kanban and other Lean methods are here to stay. It’s time for the UX field to get better educated on these topics and embrace change. Many aspects of Agile and Lean methodologies are good for UX. Here are a few tenets of going Agile-Lean that we should be using to our advantage:

1. Agile Execution Can Be Applied to Any Discipline

When Development teams adopt Agile, people expect a change in mindset regarding how work is done. Training courses, certification, specialized card decks, retro sessions and other camaraderie are all aimed at making this transition a success. At the same time, other disciplines on a product team (e.g., UX, Documentation, Product Management, QA, etc.) are often left to figure out on their own how to “fit into” the new Agile execution process.

Harboring a mindset that other disciplines need to be “force-fit” into Development’s Agile process is the wrong approach. Agile principles can be applied to any discipline. (Well, almost any discipline–for ER doctors, firefighters and paramedics, I’d prefer a less iterative process). The approach to UX and Agile needs to focus on how we can take the principles of User-Centered Design (UCD) as well as other UX methodologies and execute them in an Agile way. When we frame the problem like this, it frees us to think about what a UX Agile process should be rather than how we’re going to force-fit UX into the existing process for another discipline. This also means that UX folks need to be better educated on the principles of Lean methodologies in order to shape a UX Agile process and effectively communicate how it fits in with work being executed by other disciplines.

So what would UCD look like if we morphed it into an Agile framework? As a starting point, let’s consider two certainties for Agile execution: multi-tasking and a short timeframe for judging progress (e.g., sprints). Development teams regularly perform many activities within a single sprint. Using sprints as an anchor, if we apply a similar approach to UX activities, it might look something like this:

In the diagram above, UX is performing many activities within a single sprint, such as:

• looking forward to future requirements
• decomposing completed designs for the next sprint
• testing and refining designs for future sprints
• providing feedback on the quality of the UX for the current sprint.

Multi-tasking between different aspects of the UX within a single sprint allows us to focus on design details for near-term implementation, keep an eye on the bigger picture for future designs, and track quality of the UX.

If your organization doesn’t have a dedicated UX person and/or Development drives the design of the UX, this can still serve as a guide for the types of UX-related activities that should be considered for each sprint. Whether or not you choose to focus on it, if you have a UI, you have a user experience. Make it a good one.

2. Agile Is Transparent

Agile is more transparent than Waterfall and other heavy methods. This is good for UX. For example, the code developed within Agile is supposed to always be in a releasable state. In theory, this means that reviewing the progress made on UX for any given day or sprint should be readily available. In reality that’s not always the case, as demos break and builds can be unstable. However, in addition to this basic principle, Agile (specifically with Scrum) has native milestones for assessing progress. Checkpoints like daily “stand-up” meetings and demos of work completed at the end of each sprint are built-in opportunities for UX to engage, provide feedback on quality, and discuss issues. A UX Agile process needs to incorporate these key activities.

And while similar milestones exist in Waterfall, they are typically less frequent and often lack structure for judging UX quality. Any UX person who has had to go through the painful process of reviewing screens with individual developers (because a build works only on their machines) to ascertain the status of a UI should appreciate this aspect of Agile.

3. Agile Has Built-In Quality Control

Agile has several built-in mechanisms for impacting quality that a UX Agile process needs to utilize. First, at the end of each sprint, most teams will demo the work they have completed. Participating in sprint demos and reviewing them is a great way to judge the current quality of the existing UX and assess how far or near it is from the end goal. UX feedback from sprint demos needs to be clearly communicated and land in the appropriate location so that it can be incorporated into the workload for future sprints. That may mean adding UX feedback into a backlog, defect queue or other location.

The second quality-related activity that needs to be part of a UX Agile process is story decomposition. If your organization has anyone (e.g., Designer, Developer, Product Manager) focused on UX who is generating wireframes, prototypes, etc., then this is relevant to you. Story decomposition is the activity of taking larger epics or themes and breaking them down into more digestible chunks that can be sized and tasked. These digestible chunks can take many forms. During decomposition, UX can help the team digest design prototypes and break them down into user stories that accurately capture the intent of the design. Relevant design prototypes or mock-ups should also be tied to individual user stories. Marrying design prototypes to user stories is critical. The less reconciliation work that needs to be done to implement a design, the more likely it is that the design will be implemented as desired.

The third Agile quality bit we’ll discuss in Part 1 of this article is acceptance criteria. For each user story, acceptance criteria are needed to define what will deem the story as being complete. They are revisited at the end of each sprint to determine whether stakeholders will accept the story as done. In addition to other Quality measures, acceptance criteria should contain details about what will constitute satisfying UX quality for that particular story.

4. Agile Value #3: “Customer Collaboration Over Contract Negotiation”

An Agile process calls for an ongoing dialog with customers to understand their needs rather than wasting time on internal speculation and other logistics. To apply this principle to UX Agile, it probably should be rephrased from “Customer Collaboration” to “End-User Collaboration”, as the customer who signs the check is typically different from the person who actually uses the technology. Getting out of the building and learning about your end-users/customers is critical.

The main negative feedback heard regarding user engagement and Agile is that “there is no time for user testing, interviews, etc.” Most often this negative perception occurs because teams are attempting to create a new UI design, test and implement it in the same sprint. This is an example of “force-fitting” UX into Development’s Agile process. Unless the UX is very simple or you’re running month-long sprints, you CANNOT create a design, test it, incorporate feedback and implement it during the same sprint. This is the wrong approach and one of many good reasons that UX needs to define its own Agile process! If executed over several sprints, user interviews, testing, observation and other activities can be part of a UX Agile process.

The rub is that designs are tested and iterated over several sprints (see Figure 1). In addition to testing design prototypes with end-users and other user-related activities, supporting future Definition work with Product Management should be part of the UX Agile process. This definition work might not occur during every sprint for UX, but it should be part of the process. And yes, Product Managment can be Agile, too (see Figure 1).