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.
- Release Management
- Features
- Issues and risks
Issues and risks
Triage defects and keep delivery threats visible to their owners.
OverviewOpen Issues×
Release Management · Issues and risks
New
Open Issues
Issues
Critical2
IK-751Open iss-652
05 Oct
IK-975Triaged iss-570
05 Oct
Add
High2
IK-111Triaged iss-166
24 Oct
IK-420In progress iss-127
18 Oct
Add
Medium1
IK-939In progress iss-213
10 Oct
Add
Low1
IK-563Open iss-538
09 Oct
Add
What you can do
Issues and risks in daily work
Issues capture a defect or change item against a project, including severity, reporter, owner and reported date. When an open issue has severity, Issue Triage moves it to Triaged and creates an operation receipt. A failed attempt also produces a receipt. Risks carry category, probability, impact, mitigation and owner so the project manager can monitor a threat before it becomes a delivery problem.
How the work is organized
- Owner. QA Engineer records issue severity and checks the triage receipt; Developer follows the investigation after triage. Project Manager owns a separate risk record when the possible effect on schedule, cost or quality needs mitigation.
- Record. An issue belongs to a project and may have an owner. The triage workflow accepts only an Open issue with severity, then changes it to Triaged and writes a receipt. A risk has its own probability, impact and mitigation; changing an issue status does not update that risk.
- Decision. Check the issue receipt and risk mitigation separately before the delivery lead reports the exception.
What to agree during setup
Agree how the team assigns issue severity and risk ownership. An issue that lacks severity cannot pass the triage guard. Choose who reviews the open issue list each day and who updates mitigation as a risk moves from Open to Monitoring or Mitigated. Keep issue states and risk states distinct in discussions.
Rehearse this module with an active project and a package whose dates the team can discuss. Give each participant access to the linked records they need, then ask a second person to find the same owner, status and next action. Keep the original record available for the next review.
Check the handoff on an actual case
A critical issue is raised shortly before a deployment window. QA Engineer records severity and the project, and the triage action creates a receipt. The delivery lead looks at the triaged issue with the pending window and asks the owner for the next action. A related schedule risk can be monitored with its own mitigation.
A failed triage attempt still leaves an operation receipt. QA Engineer checks whether severity was absent or the issue had already left Open, then updates the issue itself. The project manager reviews the related risk independently.
After the triage receipt appears, check the issue owner. A severe item with no next person assigned still needs a clear handoff before the next release review.
What your team sees
- Open Issues — Find open, triaged and in-progress issues by severity and owner.
- Open delivery risks — Review open and monitored risks with their mitigation owners.
Follow the work through
See plan and delivery, issue triage and release window review for the steps around this work.
What it keeps track of
Data model- Issues
- Defects and change items raised against project work.
- Risks
- Project risks with probability, impact, owner and mitigation.
- Projects
- Engagements delivered for an organization, with budget and schedule.
- Operation receipts
- Evidence that a delivery operation was executed.
- Team members
- Delivery staff with role, practice and weekly capacity.
Who uses it
Permissions- QA Engineer
- , Project Manager and Delivery Lead.
Set up Release Management your way.
Start free, then use Proto to change fields, steps and approvals before your team goes live.