For Scrum Masters

You run sprints. You care about the board, velocity, and whether your team is healthy. You don’t want to learn CPM, and you shouldn’t have to. TruePPM is built so your agile surface is fully native — and the translation to the PM’s Gantt happens automatically, behind the scenes.

This is your guide. The PM’s Gantt exists. You don’t have to open it.

Sprint lifecycle

TruePPM sprints have three states: Planned → Active → Closed (plus Cancelled for a planned sprint that never starts). Only one sprint per project can be active at a time.

Planning a sprint

Open the Sprints workspace and use the Plan next button to create the next iteration. Set the name, start date, finish date, and an optional sprint goal. The default cadence is two weeks — adjust to match your team’s rhythm.

When you close a sprint you choose whether unfinished stories carry to the next sprint or return to the backlog. Sprint planning happens on the board: drag stories from the backlog into the sprint, discuss, split, estimate.

→ See Plan Sprint dialog for field details.

Activating a sprint

When the team is committed, activate the sprint. Activation locks the sprint scope for burndown tracking — subsequent scope adds are marked as scope change events on the burndown chart so you can see what arrived mid-sprint vs. what was committed.

Capacity preflight runs automatically at activation: it checks whether the sprint’s estimated story points are within the team’s available hours. If anyone is over-allocated, you see it before you start — not on day 8 when it’s too late.

→ See Capacity preflight

Closing a sprint

At the end of the sprint, use the Close action. TruePPM prompts you to choose what to do with unfinished stories: carry them over to the next sprint or return them to the backlog. Velocity is recorded from completed story points.

The retrospective panel is attached to the sprint. Action items you mark with “promote to backlog” become real tasks in the next sprint automatically.

→ See Retrospective panel

The board

The board is your daily view. Five columns: Backlog → To Do → In Progress → Review → Done. Each column has a WIP limit — when a column exceeds its limit, it turns amber (warning) or red (over limit). The default limits are IN_PROGRESS: 5, REVIEW: 3.

What you see on each card

• Task name and assignees (up to 3 avatars)
• Story points
• Sprint chip (which sprint this story belongs to)
• Critical-path indicator (if the story is on the project’s critical path — rare for sprint stories, but possible for baselined work packages)
• Blocked indicator (red border if the task has an unresolved dependency)
• Progress ring

Daily standup — walk the board

The active sprint board has a Standup button in the sprint panel header. It opens a focused walk-the-board mode that guides the team through each person one at a time, with three columns per teammate:

• Done since last working day — calendar-aware (Monday includes Friday’s completions)
• In progress today — their current In Progress and Review cards
• Blockers — blocked cards with blocker type and age; the private reason text is never shown on the shared screen

Navigate with the Prev / Next stepper, the ← / → arrow keys, or click any dot in the person rail to jump to a teammate. The Sprint Goal is pinned at the top throughout. Press Esc to exit.

→ See Daily standup — walk the board

The daily delta panel

The Sprints view carries a “what changed since yesterday” delta panel — a team-wide, chronological view of status moves, new blockers, scope injected mid-sprint, the burndown swing, and per-person activity counts. It is pull-only and status-level. A window control lets you choose 24h, 48h, or Since I last looked (Friday-to-Monday replays the whole weekend). The standup walk-the-board footer links directly to this panel.

→ See Daily standup — what changed since yesterday

WIP overload

Check the WIP overload panel if any column turns amber or red — this is a natural conversation topic after walking the board.

→ See WIP overload detection

Velocity

TruePPM tracks velocity across all closed sprints. The velocity panel shows a bar chart of the last 8 sprints with a rolling average and standard deviation. This is the number that feeds the PM’s forecast — no manual export, no spreadsheet.

What velocity drives

Your team’s velocity feeds duration suggestions for the work packages your stories roll up into. When sprint 4 closes and you delivered 34 points instead of the 40 the schedule assumed, the PM receives a revised duration suggestion in the task drawer — when they accept it, the schedule re-forecasts. You didn’t do anything — and the PM’s plan was never silently rewritten.

This is the core hybrid benefit: your team’s actual delivery rate becomes the PM’s schedule input without any intermediate sync.

→ See Velocity panel, Velocity calibration

Burndown

The burndown chart shows actual vs. ideal burn across the sprint. Key elements:

• Solid line: actual remaining story points (updates in real time as tasks complete)
• Dashed line: ideal linear burn from sprint start to zero
• Amber dots: scope additions (stories added after sprint activation)
• Vertical dashed line: today
• Forecast chip: extrapolated close date based on current burn rate

If the forecast chip shows a date after the sprint end, the conversation to have is “what do we cut?” — not “can everyone work this weekend?”

→ See Sprint burndown

Retrospective → next sprint

The retrospective panel lives inside the sprint workspace. It has two sections:

1. Notes — free-form text for the retro discussion (what went well, what didn’t, puzzles)
2. Action items — structured list with assignee, story points, and a “promote to backlog” checkbox

Action items with the promote checkbox selected become real tasks in the project backlog when you close the sprint. They show up in the next sprint’s planning session with → T-XXXXXX chips linking back to the originating retro action.

→ See Retrospective panel

Multi-team support

If you’re the Scrum Master for more than one team, the multi-team lens aggregates your active sprints across projects. You see per-project summary cards: day N of the sprint, remaining story points, capacity %, trend, and forecast close date — sorted by most-behind first.

→ See Multi-team Sprints lens

The hybrid handshake

The most important thing to understand about TruePPM’s hybrid model: you and the PM are not looking at two different tools that sync. You’re both looking at two views of the same data.

When the PM builds the schedule, they create work packages with CPM dependencies. Your team’s stories are child tasks of those work packages. Your sprint work and the PM’s schedule are structurally linked — not via integration, not via export, not via a Monday morning sync.

This means:

• You never have to update a “status report” for the PM. Your burndown is their forecast input.
• The PM never has to interrupt your sprint to ask “how confident are you?” — the aggregate milestone-health signals are always visible, and they can see your velocity trend when your team’s signal audience includes the PM tier (velocity is team-private by default).
• When scope changes happen inside the sprint, the PM sees them as variance on their Gantt immediately.

Your job is still just: run good sprints, protect the team, facilitate retrospectives, track velocity. The hybrid side takes care of itself.

→ Read the full walkthrough in The Story

Evaluate it yourself (~10 minutes)

Seed the demo (seed_demo_project --with-personas) and sign in as maya — the Scrum Master persona (password demo). The test: you should never need to open the Gantt.

1. Open the Sprints workspace. Closed sprints carry a real burndown curve and a velocity bar chart with a rolling average — not a single fabricated number. The active sprint sits mid-window.
2. Walk the board. Find the column that’s turned amber or red. That’s WIP overload, surfaced before it becomes a team-health problem — not after.
3. Open the retrospective. An action item flagged “promote to backlog” is already a real task waiting in the next sprint. No copy-paste out of Confluence.
4. Notice what you didn’t touch. No schedule, no milestone, no dependency. The velocity you just generated is what feeds the PM’s forecast automatically.

If the sprint reads as a first-class container — goal, dates, burndown, velocity — rather than a board with date columns, it clears your one-question filter: does this respect the sprint boundary?

→ The evaluation guide adds the agile-only Aurora sample (added in 0.3) for a deeper, history-rich sprint tour.

Getting started

1. Ask your admin to set up a TruePPM instance
2. Walk through the Quickstart — seed the demo project and log in as maya (Scrum Master persona)
3. Explore the Sprints workspace — the full feature reference
4. Review the Board for WIP configuration details