Features · Plans, goals & docs

Plan across projects, aim at goals, write it down

Cross-project Gantt plans with what-if scenarios, goals aligned to strategic themes, and documentation spaces beside every project wiki.

Professional edition

Project wikis and knowledge bases are Standard; plans, goals and global docs spaces are Professional.

One project's backlog is never the whole story. Plans gather tickets from several projects onto one timeline — with dependencies, releases, team capacity and scenarios you can try before you commit. Goals say what the work is for and measure themselves from the tickets linked to them, grouped under the strategic themes they serve. And the writing that explains all of it lives in documentation spaces with page trees, revisions and comments, searchable in one place together with every project wiki.

Zoom: weeks · months · quartersGroup by project, assignee or team3 goal statesRevisions with one-click restore

What you get

Cross-project plans — A plan selects projects and, optionally, a TQL scope; it is private to you or visible to everyone, and only its owner edits it.
A timeline that computes — Gantt bars with parent dates rolled up from children or sprints, BLOCKS dependencies drawn as edges, release markers from version dates, a today line, and progress as done points over total.
Conflicts and the critical path — An edge is flagged when the blocked item starts before its blocker finishes, and the longest duration-weighted chain is highlighted as the critical path.
Capacity you can see — Per-team bands compare scheduled points with sprint capacity, turning red where a team is overloaded.
What-if scenarios — Create a scenario, drag bars to stage new start and due dates, compare the diff against today's plan, then commit — or throw it away. Nothing touches a ticket until you commit.
Goals aligned to themes — Each goal has a target date, a state — on track, at risk, done — and an optional strategic theme; progress is done points over total points of the tickets linked to it.
Documentation spaces — Global spaces with page trees you reorganise by dragging, restricted spaces with reader and editor members, revision history with restore, and page comments.
One search for all writing — Cross-space search covers global spaces, every project wiki and every knowledge base you can see, in one query.

See it — the plan timeline

Plan timeline. Parent dates roll up from children; BLOCKS edges flag conflicts and the critical path; releases and today are marked; a team's capacity band turns red when scheduled points exceed its sprint capacity. The dashed bar is a what-if scenario's staged move — nothing changes on the ticket until you commit.

Scenarios: change the plan without changing the tickets

A scenario is a set of staged date changes on top of a plan. While it is active, dragging a bar stages a change instead of editing the ticket; the diff view lists every move. Committing applies each change through the normal ticket update — permissions, changelog and notifications all apply — and the scenario is only deleted when every change went through. If one ticket refuses, the scenario survives with that change still staged, so a partial failure never leaves you guessing what landed.

Goals that measure themselves

A goal is linked to tickets, not to a number someone types in. Its progress is the done points over the total points of those tickets, judged by status category, so it moves when the work moves. The alignment view groups goals under the strategic themes they serve and calls out two things worth a conversation: goals that serve no theme, and themes that no goal serves.

Wikis for projects, spaces for everything else

Every project has a wiki — a page tree in Markdown with Write and Preview editing, full revision history, restore to any revision, and comments on pages. Documentation spaces take the same model organisation-wide: admins create spaces, pages form a tree you can re-parent by dragging, deleting a page re-parents its children rather than orphaning them, and a space can be restricted to named readers and editors, hidden from everyone else.

In practice

POST /api/v1/plans/{id}/scenarios                      — create a scenario
PUT  /api/v1/plans/{id}/scenarios/{sid}/changes/{ticketId}  { "startDate": "2026-03-09", "dueDate": "2026-03-27" }
POST /api/v1/plans/{id}/scenarios/{sid}/commit            — apply every staged change

GET  /api/v1/goals/alignment
GET  /api/v1/docs/search?q=rollback%20procedure

See Iskue on your own screen

A demo takes half an hour. A pilot runs on your servers, with your data, from day one.

Request a demo Read the FAQ