Process Tracking Software
Most process tracking runs on a status field someone has to remember to change. ShipSprint tracks it through where the card physically sits, which is much harder to forget.
The field that's always a little behind
The usual mechanism for tracking process state is a dropdown: Not Started, In Progress, In Review, Done. It works fine for the first week. Then someone starts a task and forgets to flip it from Not Started, or finishes one and leaves it on In Progress because they've already moved on to the next thing. The field becomes a lagging, unreliable proxy for reality, and eventually people stop trusting it and start asking instead, which is the exact manual status-chasing the field was supposed to eliminate.
The underlying design flaw is that the field and the work are two separate things a person has to keep synchronised by hand, and syncing two things by hand is exactly the kind of task that quietly stops happening under any real deadline pressure. The fix isn't a smarter field. It's removing the second thing entirely, so there's nothing left to fall out of sync.
ShipSprint doesn't rely on a status field as the primary signal. It tracks process state through board position: the column a card sits in is the status, not a separate label attached to it. Moving a card to "In review" and updating its status are the same action, because there's only one action to take. There's no second field to forget.
This isn't a workflow engine that computes state from a set of rules. It's closer to the opposite: state is whatever's directly observable, made visible in one glance rather than inferred from a report. Teams that move to this from a status-field tool usually notice the change isn't that the board looks different; it's that nobody has to ask "is this actually updated?" anymore.
There's a small discipline this requires that a separate status field doesn't. The columns on a board have to actually mean something specific, and mean the same thing to everyone using it. A board with vague columns like "In Progress" covering three different real stages of work will track process just as badly as a stale status field would. The fix isn't the mechanism alone; it's naming the columns for what actually happens at each one.
What position on the board actually tells you
Five things that make "where is this" answerable without asking.
Where a card sits left to right is the process state. There's no separate status field drifting out of sync with what's actually true. Reading the board is reading the state.
A card that's been in the same column for nine days is telling you something a status label can't: that the process has stalled at this exact step, not just that it's "in progress" generically.
Because a full column blocks new entries, cards can't pile up in an early stage while everyone pretends the pipeline is moving. A stuck stage becomes visibly stuck, immediately, rather than hidden behind an unlimited queue.
On Team plan and above, a branch moves the card and a merge closes it, so engineering process state reflects the actual code rather than someone's memory of updating a field after the fact.
A card can sit in the right column and still be stuck, blocked on someone else. One tap marks that explicitly and pulls in who can move it, adding the one piece of state that position alone doesn't capture.
The owner's view reads process state from board position across every team at once, so it's easy to see which project's stalled and which is moving, without anyone writing a status report to produce it.
When a process step's meaning or order genuinely changes, that gets written on the relevant wiki page, with history, so someone looking back later can see not just where a card sat, but why the process worked that way at the time.
What board position can't tell you
Position answers "which stage" well and "why" not at all. A card sitting in "In review" for a week could be waiting on a reviewer, waiting on a dependency, or simply forgotten. The column alone doesn't distinguish those. That's what the wiki and the blocked flag are for: writing down the why, and surfacing it to a person, rather than trying to encode every possible reason into more columns and sub-statuses.
If your process genuinely needs fine-grained sub-states, say sixteen distinct stages with specific entry and exit criteria for each, a board can technically model that with sixteen columns. But at that point the board itself becomes the thing nobody can read at a glance, which defeats the reason this approach works in the first place. There's a practical ceiling on how many columns still tell a useful story.
Most teams that hit this ceiling are trying to encode too much into the board that really belongs in the wiki instead. A column answers "which stage." A wiki page answers "what does this stage actually require, and what changed about it last quarter." Splitting those two jobs, rather than trying to make the board do both, is usually the fix, before reaching for more columns than a glance can take in.
What this looks like day to day
- Someone asks "where's the vendor contract" and the answer is visible on the board in seconds, not after a message to whoever owns it.
- A card that's been stuck for eight days stands out against ones that arrived yesterday, without anyone tagging it as delayed.
- A merged pull request closes its card the same afternoon, so engineering's board matches the repository without a manual update.
- A blocked task gets flagged from a phone, and the reason is attached, rather than the card just sitting quietly in its column.
- The owner opens the command center and sees which teams have stalled work this week, across the whole company, in one screen, without a single status meeting to produce it.
- A board's columns get renamed after the team realises "In Progress" was quietly covering two different real stages of the process.
- Someone reads the wiki page linked from a card to understand why this stage of the process works the way it does, instead of asking around.
Common questions
Column position is the primary state. Moving a card is updating its status, in one action rather than two. There's no separate dropdown to keep in sync with where the card actually sits.
Time in column is visible on the card itself, so a stalled item stands out against ones that just arrived. No separate aging report needs to be pulled.
Not as built-in sub-statuses. The practical approach is adding a column if a distinction is worth tracking on the board, or noting it on the card's wiki-linked context if it's more situational than structural.
Yes. Engineering, HR, marketing and operations each track process state through their own board's columns, on one subscription, all visible from the same owner command center. See pricing for plan details.
That's a naming problem the board itself won't resolve. The fix is agreeing on the definition and writing it down, usually on a linked wiki page, so the column's meaning stops depending on memory. It's a five-minute conversation, not a system limitation.
Yes, in the common case. A card can move from one team's board to another's, or a shared board can have columns representing each team's stage, so a handoff is still a change in position rather than a separate status update two systems have to agree on.
Related pages
See it on your own work.
A workspace your whole company will actually use is 60 seconds away. No card, no risk, nothing to install.
14-day full-access trial · sample project included · no card required