Scrum by the book - inside your project business
Product backlog, sprints, events and metrics in the vocabulary of the Scrum Guide - in the same system your portfolio reports in. The team works agile, the organisation stays answerable.
Where Scrum sits on the spectrum
And which methods are in the neighbourhood
Scrum: iterative, empirical, team-centred
Scrum sits at the agile edge of the spectrum - short cycles, empirical control, self-organising teams. In WORKSPACE.PM that is no island: the container concept lets agile and classic workstreams run side by side in the same initiative, and teams that want flow instead of timeboxes switch to Kanban.
Where Scrum grinds against project business
Four patterns from teams working agile inside organisations that report classically
Two tools, two truths
The team works in the agile tool, the organisation asks in the PM tool - and someone copies between them every week.
Story points meet status report
Management wants percentages and dates, the team delivers points and sprints. The translation ends up on your desk.
Events without memory
Daily notes in chat, review results in slides, retro decisions nowhere - none of it lands on the work itself.
A backlog is not a backlog
The order lives in heads and spreadsheets. Whoever missed the meeting prioritises differently - and nobody notices.
The Scrum anatomy - and what backs it in WORKSPACE.PM
Six elements from the Scrum Guide, each with the tool that carries it.
The Scrum team: three accountabilities
Product owner, scrum master and developers share accountability for the product - with no hierarchy inside the team.
Free-form roles, unambiguous accountability per card
Instead of rigid templates you define roles yourself - globally and per project, plus team roles like team lead, member and observer. On the board, Scrum logic applies: exactly one accountable person per card, and only they can commit or decline - enforced server-side.
The product backlog
The single, ordered source of all work on the product - continuously refined and reordered.
One ordered list with ten work item types
The backlog view orders by drag and drop; the rank is kept server-side per board, and sprint assignment happens in the same motion. Ten work item types from epic via story and spike to tech debt, a hierarchical label tree and parent/child card links keep the inventory tidy.
Refinement and estimation
Items are sliced and estimated until they fit into a sprint - in the unit the team agrees on.
Five estimation units, enforced by the server
Story points by Fibonacci (1-21) or linear (1-10), T-shirt sizes from XS to XXL, hours or days: the unit is set per project, and the server enforces it including the allowed value set on every create and update - no mixed estimates in the same backlog.
The sprint and its events
A fixed timebox with four events: sprint planning, daily scrum, sprint review and sprint retrospective.
A timebox with meeting series, agenda memory and review note
The sprint is created and filled from the backlog by drag and drop. The daily runs as a meeting series - open items move to the next agenda via a click marker. The close-out is guided and keeps the review note on the sprint; for the retrospective there is a wiki template and anonymous polls in the project feed.
Sprint backlog and inspection
The sprint’s work is visible at all times - the team inspects its progress based on data.
Sprint board plus a dedicated metrics page
The board filters to the sprint - to do, in progress, in review, done - with a burndown that toggles right inside the board. The metrics page adds sprint burndown with ideal line, velocity across the last ten sprints with an average line, cumulative flow, cycle time and the sprint history.
Empiricism meets the organisation
Scrum organises the team - and the organisation continues to need dates, budgets and reports.
Progress from Kanban, reporting without translation
Workstreams can measure their progress “derived from Kanban” - sprint work then feeds health indicators, status reports and the portfolio directly, without anyone converting points into percentages. Classically run workstreams live under the same roof.
Agile in the team, reliable upwards
Scrum does not end at the team boundary: through the progress method “derived from Kanban”, sprint work flows into health indicators, status reports and the portfolio without conversion. The team keeps its cadence - and the organisation gets answers in its own language.
Where Scrum is at home
Project worlds and teams where the method plays to its strengths
Frequently asked questions about Scrum in WORKSPACE.PM
The tools behind roles, artifacts, events and metrics
WORKSPACE.PM maps the Scrum anatomy: an ordered product backlog, sprints with a guided close-out, a sprint board with burndown and a dedicated metrics page. Which events you run in the system is your call - the platform follows your process. The method lives in the team, the tool carries it.
Roles are freely definable - you model product owner and scrum master exactly the way your organisation lives them: globally and per project, in four permission levels. The Scrum logic sits in the mechanics: whoever may order the backlog orders it; each card has exactly one accountable person, and only they can commit.
The sprint goal appears as a widget right on the project overview. You keep the definition of done where the team reads it: as a wiki page with a verification badge - and secure it per card via checklists. The DoD stays visible and lived.
The daily is a meeting series with an agenda: open items on a card move to the next agenda automatically via a click marker, and the minutes link cards and people. For the retrospective there is a dedicated wiki template category and anonymous polls in the project feed - and when the retro runs as a meeting, its actions move straight onto the board as tasks.
The metrics page bundles the measured truth: velocity of the last ten sprints with an average line, sprint burndown with ideal line, cumulative flow and cycle time - plus the sprint history with review notes. The team makes its sprint decisions on data instead of gut feeling, just as empiricism intends.
Yes - through the project roof: several agile workstreams work next to classic ones in the same initiative, each with its own way of working, all in one portfolio with one reporting line. Teams that want flow instead of timeboxes switch to Kanban per workstream - and organisations with a broad method portfolio run an initiative PMI-oriented.
Related methods
When your team changes or extends the framework
Start your next sprint where your portfolio lives
Create the backlog, set the unit, fill the sprint - ready in minutes.