Sprints are a fundamental concept of agile working and a crucial part of how we do things at Mindera. Our standard practice is to work on the basis of a two-week sprint but we wanted to see what happened if we reduced this to a single day.

As a team learning exercise, we held a sprint in a day. We did so to find out what it would be like to work in a different way, see what we could learn, and have some fun along the way! The results were really interesting and gave us some great ideas for the future.

This blog post walks you through our sprint in a day, explaining:

• Why we ran it.
• How we carried it out.
• What the results were.
• What our learnings were.
  

We hope it gives you some useful ideas for how to run your own sprints and inspires you to give it a go as well.

Why did we hold a sprint in a day and what is it?

When speaking with Paul Evans (Mindera’s CEO) about sprint in a day, he had this to say: “Sprint in a day. Sounds a bit like a diet.”

It sort of is like a diet, in a way. It slims a sprint down from the usual length of two-weeks, making it leaner and trimmer.

We came up with the activity as part of a team reset sprint following some team changes, and wanted to conduct some team activities where we would get to know each other better, try some different ways of working, as well as maybe actually deliver some value quickly.

We were coming up with a few ideas on different activities we could run, especially on a few of the days where we didn’t have the entire team present and one of the things we came up with was a sprint in a day. So we gave it a go.

What exactly is a sprint in a day? It’s exactly what it says on the tin — it’s a sprint in a day.

Credit: PxHere

How did we run the sprint in a day?

The team involved was a mix of Minders and non-Minders. Some of the team had worked together for several years, and others were quite new to the team and client.

As per a typical sprint, we did some pre-sprint planning in advance. Not much, just a little bit to make sure we had a shortlist of tickets to discuss at planning on the day and to help the day start off smoothly.

We didn’t pre-determine the tickets but went through our backlog and established which ones we thought could be contenders.

We also scheduled in the standard sprint ceremonies in the calendar for the team, so we knew the rough timings we were looking at. We kept it fairly flexible, taking into account people’s working hours around the globe and ensuring we had the right remote tools set up in advance — Google Meet, Zoom, Slack etc.

We timeboxed planning to 45min and scheduled this at the start of the day (09:15-10:00), as well as scheduling in a review and retro at the end of the day (15:30-16:30).

Planning

We kept planning to 45 minutes. Our normal planning sessions for a two-week sprint run at about two hours. Obviously, while we were doing this in one day, it’s not going to be a tenth of that and if we finished early we finished early.

In the end, we used all of this time up but did feel this was an important part of setting up the day for optimum success, as per any sprint.

Within the planning session, we agreed on:

• Sprint goal(s).
• Tickets to bring into the sprint and aim to get to ‘done’.
• How we wanted to work.
  

In terms of sprint goals, we agreed them early on and then revisited them at the end. A big part of the goal for having a sprint in a day was to experiment.

We kept the goals for the sprint quite basic because we wanted to try and complete all the tickets — we didn’t have anything that pulled everything together and we just wanted to see how it went.

Once we’d agreed that, we then went through our backlog and some of the tickets (as we would in any standard planning) and agreed:

• The ones we thought we could deliver in a day — based somewhat on the priority.
• On some of the definitions of ‘done’. For example, partly because it was done on a Friday, we decided it was a bit too risky to go into production with the frontend tickets and removed that from our definition. There were one or two other tickets that were just too big to fit into a day — we split them out in such a way that we were able to provide value within one day.
  

Once we had agreed on the tickets we thought we could achieve, we discussed how we wanted to work as a team. This is so we could optimise our time to achieve the goals. We came up with a rough plan to split into two teams because we wanted to experiment with different ways of working (that was part of the goal).

We split the team into a few QAs and into frontend and backend teams.

We then went away and worked on the tickets.

How did working on the tickets play out?

We agreed to reconvene around lunchtime, to see how everyone was getting on and to collaborate.

This worked reasonably well. However, what we did find is that people collaborated even more than initially expected. Although we’d planned to split up into two teams, we ended up of collaborating as one bigger team for a lot of the day.

Then we reconvened at 15:30 for the sprint review and retro and:

• Talked through what we’d done
• Got any last minute releases out
• Collated our learnings
  

What were the results of the sprint in a day?

Credit: PxHere

We didn’t quite get round to delivering all of the tickets. There was one ticket we discussed during planning that it may be a bit of of a push to get it done, but agreed to bring it in. In the end, we didn’t quite manage to close this one out.

Some highlights of the sprint include:

• We absolutely experimented with different ways of working.
• We got quite a few tickets all the way into production.
• We gathered some very useful learnings.
  

We also took a look at some of the sprint metrics, with some interesting ones being:

• Story points
• Burndown chart
• Control chart / cycle time
  

Story points

Story points per engineer day came out at 1.3 compared to our average rate of 0.6. This is a standard metric we track to help us plan for a standard sprint.

This rate obviously isn’t sustainable on a regular basis, but it did show (arguably unsurprisingly) that focussing on things, getting the tickets in, and jumping on them got people to push things through quicker.

Burndown chart

This was pretty much as good as you could get, apart from completing those final tickets.

Control chart / cycle time

Obviously for the day, this came out on average 1 day. But what we did notice was the massive dip this showed over time, still appearing as a (positive) blip several months later. Getting a ticket through in a day isn’t unheard of, but is rare, even for similar sized tickets.

Overall, in terms of getting stuff done (and especially some of the smaller tickets that were maybe struggling to get prioritised on a sprintly basis), it worked really well.

What were the learnings from our sprint in a day?

Credit: PxHere

Would we do it again? Absolutely! And we would recommend you give it a go. It was a really interesting team exercise.

Below, we’ve split our learnings into the things that went well and the things that we’d improve on next time we run a sprint in a day.

What went well?

We experimented with different ways of working

Some of the things we called out were different ways of working and we’d always recommend you try different things.

Collaborating in a bigger group within the team identified some issues earlier than they may have been during a normal, two-week sprint.

Some of the testers (people who really knew the backend stuff) picked up on some pipeline issues and were able to resolve them a lot quicker than us hitting, going back, and doing some bug fixing. That was really interesting.

Pre-shortlisted and sprint ready tickets made planning easier

Getting tickets sprint ready before going in always helps — be that for a sprint in a day or otherwise. Had we not had those tickets ready in a reasonably sprint ready view then that planning would have gone on into the day.

Blockers were brought to our attention

It (the sprint in a day) really highlighted some of the blockers we had. By having everyone on the calls, we were able to highlight issues early and note if we were dealing with a really tricky area. It also helped people to understand some of the common issues and how we can work on them going forward — to build in more time for those particular pieces during planning.

The whole team learned from the sprint

Everyone learned something in different ways. By shadowing other people, using paired programming, as well as the general team discussion, lots of knowledge sharing went on.

We completed tickets that might have otherwise been overlooked

The types of tickets we picked up meant (arguably) we did get through some of the smaller tasks in the backlog that were being ignored a bit.

What would we improve next time?

Use a blend of different sized tickets

Some of the tickets were quite small. Next time we’d recommend having more of a blend of tickets, including some larger ones that could be completed in a day. It might be more interesting to have some bigger, more complex tickets to mix things up a bit.

Try different types of collaboration

A bit of the feedback focused on if how we managed the collaboration during the day was the most effective. Points such as “I’m not sure what I did all day” were raised. Noticeably, that comment came from one of our more senior engineers. He probably felt as though he hadn’t contributed much as he was guiding others to learn, rather than just coding himself, whereas others could more clearly see (and feel) the value of this.

Probably the learning point around this is that, although we provisionally agreed to split into two teams to collaborate, everyone ended up working up more or less as one big team because they didn’t want to miss anything!

Although this did have some advantages, with some key learnings being shared with most people, from a purely getting stuff done perspective it probably wasn’t the most efficient — but then, that wasn’t our only goal.

Make sure the whole team is able to be part of the sprint

We definitely went into our sprint in a day as a bit of a filler within our team reset.

In retrospect, next time (and there will be one!) we would make sure that all the team were there. Because it did work, it was really interesting, and some of the team who weren’t there did feel as though they missed out a bit.

Ensure the team takes plenty of breaks

Breaks, always a difficult one. This was a remote session and it can be tricky to manage breaks. It was really draining at the end of the day and was very hard to ensure breaks were taken, as everyone was on a call. So, just a reminder to make sure everyone does take enough breaks.

Don’t schedule it on a Friday.

Holding the sprint on a Friday worked better than expected and did fit into our overall reset agenda.

But, as a general learning, we would recommend to try and do it on another day, one where you could arguably get more releases in (less risk before the weekend!), have less barriers, and potentially work later if you want to (although this isn’t necessarily a good thing) — you could even have a social event with the team afterwards.

Final thoughts: this was a great learning experience

We learned a lot from our sprint in a day and know for sure this won’t be the one and only time we do it. We hope you picked up some useful ideas and that you try your own sprint in a day sometime soon.

If you found our blog post helpful then let your peers know about it by sharing it on your social media channels.