sinraWhat is a Cycle?
A Cycle in Sinra is a time-boxed period during which your team commits to delivering a set of issues. Unlike traditional sprints, Cycles are independent of Releases: they organize the time of the team, while releases organize what is delivered.
Cycle States
Cycles have three states:
- Upcoming - planned but not started
- Current - actively in progress
- Completed - finished, with metrics locked
Cycles and Releases Are Independent
A Cycle does not belong to a Release. The cycle says when you work, the release says when you ship, and the link between them is made by issues: each issue has its own cycle and its own release (inherited from its capability). A single Cycle can therefore contain issues from several releases, and a release is usually delivered over several cycles. See Releases.
Capacity Management
Sinra calculates team capacity per Cycle based on:
- Team members assigned to the Cycle
- Each member’s availability (days x hours/day)
- Issue estimates within the Cycle
This prevents over-commitment and gives realistic delivery forecasts.
The workload compared against capacity counts the estimated time of tasks and bugs only. Specifications and plans can be planned in a cycle: they appear in a separate Writing zone of the kanban and list views, grouped by writing status, and their time is shown apart. See Capacity Management.
In the cycle list, a cycle that has not started carries an “Upcoming” badge, and a running cycle an “In progress” badge.
Reading a Cycle
The workload panel starts with the total of the cycle: “Planned development 17.5 / 18 d · 97% of capacity”, with the specification and plan time apart. Every percentage is labelled and its formula is in the tooltip.
The statistics of a cycle are named after what they measure:
- Time elapsed: days elapsed over the duration of the cycle, 0% until it starts.
- Development progress: progress of tasks and bugs weighted by their estimate.
- Time spent vs estimate: time spent over time estimated, not related to the calendar. A future cycle can show a few percent here if time was logged on its issues.
Workload Gauge
The header of a cycle shows a compact gauge, readable without unfolding anything: “17.5 / 18 d · 97%”. The planned development (tasks and bugs) is compared with the capacity of the composition, and the colour gives the level: under 80%, from 80 to 100%, above 100%. Above 100%, the gauge also shows the days beyond capacity. The cycle list shows the same gauge for every cycle.
A badge “1 overloaded” appears when someone is above 100% of their own capacity, even when the cycle as a whole is not. The tooltip names them, and gives the days assigned to people outside the composition. A click on the gauge opens the detail by person, where each overloaded member is marked.
When a cycle has no capacity, the gauge asks you to define it instead of showing a percentage.
Composition of a New Cycle
A new cycle takes the composition of the previous cycle (same organization, and same project when the cycle has one): the same people, with the same percentages. To leave someone out of the cycles, a manager or a product owner who does not develop for instance, remove them from the composition of a cycle: the following cycles leave them out too. They stay in their team, and you can add them back from the composition. Only active people who are still members of an active team are taken over.
The percentages are kept, the days follow the duration of the new cycle: a cycle twice as long has twice the capacity. Without a previous cycle, the composition comes from the teams. The creation message says where it comes from: “Composition taken from Cycle 2 (17.5 d)”.
Attaching Issues to a Cycle
Add issues lists the issues of the current release that are not in a cycle yet. Each line shows what attaching it would do: the load of the cycle before and after, and the load of its assignee when it has one. If the spec of the issue’s capability is not finished, a warning says so and the button reads Attach anyway: the issue can still be attached.