Team Performance Software

Team performance, measured as a team

The usual approach to team performance is to average a set of individual numbers and call the average the team's score. ShipSprint doesn't build it that way. The scorecard is a team-level view (throughput, workload against real capacity, how often commitments hold) tracked sprint over sprint, adjusted for the leave and time off that actually happened. It's a measure of the team as a unit, not an average of its parts.

Leave adjustment sounds like a minor detail until a team without it looks bad every quarter someone takes annual leave, and looks great the quarter nobody does. Compare capacity to capacity, not headcount to headcount, and the comparison stops lying. It also stops creating a quiet incentive to skip leave in order to protect a number.

None of this comes from watching anyone work. It comes from what left the board, what got logged, and who was actually available to do either: the same records the team already produces by doing its job.

Take a six-person team where two people were on approved leave for half of last sprint. A raw headcount comparison makes that sprint look like a slump. Adjusted for the leave that actually happened, it might read as completely ordinary, since the team did roughly what four and a half available people could do. That's the difference the adjustment is for: telling a real dip apart from a predictable dip nobody needed to worry about.

The same logic runs the other direction too. A team that looks flat quarter over quarter but has been quietly absorbing more leave, more onboarding time for new hires, or more support interruptions each period isn't actually flat: its output per available person may be climbing. A raw trend line would call that team stagnant. The adjusted one gives it credit for holding pace while carrying more.

Comparing teams without flattening them

Engineering, HR, marketing and operations don't produce the same kind of work, so a single scorecard format applied uniformly across all of them tends to flatter one and misrepresent the rest. Each function keeps its own templates and vocabulary on the same subscription, and the scorecard reflects that: a marketing team's throughput isn't measured on an engineering sprint clock. It's a small thing, but it's the reason an owner running engineering, HR, marketing and operations on ShipSprint can trust a comparison across teams instead of squinting at four scorecards built on different assumptions.

What stays consistent across every team is the underlying logic: measured pace, adjusted for real availability, visible to the people being measured. That consistency is what lets an owner look across departments on one screen without needing five separate reports translated into one language first.

A number worth arguing with

The point of a shared scorecard isn't to end a conversation with a number. It's to give the team and the manager the same starting point for one. If throughput dropped this sprint, the team can see it at the same time the manager does, and the discussion becomes "here's why: two people were out, and the client added scope mid-sprint" rather than a manager presenting a verdict the team is hearing for the first time.

That only works if the number is traceable. Nobody has to take the scorecard's word for it. The throughput and capacity behind it trace back to the same board and time logs the team already sees every day, so a disagreement about the number is really a disagreement about the underlying work, which is a far more useful argument to have.

It also changes the shape of a quarterly review. Instead of a manager arriving with a private assessment and the team hearing it cold, the scorecard's trend line has usually already been visible to everyone for weeks. The review becomes a conversation about what to do next: add headcount, cut scope, fix the bottleneck, rather than a reveal of information the team didn't have.

It changes hiring conversations too, in a smaller but real way. A team lead asking for another engineer has a trend line to point at rather than a feeling that things are stretched: capacity against workload, over several sprints, with the leave adjustment already accounted for. That's a stronger case than "we're busy," and it's the same number the person approving the hire can pull up and check themselves.

Where the scorecard shows up

• Inside the team's own view, updated as sprints close, with history rather than a single current-state number.
• Rolled into the owner command center alongside every other team, so cross-team comparisons don't require someone to compile them.
• Summarised in the Monday digest, so a shift in a team's pace is visible at the start of the week it matters, not at the end of the quarter.
• Backed by the same board WIP limits and triage inbox that keep new work from silently piling onto a team that's already at capacity.