Jira Issues. 1. Issue Start time End time. 1. Issue 1.1. Start time End time

Transcription

1 Jira s 1. 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 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 Start time 1.2. End time 1.3. Duration and Units Leaf Container Version 1.4. Percent Done 2. Timing 2.1. Auto-scheduled issue 2.2. Manual-Scheduled 2.3. Not Schedulable 3. Scheduling Constraint 4. Milestone 5. Container 5.1. Management 6. Version 7. Multiple Presentations of Same 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" "Non Working time" 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. 2 If the custom field is missing or unset and "Res olution Date" is not empty, the value of " Resolu tion 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. 4 If 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".

2 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 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 Leaf 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" Container The duration of a container is calculated using the sum of duration of its children Version Same as container issue, the duration of a version is calculated using the sum of duration of its children Percent Done The progress state is indicated by a pecerntage. The method of computing is different through issue type

3 Type Description Formula Container Version Component The computing is based on Remains Estimate, Original Estimate and Spent Time from working logs. Its progress state is calculated by the sum of Spent time of its children over the sum of Original Estimate of the contained issues. 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. 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. 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. 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. If the issue gets started, the computing is based on: Spent time / (Spent time + Remains Estimate) Otherwise, it is: Spent time / Original Estimate If the issue gets started, the computing is based on: Spent time / (Spent time + Remains Estimate) Otherwise, it is: Spent time / Original Estimate to "Loading Scope", same as Contaimer to "Server Scope", the progress is calculated on: Number of Resolved s / (Contained total issues) to "Loading Scope", same as Contaimer When "Progress Scope" is set to "Server Scope", the progress is calculated on: Number of Resolved s / (Contained total issues)

4 Project 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. 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", sam e as Contaimer to "Server Scope", the progress is calculated on: Number of Resolved s / (Contained total issues) 2. Timing 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 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 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 ". It can go back to auto-scheduled if all dependencies on the resolved issues get deleted Not Schedulable if an issue has a working log, this issue is not schedulable. It means this issue cannot go back neith er 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.

5 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 A container 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 Management s 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 via the Administration. But there is a limitation: one level is supported, it is not possible to create a of a. This plugin provides a possibility to bypass this limitation using a custom link. The table below show the possible result of combinations of JIRA, Respect JIRA Rule and Custom Link: Configurati on JIRA Respect JIRA Rule Custom Link 1 Level Sub-Task if exists Other Sub-Tasks Descriptio n 1 Disabled X X isn't supported 2 Enabled Enabled disabled X Respect the JIRA policy, Only one level is possible.

6 3 (default) Enabled Enabled Setting Custom Link Respect the JIRA policy, first level using JIRA type, others are handled by Custom Link. 4 Enabled Disabled disabled s is supported using JIRA type if the project has at least one type. 5 Enabled Disabled Setting 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 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.

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