Glossary

A

B

BUG

Bug - a defect or an error in implementation or a mismatch between the actual result and the expected one.

A bug created by a reviewer during the Review stage when issues were found with a task and it needs further work becomes a subtask for the executor.

Lifecycle:

• Proposed - proposed. When a bug is created, it receives this status by default.
• Rejected - rejected. If a bug is proposed by a reviewer, returned for re-review, but not fixed, it is moved to the rejection status for further re-assignment to the executor. In this case, the completion of the subtask created to fix this bug is canceled.
• Fixed - fixed. Accepted by the reviewer.

 
C

COMPETENCE

Skill level - the level of proficiency in certain skills, meaning a team member's personal ability to solve tasks of varying complexity.

The system has standard competence levels - Junior, Middle, Senior.

E

EFFORTS / ESTIMATE

Estimation of the amount of time required to complete a technical task (Task). Expressed in specific units of time (month, day, hour). The system allows users to provide maximum, minimum, and expected estimates for each type of work.

EPIC

Project business goals are a detailed set of functional and comprehensive steps taken to achieve broader corporate objectives. They have a clear final outcome and can be broken down into specific technical tasks (Tasks) to achieve this outcome.

Each business goal (Epic) in the system has a business weight.

Business Weight

The priority of a business goal (Epic) in the project, expressed as a numerical value, is determined by the system administrator based on the importance of logical dependencies in the execution of all tasks in the project.

The business weight of an Epic influences the system's algorithms in distributing the sequence of work execution to achieve the expected result within a certain time period.

On a scale from 1 to 10, where 10 represents the highest importance.

G

GANTT

The essence of a Gantt chart is the systematization and control of task deadlines, ensuring the timely achievement of business goals in a project executed outside the system.

I

INBOX

Individual workspace screen within the system, meaning that on the screen's workspace, the system displays only tasks assigned to the selected team member. Regardless of the access level within the system, users cannot view the screens of other team members.

K

KANBAN

System screen. Provides visualization of the progress of a technical task through all production stages of the workflow, from its creation to successful completion in a project that is executed outside the system. The visual process of moving a technical task (Task) through workflow stages provides users with a visualization of the real state of work processes in the project as a whole and each individual technical task in particular. Based on the information displayed on the screen, the user has quick access to control and analysis of team workload and all project work processes.

• At any given moment, the screen visually displays the current rhythm of work on technical tasks:
• Tasks at each stage of the workflow and the workload of each team member with tasks.
• The order of work execution for the project as a whole and for each team member separately.
• Visual identification of technical tasks that are "stuck" at a certain stage for various reasons.
• Completed technical tasks that have passed quality checks (Review) and/or unique quality review sub-stages created by the system administrator.
• Tasks returned to previous workflow stages for further refinement, performed by a specific team member, or tasks that require a specific Skill for execution.
• Successfully completed tasks - tasks that have been executed and have passed all quality check stages - technical tasks.

In the graphical section of the technical task card, all the information necessary for registered system users to gain a comprehensive understanding of all the work in the project executed outside the system is displayed:

• Technical task name.
• Execution deadlines.
• The number of production-related technical tasks related to this task.
• The name of the executor assigned by the QPM system.
• Number of subtasks (Subtask).
• Number of attachments (Attachments).

P

PIPELINE

Pipeline is an approved sequence of task execution designed to meet typical needs.

Each pipeline consists of multiple stages. A Pipeline stage is an individual task that requires specific competence (skill and level) and has an estimated execution time (estimate). The sequence of these stages reflects dependencies between tasks. Users can configure a Pipeline, which is a group of tasks with defined competencies and a sequence of their execution, and utilize this pipeline for other typical needs.

In QPM, Pipelines serve as a means of automating the creation of typical tasks in a project.

The configuration of technological pipelines is performed at the enterprise level and is common for all projects.

Customization option:

For each stage of the pipeline, the user has the ability to reassign the workflow through which tasks will go at this stage. Regardless of the previously created or default workflow assigned to a skill defined at this stage, the workflow defined on the pipeline screen will take priority for this stage of the pipeline.

PROJECT

Project - is a set of actions, limited in time, and aimed at solving a specific problem or achieving a particular goal.

Project statuses:

• Status "Active": This is the default status when creating a project. In this status, work on the project takes place, including the creation and decomposition of Product Increments.
• Status "On hold": Transition to this status is done manually. Work on the project is suspended in this status, and the creation and decomposition of Product Increments are not possible. Any changes to the project's data are also not possible.
• Status "Completed": Transition to this status is done manually. In this status, work on the project is completed, and the project is considered finished.

PRODUCT INCREMENT 

Product Increment (PI) is a tangible business outcome that a team achieves as a result of completing a specific block of project business goals (Epic) and is limited by a specific date. In the system, the user can create the necessary number of PIs, with each subsequent PI either complementing the previous ones or functioning independently as part of the project.

A Product Increment includes:

• A block of project business goals (Epic) that are united by a common result.
• The planned completion date for all work.

S

SKILLS

Skills in a specific field necessary to achieve the business goals (Epic) of the project. Relationship with other elements of the system:

• Each skill has its own Workflow, which represents the stages of task execution that require this skill for the performer.
• Child skills can inherit the parent's Workflow, or they can be assigned a separate Workflow.
• A skill can also be additionally assigned to the Review stage.
• Each team member possesses one or several skills with a specific competence level for each skill.
• The required skill for task execution is determined in the technical task.

SOLUTION ITEM 

Solution Item - the result of targeted work performed within a specific set of technical tasks. It can be considered as a standalone element that can be decomposed into technical tasks (Tasks) at any time.

A Solution Item can be related to other elements through input/output dependencies (execution sequence) or be an autonomous decomposition element.

Users have the ability to automate task creation - creating a pipeline for each item in the solution. The relationship between Solution Items and pipelines is established through the belonging of the Solution Item to a specific category.

CATEGORIES SOLUTION ITEM

Solution Item Category - is a grouping of Solution Items that share common characteristics and rules. The category is associated with the type of production (Pipeline) and can be predefined or changed during project work.

Solution Item Category allows you to:

• Define specific parameters for a group of tasks.
• Plan and manage tasks and stages of the Pipeline, taking into account these parameters.

Changes in the Solution Item Category can affect the distribution of tasks and resources in the future while preserving all past project work processes.

SUBTASK

A sub-element Task is a set of small subtasks, the execution of which leads to the implementation of the Task technical task. The system offers the user to break down the technical tasks of a project, which is implemented outside the system, into the necessary number of specific steps - subtasks, for the successful execution of the technical task. Each subtask contains a part of the technical task execution stage, but the overall complexity of subtasks does not exceed the complexity of the original task.

T

TASK

A technical task is a sequence of actions, the completion of which will lead to the implementation of the corresponding business goals (Epic) of the project. The system allows the user to decompose each Epic of the project into the necessary number of technical tasks for the successful realization of the business goal. Each task contains a portion of the business goal's value, but the overall complexity of the tasks does not exceed the complexity of the original goal.

TEAM MEMBERS 

All project participants are registered in the system and/or are employees of the same company. They have a set of specific skills and competencies required for the project's implementation.

TEAMS

Project participants who are registered in the system and are connected by functional tasks (if there are multiple teams) and/or are employees of the same company (if it's a single team). They have a specific set of skills and competencies required to achieve a particular project's business goal (Epic). This structure is complex, grouping participants based on the hierarchy accepted within the company, roles, project goals, processes, and more.

Executors and coordinators of any processes, regardless of their role in the project, cannot simultaneously belong to different teams (one solution item - one team). 

V

Visual review 

Visual review is a type of quality control process stage that involves the presence of visual artifacts in the task and multiple versions of these artifacts. Depending on the functional role, this type of review provides the user with the ability to:

• Upload visual artifacts.
• Add an unlimited number of artifact versions.
• Leave comments on artifact versions.
• Accept existing comments or add new ones during the review of different artifact versions.

W

WORKFLOW 

Workflow is the process that a task goes through from creation to successful completion. In the system, a workflow displays the sequence of production stages aimed at coordinating, monitoring, and managing the quality of task execution in a project.

A workflow has a clearly defined structure consisting of core stages (Workflow Stage) - TO DO, DOING, DONE. Workflow stages determine and control the progress of project task execution.

The system allows the user to configure the REVIEW stage. Configuration in the system involves creating individual sub-stages within the REVIEW stage based on the company's internal policies or the need to create additional actions during quality control of task execution and project goals.

Workflow Stage

TO DO 

Default stage in the system is a stage in which the user cannot make any changes to either the structure or the visual representation of this stage in the system. The rule of default also applies to sub-stages.

• AWAITING - The task is ready for planning (with defined skills and competence level of the executor, and tasks have estimates) and is awaiting assignment to an executor. At this stage, tasks that depend on the completion of other tasks are located, meaning they cannot be started until the previous task is completed.
• READY TO DO - The task is ready for planning (with defined required skills and competence level of the executor, and the task has estimates) and is awaiting assignment to an executor. At this stage, there are tasks whose completion does not depend on the completion of other tasks. Or, if the executor has already been assigned by the system, the task is waiting for the executor to start its execution.

DOING 

The task moves to this stage when the executor starts its execution, and time tracking begins for the task's execution.

REVIEW

This stage includes quality assurance of the completed task and may contain unique sub-stages created by the user, depending on the industry, internal company rules, or the need to create additional or intermediate quality checks for task execution and project goals. For each created sub-stage, a separate skill (Skill) may be assigned, different from the one used for this Workflow stage.

DONE 

This final stage involves completing all tasks that are on it and does not require any further action from team members. (Default stage in the system - the user cannot make changes either to the structure or to the visual representation of this stage in the system.