Handover Day

The lesser-known final day of the Design Sprint (where dreams become reality!)

Ross Chapman
Sep 9, 2019 · 5 min read

“The Design Sprint is great, but…”

One of the most common issues I hear time and time again comes from teams after the Design Sprint.

Teams will say something similar to:

“The Design Sprint is great, but we don’t have everything we need to continue the good work and put into production”

The thing is, the problem isn’t really with the Design Sprint. It’s with the time after the Sprint that teams can often lose momentum and lose direction.

In a recent Design Sprint, we aimed to solve that problem with what I’m calling .

We had a couple of tech leads help us understand what they needed to move this Design Sprint into production, so I thought I’d share the method here in case others also wanted to supercharge their Design Sprint and finish with exactly what production teams need to move into build.

The key ingredients to Handover Day

Handover Day doesn’t have to be its own specific day. It’s just a few hours, but I’d suggest it needs to be near the Sprint so that the team are still in the problem space and can contribute well.

For this to work, it’s important to have either a Solutions Architect or Tech Lead to help the team with what’s possible tech-wise and raise potential complexity with solutions.

A recent Design Sprint Bootcamp in London, UK

So here’s what the plan for Handover Day looked like:

  1. List the Epics
  2. Complexity versus Impact
  3. Note Technical Considerations
  4. Highlight Risks and Assumptions
  5. Create User Stories for the Epics
  6. Prioritise User Stories

1. List the Epics

From your Map, you need to work out what Epics this product/service has. What’s an Epic?

An Epic can be defined as a big chunk of work that has one common objective.

An example could be “Notifications” or “User Management.” Think of it like a function that might cover a number of areas or a specific area of your product/service.

I used Mural to create this illustration — and you can use Mural to organise your Handover Day! Neato!

2. Complexity versus Impact

Now that we have the Epics, we need to prioritise them. What is easy to complete and has the highest impact? What is a little more complex, but won’t be needed early on?

Complexity versus Impact plotting

3. Note Technical Considerations

What questions do we have about the technology? For some unknowns, you can list down on single post-its what technical considerations we may have.

If you have tech-leads in this session, they may find drawing a technical drawing useful to expose areas that may need defining in respect of the product/service you’re creating. This can help lead the activity. What assumptions need validating?

Notes to investigate after Handover Day

4. Highlight Risks and Assumptions

What are the biggest risks and what assumptions do we need to validate? Here, we can use the sailboat exercise to help us understand risks and assumptions.

It may seem weird at first (I mean.. Sailboats), but go with it for now — Agile peeps love it!


  • who can help us (a motivated team)
  • what could sink us (running out of funding)
  • what could pull us back (other teams not knowing about our project)

The Sailboat exercise

5. Create User Stories for the Epics

Now that we have our Epics, most production teams like to work from user stories to help guide functionality, but most importantly, it’s from a customer perspective.

The format for a user story is:

As a [], I want to [], so that [].

Examples can include:

  • as a , I want to , so that
  • as a , I want to so that

An Epic with user stories underneath to describe functionality

6. Prioritise User Stories

Then it’s a case of prioritising stories.

User stories can then be prioritised to Minimum Viable Product, Phase 1 etc.


Having completed , you now have:

  • a list of prioritised Epics
  • questions about the technicalities of building the solution
  • prioritised user stories
  • all within 1 day!

We’ll perfect this recipe over the next few Design Sprints, but we think it’s a good start to that all-important hand over to make product ideas — a reality!

Like this and want more?

Ross Chapman is the Head of Etch Sprints in London, UK.

He has run an extensive range of Design Sprints with product teams and brands to solve business problems within four days, getting teams working faster and better together.


Stories about Etch Sprints

Ross Chapman

Written by

Product designer and facilitator at Etch Sprints


Stories about Etch Sprints

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade