The foundation of Scrum is empirical process control, a technique to build complex products in complex environments, where few activities are repeatable and the course of work is quite unpredictable. Which is the case for the creative work that software development is.
In empirical process control objectives are fed into a system, and via closed-loop feedback results are regularly inspected against the objectives in order to adapt materials, tasks and process. Skilled inspectors do inspection at an appropriate frequency, so focus and time to create valuable output are balanced against the risk of allowing too much variance in the created 
output.
Scrum includes 2 cycles and a lightweight set of events and artefacts to do inspection and adaptation upon transparently available information and commonly understood standards.
- At the Daily Scrum the Development Team inspects its progress, estimates, planning and tasks within the container of the Sprint. All of these elements were initially laid out at the Sprint Planning. They use the Sprint Backlog, the Sprint Goal and a progress trend on remaining effort. It assures they don’t get out of sync with each other and with the Sprint Goal for more than 24 hours.
- At the Sprint Retrospective the Scrum Team inspects the complete, well, ‘process’. Rather the way they have played the game of Scrum in the performed Sprint. The objective is to define what playing strategies will be applied in the next Sprint. No topics are excluded; tools, technology, communication, relationships, quality, engineering standards, definition of done, … It’s basically about establishing what went well, what shows room for improvement and what experiments might be useful to conduct in order to learn and build a better product.
There seems to be a tendency to move to shorter Sprints. The last version of the Scrum Guide advises Sprints of 1-4 weeks. 4 Weeks being an absolute maximum, I think 1 week is an acceptable minimum.
Let’s say you would do 1-day Sprints. Both Scrum’s described inspection events will occur at the same time, or at least take place at the same frequency. The danger is very substantial that a Scrum Team will focus merely on its daily work and progress, but takes no time to inspect & adapt the overall process and ways to improve quality.
We should also keep in mind that Sprint length is best defined upon the frequency at which the Product Owner and the Development Team need to consult with the stakeholders over a working version of the product and the decision on a functional release of the product. Sprint length will take into account the risk of losing a Business opportunity because Sprints are too long. Well, if your business is indeed so volatile that it is only 1 day, please do 1-day Sprints and release daily. But be careful in burning your inspection mechanisms.
Above all, do organize the Scrum events and enjoy the adaptive power of the 2 mutually re-enforcing inspect & adapt cycles. If you would only release on a weekly base, be realistic and go for the optimal approach, a Sprint that matches your product cycle and takes 1 week within which you will still adapt to reality on a daily base.
