--- title: "Release Planning Coordination | Orangescrum" description: "How to coordinate a release: fix the cut, name an owner, agree go or no go criteria early. Plus which Orangescrum features help." canonical: https://www.orangescrum.com/optimization/release-planning-coordination --- # Release Planning Coordination | Orangescrum > For the complete documentation index, see [llms.txt](https://www.orangescrum.com/llms.txt). [Home](/) / [Planning techniques](/optimization) / Release planning coordination Planning technique # Release Planning Coordination, _Explained Properly_ A release is never one team's work. Here is how to coordinate the people who all have to be ready on the same day, and what Orangescrum gives you in each edition. [Start free trial](/sign-up?utm_source=site&utm_medium=technique&utm_campaign=optimization_release-planning-coordination) [See all features](/features) ## What is release planning coordination? Release planning coordination means agreeing what goes into a release, when it ships, and who has to be ready on the day it does. A release is rarely one team's work: features, fixes, testing, documentation, support, and often sales or marketing all have to land together. Coordination is the job of making those dependencies explicit and holding a single date that everybody plans against, rather than several dates that each team believes privately. It matters most at the edges of the release, in the week before the scope is cut and the week after it ships, which is where most releases actually go wrong. ## Where releases _quietly go wrong_ - **Scope keeps changing up to the cut**Items are still being added days before the date, so testing is always working against a moving target and the regression pass is never finished. - **Nobody owns the go or no go**On the day, three people each believe someone else is making the call. The release either ships without a decision or waits for a meeting nobody scheduled. - **Support and documentation find out on the day**The build is ready and the help articles are not, so the first customers to see the new behaviour are explained to by someone reading the release notes live. - **There is no agreed list of what is still broken**Testing has one list, engineering has another, and the release goes out without anyone deciding which known defects were acceptable to ship with. ## What Orangescrum _actually gives you_ Real features, named. Nothing here is an algorithm that decides for you. [**Group the work into a named release**In Self-Hosted, a release holds its work items, its defects, and its target date together, so the contents of the release are a thing you can look at. Self-Hosted only._Release management_](/release-management)[**Hold the date as a milestone**On Cloud, a milestone is the single date every team plans against, with dependencies showing what has to be finished before it can be met._Milestones_](/gantt-chart)[**Cut scope at a visible boundary**Sprint boundaries give the release a natural point where scope stops changing, so testing and documentation know exactly what they are working against._Sprints_](/agile-project-management)[**Know what is still broken**Defects tracked against the work give one agreed list of known issues, so shipping with a defect is a decision somebody made rather than an accident._Defect tracking_](/bug-and-issue-tracking)[**Agree what was actually tested**Test cases and their results record the coverage behind a release, which is the difference between saying it is tested and being able to show it._Test cases_](/test-case-management)[**See the build state next to the work**In Self-Hosted, Jenkins pipeline status appears against the work item, so the state of the build is visible without leaving the plan. Self-Hosted only._Jenkins integration_](/integrations/jenkins) ## How to _coordinate a release_ 1. **Fix the ship date and the cut date separately**The cut is when scope stops changing. The ship is when it goes out. Teams that only publish one date discover that scope was still moving during the test pass. 2. **Name one person who owns the release**One named owner who makes the go or no go call. Not a committee, and not the loudest voice in the room on the morning of the release. 3. **Write down who has to be ready, not only what is built**Documentation, support, training, and anyone with a customer-facing change. Each of them is a dependency on the release date, so plan them as work. 4. **Freeze scope where everyone can see it**Cut at a sprint boundary or a named release so the list is fixed and visible. Anything arriving after that goes into the next one, by default and without debate. 5. **Agree go or no go criteria in advance**Decide before the day what would stop the release: open defects at a given severity, a failing pipeline, missing documentation. Deciding under pressure produces worse calls. ## What Orangescrum does not do here Two things, and both matter before you buy. First, release management as a named module is Self-Hosted only. On Cloud you coordinate releases with milestones, sprints, and the project calendar, which works well enough for most teams but is not the same thing, and it is better to know that now than after signing up. Second, nothing here decides the release for you. There is no engine that picks which items make the cut, no automatic go or no go, and no deployment of any kind. Orangescrum holds the scope, the date, the known defects, the test coverage, and in Self-Hosted the pipeline status. The call is yours. ## Release planning coordination FAQ Does Orangescrum automatically decide what goes into a release? No. There is no engine that selects the contents of a release and no automatic go or no go decision. Orangescrum holds the scope, the date, the defects, and the test results in one place so the people responsible can make the call with the facts in front of them. Is release management available on Cloud? No. Release management is Self-Hosted only. On Cloud you coordinate releases using milestones for the date, sprints for the scope boundary, and the project calendar for the surrounding activity. That covers most of the need, but the named release object itself is Self-Hosted. Can Orangescrum deploy the release? No. Orangescrum is not a deployment tool. In Self-Hosted the Jenkins integration shows pipeline status against the work item, so you can see the state of a build, but the pipeline runs in Jenkins and the deployment happens there. How do we track the defects going into a release? Log them as defects and link them to the work they affect. Before the go or no go, review the open list against your agreed severity threshold, so shipping with a known issue is a recorded decision rather than something discovered afterwards. When should the scope freeze be? Far enough before the ship date that testing can complete a full pass against a fixed scope. If your test pass takes three days, freezing the day before means you are shipping something nobody has tested end to end. Who should own the release? One named person with the authority to say no. It does not have to be a manager, and in many teams it is the engineer or tester who knows the state of the build best. What matters is that the name is written down beforehand. Which plan or edition do I need for this? Milestones, dependencies, and the Gantt chart are in Cloud and Self-Hosted. Sprints are on Cloud Pro and above and included in Self-Hosted. The project calendar is in all three editions. Release management and the Jenkins integration are Self-Hosted only. ## Coordinate the whole release, not just the build Free 14 day trial, no credit card. Every plan includes unlimited users. [Start free trial](/sign-up?utm_source=site&utm_medium=technique_cta&utm_campaign=optimization_release-planning-coordination) ## Related [**Release management**Named releases in Self-Hosted](/release-management)[**Gantt chart**Milestones and dependencies](/gantt-chart)[**Sprint and iteration scheduling**Committing to a realistic sprint](/optimization/sprint-iteration-scheduling)[**Multi-project scheduling**Several projects, one team](/optimization/multi-project-scheduling)