Backlog Health
Per Project: Backlog count by IssueType, by Priority, and by ParentEpic; share of Backlog rows missing required Estimates (per IssueTypes.RequiresEstimate); share missing FixVersion. The Product Owner's grooming worksheet.
Projects and backlog
Organise product and IT work by project, component and a clear backlog priority.
selected projectno sprintStatusnot Done or Cancelled
| Issue Key | Title | Issue Type | Priority | Parent Epic | Estimate |
|---|---|---|---|---|---|
| IK-556 | Lowest iss-657 | IT-3797 | Lowest | EPC-5237 | 400 |
| IK-365 | Low iss-639 | IT-7722 | Low | EPC-2365 | 890 |
| IK-758 | Medium iss-304 | IT-3806 | Medium | EPC-3817 | 390 |
| IK-221 | High iss-494 | IT-9562 | High | EPC-4666 | 760 |
| IK-380 | Highest iss-910 | IT-4651 | Highest | EPC-9960 | 560 |
| IK-966 | Critical iss-851 | IT-4743 | Critical | EPC-5029 | 340 |
Project bootstrap
Project Lead creates a Projects row with a Key prefix that namespaces the IssueKey (AUTH, BILL, IT), ProjectType (Software / Infrastructure / InternalIT / Research), Lead, ProductOwner, ScrumMaster, Team, IssueRolloverRule (MoveToBacklog or MoveToNextSprint), AutoTransitionOnMerge (whether PR-merged auto-flips the linked Issue), StandupTimezone, and NotifyTo (Slack / Teams channel or email distribution). Components line items are seeded for the project’s sub-modules (auth-service, billing-api, web-ui). The Project’s per-IssueType Workflows are cloned from the Admin defaults and may be customized at Project scope.
Issue intake
Issues land in the system through three paths: (a) UI creation by Developers, QA, or the Project Lead; (b) Reporter creation by internal users outside the squad (constrained to Bug / Task / Improvement / Incident types); © the issue-creation-from-webhook workflow firing on inbound email, Slack /issue slash command, support-helpdesk Ticket promote, or it-itsm Incident promote. The webhook code resolves target Project + Component from routing rules (subject prefix, channel, sender domain), creates the Issues row with Status: the Workflow’s InitialStatus, Priority: Medium defaulted, and emails the Reporter with the IssueKey acknowledgement. Bug-type Issues trigger bug-priority-recompute immediately.
Backlog grooming and Sprint planning
On the Backlog’s GroomingCadence, the Product Owner opens the Project Backlog view, ranks Issues via BacklogRank, sets Estimate on IssueTypes.RequiresEstimate = true rows, assigns ParentEpic and tentative FixVersion. For Sprint planning, the Scrum Master opens a Future Sprints row (with Goal, StartDate, EndDate, Board, CapacityPoints defaulted from TeamVelocity.TrailingThreeAverage), pulls top-ranked Backlog Issues into the Sprint by setting Issues.Sprint to the Future Sprint, until the committed estimate matches capacity.
Triage an issue from another team
An internal customer can report a bug without receiving the squad’s full workspace. The reporter sees their own issue and the comments or attachments deliberately marked ReporterVisible. Internal investigation notes stay within the project audience. Changing a comment’s visibility must not expose unrelated project information.
The project lead checks that the component, workflow and intended version belong to the same project before accepting the issue into the backlog. A valid issue key from a different project is not a substitute for that relationship. Duplicate reports can be linked through a controlled relationship while preserving each reporter’s access.
Prioritisation is separate from an iteration commitment. A high backlog rank makes work easier to find; it does not put that work into an active sprint or guarantee a release date. Use the project’s declared estimate unit consistently, and keep missing estimates visible when the selected issue type requires them.
Modules
-
Projects and backlog
Organise product and IT work by project, component and a clear backlog priority.
-
Sprints and commitments
Plan each iteration around a visible goal and preserve what the team committed to at the start.
-
Boards and workflow
Move work through explicit states while respecting the team’s review gates and work-in-progress limits.
-
Bugs and verification
Keep reported evidence, investigation and independent quality decisions attached to the issue.
-
Code and releases
Connect repository evidence to a reviewed release scope without confusing a merge with a deployment.
-
Roadmaps and delivery insights
Review epic progress and iteration history using dated evidence and consistent estimate units.
Reports
All reportsThroughput by Type
Per Project, per week: count of Issues moved to Status: Done bucketed by IssueType (Story / Bug / Task / Improvement). Pairs with created-count to surface bug pile-up vs. story delivery rate.
Roles and permissions
Owns the Project end-to-end — backlog priority, release planning, estimate overrides, scope decisions. The DRI for the product the Project ships.
Runs the Sprint cadence and the Board. Owns ceremonies (planning, standup, review, retro), WIP discipline, and the burndown.
Delivery contributor. Works assigned Issues, transitions Status, logs work, comments, attaches files, opens PRs that auto-link back.
Read-only audience for an assigned Project — executive sponsor, adjacent team lead, internal customer. Sees the board and the roadmap but cannot change anything.
Internal user outside the squad who needs to file Issues — IT help requesters, internal customers of an API team, stakeholders who hit a bug. Can create Issues and comment on own Issues; sees nothing else.
Quality role. Files and verifies bug Issues, transitions Issues through the verification gate, signs off on InReview → Done for Bug-type Issues.
Related processes
Intake to sprint commitment
Turn incoming work into a prioritised, reviewed iteration scope.
3 stages · 0 approvals
Work to verified outcome
Apply the same workflow and quality checks to every delivery transition.
3 stages · 1 approval
Completed work to release cut
Review eligible issue scope before recording the release version.
3 stages · 1 approval