Handover day
Finish your design sprint with exactly what production teams need to move into build.
The lesser-known final day of the Design Sprint (where dreams become reality!)
“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, I 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
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.
So here’s what the plan for Handover Day looked like:
- list the Epics
- complexity versus impact
- note technical considerations
- highlight risks and assumptions
- create user stories for the epics
- 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.
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.
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?
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.
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?
Activity: Put 15–30 minutes on the clock and start collecting questions that the tech-team would need to answer.
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!
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
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 [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.
6. Prioritise user stories
Then it’s a case of prioritising 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.
Outcomes
Having completed Handover Day, you now have:
- a list of prioritised Epics
- questions about the technicalities of building the solution
- prioritised user stories
- all within 1 day!
I'll perfect this recipe over the next few Design Sprints, but I think it’s a good start to that all-important hand over to make product ideas — a reality!
