We had a great opportunity to run a Google Ventures Sprint during our UX Camp 2016, an annual weeklong venue where all Zühlke usability engineers and design experts meet to run educational tracks.
What is a Sprint that solves big problems and test new ideas in just 5 days?
For a team, which has to solve big problems, Sprint is a process and method set that delivers real world answers. Unlike endless group talks, the Sprint leads to team decisions.
Usually, a Sprint is run during a 5-day work week:
“On Monday, you’ll map out the problem and pick an important place to focus. On Tuesday, you’ll sketch competing solutions on paper. On Wednesday, you’ll make difficult decisions and turn your ideas into a testable hypothesis. On Thursday, you’ll hammer out a realistic prototype. And on Friday, you’ll test it with real live humans.”
The Sprint book authors explain work modes and voting techniques for each day to create a better solution, instead of using brainstorming and endless group talks to only agree on a mediocre solution idea. These work modes and voting techniques help to utilize all team brains and experiences to stitch individually created solution parts of the overall solution together, which will be tested at the end of the Sprint week.
We, a team of 5-6 creative people and a curios facilitator, tried out the Sprint at our UX Camp 2016. Our challenge: Design a new newspaper solution.
What we did in our Sprint
To kick-off the Sprint week we first had to define our Sprint challenge. Of course, in a normal situation a team would already have a product challenge to work on or has done their research beforehand, but our newly formed Sprint team first had to come up with a common challenge at the UX Camp.
During the week we followed the instructions in the Sprint Book to achieve our results:
On Monday, we agreed to our long term Sprint goal to create ‘The new newspaper – delivering better information faster’. We selected the ‘news reader’ as the key stakeholder (and not the editor) and finally agreed on the Sprint key question.
How do we deliver enriched news, e.g. with bias, history, perspective and relations to users, which give more value than existing news aggregators?
Like the book suggests, we created a Map to overview the challenge space, interviewed an expert in order to enhanced our newspaper knowledge and created a clustered wall of “how-might-we” questions extracted from the expert interview. We then selected 3 “how-might-we” questions to detail our Sprint challenge.
One Tuesday we did a lot of work by researching and creating a solution portfolio of news aggregation features outside the newspaper industry, using lightning demos and crazy 8s of individual ideas. We added individually drafted solution sketches to the portfolio and voted for the best solution parts from this portfolio to initially fill the prototype storyboard, using speed critique and sticker votes.
It was really an exhausting day filled with news article design and decisions making about enriched news features, along with questioning the Sprint process by team members throughout the day.
On Wednesday, since we only had a half Sprint day available to us we just finalized the prototype storyboard.
On Thursday we built the goldilocks prototype with Axure, an expert UI prototyping tool.
We created a news app for smartphones showing Brexit news articles, where the news reader could swipe between different article sources. The news sources reflect different editor bias levels between ‘Stay EU’ and ‘Leave EU’ opinions about the Brexit.
Additionally, a map feature indicates the location of the news article source with a bias color indicator of „Stay EU“ vs „Leave EU“ opinion.
On Friday we could only conduct 3 test interviews with news readers instead of 5, because we needed to finish our Camp sessions middays. We had tests with a classic paper newspaper reader, an online short news reader and part time politician reading opponent news on twitter and detailed newspaper articles at the weekend.
What I learned as a Sprint facilitator
As the facilitator of my first Sprint I was keen to follow the Sprint process as strict as possible to understand every proposed Sprint activity in the book during our UX Camp, so that I’m able to understand what might be a valuable change later in a customer facing workshop setting.
Reflecting the Sprint done with Markus Flückiger, a colleague and principal consultant at Zühlke, unfolded many lessons learned as a Sprint facilitator:
- Do not compromise on the recommended infrastructure.
Have a dedicated Sprint room to keep the people focused and isolated from company distractions. Have a separate interview room so that interview guest will not be interrogation by the Sprint team during the prototype discovery.
- Introduce the new style of Sprint communication
Make your Sprint team aware of the different communication approach during a Sprint beforehand. Creative and contributing people are used to talk about their new ideas versus the Sprint less noisy team leading approach of sketching and voting exercises.
- Prepare for interruptions
Check the commitment during Team setup to the no device rules. Leaving the Sprint team during decision phases because of that urgent customer call is very annoying, because the returning team members most likely will drop in new ideas after coming back. Stop-it early.
- Prepare for change
Check the team commitment to the Sprint goal and question on Tuesday morning after the team has slept over it. Ensure a specific rather than an open Sprint question. We should have preselected 1-2 specific news features to test to limit scope discussion later that week.
- Commit to the process
Some team members will always question the Crazy 8s, but they help to gather a great portfolio of solution ideas before you draft your personal solution. I recommend to split the solution creation process of the book explicitly in an information gathering and design phase.
- Deciders need to decide
Coach the Sprint team to apply Sprints straw poll or note and vote techniques to help the decider to decide. Help the decider to ask for votes instead of starting group discussion to make his call. Newly formed teams tend to do team storming and not team voting.
I fully recommend the Sprint to solve big problems and test new ideas in just 5 days, as opposed to working in isolation and getting customer reactions late after weeks of development. But hey, you can achieve this with any other Agile methodology too, e.g. Scrum, Kanban, HCI Design Process.
What makes the Sprint valuable is the group work and decision techniques you apply, to get the best solution ideas from everybody’s experience to build a testable solution together with less waste of endless group debates.
What might be exhausting is the transition from a group of people to a team. Therefore, we recommend to start into the Sprint week with a common challenge and commit to the process during this week.
Armin Egli, an interaction design expert and colleague, mentions that most challenges to be solved are improvements and will benefit from ask the user in addition to ask the expert on the Sprints Monday afternoon. Ask the experts helps to define the domain better especially since, as a start-up company, you might not have existing customers. If you improve an existing solution, which already has a user base, we recommend talking to the users right from the beginning. Don’t wait until the last Sprint day to better understand the real solution needs.
If you are unable to talk to existing users, e.g. in the financial service industry you’re often not allowed to get in direct contact with the bank’s clients, then the Sprint is still helpful. You just run your tests separated by interview and Sprint room to fulfill the contact constrain. This way the Sprint improves the value and quality of the products, instead of assuming the user needs for many weeks.
I’m proud of the Team and what it has achieved during 1 Sprint week and the positive reactions received from real users for our new newspaper App.
The Sprint Team:
Ines Lindner, Lead Consultant UX, Germany
Dan Foia, UI Designer, UK
Neelesh Sonawane, Senior UX Analyst, UK
Armin Egli, Lead Consultant, Switzerland
Fredrik Gundelsweiler, Lead Consultant, Switzerland
Manuel Hachem, Expert Requirements Engineer, Switzerland
 Jake Knapp with Braden Kowitz and John Zeratsky, 2016, Ver. 1.0, Sprint how to solve big problems and test new ideas in just 5 days, p.21, Transworld Publishers.
 We interviewed only one additional expert because of time constrains.
 Short presentation of possibly helpful features by each team member to create a solution design portfolio.
 Create 8 variants of your favorite solution idea in crazy short time to grow your solution design portfolio.
 Brexit, the British exit of the UK from the European Union has been concluded by a referendum on 23.06.2016
 See ShuHaRi, a method to learn a new technique, further reading