You Can Have Your Agile, and Do Your UX Research Too.
“The time of Agile is upon us! Join the cult, don the Agilian robes and attend our ceremonies!”
Or at least that is what it feels like.
Agile is an iterative method of project management that seems to now be used on every project, everywhere. It proposes that instead of projects happening in successive stages, they happen in shorter, iterative cycles. Even when Agile is adopted though, projects still derail from the timeline and UX research is the first thing to get cut. Long before this however, there are other factors at play that put UX research at risk. Sometimes it is because there was not enough planning or preparation. But other times, it is because of a fundamental misunderstanding of Agile and how it should be implemented.
Agile is not about being “fast” or building products more quickly than with a waterfall methodology. It is about frequent smaller delivery, maximizing simplicity, and being able to pivot quickly (Beck, et al., 2001). But the decision to pivot at all should be based on, and validated with user research. Instead of a two-week mini waterfall cycle, research should be done throughout a project. As a framework that prides itself on being fluid and flexible, making Agile work for UX research has to be possible. If researchers plan properly, categorize
activities and involve the whole team, there should always be room for UX research in an Agile project.
Preparation and planning at the beginning of the project is essential. Taking the time to plan out what research activities to include, identifying deadlines and how many sprints they might take is a great start (Christopher, 2018). When thinking about what research activities to plan for, identify a few activities that “that will work well in a short time frame and can be taken advantage of at any point throughout the project” (Barber, n.d., p. 5 ). Identify deadlines with consideration for the time it takes to recruit participants, gather and analyze data and report it out. Making this plan will communicate the intent to do research throughout the project, and show what will be missing if research tasks get cut. Planning the overall research strategy also helps set expectations “for stakeholders [and the team] on when they can anticipate the research to be completed” (Christopher, 2018). It is impossible to know specifically what research questions will come up throughout the project, but all projects need answers around vision and goals, features and flows, and usability and accessibility.
Projects usually begin with a discovery phase, which unfortunately sometimes is the only research done. Discovery falls under strategic research efforts and explores the project vision and goals. To make sure research continues throughout the project, plan out the cycles of strategic research and other methods to include. These might be user interviews, contextual inquiry, or ethnographic studies. Strategic research takes longer than a single sprint, and should operate two to three sprints ahead of tactical research (Handa & Vashisht, 2016).
Tactical research efforts uncover information about what features the product should have, how they should work, and which are most valuable. This type of research helps inform decisions around prioritizing items in the backlog (Handa & Vashisht, 2016). Tactical research efforts should run one or two cycles ahead of the validation efforts (Smith, Rauch, & Moyers, 2019).
Validation research efforts should take place every sprint and include usability and accessibility testing. At this stage, the UX team partners with Development to answer questions during implementation (Smith, Rauch, & Moyers, 2019). Validation efforts help refine the product and ensure a quality product.
Identifying the efforts that should take place over the course of the project helps translate research methods into Agile’s cycles. In the same way, research findings have to be translated into Agile’s task chunks.
Agile methodology loves it’s jargon, and here are three more buzzwords: epics, stories, and tasks. The findings from strategic research efforts can translate into epics, or “stories that are too large in scope or complexity to complete...within one sprint” (Handa & Vashisht, 2016, p. 29). These epics can be broken down into stories, or “user requirements that a team can realize within the span of a sprint” (Handa & Vashisht, 2016, p. 29). Each story is then broken down into tasks to be done to complete the story. Understanding these terms and how to translate findings into actionable items will ensure research is guiding efforts on the project.
To make UX research work in Agile, it is a good idea to get the whole team involved. Because Agile is a development-focused method, when development is not in the spotlight there is often a sense of unrest on the team. This is a good time to remember that Agile is about efforts happening in parallel, not in succession, and there is no need to wait for research to be “done” before development can do any work. If all other background preparation work is done, designers or developers can “participate in some of the research to learn about users firsthand” (Handa & Vashisht, 2016, p. 16). Researchers from the UK’s Government Digital service believe that “research is a team sport and encourage all team members to observe research sessions for at least 2 hours ever 6 weeks. There is good evidence that this helps teams create better products” (Reichelt, 2013, p. 8). Bringing team members in on research activities lets them hear users concerns and hopefully start building empathy for them (Handa & Vashisht, 2016).
Even though Agile often feels like it is being inflicted on us, there is a way to make it work for UX research. We don’t have to join the cult or wear the robes, but we do have to remind people that Agile doesn’t simply mean “go fast,” and do the work of advocating for the value of continued research. If we make plans for the timeline based on different research questions, if we translate those findings into Agile-speak, and include the team in research activities, we may be able to tame the Agile beast and use its power for good.
Barber, I. (n.d.). Three Tips for Agile UX Research. Retrieved from https://blinkux.com/ideas/agile-ux-research
Beck, K., Beedle, M., Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., et al. (2001). Manifesto for Agile Software Development. Retrieved from http://www.agilemanifesto.org
Christopher, S. (2018). Agile User Research? That’s Umpossible. Retrieved from https://uxdesign.cc/agile-user-research-thats-umpossible-a052fd45fa6a
Handa, A. & Vashisht, K. (2016, November 21). Agile Development Is No Excuse for Shoddy UX Research. Retrieved from https://www.uxmatters.com/mt/archives/2016/11/agile-development-is-no-excuse-for-shoddy-ux-research.php
Reichelt, L. (2013, August 30). How We Do User Research in Agile Teams. Retrieved from https://gds.blog.gov.uk/2013/08/30/how-we-do-user-research-in-agile-teams/
Smith, C., Rauch, T., Moyers, H. (2019). AUX3: Making UX Research Track with Agile. User Experience Magazine, 19(1). Retrieved from http://uxpamagazine.org/aux3-making-ux-research-track-with-agile/