Roadmaps and delivery insights

Sprint close, retro, rollover

On the Sprint EndDate the Scrum Master flips Status: Active → Closed. The sprint-end-rollover workflow fires, finds every Issue in the closing Sprint with Status NOT IN (Done, Cancelled), and first freezes SprintOutcomes for all committed, added and removed issues. It then applies Projects.IssueRolloverRule: either nulls Issues.Sprint (back to Backlog) or sets it to the next Future Sprint. The velocity-recompute job upserts the Sprint’s TeamVelocity row with CommittedPoints (from SprintCommitments), CompletedPoints (from immutable SprintOutcomes recorded before rollover, using the agreed estimate unit), and Carryover; refreshes the trailing-3 average. The retrospective digest emails to Scrum Master + Project Lead. Scrum Master writes RetrospectiveNotes on the closed Sprint.

Release cut

As Issues complete with FixVersion = <version>, the Project Lead readies the Version. On Versions.Status: Unreleased → Released (typically after a release-board sign-off and CI green), release-cut-from-version fires, validates every Issue in the proposed version is completed or explicitly excluded before the reviewed release scope is frozen; for those eligible Issues, stamps ReleasedAt, applies an IssueLabels row released-<version>, updates parent EpicProgress rollups, and emails the release-notes digest (Issues grouped by Type — Story / Bug / Improvement) to the Stakeholder distribution list. A Released Version is not modified — additional fixes ship in the next Version.

Reporting and roadmap loop

Every role sees a scope-appropriate dashboard: Developer sees My Open Issues + the Active Sprint Board; Scrum Master sees Sprint Burndown + Velocity Trend + Stalled Issues + WIP Warnings; Project Lead sees Backlog Health + Release Progress + Epic Progress; QA sees Bugs Awaiting Verification + Bug SLA Attainment; Stakeholder sees Epic Roadmap + Release Forecast for assigned Projects; Reporter sees My Reported Issues; Admin sees Workflow + IssueType health. The Sprint Velocity Report and Sprint Burndown drive the ceremonies; the Cycle Time / Lead Time and Throughput by Type reports drive process improvement; the Release Forecast and Epic Roadmap drive stakeholder communications.

Compare the forecast with the evidence behind it

An epic with no child issues has no meaningful completion percentage. Show that missing basis rather than rendering the epic as fully complete. For an active epic, distinguish completed issue count from completed estimate and use the project’s configured unit consistently.

A burndown point describes the scope and remaining estimate observed on that day. Mid-sprint additions and removals remain visible; they do not rewrite the start commitment. Closed velocity comes from frozen SprintOutcomes, so moving an issue into a later sprint cannot change a previous report.

A milestone date and a forecast date serve different purposes. The owner records the target or accepted checkpoint, while a forecast is derived from available delivery evidence and can remain unknown when history is insufficient. Stakeholders see only projects explicitly granted to them, with internal work-log detail still masked in charts and exports.