Agile UX design: a Scrum-inspired process for UX teams

By Inviqa

We look at why and when UX teams should implement the Agile-inspired SCRUX approach to digital projects.

UX design projects can vary in scale and process. A product development process is typically a Waterfall project, where upfront requirements lead to staggered delivery of the whole implementation, or Agile, where the team works more closely with stakeholders and delivers the work in short sprints.

SCRUM is an agile development framework typically used in traditional software development. This framework provides a set of practices and processes, which, when done correctly, ensure delivery on time and on budget, for a given scope. Ultimately SCRUM is a philosophy that can be applied to many types of processes.

Typically at Inviqa we run intensive user research up front to inform a digital strategy, before diving into iterative design phase with more user validation; a kind of blended Waterfall into Agile approach. This means we're pretty confident we are building the right thing before we start designing.

When it comes to the design phase of a UX project, we have successfully managed to apply a similar Agile UX design process to SCRUM. Let's call this method SCRUX.

SCRUX is different from Lean UX, which is about minimal delivery (e.g. wireframes) and getting things into code as soon as possible to test. Unfortunately, you don’t always have that luxury with every client.

It's important to note that SCRUX is different from Lean UX. Lean UX is about minimal delivery (e.g. wireframes) and getting things into code as soon as possible to test. Unfortunately, you don't always have that luxury with every client.

There is some overlap between Lean and SCRUX. However, the latter is more suitable when you are not working as closely with the development partner as would be ideal; nevertheless, you'll still want to maximise the benefits that agile can bring.

Using SCRUX as your Agile UX design process means you will have a series of well-validated wireframe prototypes and visual templates the client has signed off, with the confidence you are 90% of the way to success before development. You can then deliver your design in chunks to whoever is developing the code.

You'll then need to work closely with them, to provide ongoing support in their chosen development process, as you normally would with any handover.

SCRUX: key processes and practices


The three key roles in SCRUX are:

  • Product owner: this is the client who must be able to make key decisions on behalf of the company who is paying the bills. They may need to tee-up relevant stakeholders for rapid sign-offs if they can't make decisions.
  • SCRUX Master: this is the person who ensures everyone adheres to the processes and practices of SCRUX. This could be a dedicated project manager, or it could be a member of the design team.
  • The team: this is the design and research team, typically consisting of one or more UX designers, one or more visual designers, and one or more UX researchers.


sprint is a period of time (we tend to use 1 or 2 weeks), in which a scope is agreed by the client and team ahead of design. Before the project begins we find it is a useful exercise to roughly divide up the chunks of deliverables into prioritised sprints so that the product owners know what is coming and inform other stakeholders. You can always tweak this later as you evolve and learn.

Each sprint has a goal. Early on in the process this is likely to be to deliver a functional chunk of the overall deliverable. For example, with a shopping website this might be to design the checkout process. This keeps the team focused on the task at hand and ensures specific stakeholders can be present for that sprint.

If you haven't conducted extensive user research to inform a feature roadmap, you may want to reserve a couple of early sprints to do some Lean research to inform what to focus on.

Your UX design project will include usability testing as well as design. You may choose to reserve whole sprints for user testing and amends, for example, if you want to test on 2-3 larger participant groups. Alternatively, you may just have a test day once a sprint, with perhaps three users. It's really up to you.

Before each sprint you will estimate the time for each task you have planned. The number of hours estimated for the scope is balanced with the number of hours you have resourced as a team.

It's all about pure transparency. You need to make it clear to the product owner that time is money. You are trying to help them by making sure the process supports the most effective product within the constraints of the budget. Oh, and you're going to deliver it on time as well.

The scope estimate is not exact, but it means you probably have a good chance of delivering what you set out to do. It doesn't necessarily matter, as you can pick up any slack in the next sprint.

At the end of the sprint you will ideally have a prototype (e.g. inVision clickable designs) of a functional chunk of the overall deliverable, which can be demoted and even handed over for coding.

Sprint board

The sprint board is a place to house all online communications about the delivery process. We use Trello, which gives us the flexibility to share the board remotely. You can also use the Trello Plus Chrome plugin to add and aggregate estimates for the sprint backlog. However, you could just go lean and use post-its and swim lanes on a whiteboard. It's the process that counts.

Apollo sprint board

Within each swim lane are the estimated tasks you need to complete to deliver the product, which are moved along the lanes as they go through their lifecycle.

task will often be a specific page or template you want to mock up. You may want to separate out desktop/tablet/mobile sizes, but it's up to you how you work. A task could also be putting together a discussion guide for testing.

Your tasks should range from around 2 to 16 hours work. Any less and it's getting too granular. Any more and you probably need to break it down.

What is in the sprint board?

  • Product backlog: all the tasks for the entire project belong here. Since this may evolve, typically you will add the tasks for the coming sprint towards the end of the current sprint.
  • Sprint backlog: before the start of the sprint you will move the tasks into the sprint backlog, which the product owner will approve the priority (top to bottom). The estimate in hours should match the resource you have scoped for the sprint.
  • In progress: once the sprint begins, the team should self-assign tasks and move them into this lane as appropriate.
  • Blocked: if anyone cannot complete a task this is moved into blocked. This is important because it gives the product owner visibility that you cannot proceed until decisions or answers are provided.
  • Under review: once each task is complete it is moved into this lane. At the end of the sprint, most/all of the tasks will be here. You can then review the deliverables to seek approval from the product owner.
  • Done: once the client has approved, you move the task into 'done'. If something crops up later, you can create a new task to reflect the requirement. This keeps estimates clean and ensures that they realise that more changes means more task, which means more time and budget allocation.

Sprint meetings and work

There are four key types of meeting:

  • Sprint planning: agree scope for the sprint with product owner by prioritising items from the product backlog into the sprint backlog, in line with the sprint goal.
  • Daily stand up: everyone gives a short, one-minute update on their progress yesterday and their plan for the day. They also raise any blockers, which the SCRUX Master can address outside the meeting with the client if necessary.
  • Sprint review: the team present the work for the week to the product owner. Since the stakeholders have been involved daily, there shouldn't be any surprises. But the team can then capture any further amends to complete that day or roll into the next sprint.
  • Retrospective: the team without the product owner discusses what worked well and what could be improved for next sprint. This ensures any concerns and risks are highlighted, and the process as efficient as possible.

In terms of design work, we typically sketch as a team and then stagger visual design templates, just off clickable wireframes so that they're closely aligned. For some projects, we may involve a frontend developer to build a frontend responsive prototype.

What does a typical, five-day design sprint look like?

Day 1:

  • Sprint planning, AM: 1–2 hours
  • Sketching: 6 hours

Day 2

  • Stand up sketch review, AM: 30 minutes
  • Prototyping wireframes: 7 hours
  • Visual design exploration: 7 hours

Day 3

  • Stand up, AM: 15 minutes
  • Prototyping wireframes: 7 hours
  • Visual design templates: 7 hours

Day 4

  • Stand up, AM: 15 minutes
  • Prototyping wireframes: 7 hours
  • Visual design templates: 7 hours

Day 5

  • Sprint Review, AM: 2 hours
  • Prototype amends: 7 hours
  • Visual design templates: 7 hours
  • Retro: 30 minutes

Caveats to making SCRUX a success

SCRUX isn't for everyone so make sure you consider the following before attempting to follow this method.

  • Stakeholder buy-in: You need to convince the client this is the right way to do things in the first place, which means you can't promise specific pages and templates up front because the deliverable will evolve. However, you will deliver the best possible product, on time and on budget.
  • Sticking to the process: Stakeholders need to attend sprint planning, stand ups, and reviews, or you won't receive the inputs and decisions you need.
  • Centralised decision makers: It's very difficult to work if you have lots of external stakeholders to the process. If it has to go through layers of sign-off and approval every sprint, you will never get anywhere.
  • Specialist knowledge: You should work out a few weeks in advance if you are tackling a section of the delivery that requires a specialist so you can ensure they attend relevant meetings.