Child pages
  • Jira Issues
Skip to end of metadata
Go to start of metadata

1. Issue

Jira tracks issues, which can be bugs, feature request, improvement and any other tasks you want to track. JGCP supports all of them without any modifications on data structure. Precisely, all issues of any project in Progress can be displayed automatically in Gantt Chart.

1.1. Start time

By default, Jira has not a field corresponding to Start time of an issue. In JGCP, by default, it is a derived information of "Estimate", "Due date" and Links link dependency and containment. It is possible to use a delicate field of type Date used as "Start Time". 

Here is the algorithm:

Precedence

Description

1

A customized field is specified in Administration,  the Start Time is used

2

If the custom field for "Start Time" is missing or unset, and the "Original Estimate" is not empty, the value is calculated on "End Time" - "Original Estimate" - "Non Working time"

3

If "Original Estimate" is empty and there are some "Working Logs", the date of the first "Working Log" will be used as Start time

4

If "Original Estimate" is empty and it has some dependent tasks, the value should be minimum of their "Start time".

5

If "Original Estimate" is empty and it has some children, the "Start time" should be the first "Start Time" of its children.

6

The default value is "End Time" - 1 - "Non Working time".

1.2. End time

Here is the algorithm for determining the value of "End time":

Precedence 

Description

1

If a custom field is specified in Administration, its value of custom field will be used.

2If the custom field is missing or unset and "Resolution Date" is not empty, the value of "Resolution Date" is used.

3

If "Due Date" is not empty and the custom field is missing or unset and  "Resolution Date" is empty, the value of "Due Date" is used.

4If it has some "Working Logs", the date of the Last "Working Log" will be used as End time

5

If it has some dependent tasks, the value of "End time" should be max of their "End date".

6

If it has some children, the "End Time" should be the last "End Time" of its children.

7

If it is assigned in a version with a Release date, the last will be used as "End Time".

8

The default value is Today + "Original Estimate" + "Non Working time" (if "Original Estimate" is empty, 1 will be used).

When you modify the "End time" in Gantt Chart or Spreadsheet and if a custom field is specified, the custom field will be used. Otherwise, "End Time" is changed.

For a version, if the project is enabled for Greenhopper and the option "Enable integration with GreenHopper:" is enabled, the End Time of setting in GreenHopper is used. Otherwise, its release date will be used and End Date.   

1.3. Duration and Units

Duration is a time span of an issue. It depends on two factors: a total amount of time it would take to complete this issue and resource allocation. A total amount of time is kept in the fields "Original Estimate", "Remaining Estimate" and "Spent Time", but there is not an equivalent information about resource allocation in JIRA. We have to introduced a custom field to manage it, named as Units. Its value should be between 1 and 100. It represents the percentage of resource allocation. The default value is 100.

1.3.1. Leaf Issue

If the issue is not started, the duration is calculated using this formula:

Duration = Original Estimate * 100 / Units.

In this no-start state of issue, when we modify the duration, "Original Estimate" will be modified.

When the issue gets started, the following formula gets used:

Duration = (Remaining Estimate + Spent Time) * 100 / Units.

When the Remaining time is 0, the Original Estimate will be used.  

The change of duration of started issue via Gantt-chart will modify both "Original Estimate" and "Remaining Estimate".

1.3.2. Container Issue

The duration of a container is calculated using the sum of duration of its children. 

1.3.3. Version

Same as container issue, the duration of a version is calculated using the sum of duration of its children. 

1.4. Percent Done

The progress state is indicated by a pecerntage. The method of computing is different through issue type

Type

Description

Formula

Issue

The computing is based on Remains Estimate, Original Estimate and Spent Time from working logs.

If the issue gets started, the computing is based on:
        Spent time / (Spent time + Remains Estimate) Otherwise, it is:
        Spent time / Original Estimate

Container

Its progress state is calculated by the sum of Spent time of its children over the sum of Original Estimate of the contained issues.

If the issue gets started, the computing is based on:
        Spent time / (Spent time + Remains Estimate) Otherwise, it is:
        Spent time / Original Estimate

Version

When the option "Progress Scope" is set to "Loading Scope", its progress sate is calculated on the sum of Spent time over the sum of Original Estimation of the loaded issues, same as Container.

When the option "Progress Scope" is set to "Server Scope", the progress state is calculated based on the number of resolved issues like Same as JIRA Agile, instead of timing.

When "Progress Scope" is set to "Loading Scope", same as Contaimer

When "Progress Scope" is set to "Server Scope", the progress is calculated on:

Number of Resolved Issues / (Contained total issues)

Component

When the option "Progress Scope" is set to "Loading Scope", its progress sate is calculated on the sum of Spent time over the sum of Original Estimation of the loaded issues, same as Container.

When the option "Progress Scope" is set to "Server Scope", the progress state is calculated based on the number of resolved issues like Same as JIRA Agile, instead of timing.

When "Progress Scope" is set to "Loading Scope", same as Contaimer

When "Progress Scope" is set to "Server Scope", the progress is calculated on:

Number of Resolved Issues / (Contained total issues)


Project

When the option "Progress Scope" is set to "Loading Scope", its progress sate is calculated on the sum of Spent time over the sum of Original Estimation of the loaded issues, same as Container.

When the option "Progress Scope" is set to "Server Scope", the progress state is calculated based on the number of resolved issues like Same as JIRA Agile, instead of timing.

When "Progress Scope" is set to "Loading Scope", same as Contaimer

When "Progress Scope" is set to "Server Scope", the progress is calculated on:

Number of Resolved Issues / (Contained total issues)

2. Timing Issue

From scheduling behavior standpoint, all issues are divided in two categories through the value of the field "Due Date": Fixed-Scheduled issue and Auto-Scheduled one.

2.1. Auto-scheduled issue

An auto-scheduled issue is an issue whose field "Due Date" is empty. Its scheduled is yet really fixed. The above algorithm is used to reduce the "Start Time" and "End Time". For example, if unscheduled B issue is Start-to-Finish dependent on A, the Start date of B will be used as the End date of A.

An auto-scheduled issue becomes scheduled one when you move it by mouse or change the End date value in Spreadsheet. It is decorated by an '?' icon at left and on top of issue bar: 

2.2. Manual-Scheduled Issue

A Scheduled issue has a fixed "Due Date" or a working log, named as Manual-schedule, By default it is determined by the field "Due Date" or Custom field if it is setup. Once there is a working log, the issue remains in Manual-scheduled. It cannot go back to auto-scheduled.

If an issue depends on a resolved or closed issue, it becomes Manual-scheduled. It cannot go back to auto-scheduled by the context menu "Convert to Auto-Scheduled Issue". It can go back to auto-scheduled if all dependencies on the resolved issues get deleted..

2.3. Not Schedulable Issue

if an issue has a working log, this issue is not schedulable. It means this issue cannot go back neither to Auto-Scheduled, or not to Manual-Scheduled directly. The only solution to go back to schedulable issue is to delete its all working logs.

3. Scheduling Constraint

From the point of view of time constraint, most of issues are constrained by the working schedule. But in practice, some tasks have to be carried out beyond the Working Schedule such as Deployment, Database backup/restore. We reference an issue constraint by the working schedule as WorkingTime issue, and an issue without this constraint as Freetime issue. Anytime, a WorkingTime issue can become Freetime issue via context menu, and vice versa.

4. Milestone

Within the framework of project management, a milestone is the end of a stage that marks the completion of a work package or phase, typically marked by a high level event such as completion, endorsement or signing of a deliverable, document or a high level review meeting.

In JIRA, there is not such notation. JGCP takes any issue of any type as a Milestone when its "Original Estimate" is zero.

5. Container Issue

A container Issue is in fact a dynamic issue. The schedule of a dynamic task depends entirely on its children. The change of the duration and workload of a child issues will automatically update the one of container issue. The "Time Planning" of JGCP provides two modes: scheduling and tracking. All fields of a dynamic issue are read-only.

All "Due Date" and "Original Estimate" and working log are ignored. Its "Start Date", ""End Date" and its duration depends on its children. The "Start Date" and "End Date" are respectively the earliest date and the latest the "End Date" of its children.

5.1. Sub-task Management

Sub-tasks are a convenient way to organize tasks in hierarchy by classification or decomposition.

In JIRA, it is possible to enable or disable the support of Sub-task via the Administration. But there is a limitation: one level Sub-task is supported, it is not possible to create a Sub-task of a Sub-task. 

This plugin provides a possibility to bypass this limitation using a custom link. The table below show the possible result of combinations of JIRA Sub-task, Respect JIRA Rule and Custom Link: 

Configuration

JIRA Sub-task

Respect JIRA Rule

Custom Link

1 Level Sub-Task if exists

Other Sub-Tasks

Description

1

Disabled

 

 

X

X

Sub-task isn't supported

2

Enabled

Enabled

disabled

Sub-task

X

Respect the JIRA Sub-task policy, Only one level Sub-task is possible.

3 (default)

Enabled

Enabled

Setting

Sub-task

Custom Link

Respect the JIRA Sub-task policy, first level using JIRA Sub-task type, others are handled by Custom Link.  

4

Enabled

Disabled

disabled

Sub-task

Sub-task

Sub-tasks is supported using JIRA Sub-task type if the project has at least one Sub-task type.

5

Enabled

Disabled

Setting

Sub-task

Sub-task or Custom Link

The sub-task is used if there is a sub-task can be used. The custom-link will be used if there is no sub-task defined in project.

where "Respect Jira Rule" and "Custom Link" are the options in the administration "Global" of this plugin.

6. Version

The version is directly supported in JGCP.  The above algorithm is used to calculated the "Start Time" and "End Time" if "Release Date" is empty. 

7. Multiple Presentations of Same Issue

It is possible that an issue will be displayed more than one time. For example, an issue is fixed in more versions. In this case, one issue will be displayed with all information such as dependency and children if its has. Other presentations play a proxy; only the fields of the root issue will be cloned and all links will be ignored. The cloned issue is displayed in dash border.   

   

 

 

If "Due Date" is not empty and the custom field is missing or unset, the value of "Due Date" is used.

  • No labels