Get certified - Transform your world of work today


How to Fit UX/UI into Agile and Scrum

17 November 2016

Cornelius Parkin

I am sharing this article to describe my experience with UI and UX during project delivery, within a large enterprise. Audiences within large corporations, or those thinking of moving over to one, may find this article of most value.

Let’s face it. Design-driven software makes users happy, but that’s not the only thing that makes users come back for more. Let’s consider what makes users use your product over and over.

First, let’s get the terminology right. I’ve noticed delays in software delivery because people mean different things when referring to something like UX. In the end, stories are written, test cases executed, design made, or code written based on invalid assumptions. And you know what they say about assumptions. . . . Imagine the impact on every release. Getting terminology solid and mutually understood is as important as setting a Definition of Done (DoD) or Definition of Ready (DoR), in my opinion. It sets the scene, removes assumptions, and paves the road to clear communication and success.


  • Design team: The person/people/teams/organizations responsible for creating the UX and Look and Feel.
  • Design: The processes and tools used by the design team to create UX and the Look and Feel assets.
  • UI (User Interface): This could be any interface that a user uses to interact with your product or service. Developers create code that allows users to interface with a product or service. Developers, UX, and graphic designers contribute to the UI, which becomes the end product a user uses. In Scrum, developers, UX, and graphic designers are all known as developers.
  • UX (User Experience): This relates to the interaction a user experiences on the UI (i.e., flow, clicks, gestures, swipes, etc.). Usually, wireframes are a product of UX, and they are created by the design team.
  • Look and Feel: The graphics, logos, fonts, colors, etc. that make up what your UI looks and, well, feels like. Assets (files) are usually a product of Look and Feel and are created by the design team.
A great product comprises much more than UX, UI, and Look and Feel. It’s the total package, which encompasses:
  • UI, UX, Look and Feel
  • Security
  • Quality (bugs irritate users)
  • Speed (slow products irritate users)
  • Usefulness (does the product meet a customer need?)
  • Addictiveness (that is, a design that users cannot help but come back to — I recommend this interesting article: "How to Hook Users with Habit-Forming UX Design")
Meanwhile, back at the ranch, an organization works hard to ensure that everything is in place to maintain a product of the highest standards. Things like penetration testing for security, test automation, monitoring, continuous integration for quality, and much, much more.

OK, so we have some good context for what UI, UX, and a great products looks like. Now, how do UX and Look and Feel fit into Agile?

Challenges with fitting into Agile

In my experience, designers like to be creative. They do not like pressure or deadlines. They would prefer to sit in nature somewhere and soak up the beautiful energy around them, which they translate into wonderful UX and Look and Feel — like true artists. The problem is that business does have deadlines, and budget constraints, and marketing timelines, so it is inevitable that business would expect the design team to deliver within deadlines, like the rest of the organization.

In addition, UX is supposed to not only be inspired but also informed by user testing. Imagine the delays this could bring into a single vertically sliced story. Additionally, designers cannot create a design based on a single vertically sliced story, because they have to consider the whole user journey. For this reason, they tend to prefer designing on an epic level.


So what to do? The design team has to deliver within commitments, similar to code. The ways they reach their commitment may be different, but there must be a commitment and a deliverable. Why? Because UX (and sometimes Look and Feel) usually affects everything — from the UI developers all the way to the people who write services (API layer). It sets the tone, in alignment with business, for what the end product will look like. So if the design team (which is the key dependency for the rest of the teams) is not delivering within realistic timelines, no one is.

Not only does UX affect UI and service development but service and UI development can also affect UX (based on legacy systems, regulatory constraints, technical feasibility, and more).

Based on this complexity, what is the best way to run a project dependent on UX within such a large corporation, with tons of bureaucracy? You have the following options:
  1. Run the design team in Kanban and the rest of the teams in Scrum.
    1. Advantage: Design can execute at their own pace.
    2. Challenges
      • Kanban usually has no timebox period, meaning that whatever the design team delivers that meets DoR for UI and service developers is completely unpredictable. The outputs of the design team remain the inputs of the UI and service developers, which means that your whole project rests with the design team, and your UI and service development team may be sitting idle a lot, which is bad for business.
      • One team cannot commit to delivering x work in a sprint while another team delivers at a Kanban tempo.
  2. Run all teams in Scrum.
    1. Advantages
      • The design team commits to delivering n number of designs by the end of the sprint. This makes budgeting and planning easier.
      • The UI and services development team knows what design work will be ready to take into the next sprint.
    2. Challenges
      • Design is still a dependency and needs to run one sprint ahead of the rest.
      • The design team may need to attend a Certified Scrum Developer® (CSD®) course to learn how to function properly within Agile and Scrum as a designer; this is another business expense/investment.
      • The design team tends to not make these commitments because of the complexity of creating a design for an epic, with all of its positive and negative flows.
  3. Run UX and Look and Feel as a separate project.
    1. Advantages
      • The UI and service development teams can continue with other priorities, while business, architects, design, and users all flesh out a prototype that the UI and service developers can use once the project is complete. Resources are used to optimum level.
      • No delays. When the prototype is done, UI and service developers know exactly what to develop, and they execute accordingly.
    2. Challenges
      • Agility has been removed from the equation, which makes adapting to business change void. We are back at Waterfall.
      • As UI developers convert UX and Look and Feel into a UI, by the time users interact with the UI, it is guaranteed that the way certain user interfaces were designed and prototyped seems to be not such a good idea any more. We are back at waiting for the design team to make changes, user-test them, and feed them to UI and service development.
We’ve been using option 2, running all teams in Scrum, and making sure that the design team runs a sprint ahead of the UI and services development team. However, there’s another spanner in the works: Complete working services are also required, in essence, for UI developers to consume them!

Now we are faced with the following pattern: UI development depends on design and services. Services depends on design; design depends on business, UI, services, and users; business depends on services and UI for technical feasibility and on design for best UX consultation.

I’m not convinced that we have found the best solution yet, and the way we got around the service dependency was by creating service integration user stories and stubbing code on UI based on service integration assumptions. So, at least we could get UI and service development to run Agile with each other. UI would develop the bulk of the work, and so would services. Once services was ready, the integration story would be pulled into the sprint (current or future) by the UI development team. Design remained a critical entrance criteria component we could not get around.

In conclusion, the critical factors we found that were causing design to hold the project back was that they did not understand how to fit design work into Agile and Scrum. Also, they did not completely comprehend the impact they have end to end. The best solution is to give training to design team members (CSD recommended) and have them understand how to make design work within Scrum. Teams that use outsourcing capabilities would also have to ensure that the designers who get on board have a CSD qualification and relevant experience. Additionally, the ScrumMaster (and/or business analyst and/or system analyst, depending on team structure and responsibilities) should be able to help the design team create stories and tasks in a way that they are achievable within a sprint, meeting their own DoR and DoD. Design story DoD should fit in with UI and service development DoR.

Because of all the dependencies, we found that creating and executing stories vertically sliced (end to end) is not possible yet.

Any alternative suggestions are welcome. We are Agile; we are learning; we are improving!

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 3.8 (4 ratings)


Tim Baffa, CSM, 11/17/2016 2:35:12 PM
In my opinion, you will continue to have a difficult time managing all of your inter-team dependencies until teams are created with enough cross-functional skill to be able to vertically-slice stories and deliver them e-2-e within a single sprint.

You are managing the dependencies, and coming up with multiple ways to do so. Try to think of ways to eliminate the dependencies, and see where that conversation takes you.
Cornelius Parkin, CSP,CSM, 11/22/2016 6:49:20 AM
Hi Tim. I am in total agreement. Problems we are facing are things like: Permission and Access Control (it's a bank), limited resources etc.

Apart from that, having a fully cross-functional team when a single story may touch up to 36 different business units, means that there may be 36 team members in a single team to complete a story in a sprint (which breaks the maximum amount of developers per team rule), and most of them will only be running at a low % capacity which does not make it economically feasible.

Ideally, cross-functional is best. Realistically, managing dependency and integration is where we are now.

Thanks for the comment.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up