You are viewing an old version of this page. View the current version.
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:
A customized field is specified in Administration, the Start Time is used
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"
If "Original Estimate" is empty and there are some "Working Logs", the date of the first "Working Log" will be used as Start time
If "Original Estimate" is empty and it has some dependent tasks, the value should be minimum of their "Start time".
If "Original Estimate" is empty and it has some children, the "Start time" should be the first "Start Time" of its children.
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":
If a custom field is specified in Administration, its value of custom field will be used.
If "Due Date" is not empty and the custom field is missing or unset, the value of "Due Date" is used.
If it has some "Working Logs", the date of the Last "Working Log" will be used as End time
If it has some dependent tasks, the value of "End time" should be max of their "End date".
If it has some children, the "End Time" should be the last "End Time" of its children.
If it is assigned in a version with a Release date, the last will be used as "End Time".
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:
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:
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.
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
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:
Its progress state is calculated by the sum of Spent time of its children over the sum of Original Estimate.
Same as GreenHopper, the progress state is calculated based on the number of resolved issues, instead of timing.
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.
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:
Respect JIRA Rule
1 Level Sub-Task if exists
Sub-task isn't supported
Respect the JIRA Sub-task policy, Only one level Sub-task is possible.
Respect the JIRA Sub-task policy, first level using JIRA Sub-task type, others are handled by Custom Link.
Sub-tasks is supported using JIRA Sub-task type if the project has at least one Sub-task type.
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.
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.
- No labels