Releases

What is a Release?

A release represents a version of your product. It answers: “what are we delivering, and when?”

In Sinra, a release is defined by its scope: the set of capabilities it includes. This is decided deliberately at planning time, not assembled retroactively from whatever was finished before the deploy.

Release vs Cycle

These two concepts are often confused. They are independent:

A single cycle can contain issues from multiple releases. This enables teams to work on a maintenance fix for v1.2 at the same time as new features for v2.0, within the same cycle.

One Rule: an Issue Takes the Release of its Capability

An issue takes the release of its capability. Without a capability, you choose its release by hand.

This rule has no exception, whatever the type of the issue (specification, plan, task or bug). It means the release of a capability and the release of its issues can never disagree:

• On the issue form, the release and the wished release are read-only when the issue is in a capability. They name the capability they come from. Choosing or changing the capability updates them before you save.
• Moving a capability to another release moves all its issues, in one operation that succeeds or fails as a whole.
• An issue without a capability, of any type, picks its release freely. Detaching an issue from its capability keeps the release it had, and the field becomes editable again.
• The wished release follows the same rule.
• The form shows the inherited release as text, with a link to the capability it comes from. Any request that changes the release of an issue that stays in its capability, from the interface or from the API, is refused with a message (422 for the API).
• The API refuses an issue that is in a capability with a different release, and accepts it when no release is sent: the issue then takes the release of the capability. CSV and repository imports never fail on this rule, the release is simply taken from the capability.

On a release page, issues that are in a capability appear under their capability. The Outside capability group contains only issues without a capability, and the groups always add up to the number of issues of the release. You can add or remove an issue from the release directly only when it has no capability: for the others, the page tells you to move the capability. Bulk edits that set a release skip issues that follow their capability, and tell you how many.

Defining a Release

When you create a release, you set:

• Name and version number: your versioning scheme (semantic or calendar-based)
• Target delivery date: when you plan to ship
• Target capacity: days of work budgeted for this release

Then, using the Backlog view, you assign capabilities to the release. Each capability brings its issues along. This is where scope decisions happen.

Capacity Planning

Sinra calculates whether your release is achievable based on:

• Total estimated time of the tasks and bugs in the release, issues without a capability included (the development load)
• Team capacity available across the cycles that will deliver those issues

The estimated time of specifications and plans stays visible but is shown apart, as writing load, and does not count against capacity. See Capacity Management. The figure is the same on the release page, the backlog and the release list.

If the release is over capacity, Sinra surfaces it before you commit. This is the fundamental shift Sinra makes: confronting ambition against reality at planning time, not at delivery time.

Reading the Load of a Release

The release page has a Workload block: development against the target (“39 / 40 d (98%)”), the specification and plan time apart (“Spec/plan 27.5 d, outside capacity”), the number of unestimated tasks and bugs, and the comparison between the target and the capacity of the cycles. The Backlog card and the product dashboard show the same development figure.

The progress indicators are named after what they measure:

• Development progress: the progress of tasks and bugs weighted by their estimate, Σ(estimate × status %) / Σ estimates. A finished specification does not change it; a specification shows its own writing progress and the realization of its tasks apart.
• Time spent vs estimate: time spent divided by time estimated, tasks and bugs only. It is not the calendar.

Hover a label to read its formula.

Release States

When a release is delivered, Sinra automatically creates its retrospective.

Communicating a Release

A release scope defined in capabilities translates directly to stakeholder communication:

“v2.4 ships in July. It includes: email notifications, CSV export, and role management.”

This is something your sales team, your users, and your support team can understand without opening the backlog.

Retrospectives

Each release generates a retrospective automatically when it closes. The team fills in four categories:

• Good: what worked well
• Bad: what did not work
• Improvements: process changes to try next time
• General: anything else

Retrospectives are tied to releases, not cycles, because what you learn is about what you delivered, not about how long you worked.

Reading the workload figures

Hover each figure of the Workload block for its definition. Development is the estimated days of the release’s tasks and bugs against the target capacity. Spec/plan days are counted apart and never taken from the capacity. Target is the capacity the release was planned with, Cycle capacity is the sum of the capacity of the cycles that carry it (a cycle shared with another release counts in full in each), and Gap is cycle capacity minus target: positive means room to spare.