Features · Backlog & sprints
Backlog & sprints that keep their promises
Stable ordering, one active sprint at a time, and nothing falls through when it closes.
Your backlog is a single ordered list, ranked with LexoRank-style strings so moving a ticket writes exactly one row — no mass renumbering. Sprints follow a strict lifecycle: planned, active, completed, with one active sprint per project at a time. When you complete a sprint, anything not done goes straight back to the backlog, so nothing silently disappears.
What you get
- Single-row reordering — Each ticket carries a lexicographic rank string over the alphabet a–z; moving it between two neighbours computes a midpoint string and updates one row.
- Nightly rebalancing — A scheduled job runs at 03:00 and, when any rank in a project grows past 20 characters, rewrites that project's ranks as short, evenly spaced strings with room for future inserts.
- Single-active sprint guard — Starting a sprint is rejected with a conflict if another sprint is already active in the project, so your board always reflects one current sprint.
- Unfinished work returns — Completing a sprint moves every ticket whose status category is not Done back to the backlog and stamps the sprint's end date.
- Sprint goals and workload — Each sprint carries an editable goal, and a workload panel totals tickets and story points per assignee, with the unassigned bucket always listed last.
- Team capacity planning — Set a planned point capacity per team for a sprint and compare it against actual load; over-capacity teams are flagged with a red load bar.
Ordering that stays fast
Ranks are plain strings compared lexicographically, so the database sorts the backlog with an ordinary index on (project, rank). Repeated midpoint insertion slowly lengthens rank strings; the nightly job detects any rank over 20 characters and rewrites the whole project's ranks as fixed-width strings with gaps of at least 26 between neighbours. Bulk imports get constant-width 7-character ranks up front, so imported backlogs never trigger runaway growth.
A deliberate sprint lifecycle
A sprint is planned, active, or completed — nothing else. Only a planned sprint can start, and starting sets the start date to today with an optional end date. Only an active sprint can be completed, and a completed sprint refuses new tickets. Sprint management — create, start, complete, and assigning tickets to a sprint — sits behind a dedicated permission, separate from ordinary project membership.
Planning signals where you plan
The backlog page shows each open sprint with its running point total, goal, and end date. Open the workload panel for a per-assignee breakdown of tickets and points, and a per-team view of load against planned capacity. You can group the backlog by status, assignee, priority, or type; rank controls step aside while a grouping is active, because rank order only means something in rank order.
In practice
POST /api/v1/projects/CORE/sprints/{sprintId}/start
{ "endDate": "2026-08-14" }
POST /api/v1/tickets/CORE-42/rank
{ "previousTicketKey": "CORE-7", "nextTicketKey": "CORE-19" }See Iskue on your own screen
A demo takes half an hour. A pilot runs on your servers, with your data, from day one.