The UX Runway - Integrating UX, Lean and Scrum Cohesively

Natalie Warnert, Thomson Reuters, www.nataliewarnert.com, @nataliewarnert

Scrum has been the buzz for the past decade and User Experience (UX) wasn't far behind. There is much confusion about UX integration and my company is no exception. We no longer desire to have the entire system design completed before the coding starts as waterfall practices have prescribed; however, not all design can or should be thought about only during the development Sprint. The rapidly changing requirements and priorities these projects welcome can be detrimental if UX is not incorporated in a timely and correct way.

Additionally, UX work is hard to classify as "done" because there is always more that can be added, user tested, and improved. Lean UX helps to keep the focus on delivering the minimum viable product (MVP), the very base amount of detail needed, in a timely manner for development integration. This led me to create a UX Runway concept to help tackle some of these problems up front instead of waiting until the development Sprint. This concept originated from the Architectural Runway concept that the Scaled Agile Framework® (SAFe™) details.

This article looks to educate developers, project managers, ScrumMasters, Product Owners, product managers, UX team members, and the like about a way to integrate UX and Lean UX principles into Scrum projects. It specifically focuses on the Scrum framework so familiarity with that method is encouraged when implementing the UX Runway practice detailed here and understanding this article. There are some concepts from SAFe but an in depth understanding is not critical. Though I have based the UX Runway around Scrum, it does have reusable concepts and could be readily adapted for other Agile methods.

What is User Experience (UX)?

It's important to understand what UX is, the different roles that can be on a UX team, and where these roles fit in relation to Scrum development. Simply put, UX is how a person interacts with a system - its information flow, intuitiveness, accessibility, ease of use, and their perceptions when using it. UX also often has responsibility for branding and consistency within an application, or suite of applications, and how it interacts and interfaces with other systems. Figure 1 shows a high level view of UX interaction.

Figure 1 - source: www.uxpassion.com

The UX Centralized Scrum Team

The team I am the ScrumMaster for is very cross functional in their expertise and roles and is centralized within department. The team "consults" on many different projects throughout the organization. Each of the members is assigned to one or more projects and they work with many different development teams to direct the UX of the system. The team consists of user researchers, information architects (IAs), visual designers, and CSS developers.

This is different than what I call a decentralized UX team; one where UX experts are part of development teams as cross functional members and do not have a central department or a UX specific team with individual disciplines. Instead, the UX expert on the development team is meant to be an expert in all of the aforementioned roles. This is what Scrum would prescribe, but in large highly specialized organizations, this sometimes can't be the case. Here is a closer look at what the different roles within a UX team are responsible for.

User researchers conduct usability research in many forms before, during, and after applications are developed. Some of the more common studies are contextual inquiries, card sorts, user surveys, observatory research, interactive and paper prototyping and heuristic evaluations. These are all different ways of observing and interacting with users to understand how they use and react to the applications.

Many projects don't allocate much of their budget to research, but it has been proven to be very effective when it is correctly incorporated into the design of the application. By utilizing ongoing user research during the project, user behavior as a result of a misunderstood feature or interaction can be discovered earlier. This allows UX and development teams to respond rapidly to change and incorporate the feedback into a later Sprint to make a better end product.

Information architects take the user research, if applicable, and determine the logical user and data flow through the system. They detail how a user should interact with a system or follow a process to accomplish their end goal. They craft the wording contained in error or instructional messages and determine where additional information and/or directions are needed. They draft how problems should be solved, resulting in how features should be laid out on the page and interact with each other and the user and how the data should flow. This work is generally done in low fidelity wireframes and whiteboard sketching. These are the deliverables IAs produce to the development teams to aid in their coding of the application.

Visual designers work closely with the IAs and researchers to determine how the application should look in order to support the functionality. They determine the appropriate colors and styles to keep the user engaged and keep the system cohesive. They determine where buttons, widgets, and messages should be displayed to make the flow logical and make important features stand out. As my team members say, "make it pretty." Visual designers produce high fidelity mock-ups complete with the appropriate imagery, icons, and colors to be included in the application development.

CSS developers are a bit different than the other three roles above. CSS developers are often included as part of the cross functional development teams (though not in my organization). Contrary to the other roles, CSS developers do not need to work ahead of the development team for the most part; their work is parallel to the development work as they are creating actual code that can be deployed as part of a feature or story. They basically translate the visual designs into the code so widgets are aligned properly, correct images are used, and applications are coded to be accessible and compliant with government 508 guidelines (or the equivalent) surrounding screen readers and the like for users with disabilities. Some teams also have accessibility experts as a separate discipline, too.

Depending on how the development environments and associated systems are set up, there may be additional CSS work that can be done ahead of development. Certain HTML templates and packaged style sheets can be worked on in conjunction with the visual design direction. This allows the technology teams to be able to apply styles as they are developing and helps to prevent rework from the inline styles that may be incorrectly used. This is not the case in all projects or environments but there may be more planning that needs to be done up front in some CSS cases than others.

The specialization on this centralized UX team has some challenges arise but makes better products when the work is managed effectively. There can be confusion for the UX team when creating the Product and Sprint Backlogs because of the hand-offs and pre-work. It is also difficult for the development teams to write and break down stories and tasks because of the sheer number of dependencies and some of the uncertainty around a design or wireframe that is not yet complete.

This leads me to the UX Runway concept. After all, a runway is only a stretch of time or area when preparation for the next step is done (e.g. an airplane on a runway is preparing to take-off). As SAFe 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 actually done?

UX Runway Project Kickoff and Sprint 0

When a business case is proposed, the Product Owner likely has a rough idea of some of the key functionality that will make the product desirable and aid its potential success. UX can provide some helpful context by creating business case designs. These designs can assist the Product Owner to think through their ideas, determine research opportunities, and put some visualization behind the words of the business case.

After business case approval and before development work can begin there is much demanded of UX, making a case for a period of time called the initial UX Runway. This initial UX Runway allows the UX team sufficient time to do their due diligence in mapping out the application and certain problems at a high level prior to development work starting. The Lean UX principle of problem focused designs makes more sense at this point instead of features because UX needs to be looking at the whole system and problems instead of working in a feature constrained box. This helps the system to remain cohesive and not constrain problem solving solutions at this early phase.

Another key UX deliverable during this time is the user personas. As a Product Owner is forced to think through who will actually use the product, what scenarios they will be using it for, and what their role in the system is it helps to extract more detail around the business case and high level view of system functionality. These revelations can lead to some of the epics that will initially drive release planning and the UX work.

User research can also use these user personas to identify potential roles and actual customers who can be used for user testing. Testing will vary depending on the phase of the project. At this point, contextual inquiries may be the best - simply watching how users do their job, either using an existing system, a competitors system, or even doing things manually. The most important part of this is the Lean UX principle of GOOB: Get out of the building. By observing users in their environment and learning how they do their job, much more valuable information can be gathered. Upon returning, this can be incorporated into solving the problems and the overall design of the whole system.

Development teams generally appreciate high level wireframes, designs, or prototyping work to put more context and transparency behind what they need to develop. I suggest and encourage UX team representatives to be involved in road mapping and epic and story creation sessions prior to the project kick off and Sprint 0. This allows UX to incorporate their opinions regarding where to include user research studies, critical linked system integration points, and identify other scenarios that will require extensive UX work.

During road mapping sessions, it is helpful to identify each of the known epics in the first release. As the development teams and the Product Owner(s) are prioritizing, brainstorming, and writing stories to break down the epics, UX representatives should also be in the room. They can help to identify UX milestones and dependencies which should be documented as stories, too. These stories will help to create the initial UX Product Backlog. It is important to note, similar to traditional Scrum teams and planning, these are not the final or only stories for the release. As more details emerge in further planning and Sprint work, more stories will be added for UX and development teams.

When arranging the stories in a planning roadmap format, the development team stories should be planned prior to planning the UX stories. Then when the stories are in the agreed upon priority and development order, UX dependencies should be ordered in Sprints prior to the respective dependent development stories. It is done in this order because it gives both the UX team and development teams a better idea of how long features will take to develop. Also, it allows the UX team to see how the development teams are breaking down the epics, which guides research, wireframe, and design work delivery. Depending on feature size and problems to solve, the UX stories should be placed one to two Sprints prior to when the feature is set to be developed. This creates another facet of the UX Runway.

As mentioned earlier, after a rough roadmap is developed, the UX team should be allotted an initial UX Runway prior to and including Sprint 0, before development teams start any user interface (UI) work. The time length is not strictly prescriptive; it really depends on the project size (e.g. a rough estimate is about one week per large feature in a release per two UX team members). This allows the UX team adequate time to contribute to the project vision for the project sponsorship team while doing some additional user research and creating other desired deliverables. As the development teams start doing backend and other Sprint 0 work, they can see incremental progress on how the product will function and what it may look like. Architecture should also be involved with UX Runway initiative and the key members should work together to determine what usable and architecturally sound solutions the development teams should be setting up infrastructure for.

As the project kicks off and development teams start Sprinting, the ongoing UX Runway continues a Sprint or two ahead to make new wireframes and designs, add more detail to existing ones, redesign when necessary, conduct user research, answer questions, and react to change.

UX Runway during an Agile Project

When looking at the construct through a Scrum perspective, it is nearly impossible to research, wireframe, design, code, style, and test, and re-research a feature within a Sprint. Even if it were possible, many advocates would likely advise against it because it is nearly impossible to create stories small enough to allow all that work to be completed in a two to three week Sprint.

The centralized UX team works like most other Scrum teams with a few modifications. They follow the same cadence as the development teams they're working with but not the same delivery schedule. When the development teams are coding the stories for the current Sprint, the IAs, designers, user researchers, and Product Owner are working from one to three Sprints ahead of them on future Product Backlog items creating a runway of sorts. There is some overlap that happens, which is planned and will be discussed in the following paragraphs. See Figure 2 below for a visual representation of the UX Runway and work breakdown between teams and roles.

Figure 2 - a visual representation of the UX Runway

Though the concept seems simple it takes a lot of look ahead planning and coordination on the upcoming work in the Product Backlog. This requires staying in constant communication with all Product Owners and other development team's ScrumMasters. Cooperative Product Backlog grooming and Scrum of Scrum meetings are vital to the success of the UX Runway.

At grooming meetings, the Product Owner discusses features for the upcoming Releases and Sprints. As more details emerge around features, it is determined if there are going to be UX dependencies. When UX dependencies arise, the UX Product Owner for the centralized UX team and gathers notes and details to use in constructing the UX team's Product Backlog. These details also emerge during UX team working sessions with the project Product Owner and questions from development teams during grooming.

These working sessions are key to the UX Runway and Lean UX. This is where the Product Owners start to define the problem and the requirements. The UX team helps by acting as business analysts and problem solvers to better define what the Product Owner is looking for. Again, they are looking for the outcome, not the output. By working this closely together it creates a shared understanding between all parties. No one is the expert; instead the team is cohesively working together to avoid repetition and to be innovative. Additionally, these working sessions value action over analysis. This means they value generating ideas versus talking them to death. Using Lean principles, we know the first things will probably be wrong, but it's better to fail fast and continuously deliver until it is the right solution.

Ideally this leads to having a UX Product Backlog that is defined two to three Sprints ahead and a development team Product Backlog that clearly has dependencies linked to associated UX stories. The UX Product Backlog is groomed regularly to ensure continuity remains with possible requirement or priority changes.

UX Runway - Sprints

When Sprint planning, the stories being committed to by the UX team link to stories and features being developed by the development teams one to two Sprints ahead of the current Sprint being planned as Figure 2 shows. This UX Runway gives appropriate time for UX spikes, research, wire framing and designs to be developed and delivered to the development teams before the development Sprint for those features. With some of the larger features this runway may be adjusted to allow more time for any of the above activities, however just in time (JIT) Lean design and continuous delivery is the main goal.

JIT and Lean design lessens the confusion that can be related to working on Product Backlog items that simply aren't ready to be worked on, either because the Product Owner is not ready to start discussing them or the feature is not yet funded. This generally emerges in backlog grooming but it is wise to make sure stories are ready to be started by making a Definition of Ready for both the centralized UX team and the development teams. In fact, the Definition of Done for the UX team and the Definition of Ready for the development team should have overlapping pieces as should all dependent and dependee team's definitions.

Utilizing a Definition of Ready can help immensely with the UX Runway. If all cross functional team roles within the UX team are utilized in solving a problem, it creates a series of potential bottlenecks. A UX Theory of Constraints results: the UX Runway is only as short as its longest dependency: research, wireframes, design, or CSS. In order to incorporate the research into the wireframes and design it needs to be ready to do so, meaning it needs to be done. In looking back at Figure 2, there is not much of a runway between the cycles. User research often has a lot of front end planning, too. Staying ahead of these things and defining when research is ready to be continuously incorporated just in time is vital to keeping the project moving. Even when research is not needed, the principle of small batch sizes is once again used to continuously deliver the least amount of work for the development teams to start.

UX Sprint planning is done in a similar fashion to traditional Scrum teams. As mentioned before, the centralized UX team is on the same cadence as the development teams. Generally, it is wise to do UX planning after development team's planning is complete but within the same day. This ensures that if a feature gets pulled forward and it has not yet been on the UX Runway and is not yet "ready" from a UX perspective, the UX team can plan accordingly and reprioritize their Sprint work or advise against development in the Sprint.

In Sprint planning, UX team members volunteer for stories and write tasks. The team then commits to the work for the Sprint. One distinction is the stories (wireframes, designs etc.) being delivered from the IAs and designers will only be about 90 percent complete upon delivery to the development teams at the end of the Sprint. There are about 10 percent of team capacity built into every Sprint for a bit of re-work and question time from the development teams relating to those deliverables. This can happen for many reasons including:

• Technical issues or limitations that cause wireframes and user flow to change
• Identification of an issue or user scenario that was overlooked
• Low hanging fruit that hasn't been on the UX Runway yet and is pulled forward

A final thought to Sprint planning is the reality of the dependent team in a Scrum environment, UX aside. When a team is explicitly dependent on another to complete their work and is working in a fast changing environment it is hard to stick to a strict Sprint Backlog as Scrum prescribes. This is again why 10 percent capacity is left in the Sprint after UX feature delivery. Sometimes when development priorities are shifted late in the previous Sprint and the Product Owners are in support of it, the Definition of Ready can get ignored and the development team will need to start working on something that is not UX "ready" and has missed the UX Runway.

Scrum tells us to say "no" to new work being added during the Sprint, but being a dependent team it is not that simple. To combat this additional work I've found it to be best to monitor how much unplanned work is submitted after the Sprint starts by development teams and make a velocity of it. When that unplanned work velocity is normalized as much as it can be, the additional capacity needed can be built into the UX Sprint Backlog by subtracting it from the current UX team's velocity. This can mimic an expedite lane as seen on some Kanban boards. This velocity should be communicated to Product Owners and if unplanned work is added to the Sprint, they need to choose what is the most important.

Is this the ideal solution? No, but as changing requirements and priorities are embraced and teams are dependent on UX, we need to concede that not everything will make it on the UX Runway. The ultimate goal is that development teams are driven by UX work through the Product Owner explicitly, but is not the norm. Sprint planning needs to take this reality into account to ensure things are still getting delivered and the team collaboration is not upset by these very real changes.

After planning is done a Sprint Backlog of what the centralized UX team committed to is emailed to all development teams and parties involved. The Sprint Backlog is also available to view in the shared work management tool by stakeholders, development teams or anyone else with a stake in the work.

UX Runway - Scrum Meetings

The UX team does have Scrum meetings, though only about twice a week. This allows for members of the UX team to attend the daily Scrum of the teams they are working with a few times a week. Through this, all team members of both the UX team and the various development teams can stay up to date on the work and get valuable face time to answer questions and have some discussion if necessary. As with most Scrum teams, this also cuts down on some of the emails that can flood members' inboxes with questions and requests more efficiently solved in person.

These Scrum meetings can be done as a whole UX team or as the smaller cross functional UX teams that are working on each project. Each has value: the centralized team can keep up to date on other projects and obstacles that may become issues to their project while keeping it to the small cross functional team can allow for more project specific discussion after the meeting. The teams should determine what they find to be useful and be willing to inspect and adapt.

We also use a Scrum board during our Scrum meetings. It helps to limit the work in progress and also visualize where the different work items are. There are many steps stories go through, as could be imagined with the many different team roles. To ensure the products stay consistent, wireframes and designs are reviewed while they are in progress by different members of the team at weekly internal reviews. This ensures quality and continuity between wireframes, designs, coding, and final CSS, all of which can take a few Sprints to be fully completed. They are also reviewed with the development teams and Product Owners in the end of Sprint demos.

UX Runway - Sprint Demos

The demos are a great time to showcase the wireframes and designs to the Product Owner and the development teams. Demos are a time to ask questions and analyze the proposed flows and user interaction recommendations the UX team is making. This helps the development teams to identify potential technical limitations with the recommended designs. This step is vital and gives the UX team time to rethink designs and offer other solutions when limitations arise.

The demos also allow the development teams and Product Owners to take a second look at the stories on the development team's Product Backlog and their acceptance criteria. Often wireframes and designs can help to uncover details that may have been missed in the earlier phases of discussion or where additional user research results have been added post story creation. The wireframes and designs can also help the development teams to flesh out story tasks during their Sprint planning. As previously mentioned all of these additional details and questions that result spur more conversations with the UX team.

These questions can lead to revisions to the wireframes and design, which is why the aim is to deliver 90 percent completion during the UX Runway Sprints and to providing just enough detail for the development teams to get started. This allows the UX team to remain lean by keeping the batch sizes small each Sprint. By not doing too much extra work, they eliminate the waste and re-work that can come from providing too much detail at the beginning. This lets the design iterate through UX continuous delivery and work out the smaller detail as they go. The UX team finishes the remaining 10 percent in the development Sprint based on what arises. This leads to a more well thought out and user-friendly final product.

Working Space

Another thing to consider is the concept of co-location when integrating a UX runway with a centralized team and multiple project teams. When each member of the UX team is working with multiple projects, teams, features, and Product Owners it is not prudent to have team members split their time between multiple team rooms. Though it may not be feasible for all teams, a project room for the UX team is great if there is availability.

It's a place for the UX team to collaborate on designs and wireframes to keep look and feel consistent between applications and problems that may be being solved by different team members. It also is a common place where Product Owners can stop in and clarify requirements and development team members can ask questions and have impromptu meetings. As in most team rooms there should be plenty of whiteboard space, places to meet, and quieter spaces for team members to have creative time.

A few great ways I've seen this utilized is by hanging up a product vision or storyboarding on the white boards, or in Lean terms, externalizing your work. Team members look at the vision individually and put sticky notes on things that are not clear. As for storyboarding, quite often the windows will be covered with sticky notes and the white boards with drawings and pictures. This helps to be leaner by getting out of the deliverables business. The artifacts we come up with don't solve the problems; I've seen wireframes done on a paper plate. It's the collective understanding and frequent collaboration to get everyone on the same page. The UX Runway simply allows for adequate time to have those conversations and think through the problems in whatever way is best at that time.

ScrumMaster and Product Owners for UX team

The UX ScrumMaster, in addition to the planning, grooming, and daily Scrum facilitation, attends Scrum of Scrum meetings for each project. This allows yet another layer of transparency with what the UX team and the development teams are working on. It is a place where issues are discussed and demos and working session meetings are coordinated.

The role of a ScrumMaster is very important. They facilitate the Scrum meetings such as retrospectives, planning, daily scrums etc. and work to remove impediments and make things easier for the team to do their work. A senior UX expert, or less ideally the ScrumMaster, can act as the main Product Owner for the team, too.

Within the UX team the main Product Owner provides priority for the different project feature problem solving work each member is doing (remember each member is likely working on multiple projects and priority setting is key among projects), help them to set up sessions, ask the right questions to the right stakeholders, and have a forum to share their deliverables with the development teams and business Product Owners.

This should provide some context on how UX, Scrum and Lean can successfully work together in a large organization with a centralized and specialized UX team that is in very high demand. When UX teams are given appropriate UX Runway time both before the project starts and during the Sprinting phases, they can think through problems and make several solutions. This UX Runway allows for more iterations of problem solving, wireframing, design, and research to deliver high quality, user based solutions.

By being involved at all points of the development process and sitting at the table with development teams throughout, dependencies can be identified earlier and reduce the "fire drills" that so often are part of large projects, even in a Scrum framework. It is also important for the UX team to remain flexible and lean. When integrated correctly, all features should go through with the UX team. This increases consistency and provides a great tool for development teams to use in story writing and coding. If the process is managed and adapted to fit the project and the teams, the overall product will more usable and intuitive and added overhead will be minimal. Though it is not following all Scrum guidelines, the UX Runway has been proven to work in allowing inspection and adaptation for efficiency and quality among multiple applications.

References

Lean UX Applying Lean Principles to User Experience, Jeff Gothelf with Josh Sieden, O'Reilly Media, ISBN 978-1449311650

508 Compliance: https://www.hhs.gov/web/508/accessiblefiles/index.html

UX Runway - How to Incorporate UX with Agile/Scrum teams: https://nataliewarnert.com/ux-runway/

Definition of Ready (DoR) in Dependent Relationships: https://nataliewarnert.com/definition-of-ready-in-dependent-relationships/

Scaled Agile Framework (UX): https://scaledagileframework.com/

Scaled Agile Framework® and SAFe™ are trademarks of Leffingwell LLC

---

Agile and UX Articles

The Psychology of UX

The Psychology of UX - Part 2

Scrum Sprint Length: What is Right for You?

Agile and UX Resources

Scrum Expert

Agile Videos and Tutorials

---

Click here to view the complete list of archived articles

This article was originally published in the Winter 2013 issue of Methods & Tools