[cwalv]

IMO it should be 'fix anything when you feel like it.'

"Sprints" have given agile a bad name (to the extent it has a bad name, as in gp's complaint). The point is to optimize for changes, as they're inevitable, by: 1. Keep the code in a 'clean' (testable, free from cruft, etc) state continuously 2. Release continuously 3. Embrace YAGNI

If short, regular sprints help with those things, use them. But sometimes they don't

[ozim]

Problem is you want to have changes going through process. It has to go through other devs, it has to go through QA, if its user affecting it has to go through business. Yeah like we have linters and auto formatting so no one is arguing on that in my team. We don’t have superficial fix anything, people fix stuff that can affect users but as they work with system they notice improvements.

Having that arbitrary deadline of a sprint helps to synchronize people. Because there will always be that one change that is released but not touched by QA or we need some business analyst to review feature on test server to make sure we did right thing.

Keeping code in testable state and somewhat clean state is easy like I mentioned linters, code formatting automatically. Keeping system changes as in frontend/ backend / third party services aligned is not because it is not something you can just write in one place in code.