Design and UX Integration in Scrum Sprints
Answers common questions about integrating design and UX work into Scrum Sprints, clarifying why dedicated Design Sprints aren’t needed and how to …
TL;DR; Design Sprints should not be treated as separate or special sprints in Scrum; instead, design and UX work should be integrated into regular sprints as part of the team’s ongoing activities or handled during backlog refinement for future work. All team members should collaborate on these tasks, leveraging individual skills without creating silos or specialist-only phases. Development managers should ensure design activities are visible, collaborative, and aligned with sprint goals, using communities of practice to share knowledge across teams.
As part of the Scrum .org webinar “Ask a Professional Scrum Trainer - Martin Hinshelwood - Answering Your Most Pressing Scrum Questions” I was asked a number of questions. Since not only was I on the spot and live, I thought that I should answer each question that was asked again here, as well as those questions I did not get to.
In case you missed it, here is the recording of yesterday’s Ask a Professional Scrum Trainer webinar with Martin Hinshelwood! Watch here: http://ow.ly/ijiM50vwEkD
There are no special sprints; No Sprint 0, no release sprints, no hardening sprints, and absolutely no design sprints. The teachings of Frederik Winston Taylor lead to a successful Industrial Revolution but are inadequate today for leading knowledge workers solving creative problems. The notion that we need specialist teams of Coders, Testers, Operations, Architects, or UX is founded in those ideas and needs rejecting. As such, the idea that you would need a special Sprint to gain some specialist outcome is also founded in these ideas and is antagonistic to the desired outcome of high-quality working software .
All work from Development Team members that seem to fall into a specialisation (e.g. UX) is all done in one of two places:
All that work that is UX falls into 2 categories:
Ultimately no work should be done in a vacuum or away from the scrutiny of the entire team involved in the work. At scale, it makes sense that one of the activities required of the UX Community of Practice is to get the right people together to work on creating reusable and consistent interactions as part of a framework that can then be used as part of a products DoD. This group should not be dedicated and should be made up of representatives from all of the teams to make sure that the information disseminates at Scale.
Linking Team of Teams and Communities of Practice are critical for incorporating all of the skills required to build awesome software.
While there are no right answers there are some answers that are better than others. For your given situation select the most right answer and iteration to the best version of it.
Each classification [Concepts, Categories, & Tags] was assigned using AI-powered semantic analysis and scored across relevance, depth, and alignment. Final decisions? Still human. Always traceable. Hover to see how it applies.
If you've made it this far, it's worth connecting with our principal consultant and coach, Martin Hinshelwood, for a 30-minute 'ask me anything' call.
We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.
Milliman
Trayport
ProgramUtvikling
DFDS
Cognizant Microsoft Business Group (MBG)
Workday
NIT A/S
Boeing
Hubtel Ghana
Lean SA
Epic Games
Jack Links
Alignment Healthcare
Bistech
Emerson Process Management
Big Data for Humans
Healthgrades
Kongsberg Maritime
Washington Department of Transport
Nottingham County Council
Ghana Police Service
Royal Air Force
Washington Department of Enterprise Services
Department of Work and Pensions (UK)
Cognizant Microsoft Business Group (MBG)
Healthgrades
Ericson
New Signature
Teleplan
Jack Links