Fix Delivery

A triaged defect needs a practical next action. Project Manager creates the corrective task within a work package and assigns the Developer who will investigate or implement the change. The task holds priority, estimated hours and a due date. Its description includes the defect’s issue key so the person doing the work can return to the reported behavior.

The task and defect describe different aspects of progress. A task can be In Progress while its owner investigates the correction. A defect becomes Fixed when the change is ready for independent assessment. The task then moves to In Review while the QA Engineer checks the result. Keep both records current so planning discussions do not mistake implementation progress for an accepted fix.

• Work-package scope. Group corrective tasks within the project work package that owns their delivery. The package carries its own start and end dates and estimated hours. Confirm the task’s project matches the package’s project before using their totals in a delivery review.
• Assigned next action. Give the task a clear title, assignee and priority. Record the issue key in its description and explain the correction being attempted. Use the task’s start date and due date to discuss when the owner expects to begin and finish the work.
• Visible interruption. Mark a task Blocked when the owner cannot proceed and explain the reason in its description. Project Manager resolves the delivery dependency or reprioritizes the work. Return to active work when the obstacle is addressed and retain enough explanation to understand the interruption.

Agree how task priority is chosen alongside defect severity. Severity describes the impact of the problem; priority expresses the team’s current order of work. Decide how the Project Manager handles an urgent investigation that competes with an existing commitment and when the Delivery Lead needs to review the staffing position.

Define the evidence a Developer provides when handing a correction to QA. Include the behavior being changed and the conditions the tester should repeat. Agree when actual hours are updated on the task and how those values relate to separately booked time entries. The team should understand both measures before using them to judge an overrun.

For the checkout discount defect, Project Manager creates a task in the checkout work package and places the issue key in the description. The Developer starts the investigation, updates the task to In Progress and records the correction. If a required test environment is unavailable, the task becomes Blocked with an explanation and an owner for the next action.

Once the correction is ready, the Developer presents the defect as Fixed and the task as In Review. QA Engineer follows the issue key back to the original report and repeats the reported behavior. Only after the correction is accepted should the task move to Done. Rehearse a task that reaches Done too early and confirm that the defect still needs its separate verification decision.

• Tasks In Flight — Active corrective work and tasks awaiting review, with assignees and due dates.
• Task Board by Status — Tasks arranged by delivery state for discussing the next action.
• Blocked Tasks — Interrupted work with its owner and explanation visible.

Use fix and verification, then follow project delivery review when the work package is ready for acceptance.