In the past few years, Agile has become the dominant method for software-project management. In a recent survey, we found that 69% of UX practitioners’ projects use an Agile approach. However, UX practices and Agile workflows do not always easily fit together, as Agile processes were not originally developed with UX in mind. As a result, UX professionals have had to learn to be flexible and adapt their processes and workflows to fit within the rules, ceremonies, and pace of Agile development.

With the typical Agile cadence of one- or two-week sprints, it can be a challenge to fit all needed UX activities in during this brief period, so UX practitioners often work one or more sprints ahead of the development team, either doing research to discover user behaviors and to test prototypes or preparing polished designs for implementation as far ahead of the development team as possible.

User Stories, Tasks, and Story Points: Typical Agile Work Tracking Units

On many Agile teams, feature and functionality planning is documented in the form of user stories: each feature is condensed down to a deliberately brief description of the functionality from a user’s point of view, focusing on what the user wants to do, and how that feature will help. The typical format of a user story is a single sentence: “As a [type of user], I want to [goal], so that [benefit].” For example, “As a checking account holder, I want to deposit checks with my mobile device, so that I don’t have to go to the bank.”

These user stories are typically collected into a backlog where they are prioritized and assigned estimated implementation costs, so the team can plan which user story (or feature) to work on next. For each user story, the team assigns an estimate of the effort required to create and implement, typically in the form of story points. Story points are relative rather than absolute measures: they capture how much more work one task is supposed to involve compared to another (i.e., a 5-point story is more than twice the work of a 2-point story), rather than the number of hours needed to complete the task.

Finally, acceptance criteria for a user story clearly indicate what attributes the story must have to be considered “complete.”

On many Agile teams, the user stories are not the smallest unit of work; in these cases, user stories are broken down into tasks assigned to team members. This approach is popular with many commonplace Agile project-management software packages.

Account for UX Activities as Subtasks Within User Stories

Each user story is supposed to be finalized within a single sprint (though teams will typically work on several user stories at a time). However, this short timeframe poses a challenge for appropriately planning and tracking work when UX is at least a sprint ahead of development; for many teams, the question of where UX activities fit into user stories becomes tricky to negotiate.

When UX effort isn’t appropriately represented in the user-story backlog, UX work can become less visible to the team and therefore less valued with lower buy-in among team members. The resulting poor resourcing and planning can leave UX professionals overworked and without a clear view ahead, and UX designers can become overly reactive to immediate team needs and lose sight of the big picture.

If your team breaks down user stories into tasks, make sure to add UX activities to the task lists in order to accurately represent UX effort in the user-story backlog. Doing so allows UX team members to keep the rest of the team aware of which UX activities are ongoing at any point in time. It also makes upcoming user-research sessions visible to all team members, and can encourage developers, product owners, and business stakeholders to observe testing sessions.

This approach requires that the team has a well-groomed user story backlog, and that the product owner, scrum master, and development team be disciplined about keeping stories accurately prioritized for the next few sprints.

UX Activities Made Visible as a Kanban Stage

Teams who don’t break down user stories into subtasks can use Kanban boards to keep UX work visible. (A Kanban board is a method of illustrating and keeping track of various stages of task completion.) UX activities should represent task-completion stages in the Kanban board. Here’s a set of possible stages on a Kanban board:

1. Definition
2. Design
3. Usability testing
4. Ready for Developers
5. Implementation
6. QA/Unit testing
7. Ready to ship
8. Shipped

A task (or user story) would have to move through all these stages to be considered completed. This Kanban-board representation makes UX work explicit and mandatory.

A Kanban board (in this case, implemented in Trello) can be modified to include key UX activities (such as definition, design, and usability testing) as stages which precede developer work. This method keeps UX work visible to all team members and can encourage collaboration.

While this list of 8 stages is right for many teams, your needs may be better served by a different set of stages. For example, some teams will prefer a single UX stage, while others may wish to break down the UX activities into lower-granularity stages (e.g., requirements, workflow, prototyping, task creation, usability testing, analysis, iteration, mockup creation), or order the stages differently.

Adding UX activities to a Kanban board keeps each user story’s status transparent to the entire team  and enables a smooth workflow for all team members at all time. This visibility also helps the team respond to unforeseen challenges by rearranging the priority of user stories, rescheduling activities, and reassigning work.

Don’t Include Separate User Stories for UX Activities

Some less-mature Agile teams might be tempted create two types of user stories: technical ones, geared towards software development, and UX ones, focused on user research. Most UX professionals we spoke to did not recommend dividing UX and development tasks into separate user stories. The biggest downside of this approach is that it reduces collaboration among team members, which is essential for a successful Agile project.

Include UX Acceptance Criteria on User Stories

In typical Agile processes, when teams define user stories, they assign completion or acceptance criteria (“definition of done”) for them. While acceptance criteria are traditionally focused on QA (or unit testing) to ensure bug-free implementation, they can and should also include UX measures of success. While good starting UX acceptance criteria can simply address adherence to UI standards (such as “all UI elements will adhere to the look, feel, and behavior outlined in the team Front-End Style Guide”, or “product will match design mockups within 10 pixels”), consider adding usability-oriented measures such as “users should encounter no major usability issue while completing task A”. For organizations with high level of UX maturityand where management has a lot of trust in the UX team, even some quantitative measures (such as such as “most users can complete the check-out process in two minutes or less”) can be added as acceptance criteria.  While completing full quantitative benchmarking tests is often difficult to achieve during an Agile sprint and the results from a small study are likely to not be statistically significant, a highly skilled UX professional can still get a sense of whether the design is on the right track of satisfying that requirement. These criteria establish high quality standards, and also force the team to be involved in summative usability testing before shipping the product.

Estimating UX Story Points

Most teams who track work in user-story format use story points to estimate effort. However, because UX work is usually done ahead of development, many UX professionals that we spoke to preferred estimating their effort separately from the development team. The two effort estimates (one for development and one for UX) allow each subteam to work efficiently and prevent it from being underutilized; in particular, the UX team can plan for how many stories can be tackled simultaneously, as well as for any stories that will require more than a sprint.

Among developers, there are many popular point systems used for estimating effort; examples include sequential integers, the Fibonacci series, powers of 2, and so on. But instead of these, the UX professionals in our survey preferred less granular formats such as T-shirt sizing (S, M, L, XL, etc.). This system allows the UX team members to indicate effort in a coarse manner, without impacting overall team velocity measures. However, it is worth noting that separate UX points  can negatively impact team cohesion, as UX may end up being seen as a separate work unit, akin to how it is viewed in Waterfall development processes. If you choose to estimate UX story points separately, aim to eventually fold the UX team’s estimation efforts into the main team’s estimation process over time.

Conclusion

Integrating UX and Agile is a complex endeavor, but ensuring that UX activities are represented in user stories supports task planning and scheduling and encourages crossfunctional collaboration among team members.

For more techniques and detailed explanations on best practices for Agile UX, download the full report Effective Agile UX Product Development or attend the full-day course Lean UX and Agile at the UX Conference (also available as an in-house event at your company.)