My unfortunate personal experience with various teams is that Scrum is too often an excellent way to close tickets if you don't care very much about quality. T

My unfortunate personal experience with various teams is that Scrum is too often an excellent way to close tickets if you don't care very much about quality. The whole dynamic of fixed-length iterations and "commitment ceremonies" puts heavy social pressure on developers to hit lots of tiny deadlines. And when minor estimation errors occur, there's a risk of developers shipping code that technically meets requirements, but which subtly compromises quality or maintainability. But hey, they kept their promises! And then you hold retrospectives where you try to find out why production is a dumpster fire and the clients are unhappy. Even skilled software estimators may be off by 50% on individual features. Over time, this mostly averages out. But chopping time up too finely and applying social pressure to consistently hit lots of micro-deadlines has to be paid for somewhere. I am personally a fan of Kanban: Keep a priority queue of features. Estimate them as best you can. Allow decision makers to reorder the queue as they learn about customers. This still gives you rough estimates, and the ability to track estimation accuracy. But it doesn't back team members into a corner where they feel pressured to ship two days to soon just because it's the end of the iteration.