Handover Day

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

“The Design Sprint is great, but…”

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 Handover Day.

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

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

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.

Activity: The facilitator leads the group in creating the Epics. There might be 5, but there could be 15. See how far you can get in 15 minutes.

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

2. Complexity versus Impact

Activity: Using a graph, we can start to size them up, based on what the team understand. Playing a game of “higher” or “lower”, we can start positioning them. This activity may take 30 minutes.

Complexity versus Impact plotting

3. Note Technical Considerations

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?

Activity: Put 15–30 minutes on the clock and start collecting questions that the tech-team would need to answer.

Notes to investigate after Handover Day

4. Highlight Risks and Assumptions

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

Consider:

  • 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)

Activity: To understand risks and assumption, use the sailboat exercise. Take 45 minutes to do this

The Sailboat exercise

5. Create User Stories for the Epics

The format for a user story is:

As a [who], I want to [goal], so that [reason].

Examples can include:

  • as a user, I want to create a Amazon wish-list, so that I can send to friends and get what I actually want for my birthday
  • as a bicycle user, I want to find an impenetrable bike lock, so that no one can steal my new bike!

Activity: Divide and conquer! Split into small teams of 2 or 3 and start writing out user stories. Remember to think from a customer perspective. Depending on your product/service, this could take 30–60 minutes.

An Epic with user stories underneath to describe functionality

6. Prioritise User Stories

Activity: Again, divide and conquer to get through a large list. Assign MVP, Phase 1 or Phase 2. Spend 15 minutes or so on this activity.

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

Outcomes

  • 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.

Remote Design Sprint Facilitator and Product Strategist based in the UK