Some rules of engagement for Release Planning

When wanting to mature delivery capability, some rules, some process and some are inevitable. More than inevitable, necessary.

Look at the list of to-dos at the point in time when the release content is agreed; prioritize features, enhancements, and bug fixes based on business value, customer impact, and technical feasibility.

Actively avoid adding anything to an in-progress sprint. Hot fixes and emergencies need to be made the exception, not the rule.

Nothing should be added to a release without acceptance criteria and a clear scope/definition-of-done for the dev and test team to work towards.

Anything that is not ready, or does not make the grade for the deadline to include, is shunted to the next release; similarly, anything that is not finished, or does not make the grade for the deadline to go, is shunted to the next release – the release time is not extended.