1 day Sprint
Hi everyone.
I read a forum thread here from 2018 regarding if a 1 day sprint was valid. The consensus at that time was no. And in 2018 that seems like a reasonable answer.
Today, I am a 1 person dev team, with Google Gemini. I spec out a new app (within a platform framework we already built) in the morning, before noon, hand the app plan to Gemini, it asks questions back for clarity, delivers a plan, builds the code, I implement the code into the framework, run simulation, I go back with changes/modifications, it gives a new version, I test and generally after 1 or 2 revisions (same day) I compile the installer and the work is done and the sprint is over.
While this workflow and process certainly would not work for every situation, it is, perhaps, a glimpse into a new horizon that many of use may find useful moving forward.
I've set the thermostat in my apartment to maintain a temperature of between 16 and 20 degrees C. It's a complex challenge managed through empirical process control, which is what Scrum is for, but it isn't Scrum. Scrum is a means towards achieving that end, but it is not implemented for its own sake.
Sometimes Scrum just isn't needed. What matters is that complexity is being managed through feedback that is empirically fit for purpose.
A one day AI build loop is not a Sprint IMHO.
Calling it a Sprint is like calling a microwave a restaurant. The microwave can heat food incredibly fast, but it does not decide what should be on the menu, whether anyone wants to eat it, or whether it is safe and profitable to serve.
Scrum exists to manage learning, risk, and value, not typing speed. AI collapses how fast you can generate code, but it does not collapse how long it takes to get real stakeholder feedback, see how users actually behave, or reflect on what to change next.
That is why Sprints include Reviews and Retrospectives. Those are not overhead. They are the moments where teams learn from stakeholders and from themselves. You cannot compress those into a few hours just because code was generated quickly.
So nothing about Gemini suddenly makes one day Sprints valid. What it makes possible is producing a potentially shippable Increment inside a Sprint, which tightens feedback loops and improves decisions. The Sprint is still the container for stakeholder inspection, team reflection, and adaptation.
Call the workflow what it is. Rapid AI assisted delivery. Not Scrum.
Specifically:
In the case you describe, I wouldn't call it Scrum either. Scrum is a framework for collaboration. For example, if you're working alone, it's not necessary to hold retrospective meetings. If you identify an area for improvement, just try it out. Agreements aren't necessary in a one-person team. However, some Scrum techniques, and above all Scrum theory, can be useful. In this case, Scrum is oversized.
Basically:
Why shouldn't a sprint last one day? If there is a constant stream of requirements and changes, it may be useful or even necessary to adapt and learn quickly on a daily basis. This will, however, be a rare exception.
One example would be when dealing with a natural disaster, such as a major earthquake.
In this case, the 'product' would be 'saving lives and rebuilding'.
In the first few days at least, daily planning would be too slow. However, after that, it may be sensible to adjust the team's plans daily rather than every two weeks. The situation changes daily: you learn about the extent of the damage, relief supplies are delivered and so on. New experiences are gained and additional requirements are added. The team could do sprint planning in the morning, followed by a review with stakeholders — who could be authorities, victims, or other organisations — in the late afternoon. They could then consider how to improve for the following day. This may not be the perfect example, but I wouldn't rule out the possibility that daily sprints make sense in certain situations. I suspect that many rescue teams already work this way without calling it Scrum.
In software development, however, I can hardly imagine such a scenario.