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. For more context please see diagram below:
*Scaled Agile Framework (SAFe) is a trademark of Leffingwell LLC
agile Agile UX definition of ready scrum Scrum Methodology User Experience ux UX Runway
8 Responses
Natalie, this is an interesting idea. I once coached a mobile eCommerce team that had a very aggressive deadline on a completely new version of Windows mobile at the time. The UX team delivered their output using XAML, which the dev team used as input. It was one of the most unconventional, yet outrageously successful Scrum projects I’ve seen to this day.
The concept of UX runway to me seems consistent with the idea of developing a broader product ownership capability (http://www.leadingagile.com/2011/03/why-a-product-owner-team/). Also, a product owner may consider a UX team’s output as an increment of value, if that increment reveals learnings like (a) this feature feels weird, we should hold off on building it (b) now that I’m seeing the user workflow, we should add these 3 new backlog items (c) Wow, this workflow shows this feature impacts a lot of systems. We should coordinate inputs/outputs with the impacted teams.
However, I’m hearing people say this kind of UX / PO work is very interrupt-driven, and does not fit well into fixed timeboxes like Sprints.
How do you manage the flow of work through this team? How stable are your Sprint Goals for this UX team?
Nice post.
Thanks for the comment, Jesse. You make some great points and I certainly do see that both stories and tasks are being created in response to UX work – it is a delicate balance because when the work is being done in the UX runway it makes a great planning tool however when priorities change and the UX runway is too short it can affect Sprint goals for sure. I’m finding the POs are very keen to UX input and have taken a lot of our findings into consideration when determining what features to develop next.
As far as managing the flow of work – that is an entirely other story/post where I need to put on my PO hat. Stay tuned!
Thanks for the link to your post! This is great stuff…
Thanks for the informative read. Within UX work , there must be many end users whose inputs are built into the product backlog.
I have heard many challenges on the following front:
How do you manage to get these end users feedback?
Is it within the sprint? what happens if the feedback triggers changes in the prioritized stories which are already passed to development?
What is end user reaction to demoes once development team complete work but could not incorporate end user feedback within that sprint.
Great question, Amol. I didn’t go into it too much here – I have a piece I’m working on with more detail about end user feedback so stay tuned.
We handle user research and feedback throughout the projects. It is hard to get user feedback within the sprint the feature is being developed in because our sprints are only two weeks. We generally try to feel this out with prototyping ahead of development from a UX perspective and then follow up after the feature has been released for more feedback.
If the feedback triggers changes, those are prioritized by the product owner like any other stories and incorporated into the backlog accordingly as new stories.
For demos, I think it is just shared upfront if there is going to be additional work done on a feature due to customer feedback and the product owner handles questions about when and why. Again, since the feedback is hard to get in the same sprint, this usually comes up in subsequent demos.
[…] my blog and writings you maybe know a bit about my work with User Experience and what I call the UX Runway – UX working an iteration or two ahead of technology to make designs which technology teams […]
Great stuff Natalie. I appreciate the complexity of the flow and guidance that comes from UX and the inherent coupling to the underlying code implementation. Much as Jesse is saying I don’t think you need to apologize for the inability to be done done. I would extend the analogy to SAFe’s Architectural Runway further by looking to the Agile Architecture principle of “Design emerges, Architecture is a collaboration”. While we may think that some architectural component has been delivered what has really been delivered is the constraining intent of the architect through the runway. In much the same way your UX team is delivering a full product of guiding intent for the UI. This intent is then informed by the developers as they apply code to it. So your product, though not code, provides a definitive and measurable value increment.
Great read and great insights, thanks!
[…] Ux Runway – How To Incorporate Ux With Agile/Scrum Teams […]