I have worked at a variety of companies and on a variety of projects. What kind of cadence works varies widely. And the factors that go into it are everything

I have worked at a variety of companies and on a variety of projects. What kind of cadence works varies widely. And the factors that go into it are everything from what kind of software it is to the codebase to the organization it is embedded in. There was one reporting app where I was the sole developer and it was only for internal use. My regular cadence was that I would field a series of questions every day. Better than 90% of the questions already had a documented way to solve it. But many days a new feature would be needed. Most features were delivered on the same day. That was a fun project, and my reporting system wound up adopted in every department of that company. I have worked on a legacy codebase with a Kanban style ticket system. Most features were delivered in less than a week. However a significant fraction of "features" were actually bugfixes. Such is life with legacy code. I have worked on systems where features realistically took a month or three, but we pretended to biweekly sprints. The sprint cycle seemed silly there.