1-day sprints are a fantastic way of turning the traditional time pressures a team might face from negative to positive. They act as a time constraint on the team and force clarity, agility and feedback into your work system in far more significant amounts than you might already have. They can act as circuit breakers for teams struggling to meet sprint goals. They can create momentum in and outside of the team and encourage teams to focus on producing the smallest impact possible for your users. They carry risk, but some thoughtful conversations upfront can minimise any negative impact later on - and the rewards are well worth it.
What is a 1-day sprint?
There’s nothing fancy about a one day sprint. All it is, is your regular sprint cadence scaled down to eight hours. Of course, that means your rituals scale down as well. In my case, a one day sprint meant a half an hour planning session in the morning before we kicked off into work. If your regular standup is meandering, not resulting in a plan for the day or is otherwise less effective, then you might hope this is an excellent way to fix it. The broad idea here is, as John Cutler says, to have the conversation and then do the thing. See John’s article here.
Timeboxes are a forcing function. Forcing functions help you control things you want to control. Setting a timebox of one day for the sprint acts as a forcing function for the size of the work you bring into the sprint. Setting a timebox is also a forcing function for the amount of work you pull into a sprint. If you want to deliver a successful sprint at day’s end, you need to be careful about the shape of the work you commit to, as well as the amount of work you pull in.
Small timeboxes lead to chunking down work smaller. Your larger work items won’t fit, so they need to get smaller. The process of breaking down those larger items forces clarity and understanding. Where before you might have a big fuzzy thing you want to deliver in two or four weeks or longer, you now have to split it up and to split it, you need to understand it. So, the small timebox also forces a better understanding of the work you are doing while removing all of the places uncertainty usually likes to hide.
In other words, you never have to worry about whether or not you can get something done - if you don’t think you can achieve the work in a day, keep talking and cut it down smaller. Worst case, you might spend most of the day talking, that’s okay. Planning and breaking down work is a universally valuable thing. Your company pays you to produce solutions to business problems, right? I’m assuming you’re not paid per line of code written per hour.
What made me think 1-day sprints would be useful?
(a.k.a. how can you identify when they might be helpful to you?)
I had an excellent experience with 1-day sprints on one team and projects that might not translate to another group with different constraints.
For context, I had a project that needed to be done by a specific date. We got approval to start the work, but by the time we could pull a team together, we would only have eight weeks, give or take, to build and deliver the tech (We delivered in six weeks).
The project was a challenging task mainly because of the available time rather than because the solution was novel or the technology complex. We had to deliver our solution and enable our partners to integrate with our solution simultaneously.
I identified early on that I had two important jobs that needed to be done.
I needed to:
- Hire a process that enabled the team to be highly responsive to the progress we made, and
- Do that in a way that provides clarity and transparency for our external stakeholders such as the CEO, CIO, and sales folks working with partners who want to use the solution.
The default process we use is a 2-week sprint. We had eight weeks to deliver the solution and clear instructions that if at any time we felt we wouldn’t hit the timeline, we should stop. Sharing progress with stakeholders four times before the deadline would not be good enough. Bugging teams about progress every day would negatively affect the team.
Running a 1-day sprint would yield 30 reporting opportunities rather than four. 1-day sprints constrain us to work that we could reliably achieve before the next reporting boundary, ensuring we would always be able to report progress. Making that reporting interaction a system feature rather than having an individual do it would also protect the team from undue interruption and help them maintain flow - increasing our likelihood of success.
I hired 1-day sprints to enable decision-making and reporting agility, both in and outside the team. We saw some other benefits. In the first week, we created significant momentum. We were better able to onboard new team members since the work led to making the smallest change possible. We quickly encountered, identified, and resolved bottlenecks because the moment a 1-day ticket didn’t take a day, we knew to stop and inspect.
Using a 1-day sprint created momentum and flow.
Using a 1-day-sprint also created clear intervention points where momentum and flow broke down due to missing tools or processes.
Because we could so rapidly diagnose and resolve issues affecting productivity, we were productive. Further, because we could respond quickly, a little bit of pre-planning went much further than it might usually have gone. For example, we identified some third-party dependencies early on and encountered delays with some of them. Our ability to respond and work around those delays meant that those delays did not become blocking issues where a team running a 2-week sprint may have become blocked by them.
Some other (unscientific) observations:
- The team that ran 1-day sprints had an average cycle time of about three hours.
- Our average time to resolve a blocking issue for our integration partners was about 24 hours - addressing these issues rapidly in a 2-week sprint would be disruptive and affect sprint scope. We didn’t have that issue with 1-day sprints.
- The team enjoyed working with 1-day sprints. They rated the experience at 4/5.
Risks
We did highlight risks through our regular retrospective process. There are things to think about and tradeoffs to make.
Make them deliberately and with forethought:
- Managing wellbeing can be tricky. Running sprints for a long time can lead to burnout. Folks need mental breaks. We usually build in time to recuperate (in the form of quarterly plannings, offsites or other regular “off-sprint” time) - that time can be harder to lock in with a 1-day sprint.
- Managing dependencies, blockers, or long-term plans requires thought. It can be tricky to map tactical activities up to operational or strategic activities. To address this tradeoff, you’ll need to draw lines between your day-to-day and your strategic efforts more often.
- It’s weird - 1-day sprints can be novel for many organisations. If you want to run a 1-day sprint, how does that process interact with other parts of the business? What about the governance and finance folks? Customer support? Does pushing out small batches of work every day put a strain on other parts of the organisation? Does it expose and break manual processes we might have in place? Dunno. The impacts are worth thinking through.
Conclusions
1-day sprints are a potent tool - they can help you turn around a team struggling to complete sprints and circuit-break uncertainty in the development process. In addition, 1-day sprints can help you restore confidence with stakeholders and rapidly build confidence where you don’t have a lengthy pedigree to stand on. As with most tools, this carries risk, and there are questions you’ll need to answer thoughtfully to make the most of 1-day sprints. What are your dependencies, and what impact will such rapid feedback have on other parts of your system? While 1-day sprints may work well for the team conducting them you should also be mindful of their impact on other teams. Will working in 1-day sprints place extra pressure on your colleagues? Is that pressure a feature or a bug? It’ll be up to you to ensure that pressure is positive!