From time to time we write about things you might find useful such as what we're working on and thinking about.

A picture of Beth

9 min read

My first Design Sprint: Making Agile work for you, and not vice versa

A couple of months ago, Paper offered to collaborate with social impact consultancy Noisy Cricket to run a 5 day Design Sprint for their HI “Homeless Inclusive” Future project, whose mission is to “create a scalable and sustainable solution for the employment of formerly homeless individuals”. The aim of the sprint was to design and test a small solution that would help progress the project and affect change in some small way.

As a new member of the Paper team, and new to the design and research sector in general, this would be my first assignment as a Delivery Lead. I was a little anxious about not knowing what to do, but also keen to learn.

Design Sprint prep

I began with reading various articles and Jake Knapp’s bible on design sprints. This gave me a rough idea of the types of activities we would need to do within the sprint and how long each might take. Using these as my foundation, I came up with an agenda on a Google sheet and sent it round the team. I tried to stick to the general guidance from the sprint guide book, but I condensed it into 4 days instead of 5 due to team availability.

A graphic of the original 4 day agenda, adapted from the sprint guide book

Image 1: Original 4 day agenda, adapted from the sprint guide book

To prep the room, I printed the agenda along with the above image and stuck them on the wall so they were visible to the whole team. I also had some slides that quickly went through what we’d be doing each day. Finally, I cleared all the walls in the Paper studio ready for the sprint and brought in a ton of post-it notes. Plus a smörgåsbord of food.

Day 1: Learn about the problem & choose a focus

The first sprint day (around 4 hours) went well, and was structured so that everyone knew the goal and what to achieve by the end of the day. The plan was to introduce the team, frame the problem, make a user journey map and then choose a point on the map to focus on. We managed to achieve what we wanted, although it was a little rushed towards the end, but we were confident we would pick it up the following day with fresh eyes and make sure we were happy to move forward.

Day 2: Sketch ideas, choose an idea & define the prototype

The second day didn’t quite go as intended as the team was split up due to illness and other work commitments, and we realised we needed to do more research. As a result, the original agenda was moved aside whilst we worked on other tasks. This was needed as we had to adapt, however replacing the agenda led to the team being unsure about what they needed to achieve on that day and what delaying the original agenda meant for the sprint as a whole. This led to some tension and concerns later on in the day, which resulted in the team pausing the sprint so that we could take a step back and see what needed to be done to get back on track.

Mini Retro

In order to get everyone on the same page, we decided to have a ‘mini retrospective’, where we would talk about what had gone well so far in the sprint, what could have been better and ideas for what we can do moving forward (in the next sprint days and on future projects). This was a very helpful exercise as it brought up outside factors that were affecting how people were working (things we hadn’t known or anticipated before) and I could understand why people felt the way they did. I was really impressed with the team’s and each individual’s self reflection. After the session we all knew each other’s stresses, fears and actions for moving forward, which informed a plan about how we could continue the sprint work effectively.

Some of the team principles that stood out to me were:

  • To ensure the Agile design sprint framework worked for us (not us working for it)
  • To create a flexible framework that guided the work process (so that everyone knows what we need to achieve each day)
  • Make decisions as a team and prioritise together (rather than me making an agenda for us, we could decide what we’ll work on together)
  • To ‘Stop & Check’ – a new tool we created so we could check everyone was on the same page throughout the day. Anyone could initiate it if they were unsure about something.
  • To spend more time at the start on ‘soft tools’ i.e. checking-in on how we were feeling that day, making a team canvas to map out the team, and sharing our ‘stinky fish’ (what our concerns were for the upcoming project and any general anxieties or external factors that might affect the work).

Before this sprint, I didn’t really see the importance of the soft tools, I just wanted to introduce myself and then get stuck in, but not spending enough time on these soft tools was actually detrimental to the team later on.

For example, at times I felt a bit lost as I hadn’t done anything like this before and felt I didn’t know how to be a proper delivery lead to get us back on track when we strayed – a concern I should have voiced at the beginning of the project using the soft tools. It turns out I wasn’t the only one feeling insecure, and once it was out in the open we all worked a lot better together as we’d made a safe environment for the team to voice their concerns and feel more comfortable.

Day 3: How to make our work process more flexible

Before the next sprint day, I decided to try and amend how we structured our sprint days to make our work process more Agile. To do this, I broke up our remaining days into tasks, and then wrote:

  • what the task was
  • why we needed to do it
  • how we would achieve it
  • when we knew it would be done
  • roughly how long the task might take.

I displayed these on post-its on the wall, along with our sprint goal, what we’d done so far, and the challenge we had chosen to tackle:

(Day 3: Sketching), (Day 4: Prototyping) (Day 3: Sketching) and (Day 4: Prototyping)

I walked the team through the board each day, and made a note of any concerns I had e.g. that we were short on time, or that I didn’t want to do anymore research after this point and just work with what we had. We then decided as a team what we would work on and for how long in order to reach our end goal for the day.

This system worked really well for us as it gave everyone clarity before beginning any work, and we got to decide and prioritise as a team (rather than me just telling them what we’d be doing). We used this layout to plan all our remaining sprint days, each of which went a lot more smoothly.


It’s been an interesting first project, and there are a lot of things I’ll take away for next time:

  • Failure is your friend. I tried my best to read what we should do and try to implement it. When it didn’t work out at first, I took it personally, but actually it was a good thing to fail so that we could improve and tailor the process to our team, who had different working and thinking styles. I expect I’ll need a bespoke approach for each project I work on.
  • It’s fine to spread your days out if that’s what you need. A lot of the ‘design sprint’ articles were about how to do a sprint in 3, 4 or 5 consecutive days. Ultimately, it was better for us to split up the days so that the whole team was available for the sessions rather than stick to consecutive days with sporadic team attendance.
  • As it was such a complicated project, in hindsight we should have probably spent more time narrowing down the problems and making sure we had one small, specific problem in mind before going into the sprint.
  • Imposter syndrome is the devil. And everyone feels it. I went in thinking everyone knew how a design sprint worked and the types of activities that you had to do to make it work. This wasn’t the case, everyone was learning and growing together.
  • It’s good to speak up. I think it’s important to spend time at the start of the sprint voicing any concerns or anxieties and getting them out in the open as it may change how we approach certain tasks. It also fosters a safe space within the team so everyone can feel comfortable and be themselves.
  • It’s important to make decisions and prioritise as a team. Next time the agenda changes, I’ll get the whole team together to decide on an alternative plan, what we want to achieve instead that day and discuss how we might structure the rest of the sprint to accommodate this change. That way everyone’s minds would be at ease when they started work, knowing that we had acknowledged the time constraints and made an alternative plan to (hopefully) reach the same goal as before.
  • Things can go wrong even when everyone is doing their job correctly. Being able to pause and reflect together is a great way to get back on track.

“Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days” by Jake Knapp with John Zeratsky & Braden Kowitz

“The Design Sprint” by Google Ventures

Sprint Stories on Medium

“Running a design sprint: Weeknotes” by Chris Taylor

“Let me smell your stinky 🐟” by Dan Nessler