UX design in an Agile world

When I first joined my current scrum team I had very little experience in working Agile. My work history included mainly short term agency projects and remote freelance work. I didn’t know how developers worked, how scrum teams form and the importance of sprints.

First impression? Every scrum is different. The relationships between the team members depends on the project, the sprints duration and most importantly, the team members. When I first joined my team, UX was part of the recurring 2 week sprints. Each sprint the product owner would task discovery or design pieces, the team would score accordingly and the junior UXer and myself would complete them. I very soon found this process limiting: some discovery pieces required a research period much grater than our 2 weeks sprints; the pointing system proved nearly impossible as it was difficult to estimate how much work a task would take with no previous knowledge or research; and most importantly, there wasn’t much forward thinking or a clear direction the product was driving towards.

So first step was to take UX (and some UI) out of the sprint planning. Just to be clear, I still get tasks like ‘Fix this feature’ or ‘Sketch that flow’, but those are now rare and we no longer point them. Instead, I now work closely with our product owner. We have our yearly objectives set, within each we list ideas for things to test or research. The product owner highlights what he would like to test first and I organise my work accordingly. This means I know what I’m going to be working on for at least the next 3 months. Naturally there will be some emergencies here and there creeping in or other UX projects not directly related to the site such as re-evaluate our personas, but I can plan for these easily now. We also recap every few months to make sure our objectives are still relevant.

Ironically, now that I am ‘out’ of the sprints I have to make sure I am still involved with the team. This means working much closer with them and keeping them involved with my work. One way is the morning stand ups, where we share what each of us is working on. The other is project depending. I will usually sketched rough wireframes or flows and show them to the relevant team members, asking for critique. Showing sketches early on is the best tool to get quick feedback on technical limitations or raise critical questions. Here’s a little tip for you, developers are the best people to raise ‘what if’ questions or even suggest a solution you didn’t consider, so go ask them!

After few rounds of iteration following team feedback, I will design more high fidelity wireframes, or even a tested prototype. By now I’ve addressed the main concerns back end and data base may have raised and I work closer with our UI and front end. We will go into another round of design iterations. This will focus more on the look and feel, highlighting key points as well as functionality that is consistent with the rest of the site. Sometimes they will suggest a complete different way of displaying content or interaction idea which works beautifully with what the goal was and we change the designs drastically. The bottom line is, we work together, we test ideas and we keep our egos out of the process.

Once the designs are finalised they go into implementation. Usually the product owner would task them and placed them in future sprints. This gives the developers visibility to upcoming work prior sprint planning and they can add or suggest more work if needed. My part is usually done by now and I carry on with the next piece of research or design. I am still part of the sprint reviews and planning. As I mentioned before we still have some UX tasks during sprints and I also like to know what the team is working on.

The key benefits I see in this process are these: I have control of my time frame, I can work on indirect projects and plan ahead for user testing and interviews; The team is all involved with the work, which means we care more and when you care more you try harder. I know this process isn’t suitable for every team or project and who knows, we might have to change it ourselves in the future. But for now, it works for us and I thought I’d share it.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.