Comment by piltdownman

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.