Tips on how UX can become Agile by using Scrum

Scrum is the most popular of Agile methods, and there’s a good reason — it’s simple to understand. In its simplicity, though, lies some of its inherent problems in adoption. Many people, myself included, look at it and wonder where the up-front planning we’re used to doing on projects goes? UX Practitioners look at it and ask, “where does design fit into the process”. Most of these misconceptions result in assuming that additional, separate parallel processes are required, but they’re not, and here’s why.

The Scrum process

1. There is only one Team

Scrum focusses on small teams of around 5 people, and has very few roles:

• Product Owner — Typically the Client, the one who pays the bills, etc.
• The Team — The people with the right set of skills to do the work filled by the right skills to get the job done.
• The Scrum Master — The guy who owns the Way of Working and protects the Team from things that get in the way of their work (even the client)

Given Scrum is based on the Deming Cycle, the underlying philosophy is that the Team is multi-disciplinary. If you go way back to Scrum’s initial ideas borrowed from the New New Product Development Game by Hirotaka Takeuchi and Ikujiro Nonaka they reinforce the need for the team to be multidisciplinary to do well and improve. They even make an anecdote where a group of engineers are asked to learn electronics so they can make a better product. Austin makes a number of comments to this point in his blog, suggests that agile teams should have some level of design literacy.

Overall, these elements reinforce that there should not be separate teams working on separate streams of work. Scrum reinforces the need to work on the same piece of product at the same time and to collaborate toward a single outcome. This means that the UX practitioner must work WITH the developers and the developers WITH their UX specialist.

5 people per team is optimal, although I’ve coached Scrum teams of 3-20.

2. The backlog doesn’t create itself — it comes from the business case

Good [user] research has already gone into the solution that got the funding in the first place. This is where ROI was determined that got the project started.  This means you don’t need a Sprint Zero to create a new user-centric vision. If user experience was important to the project it would have been in the business case.

If there’s no business case (which happened in the case study I used at Agile 2011) then Sprint Zero becomes very important, and typically, this is the only time I use Sprint Zero.  Light-weight, user research, data-driven Personas, and user workshops become critical to creating the backlog of functionality and products required of the project. Not everything has to be articulated in detail. The parts of the project that seem to make sense to start with are likely the right ones, so these require greater description, greater detail, and more work on the part of the Team’s IAs and BAs to create the start of the project’s Vision.

This is not to say, though, that good UX principles can’t help to refine the vision as the project evolves. This effort becomes part of grooming the backlog.

3. 10% of the Sprint is planning — this means UX as well

Each Sprint starts by looking at the products the Product Owner wants created and turning them into tasks. In this process, the Team spends quite a while understanding the needs of the Product Owner  and coming up with ways to deliver them. I use data-driven Personas from sources like Forrester, Nielson and the Australian Bureau of Statistics to create a very ‘skinny’ Persona with just enough user information to give the Team an idea who they’re building product for, their needs, wants, capabilities and  attitudes. Armed with this information (it takes about 30 mins to generate a half dozen Personas this way and I often recycle old Personas from similar projects which cuts down the time even further) this documentation helps create a shared understanding within the Team so they can start to plan together.

4. UX-needs should influence the Done criteria

During Sprint Planning, the Product Owner creates a list that will be used to review and sign-off on the products they want. The Team should help to influence what this criteria looks like. A good definition of Done will include things like:

• How the Team will make the product accessible — e.g. it must adhere to WAI Level Double-A
• That functionality is traceable to user’s needs and the context of use
• Products developed need to work well across mobile, tablet and PC

At the end of the day, however, the Product Owner’s job  is to ensure the value he wants to get out of the product is realised by the end of the Sprint. If they value a good user-experience, then remind them to articulate what that looks like and to put it into Done criteria.

5. Groom the backlog with UX goodness

The backlog is continually refined throughout a Sprint by the Team. New pieces of the puzzle that will help bring clarity to future work always emerge from a project from all members of the Team — the designers, the BAs and the developers. As new information about users emerges from workshops, research and analysis, the elements of the backlog become more and more fine-grained.

6. Development and testing is ongoing, so why not UX workshops and testing!

Good agile teams do continuous testing and continuous integration of their code. UX should work in this way also, feeding in new information from a few hours of workshops every Sprint or so to answer questions to the users’ requirements of code bring produced in that same Sprint. As more and more Sprints are completed, I need fewer workshops to understand how users think and their context of use.

7. Pair Programming

Developers use this technique so that two people can share the cognitive load of cutting code. The same technique though can be used for collaborative purposes between UXers and BAs to create a solution or define requirements together, or even pairing between the UXers and Developers to take the light-weight paper prototypes or quick whiteboard or Axure wireframes and turn them into working code. It’s a great collaborative process, awesome for increasing other team member’s design literacy, and produces interaction designs and experiences that are far better than could be created on their own.

.

This is all by no means a definitive list of Scrum + UX tips, but its a good place to start when you’re trying out Scrum for the first time. Importantly, in the same way that a professional athlete has a coach to become better, you’ll likely need a Scrum Coach to help everyone pick up these ways of working. That, in itself, though, is likely another post.

M

Advertisement