Sinra's capacity system makes the fundamental project equation visible: what you want to deliver vs. what your team can actually do. Learn how availability rates, cycle capacity, and workload calculations work.

The Core Idea

Most project management tools let you add issues without limit. You end up with a backlog that is larger than any team could ever deliver, and planning becomes guesswork.

Sinra does the opposite. Every piece of work has a time estimate. Every team member has an availability rate. Every cycle has a calculated capacity. The system makes the gap between ambition and reality visible before you commit.

Availability Rates

Each team member has a target_capacity between 1% and 100%.

100%: full-time on the project
50%: half-time (part-time, split across projects, etc.)
80%: accounts for meetings, code reviews, and overhead

These rates are set in team configuration and reflect reality, not aspiration.

Cycle Capacity Calculation

When a cycle is created with start and end dates, Sinra calculates its capacity automatically:

Cycle capacity = Σ (member_days × availability_rate)
                 for all team members
                 across business days in the cycle

A 10-day cycle with:

Alice at 100%: 10 days
Bob at 50%: 5 days
Carol at 80%: 8 days

Gives a total cycle capacity of 23 days.

This number is fixed. You cannot plan more work into a cycle than its capacity allows without seeing the overload.

Workload Tracking

Within a cycle, Sinra tracks workload per member:

Estimated: total issue estimates assigned to this member
Spent: actual time logged
Remaining: estimated minus spent

The cycle workload view shows all members at once, making it immediately visible if one developer is overloaded while another has capacity.

Composition of a Cycle

The capacity of a cycle only counts the people in its composition. A manager or a product owner who does not develop is removed from the composition of the cycle: they no longer dilute the team average, and someone above 100% stands out. A member’s percentage stays between 1% and 100%; removing them is how you leave them out.

Tasks and bugs still assigned to someone outside the composition count in the load of the cycle, with no capacity in front of them. They are flagged “out of composition” in the workload panel and in the tooltip of the gauge.

A new cycle takes the composition of the previous one, so a person removed from a cycle stays out of the next ones. See Cycles.

Team Workload

The same rule applies one level up. A team’s capacity is the sum of what its members give it, and a team’s workload is everything assigned to the team or to one of its members, measured against that sum:

Team capacity = Σ (cycle_business_days × member availability)
                for every member of the team

Team workload = Σ (estimates assigned to the team or its members)
                ÷ team capacity

Backend, on a 10-day cycle, with Thomas at 60% and Jean at 100%, has 16 days of capacity. Carrying 16 days of estimates puts the team at 100%, not at 200%. The cycle figure follows the same rule: the capacities of the teams taking part are added, never averaged.

Capacities are added at every level. Averaging them would measure one average member instead of the group, and a team that is exactly full would read 100% times its member count.

Each row of the workload panel is therefore readable on its own: a member above 100% is committed to more days than they have, and so is a team above 100%. One member over their availability does not necessarily put their team over its own, which is exactly the arbitrage the planning screen is there to support.

Development Load and Writing Load

Capacity measures implementation, so the load compared against it only counts the estimated time of tasks and bugs. This applies to a cycle, per person and per team, and to a release.

Specifications and plans can still be planned in a cycle or a release and keep their estimate. That time is shown apart, for example “Spec/plan 2 d (outside capacity)”. It is information, not load: adding a specification to a cycle does not change its workload percentage. A capability made only of specifications and plans has a development load of zero. The line is hidden when there is no writing time.

Release Capacity

At the release level, capacity planning works across cycles:

Total estimated time for the tasks and bugs in the release, issues without a capability included
Spread across the cycles where those issues are planned
Compared against total available team capacity in those cycles

This surfaces over-commitment at the release level, not just the cycle level. You can see, before starting work, whether the release scope is realistic.

Reading the Figures

Every screen reads the same figures, so a release or a cycle never shows two different totals.

Development is the estimated time of tasks and bugs. It is the only number compared with a target or a capacity, shown as “39 / 40 d”.
Spec/plan is the estimated time of specifications and plans, shown apart and labelled “outside capacity”.
Unestimated counts the tasks and bugs without an estimate (“2 unestimated”): they weigh nothing until someone estimates them.
Durations use one format, with one decimal at most: “17.5 d”, “18 d”.

On a release page, the load block also compares the target of the release with the capacity of its cycles (the cycles that hold at least one of its issues) and shows the signed gap, for example “Target 40 d · Cycle capacity 51 d · Gap +11 d”. A cycle shared with another release counts in full in each of them. It is information only: nothing forces the two numbers to match.

A cycle shows its own total at the top of the workload panel, for example “Planned development 17.5 / 18 d · 97% of capacity”, then each team with its days and its percentage of the team capacity. Work assigned to a team without naming a member is labelled “Assigned to the team, no member”. When a cycle has no capacity, the load is shown without a percentage and a message asks you to define the composition.

Why This Matters

The capacity system is what separates planning from wishful thinking.

Without it, you discover the problem at the end of the sprint when half the tickets are still open. With it, you see the problem during planning and can make a real decision: cut scope, add capacity, or extend the timeline. The choice is explicit rather than discovered under pressure.

Capacity Management