From Scrum Master to UX Researcher, Or: How I Learned to Stop Worrying About Velocity and Love the User

In the summer of 2019, I was an Associate Scrum Master, and I found myself alone in the office, standing on a chair to tape long printouts of screens and modals from my development team’s application onto the wall. I was preparing a game in which team members would be given objectives and take turns navigating the website to complete them. Every time they achieved their goal, they would win points. Every time they hit a user error, they would lose points, and their turn would pass to the next player. The developers and product manager weren't prioritizing usability issues in the development backlog, so I devised this board game to make them feel the impact of poor UX. I was desperate to make our users’ pain a reality for them. The thought 'maybe I'm in the wrong role' did not even cross my mind.

The Job I Thought I Loved

I loved being a Scrum Master. I found the organizing principles behind Agile sensible and helpful in making work more efficient and valuable. I believed in technical excellence, sustainable development, self-organizing teams, and a cyclical process of examination and improvement. But most of all, I loved the focus on people. Individuals and interactions over processes and tools. Customer collaboration over contract negotiation. At its heart, Agile aims to put real humans at the center of the development process, and I loved the idea of a role whose purpose was to coach that principle, ask hard questions, and make sure teams were building the right thing to solve a real user problem.

But the longer I was a Scrum Master, the more the role drifted from that ideal. I won't add to the pile of "death of Agile" think pieces — but what I lived through was a slow reduction of something principled into something purely mechanical. Story points reported to leadership. Consequences for missing velocity goals set by people outside the development team. KPIs and features handed down from internal roles miles away from our actual users. Questions like, "Is this feature actually valuable to our users?" became unwelcome. Leadership didn't want user-centered thinking. They wanted more code, faster.

I started missing the days when I'd been allowed to do the real work — an afternoon user discovery workshop, a ride-along with the drivers we were building an app for, or yes, the day I turned our application into a game board so my developers could finally feel what they were putting our users through.

The Accidental Researcher 

I had always described myself as a Scrum Master who was “UX curious.” Even as an Administrative Assistant back in 2016, I had devised a way to get involved in a UX project, improving our employee intranet. But I thought actually holding a UX role required a fancy degree and experience I didn’t have. Instead, I thought I could lean into the people-first aspect of the Scrum Master role. I sought to partner with UX teams at every point, looking to ensure my development teams were engaging with UX research, testing, and best practices.

Looking back, I realize I was already playing the user researcher: synthesizing information and patterns across retrospectives, designing discovery workshops, and asking, “Why?” so many times in a root cause analysis, one leader joked we were going to get to the bottom of all human weakness. 

I thought I wasn’t qualified for a UX role, but I could be a Scrum Master who championed UX and coached my development teams to center the user in everything they did. 

The “Death” of Agile

I was a Scrum Master for six years, working my way into a Senior role at a large, well-respected company. I thought I had made it. And then in the spring of 2024, my entire department was cut overnight without warning. It was a complete surprise, and I was devastated. I had thrived as a Scrum Master, producing strong outcomes and growth for my teams and winning awards as a result. I thought excelling at my job would save me from the layoffs sweeping the industry. But the profound misunderstanding of Agile as a shortcut to high output and low costs, and the overly high investment in undertrained, untenured Scrum Masters had caught up with Agile as an industry. If Scrum Masters were just glorified note takers and story point counters, were they really necessary? Companies were abandoning the Agile ship right and left, and mine had finally followed suit. My love for Agile principles and my above-and-beyond work to teach those principles to guide development hadn’t saved me. 

Suddenly, I found myself with no obligation to my current role, and I started to dream. What if I could find a role that truly did seek to understand and represent user needs in the technology sector? What if my role was seen and respected as one that could help prioritize features based on actual research and help ensure designs were based on real humans and the way they interact with technology? What if I could practice UX?

Even after working around development teams for six years, helping facilitate UX workshops and user interviews, supporting project and product managers, coordinating and wrangling stakeholders, and running design and prioritization workshops, I didn’t think I could make the leap. Did I really know enough?   

Conquering Doubt

I started by talking with UX practitioners I had worked with in the past and quickly gained confidence. The resounding feedback was “you’ve been doing this all along” and “I’m surprised you didn’t transition into UX sooner.”

I realized I had a lot of the skills and experience to become a UX Researcher. Six years of facilitation — running retrospectives, designing discovery sessions, wrangling stakeholders through collaborative prioritization — translated almost directly into the mechanics of UX research. Moderated user interviews, it turns out, are not so different from a well-run retro. Both require enough psychological safety that people will tell you something true, and enough structure that the conversation stays purposeful without shutting down room for surprise.

The analytical muscle was there, too. I had spent years tracing patterns across retrospective data and running root cause analyses. Synthesizing research findings and turning them into something a product team could act on? I had been doing a version of that every time I helped a team define and prioritize a backlog. And the cross-disciplinary collaboration — the constant negotiation between developers, product managers, designers, and stakeholders — which was a prerequisite for surviving as a Scrum Master, turned out to be equally essential in research. Most practically, the project management habits that had kept sprints on track and backlogs groomed turned out to be exactly what's needed to plan and execute a research project. Scoping a research plan, recruiting participants, keeping a study on schedule — it's a different kind of work, but the organizational instincts are the same.

Uncertain of my next steps, I sat down with a UX designer I admired and had worked with in the past. “Oh yeah!” she said, “you’d make an amazing UX Researcher!” I talked with her about the possibilities of a boot camp, which many had warned me against. “Oh no, do it,” she said. We talked about it, and both agreed a program would help solidify the foundational knowledge behind my experience and position me perfectly for the role I wanted. As long as I chose a program that would help me develop a portfolio, I had nothing to lose. Within days, I enrolled in a boot camp. Two years later, I’m a practicing UX Researcher with a range of experience behind me that has only made me stronger in the role. I have no regrets for having made the leap.

Agile, Done Right, Should Produce Great UX 

Sometimes I think the decision to transition to UX took me so long, not simply because of self-doubt, but also because of my sense of hope in Agile’s intentions. The Agile Manifesto, the document on which Agile frameworks and practices are based, explicitly values customer collaboration over contract negotiation, and individuals and interactions over processes and tools. The very first of the 12 principles states that the highest priority is to satisfy the customer through early and continuous delivery of valuable software. So the intent to center human users and their needs is there. If I was a good Scrum Master, shouldn't I be able to be a good UX advocate?

However, the problem lies not in Agile’s intentions, but in how Agile is so often misunderstood in practice. Let’s take Scrum, the most popular Agile framework, as an example. UX Researchers don't formally exist in Scrum. The framework only recognizes three roles: Scrum Master, Product Owner, and Development Team member. That means user advocacy gets diffused across the whole team rather than owned by anyone, which in practice usually means no one owns it at all.

Many argue that the prescribed practice of user story formatting for describing work to be done helps ensure the team thinks from the user’s standpoint. Though admirable in intention, this makes the grave error of mistaking Scrum Team members as stand-ins for the user. Finally, sprint timelines and a culture of code releases seen as the only valuable output to the customer means that UX research and other deliverables don’t fit neatly into a sprint plan, goal, or timeline. When is UX research and design supposed to happen? And how can the UX team member fit into the Scrum Team? None of these questions has been answered neatly or satisfactorily by Agile frameworks. 

Ideally, the Scrum Master should help the team learn to center the user, but most Scrum Masters are trained to optimize process, not to ask uncomfortable questions about whether the right thing is being built or if we’re truly designing something with a real user in mind. In addition, the Agile certificate culture actively selects against curiosity. Someone drawn to measuring success according to ticket completion and velocity metrics is never going to become a user advocate — but I’m wired a little differently, drawn more to the people-first aspects of the role and the use of facilitation and coaching to help a team wade through ambiguity and uncertainty. In other words, the Scrum Masters best positioned to become UX advocates are the ones who probably aren’t quite comfortable with what Scrum and other Agile frameworks have become. Which makes my own transition out of the Agile space less of a leap and more of an inevitability.

What I'd Tell a Scrum Master (or Anyone) Considering a Transition to UX

Though I fully believe Scrum Masters are uniquely poised to make the transition to UX roles, I also know I’ve been lucky in doing so. I have made this transition when both the Agile and UX industries are experiencing profound disruption due to AI and an oversaturation of undertrained professionals. But I’ve been asked what I would say to anyone considering a similar move, and here it is:

Be honest with yourself. 

If you’re looking to make this move because you think UX roles mean automatic riches, you’re about eight years too late. You need to be making this move because you love understanding how and why users interact with technology, you love solving interesting problems, and you love the challenge of making technology more human-focused.

Don’t assume a boot camp is your next step.

Don’t automatically sign up for a boot camp and expect a miracle. A boot camp happened to be a perfect fit for me, but most boot camps cover a lot of material very lightly and result in very generic portfolios. 

Find ways to practice UX now.

Find ways to expose yourself to UX experience in your current role. Scrum Masters have access to so many different disciplines that contribute to technical output. If you’re cooling on Scrum Mastery like I was, find what interests you and get involved.

Recognize that it will be an uphill battle.

The UX hiring landscape is particularly tough right now. This is especially true for entry-level positions. Call me an optimist, but I think there is reason to hope, especially as the AI boom reveals that good tools must first be grounded in real user problems and respond to real user needs. Our roles aren’t going anywhere; just know it won’t be easy. 

Large companies will likely ignore your resume.

No matter what you do to make your resume stand out or demonstrate your experience, any automated resume scanning program will likely reject you outright. Either use your network to get introductions or find a company that can value your unique experience and that cares about hiring enough to have their applications evaluated by a human who can see the nuance and value in your varied background.

No Regrets

It may have taken me six years to figure out that what I really wanted was to be a UX Researcher. But standing on that chair in 2019, taping screenshots to the wall, I was already doing it — I just didn't know it yet. And I don't regret the detour. Being a Scrum Master gave me the skills, the instincts, and the drive to do this work well.

Today I'm a UX Researcher at Viget, which means I spend my days diving into ambiguous problem spaces, untangling what users actually need from what businesses assume they need, and asking the question: what do we really need to build here? Right now, that includes helping ensure AI tools are grounded in real user workflows rather than impressive-looking features that nobody actually wanted. And the best part is, I’m working with teams that are agile in spirit – curious, iterative, and user-focused – without being overly framework-dependent.

The UX field is facing real challenges, and I won't pretend otherwise. But I believe the researchers who will thrive are the ones who can move past simply providing deliverables and offer something harder to come by: genuine insight into what makes technology useful to the humans who have to live with it. That, it turns out, is what I always wanted to do. I just needed six years and one very memorable game board taped to a wall to figure it out.