Adapting Scrum to a UX Model

July 7, 2014

Agile methodology—more specifically Scrum—is an increasingly popular approach to increasing the speed of software development while maintaining flexibility. Scrum works well when an entire team is collocated. Real-time communication happens between team members during daily Scrum meetings. But assume part of a team is operating in a different role, from a different location. Sound challenging? In this article, I’ll try to answer some common questions about user experience and Scrum by exploring the challenges a Development team faced when working with a separate UX team on a Scrum project. I’ll also provide recommendations for UX teams that are part of a Scrum team.

While the information in this article reflects my experience working with my clients, confidentiality prevents my discussing specific situations, so I’ll instead present a scenario that is based on some challenging situations that I’ve actually encountered in my work. This scenario resembles real situations from a very successful project on which the UX team was not colocated with the rest of the Scrum team. I hope this article will be useful to both UX professionals and software developers working on Scrum projects.

Champion Advertisement

The Scenario

In this scenario, there are two teams working together on a Scrum project from two different locations: a Development team and a UX team. According to the agreed-upon plan, the Development team is dependent on the UX team for wireframes, design comps, and graphic design assets, without which they cannot start development. To make things a bit more challenging, let’s assume that the UX team is a third-party vendor that does not usually follow the Scrum methodology as part of its day-to-day delivery model. However, they must for this engagement.

Following the Basics of Scrum

Adhering to Scrum principles and practices is what it makes a Scrum team effective in action. For example, a team must follow Scrum roles and processes by the book. Each Scrum team comprises a Product Owner, Scrum Master, Scrum team members, and a Business System Analyst, who may act as a substitute Product Owner and works with the Scrum team on a regular basis. The team participates in scheduled sprint meetings and works toward the common goals of designing, coding, and testing a deliverable—whether a new feature or just a bug fix. During each sprint meeting, the team goes through the product backlog, sprint backlog, and burn-down charts.

In this situation, a separate UX team that did not follow Scrum as a part of its delivery model would present serious challenges to the team’s realizing the benefits of Scrum. For example, a project might experience deliverables churn, get delayed because of misaligned schedules, get blocked by a slow approval process, or experience communication breakdowns.

Tips for Working Successfully on Scrum Teams

So, how can UX professionals succeed in such a situation? What are the key adjustments that it’s necessary for a team to make to the Scrum methodology to enable them to succeed when working with a separate or an external UX team? Here are some recommendations for mitigating the challenges and risks that are associated with separate UX and Development teams working together.

Plan in a fluid manner and onboard the UX team to Scrum. The entire Scrum team—incorporating both the Development team and the UX team—needs to follow identical principles, speak the same language, and use the same terminology. Provide a basic overview of Scrum to all UX team members at the beginning of a project.
Schedule the UX team deliverables such as wireframes and visual design assets at least two sprints in advance to align the UX team’s timeline with the Development team’s sprint schedule. This change will allow the Product Owner sufficient time to carefully review the UX team’s deliverables and catch issues such as system limitations and areas of unwanted customization. Complete the technical review in advance or during the first sprint.
Involve a developer in the review of UX deliverables. Product Owners are not developers. So the chances are high that they may have difficulty understanding technical capabilities. I recommend involving a developer in the review cycle to help reduce the likelihood that significant design changes would be necessary during the sprint, which could jeopardize your target dates and reduce development speed.
Use the second sprint to revise design deliverables and get stakeholder approvals. During the second sprint, the UX team should get time to make any necessary updates to the wireframes and visual design assets based on the feedback that they’ve received from the Product Owner and developer. But what about the stakeholders’ approval? Use this sprint window to get stakeholder approvals. By allocating time for signoff, the Product Owner ensures full business buy-in for all UX designs that the Development team implements. The sprint plan should expect and allow business stakeholders to request tweaks to UX designs when they later see demos, but this early review and signoff prevents the need for a complete revamp or large changes to the project during development.
Allow time for planning. The UX team is more effective when it has time to plan and assign the most appropriate designers to each project. So make sure that the UX team lead or manager has an opportunity to voice concerns early and has complete visibility into the upcoming work. Be sure to provide a clear view of the project pipeline, agree on UX delivery dates, and provide guidance to the UX team, not detailed Business Requirement Documents (BRDs). You need to give the UX team room to be creative. The Product Owner should work closely with the UX team lead or manager to convey the vision for the project and may help by sharing examples that relate to a few complex modules and referring the team to Web sites or applications with similar functionality.
Facilitate communication between the UX team and the Development team. Remember, the UX team and the Development team are not sitting together. So formal feedback makes communicating the need for any minor rework or superficial changes easier. Ask the Product Owner to expand his role and take on responsibility for facilitating communication between the UX team and the Development team. Choose a Product Owner who has strong communication skills; who understands wireframes, visual design, and technical development; and who has the ability to answer questions that come from the UX team. The Product Owner should act as a bridge between the UX team and the Development team.
Use collaboration tools to facilitate the Scrum team’s work. The Product Owner should leverage the use of various tools to make teamwork easier. Agile tools are fantastic for helping Development teams organize sprints, maintain the product backlog, and report progress. The Product Owner must encourage the team to use spreadsheet-based feedback forms, agile tools like Jira, and file-sharing networks. Using a file-sharing tool is essential. There can be a huge number of UX artifacts such as wireframes and visual design assets. Exchanging them as email attachments clogs people’s inboxes and creates confusion—particularly as the number of versions increases. When files get buried in people’s inboxes, it’s difficult to find them. Tools like Dropbox, Google Drive, Google Docs, and OneDrive solve the problem of email systems’ file-size limitations, too. The Product Owner must make use of solutions like Confluence or SharePoint to maintain strict version control and provide an archiving mechanism. The file-sharing system must be open to the entire team, enabling both UX and Development team members to upload and download the files. When a team member uploads a new version of a file, the older version of the file must be moved to an archive folder.
Communicate face to face whenever possible. Direct, face-to-face communication is always helpful, provides greater insights into UX design, and reduces the likelihood of miscommunications and gaps in requirements. However, if face-to-face communication is not possible, the Product Owner should liaise with a UX Project Manager. Conference calls and collaboration systems like WebEx provide alternatives that teams can use. The Product Owner must keep the UX team lead or manager in the loop regarding any change requests, so he or she can manage the workload across the UX team. When working with a UX team lead or manager, the Product Owner should plan extra time for design updates and pad the ultimate delivery date to allow for inevitable mid-sprint change requests.
Include the UX team in feature demos and reviews. When allocating development time based on the development of specific features, the Development team has limited time for making corrections or adjustments before they must move on to the next feature. Invite the UX team to demos so they can hear stakeholder feedback directly and can immediately identify small implementation errors that developers can quickly fix. By including the UX team in reviews, you ensure that everyone can quickly achieve alignment on any necessary adjustments.

In Summary

On a Scrum project, a UX team that does not follow Scrum as part of its delivery model presents a serious challenge to realizing the benefits of Scrum. To solve this problem, someone from the Development team must serve as a point of contact and work closely with the UX team on a regular basis to align the two teams’ timelines, as well as their expectations in terms of deliverables and requirements. This will ensure the timely delivery of UX design artifacts, better alignment on requirements, and a consistent process for providing feedback to the UX team before development starts.

In Agile Development | Agile UX

6 Comments

Sushmita Dutt

July 8, 2014 9:18 AM

Nice topic to talk about. Agile UCD is relatively new and so is Scrum, a sub-methodology under agile.

However, most of the steps mentioned as Scrum principles are mandatory requirements for any technology project undergoing design and development phases. Whether Scrum or not, a project manager is required to provide a basic overview of phased design and development plans to both UX and development teams. And then, of course, we have stakeholders’ views and change-request processes that are followed in the software industry with or without Scrum.

I have been following these steps since I began my career with Microsoft. Then, the waterfall process was what we adhered to, which has similar guidelines. Scrum is, of course, more fragmented and brings about clarity in phased design and development. But mentioning these steps as “exclusively Scrum” is probably not right.

Mark Hazlewood

July 8, 2014 9:25 AM

Great read, Anindya, thank you. Your points and process seem to focus on the “hard deliverables” of the UX team to the dev team—wireframes, workflows, comps, and so on. I can certainly see getting into a 2-sprint rhythm when it comes to those things.

But what about user research and discovery deliverables? Things like personas, scenarios, and user journeys. More of the larger design-vision items. How would the execution of those research tasks and the development of those artifacts fit into this model? In your experience, did the UX team have a jump start to perform those tasks before the sprint cycle began?

Dave Yuknat

July 10, 2014 10:40 AM

Very good article.

@Mark, I’d say that those processes take place outside of sprints completely; in fact, they are tools well suited to prioritize quarterly planning and backlogs, but are not part of the sprint-to-sprint agile process.

Peter W. Szabo

July 11, 2014 5:21 AM

Great topic, thanks a lot. Last month, I wrote an article, “7 Quick Wins in UX Management,” which is based on Scrum and my experience as a UX manager. If you are interested in Scrum based agile UX, please check it out.

Antti Latva-Koivisto in reply to comment from Dave Yuknat:

July 15, 2014 2:30 AM

@Dave, I totally agree with your response to Mark.

Scrum assumes that there is a product backlog, an ordered list of requirements expressed in terms of so-called user stories. But where on earth does that come from? How can anyone know that they have the right product backlog?

Based on my professional experience, I claim that, for the finished product to have a great UX, it is absolutely critical that UX professionals work with product management to produce the backlog, so it is based on user research. And that needs to happen before the first sprint. If it doesn’t, there is a real risk of building a totally wrong product: the envisioned product doesn’t actually address any real user needs, or it misses many important user considerations.

I would also argue that, in order to evaluate and prioritise the product backlog properly from the users’ and customer’s point of view, it is not enough for the UX professionals to produce just personas and user scenarios. The designers should also create at least an initial draft of the design framework—or wireframe—that shows the first whole version of the product. The framework should demonstrate important end-to-end user scenarios concretely, step by step.

Such a design framework makes the full extent of the product visible and concrete because it shows all the features that the users actually need to accomplish their end goals. The design can then be tested and reviewed with users, which can still result in relatively big changes. However, those changes are so much faster to make to the framework than changing the finished code of the product—even though agile methods claim that changing the code can be fast. The design framework is very helpful in prioritizing the product backlog, because all stakeholders will be able to see which features work together to support complete end-to-end user scenarios.

Doing all this UX work before the first development sprint greatly reduces the number of change requests to developers in the implementation stage, where Scrum and other agile methods are most suitable processes. Because of the radically lower number of changes, doing the user research and design framework first does not increase the total time to the first release. Experienced designers should be able to create the initial design framework rather quickly.

If the design is produced only piecewise, feature by feature, sprint by sprint, it is impossible to design one cohesive whole with a great UX. However, the UX professionals and designers can refine the design in parallel to the development, very much in the way suggested in this article. It is a good idea to do the finalised design and create the detailed visuals two sprints ahead of development.

Using proper UX methods for user research and design greatly undermines a key assumption of agile methods—that is, that requirements cannot be fully collected at the beginning of the software development cycle. UX methods are designed to do exactly that. Instead of producing long requirements documents, a design framework is created, which visually represents the final product very closely. Unlike requirements documents, users and customers are perfectly capable of evaluating how well the finished product would satisfy them—provided that the design is represented in a concrete form as end-to-end sequences of concrete example scenarios, as opposed to static, empty wireframes.

Antti Latva-Koivisto

Interaction Designer & Independent Software Consultant

Ramesha

October 20, 2014 6:10 AM

Hi Anindya, Very useful article. Thanks a lot.

Join the Discussion

Full name

Email address

Remember me (Optional)

Comment

Anindya Sengupta

Principal Consultant, User Experience, and Lead for UX and Mobility Center of Excellence

Hyderabad, India

Anindya is a seasoned UX strategist, designer, and digital media design professional with more than 16 years of experience working on various new media deliverables. Currently, UX Architect at Virtusa, an IT consulting firm in Hyderabad, India, he is responsible for their entire UX practice and helps his organization align their product roadmap with customer needs, making them future ready. As a consultant, Anindya focuses mainly on experience design—particularly understanding complex systems, processes, and relationships between people and business software. He advises his clients on how to improve products and optimize customer touchpoints. The companies for whom he has worked include the Big 4 business consulting firms, Swiss Bank, government organizations, and startups. Anindya has a Bachelor’s in English Literature from Utkal University. Read More