Starting to use Gantt-Chart for JIRA

Why am I getting this error?

0 issue(s) have been initialized by calculating related planning dates for start/end.

3 answers

Hi Aviva,

For the plugin Gantt-Chart for JIRA usage or error reporting, besides you posting a question here, I will also suggest you to contact the vendor/support for a faster response.

Here is the Vendor contact details:

  1. Frank Polscheit
  • Agricolaweg 7, Friedrichsdorf Hessen 61381, Germany
  • frank@polscheit.de

2. http://www.polscheit.de

All the best.

Amanda

If you have switched to admin mode, selected your project, choosen tab "Gantt-Chart", entered a project start/end date as well as a default estimation value and clicked on "generate planning dates….", but getting a note with a hint, that 0 issues have been updated ... please re-index and re-try afterwards.

Regards,
Frank

Hi Aviva and Amanda,

For existing projects, you have to generate planning dates (I recommend approach #2 below):

JIRA's standard field "due date" cannot be used as a planning end date, based on conceptual aspects (see my attached graphic on https://answers.atlassian.com/questions/151070/documentation-for-gantt-chart-plugin).
If you are using Gantt-Chart for a project already having issues before, this issues do not have valid planning dates. In that case, you have 2 possibilities:
1. manually maintain the planning start and end dates
2. switch to admin mode, select your project, choose tab "Gantt-Chart", enter a project start/end date as well as a default estimation value and click on "generate planning dates…."
If you are using Gantt-Chart for new issues, the following rules are used having enabled re-scheduling within the plugin configuration before:
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 choosen 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 recalcutations/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 customfield (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 themself, 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 calcuated as planned end date minus original estimation (duration of estimated effort taking weekends into account) multiplied by the velocity factor to strech the timeline. The velocity factor will be calcualted internally as 100/velocity and is 1.333 in this example: 3 days effort need 4 working days to be finished.

As documented inline with my Gantt-Chart:
  • 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 above, open the left tab named "Gantt-Chart", specify a default original estimated effort (> 0 days) for those issues having no estimated efforts and click on the button "generate planning dates ...". If an issue has no due date, today will be taken as planned start date. The original estimation or your default effort, if no estimation has been set, will be used to calculate the related planned end date taking (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 further question or company specific scenario not knowing how to solve with my Gantt-Chart addon, please do not hesitate to contact me and I'll try to help as soon as possible.

Regards,
Frank

Suggest an answer

Log in or Sign up to answer
Atlassian Community Anniversary

Happy Anniversary, Atlassian Community!

This community is celebrating its one-year anniversary and Atlassian co-founder Mike Cannon-Brookes has all the feels.

Read more
Community showcase
Bridget Sauer
Published yesterday in Marketplace Apps

Calling all developers––You're invited to Atlas Camp 2018

 Atlas Camp   is our developer event which will take place in Barcelona, Spain  from the 6th -7th of   September . This is a great opportunity to meet other developers and get n...

39 views 0 3
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you