Sprint

TL;DR

The five day plan to get to a user tested prototype is designed to speed up the idea and iteration process, focusing on verifying the idea as quick as possible instead of spending a long time developing a proposed solution only to find out it doesn’t work in the end. The sprint plan is also supposed to bring the whole team together, to take advantage of the collective knowledge of all your team members.

Summary

The Idea

The five day sprint is supposed to help achieve a goal in a short period of time. To do so, there are several rules that try to help with that. For me, the most interesting are the following (there are more, but these are the core ones that stuck in my mind, and which I think are also to some extend applicable and useful outside of the five day sprint structure):

Deadline

The tight deadline of five days eliminates procrastination. The time has to be used wisely. Each day therefore has a specific purpose, which makes it easy to keep track of the progress and step in and adjust things if milestones are not hit.

Experts

To solve the problem or find the right product or solution to develop, consolidate the real experts: the members of your team that are trained in the subject in question. The sprint and solution should be driven by the (selected) team, not by e.g. the manager or product owner. They should still be included, but mainly to facilitate and make sure the timelines are met. You have experts in all areas in your teams, use that knowledge.

Keep notes

Write everything down, keep notes of all ideas, decisions, etc. In a fast paced sprint of five days it’s easy to get overwhelmed by the amount of ideas and information flying around, and it’s crucial to keep track of it and to be aware of the status quo at any given time.

Get a timer

Since five days is a really short timeframe, it’s crucial to cut discussions and brainstorming sessions to a set time. This is one of the main tasks of the facilitator, to make sure these timefames are not streched out, to ensure the goal can still be hit at the end and the whole task doesn’t go off the tracks.

Outcome focus

The focus should be on a clear testable outcome, usually a prototype. The whole five days are the reverse engineered plan to get to that outcome. After all, the whole point of the five day sprint is to get to a proof (or disproof) of a hypothesis or proposed solution/product in the shortest possible amount of time. So that should always be the goal in the back of your head.

Everyone gets involved, but democracy wins

The idea is to get everyone involved in the brainstorming proecss to find the right solution/ideas. But once the plan is made, it is important that everyone gets on board to try to get to the proposed prototype by the end of the five days, even if it’s not your idea or plan that got picked.

Be prepared

The sprint itself will be pretty packed with action. So make sure you have everything prepared and in place to do the work. Check your supplies, make sure you got facilities organised and everyone who’s going to be involved has their time blocked to be able to work on the sprint with as little outside distractions as possible.

Five days plan

The book proposes a very strict plan for the five days of the sprint. These are nicely summarized here, but to collect the core ideas here as well:

Day 1

The goal for Monday is to define a clear plan and outcome (i.e. prototype) for the rest of the week. Start with the finish line, what is the long term goal? What are you generally trying to achieve? Then, map out the challenge. What does the adventure look like to get there? Finally, pick an abitious but achievable goal for the week, that let’s you test your hypothesis of the long term goal and the pathway you defined before.

Again, it is important to get all experts involved that can relate to the problem space. Take advantage of the collective knowledge of your team, don’t just assume whatever your manager wants is matching the customer/real world needs.

Day 2

Tuesday is all about the goal. Start with collecting ideas, existing solutions and thoughts on improving them, etc. Then each person involved tries to sketch out the final plan. Discussing these proposals, the goal of the second day should be to have a clear definition for the user testing session and the expectations from that on Friday.

Day 3

Wednesday is for the decision making. With all the ideas and possible solutions you collected with the help of your team in the first two days, you now need to lock yourself down to one of them. The first half of the day should be spend on picking the most promising proposal keeping in mind the defined long term goal. The second half of the day can then be used to create a storyboard for that solution/idea, basically a step by step plan for the prototype.

Day 4

Thursday is the day you actually build that prototype. Keep in mind, this doesn’t need to be a fully functional solution. Your goal is the prototype and the user testing session on Friday to get quick feedback whether or not the hypothesis was correct. That being said, think about where you can get away wth just buildng facades, faking actual functionality to just give the the user the experience of the end solution without having to build it in all its details.

Day 5

On Friday, the day is spent with the user testing of the prototype. Make sure you keep records and notes of all these sessions to be able to analyse everything afterwards. Don’t be afraid to be honest and call the hypothesis disproven if the user testing indicates this. It is still a successful outcome of your sprint, you learned something meaningful and didn’t waste a lot of time to get to that information.