(Part 2 of this post can be found here.)
Despite having co-written an award-winning book on the topic and lecturing, teaching and coaching on the topic for nearly 10 years now, I still get 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 organisations 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. Those experiences are captured in my writings, books, and classes. Recently, I’ve had the pleasure of working, along with my co-author Josh Seiden, with some smart, progressive members of the Agile and Scrum communities. Together we’ve been working to build a framework that spells out — step by step — how Scrum and UX design integrate. One exercise we did individually was to 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.
Interested in learning more?
Our new self-paced course on Lean UX teaches explicitly how to solve the challenges of UX, scrum and agile. Learn more here.
I’ve numbered each grouping of UX activities. 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.
[Make sure you check out the new self-paced courses on OKRs and Lean UX now available]
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.
What do you think? What did I get right? What did I miss or forget? How would you do/have you done it differently?
I’d love to know.
[Jeff]
@jboogie
www.senseandrespondpress.com
jeff@gothelf.co
Interested in learning more?
Sign up for our new Lean UX self-paced course which tackles the challenges of scrum and ux head on.
