How do you incorporate a Design Sprint in Scrum?

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 

How do you incorporate a Design Sprint in Scrum?

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:

1. Activities that need to be completed inside of the Sprint, targeting the work towards the current Sprint GoalThis is the work that every Team Member needs to contribute during the Sprint to meet the Sprint Goal. While there are no specialisms there will always be team members that have more skills to bring to bear on that particular activity. The Development Team should learn to leverage those skills to build a better product. So if we need to rework an interaction or come up with a new interaction that we did not know that we needed, then we can do this work in Sprint.
2. Activities that pertain to work that will be delivered in future SprintsWork that is for the future in Scrum is called Refinement and it happens constantly throughout the Sprint. While we want to minimise it as work don’t for something too far in the future that it never makes it to the top of the backlog is waste. We need to balance that with the need to have all the bits in place just in time for the activity for the Sprint Goal to be completed. So if we require to have a UX strategy developed and tested with real users that included Prototyping then that work needs to be done early. Don’t be afraid to build something as right as you can, given the information you have, and iterate as you get real users telemetry.

All that work that is UX falls into 2 categories:

1. UX activities that are done inside of the Sprint for the current activities of the Sprint. This is Development Team work with UX included in that definition.
2. UX Activities that pertain to work coming up in future sprints. This is Refinement work and is done as needed and should include the entire Scrum Team as required.

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.