Mostly long-term perspective, I think. Sprints (releases, versions, however you call it) are very lucrative, because being short term they offer quick turnout,

Mostly long-term perspective, I think. Sprints (releases, versions, however you call it) are very lucrative, because being short term they offer quick turnout, sense of quick progress (in terms of tickets closed, features delivered) and bring easy to achieve victories, visible in probably every daily team call/meet. The whole premise of various Agile methodologies (at least as I see it) is building minimal viable solution that solves the problem at hand without investing in bullet proof solution, because requirements may change (not necessarily client requirements. Internal design requirements as well) and that investment may be gone. From management perspective a minimax game to maximise "billable hours", which rarely include bugfixes and do not include maintenance. Though it seems to sweep under the rug the fact that next sprint may be built on top of weak assumptions under that MVS. Without long term goals a team needs a person who is experienced enough to see problems down the road, caring enough to refactor stuff themselves and capable enough to squeeze deliverable required by ticket and maintenance duties into story point value - rockstar developer, and those tend not to be available in bulk.