Online Bookings – Temporarily Unavailable
Please note that our online booking option is temporarily unavailable. To book your place on any of our upcoming course dates, please contact our friendly team on 0207 796 9903 / enquiries@agil8.com.

Menu

Anyone who’s worked in the Agile field for any length of time will be familiar with the Scrum term, “Sprint” and many of you will also be aware of the Scaled Agile Framework – SAFe.

Where most Agile methods focus on the working of a single team, SAFe, as the name implies, is a framework used by large organisations that want to follow Agile principles but have many teams working on the same products.

A question I’ve been asked several times now is, “What about Design Sprints? How do they relate to Scrum Sprints and how do they fit into Scrum and/or SAFe?”

The Rationale for Design Sprints

Let’s start by looking at the rationale for Design Sprints. One of the basic premises of Agile at any level is that we should work in short cycles, build the simplest possible thing that works and add further functionality based on feedback from real users. Scrum is a good example of this, where teams work in cycles called Sprints with the objective of producing a new Product Increment at the end of each. Nowadays we tend to use terminology from the Lean Start Up (LSU) camp and we talk about the Build, Measure, Learn (BML) cycle, which does exactly what it says on the tin.

However, we still have the problem of knowing whether or not we are building the right thing. Scrum Sprints are short, typically two weeks, but it may take several Sprints before we can build enough of the product for the customer to be able to give us feedback on. This can represent a significant investment, a lot lower than that required by traditional methods, but it still costs a considerable amount of money to fund even a single team for, say, three Sprints – six weeks.

Enter the Design Sprint. Design Sprints are a relatively new idea. Originating at Google around 2010, they differ from Scrum Sprints in that the objective is not to produce a fully working Product Increment but to design, build and test a prototype that can be evaluated by customers to give us feedback as to whether or not we should even start building the product for real. Unlike Scrum Sprints, Design Sprints are intended to give us feedback to inform our investment decisions in a single week, thereby reducing the cost of learning and the probability of failure.

Design Sprints: Scrum

Agil8 Blog: Hippo & Squeaky WheelThe Design Sprint uses Design Thinking techniques to first define the problem to focus on, before exploring different solution ideas. Later, those ideas are refined into a testable hypothesis, which is used to produce a realistic prototype that can be evaluated by real users. All of this in five working days. The problem is, of course, where do we get the five days from?

Scrum teams are familiar with the concept of Product Backlog Refinement, and Design Sprints could well be classified as such. The Scrum Guide allows the build team to spend as much as 10% of their capacity on these activities. However, the Scrum Guide also says that Scrum Sprints should be of consistent duration and back-to-back, with no gaps between them. It is difficult to see where a Design Sprint would fit.

This is where I step slightly outside of Scrum and borrow a technique from eXtreme Programming, as we so often do. Sprint Zero, or Iteration Zero as the XP folks would call it, is a period of work undertaken to get things prepared before the team’s Sprints start in earnest. Sprint Zero, doesn’t produce any end-user product but having a Design Sprint as an activity within it would certainly reduce the risk of failure and help to create a well-formed Product Backlog. You can read more about Sprint Zero here.

Design Sprints: SAFe

It seems that having a Design Sprint as part of the Sprint Zero activities is a good fit for Scrum people but what about SAFe?

SAFe has a cadence of five iterations called a Program Increment or PI. These PIs are back-to-back with no gaps and with no gaps between the iterations within them either so, again, we have the problem of where to fit the Design Sprint.

Fortunately, the originators of SAFe have already made allowances for these things, and have designated the final iteration in every PI as the Innovation and Planning (IP) iteration. They acknowledge that planning the next PI will take up some of the last iteration’s capacity, and that there may be unfinished work from the previous iterations and general tidying up to be done. They know that innovation is key to success and so here is probably the best place to slot in your Design Sprint, if you’re going to have one. It looks like Design Sprints fit nicely into SAFe too.

Big upfront design is an anathema to Agilists, but Design Sprints allow all those involved in the product to collaborate in early fast-feedback activities at very small cost – and there are opportunities to fit a Design Sprint in whether you’re doing Scrum with a single team or practising scaled agile with SAFe.


To learn more about Scrum and/or SAFe then please do join us for one our upcoming certified courses.

More information, including dates can be found here.