Project Performance Software

Performance, scoped to one project

"Project performance" gets used loosely enough to mean almost anything: team morale, budget, scope creep, vibes in the standup. Here it means something narrower and more answerable: for this specific project, is the pace of work fast enough to land on the date you told someone, and which stage of the pipeline is eating the time. Everything else that gets filed under "performance" is a separate conversation with a separate answer.

ShipSprint answers both from the project's own board and its own history, not from a status someone typed in a Friday afternoon update. The forecast is a live calculation, not a guess frozen at kickoff, and it's scoped to this one project (its own velocity, its own cycle time, its own history) rather than an average across everything the team happens to be touching.

That distinction matters more than it sounds. A plan made in week one degrades every week after, silently, unless something recalculates it against what's actually happening. Most tools never recalculate. ShipSprint does it every time a sprint closes, and teams that switch usually notice the difference the first time a project quietly turns amber two sprints before anyone would have caught it in a meeting.

It also means the answer to "how's the project going" changes depending on when you ask, which is uncomfortable the first time you see it and useful every time after. A project that looked fine in week three and looks at-risk in week six isn't lying to you twice. The second read is simply more informed than the first, because it has more completed sprints behind it.

The alternative, a status set once and revisited only when someone remembers to, fails in a specific, predictable direction. It fails optimistic. Nobody proactively downgrades a project from "on track" to "at risk" in a status field; that update tends to happen only once the deadline is close enough that everyone can already feel it slipping. A recalculating forecast doesn't have that bias, because nobody has to be the one to change it.

This is also why the useful moment for this page isn't the deadline itself. It's the six or eight weeks before it, when a forecast quietly crossing from in-range to at-risk is still something you can act on. Add a person, trim scope, push back a dependent launch. By the week the deadline actually arrives, all a report can do is confirm what everyone already suspected.

Why the forecast needs a running start

A forecast built from measured velocity is only as good as the velocity it has to measure. In a project's first sprint or two, there isn't much history yet, so the number is closer to a rough estimate than a confident prediction. Give it a few completed sprints and it firms up considerably, because it's watching your team's actual pace, not a template pace borrowed from somewhere else.

This is also why the forecast is more useful mid-project than it is on day one. Ask it in week two whether a March launch is realistic and it will hedge. Ask it in week six, after four sprints have closed, and it'll tell you plainly, because by then it has something real to measure against.

Where the time actually went

"Behind schedule" is a diagnosis; it isn't a fix. The more useful question is which stage of the project's own pipeline is holding things up, and that's what cycle time by stage is for. A project that's slow because work sits in code review for four days needs a different response than one that's slow because requests keep arriving faster than the team can absorb them: more reviewers versus tighter intake.

Both show up as distinct, separable signals rather than one blended "it's late" status. Cycle time by stage points at the first; WIP limits and triage-inbox volume point at the second. Neither requires reconstructing the story from memory in a retro two weeks after the fact, which is usually where teams on ShipSprint say they got the most time back.

There's a third pattern worth naming separately: work that isn't slow at any single stage, but keeps getting reprioritised before it finishes one. That shows up differently again: not as a stalled card or a queue, but as items that keep moving without ever reaching done. Watching cycle time alongside throughput catches this, because throughput stays flat even while individual cards appear to be in motion.

What this replaces

• The manual "where are we" thread: the project's status is a live read of the board, not a paragraph someone writes before a meeting.
• The end-of-sprint surprise: a slipping date shows up as a trend, not as news on the day it was due.
• The separate hours spreadsheet: logged time rolls up to this project automatically from the five-second entries people file next to their tasks.
• The retro guesswork about where time went: cycle time by stage answers it directly, from the board's own history.