Comment by friendzis
10 months ago
I have been saying this for years: consistent deterioration of ACs/DoDs. There is no limit to scrum and especially the constant refinement to ACs/DoDs.
Yes, you may implement a solution more efficiently by not overengineering it. But at some point constant seek to reduce "complexity" so that more features fit into sprint (funny how story point measure complexity, not time, but sprint is sized in both time and SP capacity) is bound to hit feature completeness. Once you cross over that metaphorical Rubicon it's game over - quality starts to slowly go downhill.
You will not notice it immediately. That edge case that was ignored may not surface for months or years. It may take several idiosyncrasies to line up for a feature to be declared FUBAR. At some point that technical debt does bite you back, but at that point the process (tm) has already optimized away most if not all opportunities for deep refactorings fixing previous rushes to deliver.
First off - it's a sprint forecast, not a sprint commitment. A sprint is timeboxed in the sense of guaranteeing some delivery of incremental functionality for a product on a regular basis. It's aim is not to backdoor the mapping of time to points.
Furthermore, Sprint Planning/Refinement are just innocuous ceremonies whose only aim is to facilitate productive discussion between a Product Owner/Manager and an Implementation team as regards delivery timelines and priority ordering thereof. Done properly, it allows a pragmatic approach to achieving a predictable software delivery cadence via mutual compromise.
If the process turns into 'fit as many features into the sprint as possible' at the expense of Performance/Stability/Functionality or Technical Debt accumulation, you're really just doing the 'fast' version of Cheap/Fast/Good Waterfall Project Management.