This document provides advice for UX practitioners on getting an Agile UX practice established. It recommends doing research on the development team's process and needs before starting. Key points include having the product manager write user stories to define the work, participating in grooming and planning meetings, using sprints for structure, and handling user research through scheduled sessions or as sprint tasks. Deliverables should be minimized to document intentions without extra work. Establishing expectations and communication is important for success.

1. Getting your Agile UX
practice off the ground
Diana DeMarco Brown • November 2019
Slideshare: https://www.slideshare.net/secret/yyDqWdtZVcUFmM

2. Hello!
I’m Diana.
- 10 years of experience as a UXer in Agile
environments.
- Kicked off Agile UX practices at 4 different
companies.
- Interviewed a dozen UX practitioners
about their Agile experiences.
- And talked to folks like you at conferences.

3. The good news - you get to find
your own way!

4. The bad news - you have to find
your own way...

5. Before you get started - do your research
● What process is the dev team using? What training have they had?
● If you can’t take the same training, try to get as educated as possible on
the methods that your colleagues will be using.
● What is working for them in their process? Where are the challenges?
● What do you want and need from PM, Dev?
● What do they want and need from UX?

6. Initial Research
Conceptual Design
Review
Detailed Design
Review
Ready for Dev
Rework

7. Where will the work come from?
Product Management
● Having PM write your epics and/or user
stories documents the conversation
between you - helps create shared
understanding
● Serves to create a lightweight contract
between the two groups
● PM must want to do this...
UX
● If PM is overloaded, it is possible for
UX to write their own user stories and
review them with the other functional
areas during planning and grooming
● Getting buy-in is EXTRA critical if UX
writes their own

8. Grooming and planning
● Can be a single event, or two separate meetings- let your workload and
your audience determine that
● Setting the expectations around what work is being done and creating
a shared understanding of the scope and activities are critical to
success
● Prioritization is critical. Re-prioritization over time is VERY critical.

9. Should we have “sprints”?
YES!
If there is any kind of complexity to your situation - timezones, multiple scrum teams,
multiple designers, not being co-located - this will be a useful technique.
Creates clear expectation around when UX work will be finished, and provides
insight into a process that can often be mysterious to other teams.

10. Backlog is populated
Backlog is groomed &
prioritized
Design work occurs
(user research, high level
design, detailed
mockups, prototypes…)
Sprintbegins
Sprintends
Demo (optional)

11. Sprint considerations
Sprint dynamics
● UX can be part of the dev sprint OR
have their own separate sprints.
● Working within a dev sprint works
best if there is a single designer
supporting a single team.
● Having a separate UX sprint (aka
parallel sprints) allows for a
dedicated UX backlog
Sprint length
● Even if you choose independent
sprints, it is best if the cadence
matches the engineering sprints
● It can be useful to offset by a few
days to avoid collision of
planning/grooming/kickoff events

12. More Sprint considerations
Working ahead of Dev
● Working more than a sprint ahead of dev can result in rework
● If working in parallel sprints, make sure that that Dev is aware of who you will
need time from and how much time so that they can plan for that in their sprints

13. How do we handle user research?
The gold standard
● Schedule regularly occurring
sessions (once a month, once a
sprint) and test what you have
● Creates a constant feedback loop
and gets the team accustomed to
having ongoing customer insights
A more realistic approach
● Research, Usability testing, design
validation exercises can all be tasks
in a sprint.
● A sprint or sprints can be dedicated
to research efforts when needed

14. What about deliverables?
As little as possible
● This is a negotiation with your client teams
● The least amount needed to document the design intentions
● Create artifacts needed for user research