There are many questions — mostly from product managers, executive leaders, and technical managers — on how to integrate UX and Design into the scrum process. It’s a challenge that continues to plague most organizations mainly because the reason scrum was brought in was not to do more thoughtful, customer-centric work but rather to ship more code faster.
I have worked first-hand on and with teams that have bested this challenge.
Overlay UX and Design activities on top of a well-founded model of scrum. The diagram below is my attempt at that exercise.
As you review it, please note the following caveats:
- This is by no means a comprehensive listing of design activities. There aren’t enough post-its in the world to cover that. 🙂
- I use the word Design (often with a capital D) to serve as an umbrella term for all activities that designers of all kinds normally do or take part in
- I am not particularly interested in plumbing the bottomless depths of defining “Design”, “UX” et al. Please reserve that conversation for another thread.
I’ve numbered each grouping of UX activities in the image above. Following are the brief descriptions and my rationale for each grouping.
- The product backlog contains the pieces of the broader vision that are not going to be worked on in the current sprint. High-level items, vision, and many assumptions live here. To inform the product backlog, activities like Design Sprints, Research (qualitative, all types) and hypothesis writing help inject both reality and a customer-centric focus to these items.
- Sprint planning is the day-to-day level planning effort for the team. Questions like “What will it look like?”, “How will the product flow from screen to screen?”, “What are the exceptions we’ll need to deal with?” can be answered with design tools like Collaborative Sketching (aka “Design studios”, “charettes” etc) and other group brainstorming activities that UX designers are particularly good at facilitating.
- The tactical Design work (capital D to serve as an umbrella for the various facets of product design) has to go into the tactical backlog — the sprint backlog — and is then executed by designers, primarily, but also in collaboration with the rest of the scrum team. The key is to prioritise this work in a way that allows all team members to work in parallel.
- Critically missing from the core scrum team, and necessary for the integration of UX design, is a full-time designer on the team. The only way the tactics in #3 can happen in parallel collaboration with developers, product managers, and scrum masters is if there is a full-time designer on the team.
- Sprint review is an opportunity to take a look, together as a team, at the output the team generated during the sprint. This is also an opportunity to review what we’ve learned during the sprint (aka the outcomes). Activities like design reviews, discussion, and debate of research synthesis and quantitative analysis inform the work we’re considering pushing live and help us focus our next round of both product and sprint backlog prioritisation.
It’s critical to point out that none of this can happen without a dedicated designer assigned to the scrum team. It’s their presence that ensures the relevant activities are proposed, prioritised and executed. If the design work is outsourced to a designer outside of the team (regardless if that designer is in-house or not) then the team finds itself back in the “Big Design Up Front” style of working also known as waterfall or the “sprint ahead” method — all of which reduce collaboration, shared understanding and trust between team members.
You might also be interested in my self-paced course on Objectives & Key Results
OKR’s have become the foundation for organizational agility. When done right, teams focus on the customer, collect evidence and change course as they learn. In short, they become agile.