UX Runway – How to Incorporate UX with Agile/Scrum Teams
So I’ve alluded to a UX runway and my work with Agile and UX in some of my previous posts, but what does that mean? Agile has been the buzz for the past decade and UX was quick behind. First, let me give some background on UX and my role on the team. I’m the ScrumMaster of a UX team. We are part of a large organization serving the needs of many legal application development Scrum teams. My team consists of user researchers, information architects (IA), visual designers, and CSS developers. For better descriptions of these roles please see my post about the Definition of Ready.
So what is UX and what does the team do? In a nutshell, User Experience is how a person interacts with a system – how the flow works, how they perceive things, how accessible it is and the ease of use and understanding. The team I’m ScrumMaster for is very specialized as you can see from the many roles above. Each of the members is assigned to one or more projects and they work with many different development teams to direct UX of the system. This specialization causes some challenges when creating the product and sprint backlogs because of the amount of hand-offs and pre-work. It’s also difficult to write and break down stories and tasks because of the sheer number of dependencies.
When looking at the construct through Scrum’s perspective, it is nearly impossible to research, wireframe, design, code, style, and test a feature within an iteration. This leads me to the UX Runway. I initially got the idea from the Scaled Agile Framework® (SAFe™)* and the architectural runway. After all, a runway is only a stretch where preparation for the next step is done (e.g. an airplane on a runway is preparing to take-off). As Dean Leffingwell put it, “having the UX design track a bit ahead as part of the architectural runway for a system.” But what does this look like and how is it done?
My team works like most other Scrum teams with a few modifications. We are on the same cadence as all the development teams we work with, though when they are coding the features for the current iteration, the user researchers, IAs, and designers are working an iteration or two ahead of them on their upcoming work in the Product Backlog. It seems simple but is really far more complex. I play the role of a ScrumMaster and Product Owner for the team. I facilitate the Scrum meetings such as retros, planning, daily scrums etc. and work to remove impediments and make things easier for the team to do their work (e.g. a Scrum board works very well for us and I list upcoming features for our product backlog on another board).
As a PO, I work with all the POs, PMs and tech teams to build out our product and sprint backlogs for projects that depend on UX work. Another person who could be a good team PO would be a Senior UX team member. I attend many grooming, planning, and working sessions to gather the information to build a Product Backlog that will ensure UX work gets done in time for tech to build it where it fits into the PO’s priority vision. Within the UX team I provide priority for the different project feature work each member is doing and help them to set up sessions, ask the right questions to the right stakeholders, and have a forum to share their deliverables with the tech teams and POs.
We are a little different in our sprint deliverables than a typical Scrum team. They are not true deliverable features firstly because it isn’t code or functionality we’re delivering; it’s in essence design and flow documentation the teams need to build a usable product. Secondly they are not truly finished. Our goal is to walk through and deliver wireframes or design about 90 percent complete. This gives the teams just enough to get started and allows for them to ask questions about functionality while giving us the flexibility to make necessary modifications based on questions or development concerns. This is done in working sessions or other team’s Scrum meetings that UX team members are invited to. We plan a bit of capacity in each sprint to adjust our deliverables and answer these questions – it may sound like story bleed over but in this context it is necessary and adds value.
I hope this provides some context on how I’m making UX and Agile work together in a large organization. Though it is not following all of the Scrum guidelines, it is working well for us and it allows us to adapt to change quite rapidly.
*Scaled Agile Framework (SAFe) is a trademark of Leffingwell LLC