## 5.3 Release Planning People live today at a completely different pace they used to twenty, fifteen or even ten years ago. They process a lot of information and make thousands of decisions every day. The word VUCA15, used more than ever to describe the world people live in, is just one of the several pieces of evidence that things have changed. Currently, technological, economic, social and political aspects determine that what was true yesterday, may no longer be true today, either because something changed, it was not clearly understood or was too complex to maintain. This is the new reality and it’s impossible to avoid it. Moreover, the organisations that manage to adapt are the ones thriving. When building a solution, a team should be able to refer to an organisational strategy (marketing focused, risk oriented, opportunity enablement) that clearly defines what, when and to whom will be a solution delivered. Because the strategy drives the team throughout the entire project, it is paramount to guarantee that it reflects what the business (and the organisation) needs. Still, this is just the beginning. With all the dynamism that characterises the VUCA world, the business must have the tools that will allow them to share their strategy with the Agile Project Core Team (A-PCT) regularly. This is where PM2-Agile suggests the use of Release Planning. Release Planning is designed to materialise the Learning step of the PM2-Agile Lean Start-up model. By looking at the collected data, it’s possible to learn and generate new ideas that will drive the building of the solution. By practicing two critical steps of the iterative PM2-Agile Lean UX process: Evaluate and Learn and Incept assumptions and research, the Agile Project Core Team (A-PCT) and all the other relevant business stakeholders focus on essential assumptions that need to be validated. ==Release planning’s primary goal is to guarantee that the business communicates to the Agile Project Core Team (A-PCT) ongoing changes that affect the solution strategy. The team determines how “big and complex” those changes are so the business can decide what to build and when to release==. Allowing a release strategy to become obsolete can cause total or partial unsuitability of the solution with negative consequences. Therefore, the question to be asked about Release Planning is not “shall it be used” but instead “how often shall it be done?” ### [[5.3.1 Frequency and Duration]] ### [[5.3.2 Structure of the Release Planning]] ### [[5.3.3 Guidelines and Participants]]