WI-03 Task

Work Instruction for Task configuration items

1. Introduction

1.1. Purpose

This Work Instruction provides the set of tasks required to be performed as part of the Task configuration item lifecycle.

1.2. Scope

This Work Instruction covers the complete Task lifecycle, from creation to obsolescence.

1.3. Records and evidence

Records for each Task will be held based on the records and retention policy. Tasks are used to generate the following artifacts:

Change request verification report

1.4. Responsibilities

As listed in the procedure description, each task in the Task item’s lifecycle will be completed by a member that is part of one of the following approval steps. When any of these members can perform the task, Anyone is listed.

Item Assignee: The person authoring and responsible for the Task. This organization member is responsible for managing/completing the Task lifecycle activities.

2. Procedure description

2.1. Step 1: Log into Jira

Anyone

Log into your Jira organization, e.g., your-company.atlassian.net.

2.2. Step 2: Create

Anyone

Press the Create button in the top-level navigation to open the form to create a new Jira issue.
Ensure the desired project is selected, and select the Issue type "Task". If that does not appear, check with your system administrator to ensure your project is connected to Ketryx.
Define an appropriate title in the Summary field.
Define an appropriate Assignee (the Item Assignee).
Provide additional preliminary information in the extra fields. (All fields can still be edited later.)
Press the Create button at the end of the form to finalize the creation of the new Jira issue.

2.3. Step 3: Navigate to the issue page

Anyone

Using the popover shown by Jira or other means, navigate to the Jira page of the Task, e.g., your-company.atlassian.net/browse/TSK-1.

2.4. Step 4: Change status to In Progress

Anyone

Change the issue status to In Progress using the issue status selector.

2.5. Step 5: Draft/Author Task

Item Assignee

As needed, fill in the information in the fields of the Task.

Ensure that at least the following fields are filled out:

Summary (title)
Assignee
Description
Introduced in version

If the task is used for implementing a design, set the Implemented items (Requirements, Software Item Specs, Hardware Item Specs, Anomalies, Change Requests, CAPAs) as appropriate. These constitute the design input for this Task.

On the other hand, if the task is used for a regular project management task (e.g., writing documentation), set the Related items field if it relates to any items.

The Task should be SMART (Specific, Measurable, Achievable, Relevant, and Testable). The Task should also:

be traceable to all other needed items, with clearly defined interfaces;
not conflict with another Task; and
conform to any provided design input.

2.6. Step 6: Reference task in the development workflow

If the following actions are taken, the task will have additional development information under the Details section in Jira.

Branches: Including the issue key in the branch name when a branch is created links the branch to the Jira task.
Commits: Include the issue key in the commit message to link the commit to the Jira task.
Pull requests: Include a commit in the pull request with the task Jira issue key in the commit message. Ensure that the source branch name also includes the issue key in the branch name.
Mentioning a Jira issue key in the description of the pull request will associate the pull request with said Jira task.
Builds and deployments: Build information works by default for connected CI/CD pipeline tools.

Example of development status of a Task:

2.7. Step 7: Change status to Resolved (Ready for Review)

Anyone

Once the Task is completed and ready for design verification, change its status to Resolved.

2.8. Step 8: Review as Owner

Item Assignee

Review the Task to verify:

The Task is traceable to all other needed items, and all interfaces are defined.
The Task is Specific, Measurable, Achievable, Relevant, and Testable (SMART).
The design output (the Task and its siblings) conforms to the design input (the Task's Implemented items).

If the verification fails, reopen the ticket and, if needed, provide a comment on the reason it failed, then go to Step 5. If verification passes, approve the Task as seen in the screenshot below and continue to Step 9.

2.9. Step 9: Transition to a controlled state

Ketryx

Only Ketryx can move a Task to a controlled and effective state by transitioning its status to Closed. Ketryx moves the Task to a Closed state after all approval rules have been passed, i.e., all required steps have approved the Task.

Ketryx automatically adds a comment to the Jira issue with a link to the effective controlled record in Ketryx.

3. Procedure flow diagram

{height=70%}

4. Item schema

Description (rich text): The Task description. The task description should define clearly how to implement a certain requirement/software item. Tasks should be Specific, Measurable, Achievable, Realistic, Testable (SMART).
Introduced in version (version reference): The first version this item is effective in. If empty, the item is considered effective from the start of the project.
Implemented items (-> Requirement, Software Item Spec, Hardware Item Spec, Anomaly, Change Request, CAPA): The items implemented through the specific task.
Related items (-> Software Item Spec, Hardware Item Spec, Requirement, Anomaly, Change Request, CAPA, Risk, Test Case, Complaint, Configuration Item): The items related to this task.