Projects and backlog

Project Lead creates a Projects row with a Key prefix that namespaces the issue key (AUTH, BILL, IT), project type (Software / Infrastructure / internal IT / Research), Lead, product owner, scrum master, Team, issue rollover rule (move to backlog or move to next sprint), auto transition on merge (whether PR-merged auto-flips the linked Issue), standup timezone, and notify to (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-issue type Workflows are cloned from the Admin defaults and may be customized at Project scope.

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 initial status, Priority: Medium defaulted, and emails the Reporter with the issue key acknowledgement. Bug-type Issues trigger bug-priority-recompute immediately.

On the Backlog’s grooming cadence, the Product Owner opens the Project Backlog view, ranks Issues via backlog rank, sets Estimate on issue type requires estimate = true rows, assigns parent epic and tentative fix version. For Sprint planning, the Scrum Master opens a Future Sprints row (with Goal, start date, end date, Board, capacity points defaulted from team velocity trailing three average), pulls top-ranked Backlog Issues into the Sprint by setting issue sprint to the Future Sprint, until the committed estimate matches capacity.

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 reporter visible. 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.

• Project Backlog. Open the current records for this module within your assigned role and permitted scope.