10 Tips for Integrating UX into Agile
If you’re a User Experience (UX) strategist, researcher, or designer working in software development you’re likely using Agile. At its core, Agile is a time-boxed, iterative approach to software delivery that builds software incrementally. We often hear that UX practitioners are struggling to integrate UX into Agile which can be incredibly difficult and frustrating. While it can be a slog, there are some things you can do to dramatically improve your situation.
10 Tips for Integrating UX into Agile
1. Tickets
Tickets are like mini design briefs that align expectations between clients, product owners, and teams. If you’re not already writing tickets for UX work, give it a try. It’s the single most important thing you can do to improve UX integration within a program. If you’ve never written tickets, that’s ok. It can seem like a lot at first, but it becomes easier with time.
A good UX ticket should have:
- Title should be concise and descriptive.
- Goals and Objectives are the desired results and ways to measure them.
- User Story as a [user], I want [something], so that [goal].
- Acceptance Criteria are conditions to be met to satisfy the ticket.
- Preconditions must be satisfied to complete the work.
- Tasks are steps toward completion.
- Points measure expected effort.
Pro Tip: You can always draft a ticket ahead of the refinement call and your team will thank you for it. Everyone on the UX team should be encouraged to support in the writing of tickets.
2. Decomposition
You may have heard someone say that UX work cannot fit into Agile because UX work takes longer than a sprint. Fortunately, you can always break work apart into multiple pieces which in agile is referred to as decomposition. A research study may take longer than a sprint but creating a research plan can be completed in a few days. Preparing research guides and materials can be completed in a few days. If it’s too big for a sprint just break it apart.
3. Ticketing Systems
Presumably your team is using ticketing software, such as Jira. You might not like your team’s chosen system, but it’s important to use the same system and backlog as the rest of the team to build connectivity between UX tickets and tickets for other disciplines such as engineering and testing. If you introduce an additional ticketing system, such as Asana or Trello, and you are the only team using it, your tickets may well not exist for the rest of your team.
4. Commitment and Capacity
You’ve possibly encountered a situation where you were told that UX velocity isn’t tracked on your program. The reason why may have been marginally cohesive, but if this sounds like your current program; please repeat this statement aloud: “We only benefit when we track UX commitment and capacity.”
The reason why an agile team might not track UX work could be for myriad reasons. But it might just be because tracking tickets takes work and people are busy. You might have to take this on yourself, which will require work, but knowing and sharing your team’s commitment and capacity is invaluable. How else would you know if you’re taking on too much or too little work? How would you know if you’re committing to the right load based on holidays and PTO? How would you make the argument to expand the UX team without measurement of contribution based on time and resource allocation?
5. Documentation and Artifacts
Another barrier to UX integration occurs when it is hard for people to find and access UX work. Personas, journey maps, readouts, wires, etc., can all be made using the program of your choice but once complete they should be loaded onto a shared space, such as Confluence, or SharePoint. It would behoove you to think about how your repository is structured, accessed, and will scale as UX artifacts continue to be added.
Pro Tip: Remember, it’s always appreciated by your team when you put a link in the Jira ticket or Slack message so folks can access the great work you’re doing.
6. Working Ahead of Development
You’ve probably heard someone say, “If research and design is happening ahead of development, we’re doing waterfall.” This is false.
Research should be done at the very onset of a program to ensure we’re understanding users and allowing their goals, needs, and expectations to drive product vision, product backlog, and Minimum Viable Product (MVP). Yes, research and design can absolutely happen a few sprints or even a program increment ahead of development. That said, there is tremendous value in bringing engineering and product management team members into strategy, research, and design. At minimum we owe it to our team members to share recordings, notes, and readouts, but if they can participate, the benefits are well worth the time invested.
Sketches, wires, and designs facilitate rich conversations and allow us to validate and inform requirements. They reduce risk, build alignment, and help clients and teams to feel more confident in the decisions they’re making and the product they’re building.
7. Agile + Research
Research and Agile can be difficult as it takes time to secure participants within a sprint. One way to remove this impediment is to consider research as an additional ceremony and to plan for it on a regular basis. Establishing a research panel and maintaining their involvement can also reduce the effort to schedule and recruit. Whether gathering insights for a new feature or seeking feedback on a recent release, this regular touchpoint will make gathering user feedback much easier to plan, coordinate, and manage.
Pro Tip: Keep this data handy in a research repository (as simple as a spreadsheet of interview or usability testing highlights) that you can filter by topic and reference when questions about user needs arise.
8. Divide and Conquer
Agile programs may have many scrum teams. The UX team may be a separate team comprised of strategists, researchers, and designers. It may be helpful to “divide and conquer” meaning that each UX team member should embed themselves into one of the scrum teams and attend all the teams' ceremonies. This prevents the entire UX team from attending five ceremonies (4hrs) for five scrum teams (4hrs x 5 teams). With all the time you save you may find the UX team would benefit from some ceremonies of its own.
9. Value Stream Mapping
When working on a new program it is important to identify your team’s value stream which is the process from conception to delivery. Collaborate with product managers, analysts, and engineers to create a depiction of your team’s process starting with feature identification and ending with deployment in production. To ensure consistency, document your team’s value stream and save it to a shared space. For existing programs, you can use this exercise to review the current state to identify gaps or opportunities for improvement.
10. Working Agreements
While value stream mapping provides a macro framework for team collaboration, working agreements bring clarity at a micro level by depicting how your team will work together. A working agreement is a formal document shared within a program that outlines roles, responsibilities, communication methods, and other working norms and expectations. Working agreements can help to build clarity and harmony within teams and are great for onboarding new team members.
Next Steps
Integrating on to a new team can be daunting, but hopefully these tips showed you a few ways to make the transition smoother. Start out by introducing one or two of these methods to pilot each month. This can help you establish a rhythm and build towards fully integrating UX into your Agile framework. It’s hard to do this alone so don’t be afraid to ask for help from other team members. An outside perspective can often prove to be invaluable. Remember all changes take time, even when using a time-boxed, iterative approach. 😉
