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.
The 3 key roles are:
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.
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.
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?
There are 4 key types of meeting:
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.
SCRUX isn't for everyone so make sure you consider the following before attempting to follow this method.