How to apply a SCRUM inspired agile process to UX design

by Jack Josephy on 18 April 2016

UX design-based projects can vary in scale and process. A product development process typically is either 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 Webcredible 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 are 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 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, which we cover a full day course on. 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 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

Roles

The 3 key roles 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 1 or more UX designers, 1 or more visual designers and 1 or more UX researchers

Sprints

A 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.

As a UX design project, you will probably have user 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 3 users. It's 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. Axure wireframes, 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.png

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.

A 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 & Work

There are 4 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 1 minute update on their progress yesterday and their plan for the day. They also raise any blockers, which the SCRUX Master can address outside of 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 discuss 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 they are closely aligned. For some projects we may involve a front end developer to build a front end responsive prototype.

What does a typical 5 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 - 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.

Want to find out more? Check out our Lean UX course or get in touch with us to find out more around running an Agile UX project.

Kwaku Ampomah says 04:47am 01 Jun 2016

As an experienced Scrum Master and Coach I have been advocating for UX to be an integral part of the process and starting right at the begin so as to inform the whole proces. I have beend advocating that UX and POs should be working together to drive the whole process. As such I would like to learn all about SCRUX. How do i do this?

Tim Daines says 03:18pm 09 Jun 2016

Thanks for the article Jack. Where I am at the moment, we have fallen into a Lean UX way of thinking based on decision makers being spread too far away and deadlines impacting on time constraints. We've refined our Lean UX process though and applied Sprint in 5 days. This has helped to quickly pull together the team and develop user stories that can be wireframed and then prototyped by our developers (we have the luxury of developers building in a test environment and the real enivornment.) http://www.gv.com/sprint It's working so far with UX, and the collaboration with developers has changed their way of thinking about user needs. POs are slowly come around to the idea this is making work more efficient and we are delivering what we say we can deliver to our brand clients. Here are some stories that could also be useful - https://sprintstories.com/ Thanks for the article again.

Thank you for your comment. It has been submitted for approval.

Comment Again?

Leave a comment

Please enter your name.
Sorry, this email address is not valid.
Please enter your comment.

Course basket x

Course

Price per place

Add another courseCheckout

Pay now by credit card or later by invoice (invoice payments only possible if all courses are 3+ weeks in advance)