Documentation for gantt chart plugin

Rahul Aich [Nagra]

Hi

Is there any documentation available for the gantt-chart plugin? I went on the marketplace but could not find one.

Rahul

Frank Polscheit

Hi Rahul,

without any planning dates (planned start and end date or mapped related customfields of type DatePicker or DateTime) no issue will be displayed within the Gantt-Chart. If you have enabled re-scheduling, the following rules will calculate planning dates: this is inline documented on the configuration tab (re-scheduling) of my Gantt-Chart plugin. If you do not have admin permissions, please ask your system administrator to get access for this information.

Automatic re-scheduling of planning dates: you must have enabled JIRA time-tracking!

Issue Creation

• having set due date and original estimation: the due date will be copied to the planned end date and the planned start date will be calculated as due date, adjusted to the prior working day in case of non-working day, minus originally estimated effort * velocity (see below).
• having set planned start date and original estimation: the planned end date will be calculated, taking a duration of the original estimation as working days into account from planned start date.
• having set planned end date and original estimation: the planned start date will be calculated, taking non-working days into account
• having set original estimation, only: the planned start date will be set to today and the planned end date calculated as today plus originally estimated effort * velocity (see below).
• having installed and enabled Greenhopper: planned start and end date will be set to its sprint's start and end date

Issue Update

• due date has been changed and no work logging has been done, the planned start and end date will be re-calculated as described above and all sub-issues as well as dependent issues will be re-scheduled keeping their duration in working days.
• original estimation has been changed and planned start date is set, the planned end date will be re-calculated using the chosen method above and all dependent issues re-scheduled if no work logging has been done for that issue (planning phase).
• remaining estimation has been changed and configured method is option #2 (see above) and planned start date is set, the planned end date will be re-calculated and all dependent issues re-scheduled.
• planned start date has been changed manually; its sub-issues will be re-scheduled as well as all dependent issues and their sub-issues.
• planned end date has been changed manually; all dependent issues and their sub-issues will be re-scheduled.
• having installed and enabled Greenhopper and assigned a fix version/sprint: sets planned start and end date to the same as of the sprint. If this sprint has no start/end date set, delete both planning dates.

Issue Rescheduling
Re-scheduling as shifting planned start/end dates, keeping the duration in working days, for dependent issues as well as sub-issues will be performed, if:

• one of the recalculations/events are triggered,
• the feature 're-scheduling' has been enabled for their corresponding project (see 'Admin' panel on 'config' screen on the 'Gantt-Chart' project tab panel or within the project specific Gant settings),
• the individual issue's Gantt option custom field (checkbox) has not been set to manual re-scheduling,
• the dependent issue (issue linkage) or sub-issue has not already been started (no work logging).

Doing the first/initial work logging for an issue, the planning dates will be copied into their related baseline dates.
Issue dependency must be done by linking the related issues using the Gantt-Dependency type as configured on the Gantt-Admin-Panel (main JIRA-Administration screen). You have to configure the dependency types and create dependencies between issues using the JIRA standard link feature or interactive linking on a Gantt-Chart.

Velocity Definition
In Scrum, velocity is how much product backlog effort a team can handle in one sprint. This can be estimated by viewing previous sprints, assuming the team composition and sprint duration are kept constant. It can also be established on a sprint-by-sprint basis, using commitment-based planning. Once established, velocity can be used to plan projects and forecast release and product completion dates.
How can velocity computations be meaningful when backlog item estimates are intentionally rough? The law of large numbers tends to average out the roughness of the estimates.

Description
The value of velocity is a percentage with a default value of 100%. If your team's velocity is generally slow, respectively over-estimate themselves, please adjust the parameter below.
For example: enter '75' als velocity, if your team finished an amount of 75% of the issues they have estimated within a time period. Based on this velocity parameter, planned start dates will be calculated as planned end date minus original estimation (duration of estimated effort taking weekends into account) multiplied by the velocity factor to stretch the timeline. The velocity factor will be calculated internally as 100/velocity and is 1.333 in this example: 3 days effort needs 4 working days to be finished.

Operational hints and additional inline documentation:

• Please add the Gantt customfields "planned start date", "planned end date", "baseline start", "baseline end" and "Gantt-Options" to JIRA's default screen for verifications as well as manual maintenance. This is not done automatically in order not to ignore JIRA system administration.
• Without having at least a planned start and end date, no issue will be displayed on a Gantt-Chart or Resource-Planning! You can either maintain that planning dates manually or just click on the related project link (tab "Gantt-Chart" within project administration), specify a project start date and enter a default original estimated effort (> 0 days) for those issues having no estimated efforts, then click on the button "generate planning dates ...".The original estimation or your default effort, if no estimation has been set, will be used to calculate the related planning dates taking different assigness as well as (non-)working days (globally, project-specific ones as well as assignee-specific ones) into account. If an issue has a due date set, the planned end date will be set to that due date and the planned start date be calculated as end date minus original estimation/default effort accordingly. Please take care to have re-indexed before in order not to miss some issues!
• Calendars: you can specify global non-working days, here. Project-specific (non-)working days can be specified by clicking on the "config"-button within the Gantt-Chart of the related project. Every user (potential assignee) can maintain all days not being available for project work by clicking on "Personal Calendar for Gantt-Charts", an additional menu item just below "Profile" on the top right (expand the menu of the login name).
• Integration into JIRA Issue Navigator (search issues) by just adding the special customfield "Gantt-Chart" as new column and cooperation with ALM-work's Structure AddOn (watch my sample video).
• Per project, you can click on the additionl tabs "Gantt-Chart" or "Resource-Planning" to focus on the issues of that project, if you have the related permission (intra-project view).
• Multi-projects can be displayed on a single Gantt-Chart by adding a Gantt gadget to your dashboard (inter-project view). Within the gadget configuration, you can specify any project(s) or JIRA filter to select the issues of your choice.
• Extended dependencies between version of the same project or inter-project: on a Gantt-Chart, you can link version to version as well as version to issue and visa versa by clicking on the interactive bubbles (left/right) per Gantt-Bar. Prerequisite: version must have own start and end date (use Greenhopper's classic board to set). There are several business cases, why to do this like for integration testing when an interface needs version 2 of project A and version 1.5 of project B. The test-task depends on both versions and cannot start if one or both shifts in time. If this timing is violated, the related dependency is displayed in red to signal attention!
• Sub-Issue handling: please create an issue and specify a planned start date (end date is not necessary nor estimation of effort, here). This issue will not be displayed on the Gantt-Chart, yet. Then create a sub-issue including an original estimated effort but without any planning dates: it will be scheduled automatically and the planning dates of the parent will be adjusted resulting in being all together displayed on the Gantt-Chart. You can create other sub-issues in the same way. The sub-issues will be treated as being linked by a finish-start dependency implicitely. So, they are building a sequence per assignee. Having different assignees, the related sub-issues will be scheduled in parallel sequences. Re-assignment will force an automatic re-scheduling. This functionality shall reduce a lot of manual efforts while entering and planning (sub-)tasks!
• Greenhopper Integration: updating an issue's rank by re-ordering (e.g. drag'n drop on Greenhopper's Rapid Board) will trigger re-scheduling of all issues of the related sprint: no Gantt-dependencies "finish-start" between the issues is necessary! Multiple assignees as well as multi-projects are supported. Initially set or update an issue's sprint will result in re-scheduling of all issues within (in case of update: the old and) the new sprint. Epics are displayed as grouping bars on Gantt-Charts on the same hierarchy level as sprints, because their issues may be spreat over multiple sprints. Within an epic, their stories are ordered ascending by planned start dates.

If you have any question, please do not hesitate to contact me at frank@polscheit.de.

Regards,
Frank