How a 5-days sprint works
I’ve just finished my reading on Sprint, a book from Google Ventures, and really enjoyed it. Needless to say, it is a very well-written ‘How-to’ book. You will learn to solve big problems in just 5 days of work, like launching a new product, or making a new feature, or simply a school project. The main point is, this strategy saves us from wasting time into something which may not worth the effort in the long run. It answers the legendary question which thousands of startups got headache dealing with nowadays: “Will there be customers using my product/service?”
If you got the same question, then 5-days sprint may be your big interest. So here it is.
Typical work in 5-days sprint
All works throughout the week can be summed up like this
- Monday: Map out problems and pick the most important one that you want to solve by the end of the week
- Tuesday: sketch multiple solutions on paper
- Wednesday: Make decision on the best solution & turn into testable hypothesis
- Thursday: Build a prototype
- Friday: Test it with real users through interview
Does it make sense?
Why 5 days? How about:
- Longer period? Like two-week sprint? Probably work, but it wouldn’t be as effective as 5-days span. Why? Because of the weekend. Weekends causes a loss of continuity. You more likely tend to move work that supposed to be done on Friday to Monday next week.
- Shorter period: maybe not enough to build and test a prototype. You will be exhausting to achieve them all. You also have a life out of work, right?
The magic number 5 also applies when you conduct the interview on Friday. There should be at most 5 people. Why? Again, having five conversations with your interviewers are good enough to spot the problem pattern with your product. A research about usability testing which has been conducted by Nielsen proves that, most of the time, insight is revealed after asking just 5 people. That said, why spend more time and effort, while the result is the same?
Nonetheless, 5 days still sound unrealistic. I also had that thinking in the first place. However, in the book, Jake (the author) has actually made a very clear argument that it is practically feasible, given a handful of project teams that already applied this framework successfully in real life. So I was kinda convinced. There are dozens of tips and suggestions listed in the book, but I think the following ones are key points. Taking care of them carefully can help you get the most out of the sprint’s outcomes.
Set a deadline.
I mean real deadline. The intention is to commit yourself with the sprint’s goal. I know it sounds easy to do, but in practice, rarely anyone can stick to their target. It’s all about psychology, it’s all about you. If you can trick your mind, things will be easily achieved. A few approaches that you can follow:
- Share the deadline with others: especially, if you are on an individual project, it works most of the time. Because it forces you to complete the goal on time, so you don’t feel ashamed with anybody whom you share the deadline with, thinking of you as a always-promise guy.
- Show the outcomes : again, this will tie you to the work that you committed in the first place. In software development, it’s typically the demo session by the end of each sprint, in which the users/clients can see what feature or change has been done during the period. With high-stake circumstances where big money is pouring in, the pressure was even more significant to encourage you to complete the work.
- Trade off: This idea was not mentioned in the book. I just made it up, but I think it works. Just make a bet or something like that to get yourself attached to the goal you want to achieve. For instance, you can give your little sister $20 with a commitment of completing your school assignment before weekend. Your sister will play as a ‘guard’ to protect you from procrastination. If successful, you will finish the assignment on time and get $20 back. Otherwise, your sister would have a cup Starbucks each morning next week. Either way, it’s still good for you…just kidding.
There will be a lot of times during the sprint that you will get stuck around dozens of ideas and solutions from the brainstorming. Options are good, but too many of them is a burden. There is always disagreement in group discussion, which leads to endless meeting and emails that probably drains your brain. The hardest part is then to determine which solution the team should make prototype and test. Given the limit of 5 days, you must handle this situation appropriately:
Heat Map Vote — Just give each of your team member a dot sticker, and let them vote on the idea that they like the most. Yes, democracy makes people feel good, cause it ensures they will be heard. After this, your whiteboard will look something like a heat map, where you can easily identify the most compelling idea, like this:
Decider — Sometimes democracy doesn’t work, that’s when the Decider should chime in. It’s a person who has the ultimate decision-making authority, usually the CEO, Product Manager, Head of Design or Team Lead. Typically, she has more votes (which is called Supervote) than anybody in the sprint team, and whatever she votes for is what your team will prototype and test
Nonetheless, doing all of this does not absolutely ensure that the idea is right. Sometimes the Decider can get it wrong, making the Prototype is wrong too. But it doesn’t matter. Looking at the bright side, you lose only one week to find out the idea doesn’t work, rather than spending years later to define the correct formula. It’s worth the effort, isn’t it?
IMHO, this is the most important person during the sprint. Like the name, he will do anything to bring the most out of the meeting. I realized this role shares many things in common with the Scrum Master in an Agile team. I suspect they are the same, just different in term usage. In his book, Jake outlines activities that a Facilitator should do:
- Ask for permission: nobody wants to be ordered or listen to somebody they don’t want to. More than usual, you need to interrupt when someone else’s speaking so the meeting can finish on time. That said, you’d better ask for their permission up front, by simply saying something like this: “I’m going to facilitate the meeting and keep track of time and process, so you guys don’t have to. Sounds okay?”. Perhaps not all would say yes, but the trick is you already gave them the chance to object (which they likely won’t), so they need to respect the rule.
- Always capture then move on: the team will give out dozen of ideas while brainstorming and your job is to record key ideas on the whiteboard. Asking questions like, “Is my understanding correct to write like this”, or “How should I capture that?”. When the conversation seems going nowhere, you need to summarize it again by, for example, “Is there any way we can note it here and move on?”
- Ask obvious question: no question is dumb, unless you don’t ask. Although the question already has answer known by everybody, asking it ensures there’s no misinterpretation, and sometimes key insights emerge from it.
- Take frequent breaks: this boosts productivity. A break of 10 for every 60–90 minutes would be ideal.
- Lunch late: I think it depends on geographical area or culture in your workplace, where people have lunch at mid-day or don’t have it at all. Nonetheless, lunch at 1:00PM would be perfect as it splits the day in half, in which human can stay completely focus(10:00AM — 1:00PM and then 2:00PM — 5:00PM)
- Eat light and often: avoid heavy lunch, or you’re gonna yawn and annoy others during the whole meeting.
Sometimes you are on the road of building a cool product, then you suddenly realized this product screws up, as it no longer fits with your vision, or some simple reasons like “This button here won’t work”, “Why do we need this screenshot?”, or “What should happen after the user clicks this?”, etc.
The answer to this is Storyboard. If you are familiar with Agile, you should know about Product Roadmap. I believe Storyboard and Product Roadmap share several things in common. Both of them help you to envision your finished prototype, and ensure that you won’t stuck in the middle of the road. You’ll use your storyboard to imagine your finished prototype, so you can spot problems and points of confusion before the prototype is built. Storyboarding is a common practice in movie production, typically in Pixar (If you have watched Toy Story, The Incredible, you should know about Pixar). It should look something like this in the movie industry:
Here’s how the storyboard looks like when the Blue Bottle Coffee team made a website in the beginning. It is a scenario describing how the user interacts with the application.