Okay but Seriously, Why Don't we Work in Single-Week Increments?
A single week is the most reasonable amount of time for which some work goal can be set, this unit ought form the basis of our work management.
Even if you're not following the Scrum Guide, a "sprint" has become the default unit of time for software engineering teams to encapsulate a single chunk of deployable work. This seems natural: we increment the product, test it, release it, then repeat. If you're not using Scrum you're probably still using sprints, and even if you rename it something dumb like "cattle drive" it's still a sprint. Sprints are defined by setting a goal for the team: in the next X days, we want to accomplish Y. Y is usually a list.
Two weeks is the default length of sprint time in our industry I think (I have no source to cite), though because one month was (arbitrarily?) selected as a maximum by the Scrum Guide you can find plenty of teams blowing this up to 4 or 5 weeks. There's some products and/or teams for whom this long measure is a necessity, maybe I guess. If that's you then this article doesn't apply.
For the last many years, across two companies and many products delivered, my update every Monday morning has been "I do not remember Friday, here's what I'm going to do today." I've recently stopped saying the bit about not remembering Friday. I genuinely don't remember Friday, and that's not entirely due to my upper-Midwest-level of alcohol consumption; plenty of teetotalers can't either. Or refuse to. It's probably more that I refuse to remember anything past the weekend. I've been told Severance is a good commentary on this phenomenon.
Weekends are an excellent natural break in the flow of things. 4 to 5 days (or 30 to 40 hours) is a nice chunk of time to accomplish a task. Why do I have to set a goal longer than a week? The longer I work in more-than-one-week sprints the less I understand the idea. There's plenty of sorts of work that require more than one week to figure; the week length is an individual human-level division of time. If there's work that needs to be scheduled on longer timeframes, I propose also having broader monthly goals which can be chipped away at in weekly increments.
A separate, but related, topic is that meeting every single morning about daily progress is probably functionally useless in the majority of cases, unless grinding swathes of sofware engineers down into nihilists is "functional". Meet on Monday and Friday to set and reflect on goals, respectively. Meet extra twice a month for the same purpose for the whole month. 10-12 meetings/month.
I've read of teams that already effectively do this in practice but they call the month unit the "sprint." I have no beef with you all, carry on your excellent work. To the rest of us, I propose that we should unite as we have nothing to lose but our "I don't remember what I did on Friday"s.