Deliver sprint by sprint - in the same system as everything else
Product backlog, sprint board with burndown, personal commitments and metrics you can actually read: in WORKSPACE.PM, agile work is part of the platform - not a second tool beside it.
The sprint loop
The backlog is an order - prioritised by dragging and assigned to sprints.
Why agile work fails today
Rarely at the mindset - mostly at the second tool and commitments that aren't.
The backlog lives in a second tool
Agile in one system, project and budget in another. In between: export, import and two truths.
Assigned is not committed
The planner distributes cards, the team nods silently. Whether the commitment holds only shows at sprint end.
The sprint ends with a date
No closing, no note, no look back - the next sprint just starts. Nothing gets learned.
Metrics without consequence
Velocity gets reported but not read. What a kink in the burndown or a belly in the flow means, nobody asks.
One sprint in five stations - from backlog to metric
This is how a team works through sprint 18: prioritise, commit, deliver, close with guidance - and derive the next decision from the metrics.
One list, one order - the same card all the way to the board
The product backlog is its own view: you reorder open entries by dragging and assign them to a sprint in the same motion - laid out in chronological sprint columns. And because every entry is the same Kanban card, there is no duplicate object: what gets prioritised in the backlog sits in the sprint and on the board.
Prioritise by dragging, assign in the same motion - the entry stays the same card.
The sprint is filled when the commitments stand
Every card carries a commitment status - open, committed or declined. Only the responsible person can change it; the server enforces that, even against workarounds. Assignment becomes accountability: the sprint starts when the commitments are visible - filterable and groupable as swimlanes.
Only the responsible person sets the commitment status - enforced server-side.
Four columns, one rhythm - and the burndown lives in the board
The sprint board leads from To Do through In Progress and In Review to Done - with a burndown chart toggleable right in the view. The card's workflow status stays independent of the physical column, and even the invisible work has a type: from spike to tech-debt card.
To Do
3
In Progress
2
In Review
1
Done
5
The card's workflow status is independent of the column - it survives every board rebuild.
The sprint ends with a ritual - not with a date
At sprint end, a guided close dialog opens: the review note captures what the sprint showed and stays with the sprint. Afterwards the board lands in the right place automatically - the default selection works in three steps: active sprint, else the next planned, else the last completed.
A close dialog instead of a status flip - the note stays with the sprint, the default jumps to the next one.
Metrics are answers - if somebody asks the questions
The per-project metrics page bundles burndown, velocity, cycle time, cumulative flow and the sprint history - computed from the sprint data itself. Reading them is what counts: a scattering velocity makes planning more honest, a growing belly in the flow shows the jam. And the bridge to classic stands ready: WBS progress can derive from the Kanban, and every board has a Gantt view.
Cumulative flow - four weeks, three bands
The belly in the middle band is the jam - visible before anyone feels it.
You organise daily and review as a recurring series with automatic follow-up dates - and whatever is left over, the card simply takes along via “put on next agenda”.
One sprint loop, six modules - one data foundation
In WORKSPACE.PM, agile work is neither an add-on nor an import: backlog, board and metrics run on the same engine as your classic projects.
Project management
Team organisation
AI & automation
One data foundation - from backlog to metric
Backlog entry, sprint card and metric data point are the same card. No export, no reconciliation, no second truth.
And the methodology question?
Working agile here means: tools for the team - no corset from the tool.
No framework coercion
Columns, swimlanes, work-item types and bulk actions - your team sets the rules, not the tool. Working close to Scrum works; a ceremony corset doesn't exist.
Accountability without pressure
The commitment comes from the person, not the planner - and only they can give or withdraw it. Workflows can even react to the status change.
Agile next to classic - without a trench
Cards are created classic or agile but live on the same engine. The WBS can derive its progress from the Kanban, and every board has a Gantt view.
Related use cases
The sprint is running - this is what comes next.
Frequently asked questions about agile work
What teams and project leads want to know before switching.
No. Product backlog, sprint board with burndown and the metrics page are part of the platform - and the backlog entry is the same card as on the board. Project, budget and report sit right next to it, in the same system.
The building blocks are there: a backlog with prioritisation, sprints with a guided close and review note, story points in five estimation units, recurring series for daily and review. How strictly you apply Scrum is your team's call - the Scrum method page shows a mapping of the ceremonies.
Every card carries a commitment status with three states - and only the responsible person can set it, enforced server-side. Commitments are filterable, groupable as swimlanes, and the status change is available to automations as an event.
A metrics page per project with the selected sprint's burndown, historical velocity, cycle time, a cumulative flow diagram and a tabular sprint history - computed from the sprint data, without your own analytics setup.
Yes. Cards are created classic or agile but run on the same engine. The WBS can derive its progress from the Kanban cards, Kanban deadlines appear in the project calendar, and every board can be read as a Gantt.
Bring the sprint to where the project lives
Start for free: fill the backlog, plan the first sprint, toggle the burndown - and in 30 days you'll know whether it fits.