In a CI/CD setup, you could make lots of atomic commits growing the feature behind a flag.

A side effect of atomic commits is that number of commits does better correlate to "work done", I suppose.

You could, but does that really solve any real problem? Now you're wasting more time on CI, commit messages, and trying to keep them atomic instead of delivering the feature. It's not even clear what makes up an atomic commit. If the feature does not work, it's arguably not very atomic. Stubs, mocks of parts that need to be mocked to push forward now and redone later properly, unimplemented branches that end up in abort(), these are arguably not very useful history either.

Also, I disagree that number of commits is a useful measure of work done. Not any more useful than butt in seat time. Nobody can say whether that feature is 200 or 2000 commits, it really depends on how you split it up. It could be 2 commits, plus the fixes that follow once it actually runs and gets tested and fleshed out.

If tracking progress is a priority, you break the job down to some reasonably small number (no more than a couple dozen) of items in a TODO list and update it with what's done and rough estimates of what's left to do. That's a hundred times more useful than "N commits, 123 hours of butt in seat."

Or maybe you can just demonstrate what works. Or tell, when it comes up in a meeting.

(I'd argue that butt in seat time is actually more useful than number of commits, because the latter can change by an order of magnitude depending on how you split it up but I've never estimated to take a month to deliver something that ends up taking 10 months.)

This is probably not the place to debate the pros and cons of CI/CD in general, but if a team is already doing it, isn't the list of atomic commits effectively the TODO list you're talking about?

Of course, over-engineered solutions will score you more commits (or more lines of code, or more TODO items, etc) but still be a bad outcome.

If you don't know how many commits it will be before you start, no, it is not a TODO list. I've never worked with such perfect knowledge. Usually, there's a high level understanding of what it takes to deliver a feature, which allows for the creation of a coarse TODO list that works for tracking progress & coordination. And then there's the devil, in the details. One commit is not one feature, and there are too many details for an a priori list of all the commits you're going to make. And very often you end up doing a bit of opportunistic refactoring & cleanups & little fixes to related code when fitting the new stuff in.

Even very small and simple features can end up being anywhere from 1 to 15 commits.

Yes, you're right; it's not a TODO list because it's not known ahead of time. Therefore, it can't be used to track progress on the particular project itself.

This all came up in the context of measuring productivity, though, not measuring progress on a specific project. Looking backward, it is a list of items completed. If the teams strives to keep them atomic in general, they are more likely (though by no means guaranteed) to be closer in size. So my guess is that this would correlate better to productivity than lines-of-code or time-in-seat, while still falling well short of the ideal.