Orangescrum
Documentation index for AI agents (llms.txt). A markdown version of this page is available at /optimization/release-planning-coordination.md or by requesting this URL with the header Accept: text/markdown.
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 See all 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 cutItems 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 goOn 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 dayThe 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 brokenTesting 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 releaseIn 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 managementHold the date as a milestoneOn Cloud, a milestone is the single date every team plans against, with dependencies showing what has to be finished before it can be met.MilestonesCut scope at a visible boundarySprint boundaries give the release a natural point where scope stops changing, so testing and documentation know exactly what they are working against.SprintsKnow what is still brokenDefects 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 trackingAgree what was actually testedTest 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 casesSee the build state next to the workIn 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

How to coordinate a release

  1. Fix the ship date and the cut date separatelyThe 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 releaseOne 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 builtDocumentation, 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 itCut 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 advanceDecide 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 <em>FAQ</em>

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

Related

Release managementNamed releases in Self-HostedGantt chartMilestones and dependenciesSprint and iteration schedulingCommitting to a realistic sprintMulti-project schedulingSeveral projects, one team