How We Used One Day Sprints to Improve Team Planning

Our squad’s sprint was going wonky. We often had task ‘hangovers’ that extended into the following week, which meant we always felt like we were playing ‘catchup’ with ourselves. To combat this, we experimented with one day sprints, which compress discovery, planning, execution, QA and shipping into eight hours. One day sprints helped us figure out how to better package units of work and improved how we plan our sprints. Here’s how we made them work for us.

I gave a presentation on one day sprints at RubyFuza, which you can check out here.

Remote work caveat

Now that everyone is working from home, getting in the same physical room to plan and execute on a sprint is obviously not an option. Luckily, there are numerous video conferencing options that allow your team to get together in a virtual ‘room’. Lately, we've taken to Discord. There are also remote pair programming tools available, for example Live Share, which you can use in VS Code.

Pro tip: Miro is a great resource for mapping out ideas during the planning phase. Check out the video tutorial our VP of Product, Phil, put together on how to get started with it.

I’m a developer on a relatively newly-formed Product squad at OfferZen, and at one point, our team had become stuck in a weird rhythm. We consistently had a two day hangover into the fresh week, resulting in our next sprint being shifted out by half a week. We started to feel like failures and our motivation waned.

One option was to simply run with this sprint that started mid-week, but we wanted to start on a Monday and end on a Friday – for psychological reasons. We mused that it would give us a sense of accomplishment before the weekend and a tabula rasa to inscribe afresh on a Monday. We needed to reset.

So, our squad leader suggested we try an experiment and run one day sprints. He prescribed us John Cutler’s blog post on running these kinds of sprints. Cutler describes them as ‘poking the system’ to deepen one’s understanding of it, and get a better sense of the levers we could pull to get our work done.

And so, we embarked on a two week stint of one day sprints. In that time, we learned that:

• Planning is key
• We had to optimise for group efficiency rather than individual efficiency
• It’s very necessary to combat exhaustion, and
• ‘Getting a room’ is the most important factor for success

Planning is key

Our normal sprint routine consisted of dividing up stories between team members and then coming up with tasks and subtasks for each story together. Part of the reason our sprint kept spilling into the following week was because we struggled to estimate how long tasks would take. There always seemed to be something lurking in the depths of the code that derailed our deadline. And so, during the one day sprint, we spent most of the morning on planning – more than you would think necessary.

How we planned during the experiment

The first bout of planning involved choosing a task. It seems obvious, but the task had to fit into one day. With the lens of the reset in mind, it was better for us to have a smaller task we could definitely deliver as opposed to taking on too much. We found that adding a small feature or tracking down an elusive bug were good tasks for a one day sprint.

Once we had chosen a problem, we tried to ‘solve it’ before writing any lines of code. We found where we needed to work in the codebase and then expanded out from there, following each connected thread and theorising on how to execute the task as we went.

This forced us to think about a multitude of solutions and then choose the best one. Sometimes, we found that ‘best’ was just easiest.

A day is never eight hours of straight coding. So, during our planning, we found it useful to calculate how much dev time we actually had in a day and at what time we had to press the ‘merge’ button. We used the end of the day as the deadline and worked backwards, subtracting time for sunk costs like CI tools running.

Avoiding ‘swoop and poop’

We also had to take into account stakeholders reviewing our work. This is certainly less predictable. We affectionately refer to stakeholders coming in and changing the scope, or revealing some vital information, as a ‘swoop and poop’.

Before we started the one day sprint experiment, we found that ‘pooping’ often derailed our week. While we were pushing for tighter deadlines, we tried to avoid this by communicating our plans to our team lead, our product designer and other important stakeholders at the beginning of the day so that they could express any qualms. The earlier, the better.

Another part of this strategy was spinning up a review app as soon as we could. This encouraged prompt ‘pooping’ by allowing stakeholders to review the front end and raise any issues in good time.

Optimise for group efficiency rather than individual efficiency

In late capitalism, any unit of time spent being unproductive is shameful. The way we avoided the shame during our experiment was by justifying one day sprints as optimising for group efficiency rather than individual efficiency.

The sprints allowed us to watch each other and learn. Instead of each person hacking away at a problem, one of us drove and the others sat back, observed, and offered sage advice. More brains on a problem are better, mostly.

However, we also learned that we needed to choose brains that were most useful for the problem – brains that could bring different approaches and philosophies – instead of only the ones that were available. That being said, we discovered that each team member had to be able to drive at some point, otherwise it became very boring for them. To combat the glassy-eyed stare of a disinterested teammate – or worse, them working on other stuff – we rotated drivers so that everyone could have a turn at contributing.

Combat exhaustion

One day sprints are demanding. They don't work just by going through the motions – we had to actively make them work. Externalising our internal processing was particularly difficult, or, in fewer words, thinking out loud was hard when mob programming. There was always the long tail of small to-dos at the end of a task, and dealing with the tail often happened at the end of the day, which resulted in pressure building up as the deadline neared. There's no two ways about it: stress is tiring.

For us, the limit for how many consecutive one day sprints we could do was about five. After that, they became less productive, and the team started getting overwhelmed. We learnt that after five, it was time to call it quits for a week or two, until everyone was recharged and ready to face another one day marathon.

‘Getting a room’ is the most important factor to success

We thought we had transcended meatspace. How wrong we were.

We found that, like Virginia Woolf, “we needed a room of our own” to write code in a one day sprint scenario. We worked better if we were all physically present within the same four walls.

We found that communication was quicker and didn’t have to be as precise if we were co-located – it could be contextual.

Once we realised this, we requisitioned a room for each day that was separate from our broader team’s office space.

The way we set up our room was also an important factor to the day’s success. We sat in a row, each with a laptop in front of us, but a second screen was essential for whoever was driving. We made sure we could all see their screens. The closer we came to mission control at NASA, the more involved everyone was.

So, are one day sprints useful?

One day sprints helped us in several ways:

• They helped us ‘reset’ our persistent task hangover. We cleared a bunch of work in progress and could start anew. We were much happier harmonising the end of the sprint with the end of the week – it felt much more celebratory.
• One day sprints helped us realise it’s important to parcel work into day-long units. Finishing a task each day is motivating and builds momentum.
• When the experiment wrapped up, we were able to bring some of the problem solving we did before each one day sprint into our ‘normal’ week-long sprints. We started to look at how we could solve a problem so that it could be easily broken down into smaller tasks. The pseudocoding we did during the one day sprints also helped us understand our codebase better and gave us a handle on its hidden complexity.
• One day sprints helped with team cohesion. We had a better idea of how our teammates brains’ worked and could communicate much better by the end of our two week stint.

By the end of the experiment, we had added one day sprints to our toolbelt. We now use one day sprints when there is a task that calls for it. Often, it has to do with knowledge sharing, and the sprint helps us mob on a task when it’s something we all need to get context on.

Experimenting with a new system is always simultaneously refreshing and tiring. I think the exhaustion is worth it for a team whose sprints are off-kilter. Newly created teams – as we were – will likely reap the benefits of getting to know their teammates better and delving into the depths of the codebase with them.

Check out the presentation I gave at RubyFuza on one day sprints here.

Elena spends her days working as a front end developer at OfferZen. Her interests range from baking the perfect cheesecake, to architectural illustrations, and some light eye-rolling at the quirks of late capitalism.