These cookies are required for the website to function properly. They ensure security, enable basic features like page navigation, and store user session data. You cannot disable these cookies.
- IT Projects PM
- Features
- Roadmaps and delivery insights
Roadmaps and delivery insights
Review epic progress and iteration history using dated evidence and consistent estimate units.
OverviewEpic Progress×
IT Projects PM · Roadmaps and delivery insights
New
Epic Progress
Epic progress
| Epic | Owner | Status | Target version | Total issues | Done issues | |
|---|---|---|---|---|---|---|
| Shareable analytics views | Amina Yusuf | Open | Portal 2.4.0 | 30 | 860 | |
| Payment event integrity | Leo Martinez | Closed | Inventory 1.8.2 | 80 | 420 | |
| Payment event integrity | Priya Raman | Open | Scheduler 3.1.0 | 600 | 630 | |
| Safer production releases | Daniel Kim | Closed | Payments 2.0.1 | 880 | 280 | |
| Knowledge search overhaul | Sofia Novak | Open | Knowledge Hub 1.5.0 | 160 | 850 |
6 of 6 records
Amina YusufEpic progress · EP-85441
OpenEpicShareable analytics views
Target versionPortal 2.4.0
Total issues30
Done issues860
Percent complete41,885.42
What you can do
Sprint close, retro, rollover
On the Sprint end date 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 sprint outcomes for all committed, added and removed issues. It then applies project issue rollover rule: either nulls issue sprint (back to Backlog) or sets it to the next Future Sprint. The velocity-recompute job upserts the Sprint’s team velocity row with committed points (from sprint commitments), completed points (from immutable sprint outcomes 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 retrospective notes on the closed Sprint.
Release cut
As Issues complete with fix version = <version>, the Project Lead readies the Version. On version 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 released at, applies an issue labels row released-<version>, updates parent epic progress 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 + issue type 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 sprint outcomes, 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.
What your team sees
- Epic Progress. Open the current records for this module within your assigned role and permitted scope.
What it keeps track of
Data model- Epics
- Large bodies of work that span multiple Sprints — first-class master even though
IssueType=EpicIssues exist. The Epic record carries the rolled-up status and the link to all child Issues. - Epic progress
- Derived per-Epic rollup — total / done / in-progress / backlog Issue counts and estimate sums. Recomputed by the issue status-transition workflow on every Issue change inside the Epic.
- Milestones
- Non-version delivery checkpoints per Project (alpha cut, beta cut, GA, security review pass). Distinct from Versions, which retain reviewed release cuts; deployment needs separate external evidence.
- Burndowns
- Per-Sprint daily data points — the X / Y series feeding the Burndown chart. One row per Sprint per day from start date through end date.
- Team velocity
- Per-Project per-Sprint velocity rollup — committed vs. completed points, carryover, and the trailing-3-sprint average used as suggested capacity for sprint planning.
- Sprint outcomes
- Immutable per-issue closure observations frozen before rollover; historical velocity never reads a moved or reestimated current issue.
Who uses it
Permissions- Project Lead / Product Owner
- Reviews scope and milestones.
- Scrum Master / Iteration Manager
- Analyses iterations.
- Stakeholder
- Reads explicitly granted project context.
Set up IT Projects PM your way.
Start free, then use Proto to change fields, steps and approvals before your team goes live.