A Design Sprint was originally created at Google, offering designers (and other stakeholders) to quickly evaluate and test various products and services before launching them. Moreover, it helps foresee and, consequently, reduce risks that could occur during the launch.
This is a story of how I discovered and integrated the Design Sprint Week approach, applying them to automation projects.
Once Upon a Time, There Was Chaos
Once again, half of my week flew by on meetings about project updates. The status quo was challenged once more, and the project’s scope was modified slightly.
Once again, requirements were altered, and all stakeholders were bombarded with the newest changes. All of that happened while we were already knee-deep in the project, resulting in a backlog. Slight frustration among stakeholders also often occurs.
Enter Design Sprint Week to Bring Order
I figured that I needed some kind of basic principles to keep everything in check and avoid wasting time on various changes, updates, meetings. I needed to implement and test new ideas effectively, quickly, and effortlessly, and that’s when I stumbled upon Sprint: How to Test New Ideas and Solve Problems in Just Five Days.
It turns out the book was a New York Times AND Wall Street Journal bestseller — and there’s a good reason! The approach described by Jake Knapp, John Zeratsky, and Braden Kowitz opened my eyes. I devoured the book three times in a row, each time opening my eyes a little wider to the idea that it’s possible to build and test new ideas within five days.
After almost learning the book by heart, I internalized the method and applied it to my work, making it possible to sprint through the week and complete every goal along the way.
How the Sprint Week Looks Like
Here’s a quick day-to-day overview of a standard Design Sprint Week.
- 1st day — The first day is called the Map day and is reserved for clearly defining the goal and making an overview of the status quo.
- 2nd day — The second day is Sketch day, and that’s when we start working on the solution. All stakeholders are allowed to come up with their ideal solution with minimum restrictions and maximum creativity.
- 3rd day — The Decision day is reserved for making the decision on the best solution. That way, we can start working on the prototype on the fourth day.
- 4th day — Referred to as the Prototype day, the fourth days is when we aim to start and complete building the prototype according to the selected solution.
- 5th day — We use the prototype to test it with customers and see how it’s received.
I particularly liked the Design Sprint Week because all important stakeholders were included in it. Therefore, it allowed coming up with a solution in a week, foreseeing and preventing any changes at a later date.
Design Sprint Week 3.0
As a process manager, I don’t focus on developing new products and services. Instead, I mainly focus on improving and automating processes and related projects.
It was fairly obvious that the Design Sprint Week would help me in my project and would ultimately make my life easier and my projects better. There’s one issue, though — I couldn’t use the described methods as is, so I decided to take what’s best from them and combine it with methods used for process improvement.
To do that, I had to fully understand and internalize the basic approach. Therefore, I decided to do in-depth research on the subject, reading an array of Design Sprint forums and finding other relevant information on the subject. I even had a short email exchange with Jake Knapp himself. After weeks of research, I enrolled in the Design Sprint Academy and started learning about Design Sprint Week 3.0, training to become a master in this role. At the same time, I actually started applying the approach described in my work.
After a while, I felt knowledgeable and skillful enough to develop my own approach, which I refer to as Process Sprint Week. Coming up with it wasn’t easy, though, as I needed an entire year to come up with a detailed plan which I want to share with you.
Process Sprint Week: An Overview
In this article, I’ll run you through the basics of Process Sprint Week. However, if you want to learn more about it, make sure to download the whitepaper containing additional details.
The Preparation Phase
Before the Process Sprint Week starts, it’s necessary to prepare for it properly. This includes clearly defining the problem, making a customer journey overview, and defining the process and the team required to work on it.
The Process Sprint Week Day-by-Day Overview
- 1st day (Understand & Define) — First of all, it’s important to understand the process and the problem. In addition, you need to determine where the solution needs to be implemented in the process.
- 2nd day (Sketch & Decide) — The second day is reserved for coming up with a solution. The team needs to suggest different solutions and select the best one.
- 3rd day (Prototype) — The team needs to create a working prototype.
- 4th day (Test) — The new prototype is tested and the findings about it are collected.
At the end of the Process Sprint Week, the team needs to summarize the data collected during the week and take all requirements into account before all stakeholders officially accept the solution.
It’s Just a Beginning
I’m fairly certain that the entire method of the Process Sprint Week will be further developed and improved in the future. However, it gets the job done for me, meeting all my requirements for making process optimization and automation as efficient as possible.
Using this approach, I’ve completed nine projects from May – December 2021, and three are about to go live. Before learning about Design Sprint Week, my annual goal was to complete four projects per year.
Process Sprint Week: A Detailed Overview
This whitepaper aims to explain what an ideal Process Sprint Week looks like. The approach and methods were derived from Design Sprint Week. If you’re interested in learning more about it, you can read a short overview in my blog post on Bots and People or visit one of the following links to get started.
After learning about Design Sprint Week, I was thrilled to apply it to my job, as the very idea of solving a problem within a single week was really appealing. Before studying and internalizing the Design Sprint approach, I was swamped with all kinds of meetings (summary meetings, coordination meetings, jour fixe, and more). On top of that, all stakeholders were constantly urgent to hurry up, as all kinds of obstacles popped up all the time, preventing me from focusing on the problem.
Since my main area of work is process improvement and automation, I couldn’t find the ideal Design Sprint setup and apply it to my work. Simply put, none of the approaches was good enough for my line of work.
That’s why I devoted plenty of time to learning about Design Sprint and eventually became a Design Sprint Master. The learning process included researching, testing, and even receiving practical training. Once I internalized it and was comfortable enough with my new skills, I adapted certain approaches and methods from the Design Sprint Week to develop what I call the Process Sprint Week, which I use all the time nowadays on my projects.
So, what does a Process Sprint Week look like?
Preparing for the Process Sprint Week
Before the Process Sprint Week, you need to make sure everything is prepared for it.
Sprint Challenge
The essential prerequisite for starting a sprint week is having a Sprint Challenge. In other words, you need an ongoing and concrete problem in a process that needs to be solved during the week. Therefore, it’s necessary to define it clearly to approach it in a focused and targeted manner.
Customer Journey and Process Documentation
It’s important to prepare the existing models, visualizations, and descriptions of the customer journey map and the process in advance. This will help you create a timeframe for the tasks during the Process Sprint Week.
Sprint Team
Finally, it’s important to determine the team working on the project.
Ideally, you need to select between four and seven people, one of them being the decision-maker. Other members should come from different backgrounds but have extensive knowledge of the Sprint Challenge approach.
Each team is referred to as a process participant, but you should be able to assign the roles of the process owner and the team leader.
Process Sprint Week Explained Day by Day
The Process Sprint Week is divided into four parts:
- Understand & Define
- Sketch & Decide
- Prototype
- Test
Monday: Understand & Define
As you can see, the two operations conducted on the first day are understanding and defining.
Understand
In my opinion, the first part of Sprint Week is the most important, as we need to analyze the entire process and understand the Sprint Challenge. Moreover, it’s important to understand the process at hand and its every step.
It all starts with Lightning Talk. Each team member presents their vision of the Sprint Challenge, updating other team members on their knowledge about the subject. In other words, the talks help us be on the same page.
Some of the questions they should aim to answer are:
- How is the challenge solved in other companies?
- What is the status quo of such a challenge
- How can the process be made more efficient?
After that, we can visualize the challenge using the customer journey map and a detailed process description.
-min.jpeg)
Define
Once we have a deep understanding of the challenge, we can start fleshing it out and prioritizing it.
One of the things that can help us with that is discovering the so-called hot sports on our customer journey map and process model with the help of the collected feedback. Making hot spots visible facilitates finding a long-term goal and developing sprint questions. These can ultimately help us come up with a solution to our Sprint Challenge in a targeted manner.
After all sprint questions and the goal have been determined and developed, expert interviews can be conducted if required. This is often necessary if the Sprint Challenge focuses on specific software or product or if there’s a legal framework that everyone is required to know before working on the development of a solution.
Tuesday: Sketch and Decide
On the second day, it’s time to get to work.
Sketch
With the help of various iteration techniques, each team member can start sketching what they think is the ideal solution for them. Later, they get to present their work in what we call an art gallery.
Decide
The stakeholders need to decide on the most promising solution after everyone has presented their sketches. The team can work together on the final storyboard based on the decision.
Think of the storyboard as a blueprint for building a prototype. You might not require a storyboard, though, if the happy path is visualized, as all the exceptions should already be described in the process analysis. Moreover, this could take time, and we only get one afternoon for it.
The “decide” part is also reserved for deciding the tasks for building the prototype.
Wednesday: Prototype
Building the prototype during the Process Sprint Week mainly falls on the process manager and the citizen developer. Other technical members of the team are mainly needed for queries or when creating the interview script.
Thursday: Test
During the last day, the team needs to find five process users and give them an opportunity to test the prototype (the improved process). Once they test it, there should give their opinion in an interview.
The team needs to document all feedback carefully and implement it once the testing period is completed.
Final Thoughts
Once the Process Sprint Week is over, all findings are documented in the Sprint Week report. In addition to that, the team needs to create a Process Description Document (PDD). It should contain all requirements for improvement and automation of the process that need to be performed.
Finally, the development of the improvement/automation of the process can start. Depending on the requirements, this part can be planned using a classic type of project based on milestones. However, if the team decides to rely on agile project management, they can create tickets based on the defined requirements, which can be processed in sprints.
About the author
Christoph Piller is a process management expert and works in the Center of Process Excellence & Automation at Career Partner GmbH. He has also completed numerous trainings in the area of process automation, such as the Automation Strategist training at Bots and People and is also a Mentor at our academy. He shared his experience with Design Sprint Week for automation projects in this blog article. Thank you for this!
