A step-by-step guide to planning a Sinra release: defining scope, checking capacity, breaking capabilities into issues, and distributing work across cycles.

The Planning Sequence

Release planning in Sinra follows a top-down sequence:

Define the release scope (capabilities)
Check capacity against scope
Break capabilities into issues
Assign issues to cycles

Each step produces information that informs the next. Do not skip directly to creating issues without first deciding what the release contains.

Step 1: Define the Release

Create a release with a target date and a target capacity estimate. The capacity estimate does not need to be precise yet, a rough number is enough to check your scope.

Example: “v2.0, target end of Q2, 60 days of work budgeted.”

Step 2: Assign Capabilities in the Backlog

Open the Backlog view. Drag capabilities into the release. Add the capabilities that you believe should be in this version.

As you add capabilities, watch the capacity indicator. If you are already at 120% before adding the capabilities you care most about, the scope conversation needs to happen now, not in week 5.

Step 3: Prioritize and Cut

With a realistic capacity view, decide what stays in and what moves to the next release. Ask for each capability:

Is this a must-have for this version?
What breaks if this ships one release later?
Which capabilities depend on each other?

Cutting scope in planning is a decision. Cutting scope at the end of a release because you ran out of time is a failure. The backlog makes both visible, but only planning-time cuts are controlled.

Step 4: Create Issues on Each Capability

Open each capability and create the issues that describe and build it: specifications, optionally plans, then tasks, and bugs as they appear. Attach each plan or task to the issue it carries out with its Parent issue. Every issue takes the release of the capability, so there is no release to set on each one. For each issue:

Write a clear, direct name
Set an estimated time in days
Assign to a developer or team
Set the platform (Backend, Frontend, etc.)

Specifications and plans can be estimated too, but their time is shown apart and does not count against the release capacity: only tasks and bugs do.

Keep estimates honest. A 0.5-day estimate for something that consistently takes 2 days is noise, not planning.

Step 5: Create Cycles for the Release Timeline

Create cycles that span the release period. If the release runs from April to June, create two or three cycles within that window.

Each cycle’s capacity is calculated automatically from team availability and business days.

Step 6: Assign Issues to Cycles

Distribute issues across cycles. Load each cycle to roughly 70-80% of its capacity. Leave headroom for unplanned work: bugs, integration issues, review iterations.

Use the cycle workload view to check per-developer load. If one developer is at 130% and another is at 40%, redistribute before the cycle starts.

In the issue form, choosing a cycle shows the effect of the issue before you save: “Cycle 2: 95% → 112%” for the cycle, the same for the assignee, and a warning when one of them goes above 100%. The warning does not block saving. An issue without an estimate has an unknown effect, a specification or a plan has none (outside capacity).

Reading the Figures

On the release page, read the Workload block first. “39 / 40 d” is the development (tasks and bugs) against the target; the specification and plan time is shown apart and does not count against it. The line below compares the target with the capacity of the cycles that deliver the release: a positive gap means the cycles can carry more than the target. Tasks and bugs without an estimate are counted (“2 unestimated”): estimate them before trusting the percentage.

Tracking During the Release

Once the release is running:

Check cycle progress daily (date, status, time indicators)
Log time on issues as work completes
Move issues between cycles if something slips
Keep capacity indicators green: if a cycle hits 100%+ with work still to do, escalate immediately

Closing the Release

When all capabilities are delivered and tested, mark the release as delivered. Sinra creates the retrospective automatically. Fill it in while the release is fresh.

Planning a Release