The following articles will introduce some common Gantt chart concepts and practices, as well as some of the key behaviors specific to Structure.Gantt. This information is being provided to help Structure.Gantt users and administrators better understand the basic principles of the app, so they can get the most benefits from using it.
Structure.Gantt depends mostly on Jira data, i.e. issues, their fields, issue links, fix versions and sprints defined in your Jira instance. Structure.Gantt reads that data to build and visualize schedules, show fix versions and sprints on the chart, and display resources. Structure.Gantt does not modify Jira data unless explicitly told to do so; it stores its own data (including configuration, baselines, etc.) separately from your Jira data and can be safely uninstalled at any time. |
Like all Gantt charts, Structure.Gantt has two basic parts: the list of tasks to schedule and the visual representation of these tasks on a timeline. The list of tasks is usually called a Work Breakdown Structure or WBS, while the visualized schedule is the Gantt chart itself.
Work Breakdown Structure usually represents a hierarchy of tasks that are "broken" into smaller tasks. A typical WBS may look like this:
Here you can see a three-level WBS: Initiatives are placed on top, then they're split into Epics and those are split into Stories. In some cases, the WBS might be much more complex, including items from several projects and possibly dozens of levels. Structure enables users to easily build and maintain very complex dynamic hierarchies. For more information on building hierarchies, please refer to our Structure documentation.
While the WBS contains your hierarchy of issues, the Gantt chart itself contains Tasks, Groups, Milestones and Dependencies, positioned on a timeline. Items of the hierarchy are transformed into Gantt chart elements.
Read more on Gantt Chart Elements.
Elements that are visualized on the timeline form the Schedule. Within the schedule, every task or group of tasks has its own start and finish dates, and the project has a start date (configured in the chart settings) and finish date (the finish date of the latest task). Once visualized, the schedule can then be adjusted at any time to achieve desired outcomes.
There are several things Structure.Gantt takes into account while scheduling tasks:
While scheduling each particular task, Structure.Gantt does the following:
For the above example, the positions of all tasks except "Story" and "Manually constrained Task" are determined by their dependencies. The position for "Story" is set to be Project Start date, because it doesn't depend on anything and there are no date constraints set for the task. The position for "Manually constrained Task" is determined by its start date constraint.
Groups are scheduled based on their children. A group's start date is the earliest start date of it's children, and it's end date is the earliest end date of its children.
In certain situations, Structure.Gantt may need to modify a task's schedule to accommodate for non-working time.
A task may be displayed with a different start date, finish date or duration in the following situations:
Tasks can be scheduled automatically by Structure.Gantt, or they can be manually scheduled based on start and/or finish dates from a user-specified Jira field.
By default, tasks are automatically scheduled based on their predecessors (dependencies), sprint or the project start date (if there are no dependencies). Manual scheduling allows users to explicitly specify task and milestone positions on the timeline.
When manual scheduling is enabled:
Manual scheduling can be extremely useful for visual planning - just drag items around the chart to see what works - or when some dates are known beforehand, such as a fixed milestone date.
Manually-scheduled tasks may be altered when Resource Leveling is run, if the leveling is set up to include manually-scheduled tasks. |
Structure.Gantt provides some visual clues to help you identify tasks that have been manually and automatically scheduled.
A solid edge indicates the task is manually scheduled. The solid edge may appear at the beginning or end of a task, depending on whether the start or finish date is manually scheduled. If both the start and finish dates are manually scheduled, a line will appear on both sides, and the task will be treated as having a Fixed Duration.
If Manual Scheduling is enabled, a task is automatically treated as manually scheduled if:
Work Estimate is an estimation of the effort required to complete a task. It does not take into account things like resource availability, work schedule, etc. Task Duration, on the other hand, is an actual projection of the task estimate, considering these other factors. For example, if Task A has a work estimate of 1 day (8 hours), it seems like it should be finished in a single day. But if it's assigned to someone who can only devote 2 hours a day to that project, the task's duration will be 4 days.
Any task goes through two phases:
In the following screenshot, two tasks, both with 1-week (40 hours) work estimates, are scheduled on the timeline. Notice that Task 2 has a much longer duration, because it's resource is available for fewer hours each day:
There are times when you may want to allot more time for a task than the amount of work required - for example, you may not need a task finished for three weeks, even though it will only take someone a week to complete it. Or you may schedule several tasks to a sprint, and it doesn't matter when each individual task is started or finished, as long as every task gets finished during the sprint.
In such cases, the task can be assigned to a fixed duration:
When a task has a fixed duration, Structure.Gantt distributes the work load evenly across the allotted period of time (taking calendar and availability into account as well). Changes to its work estimate will not affect its duration or its position on the timeline.
If you drag the edge of a fixed duration task, you adjust it's duration but do not change the work required to complete the task. For other tasks (without fixed duration), dragging the edge will adjust the work requirement and, therefore, its duration. |
Task estimates and dependencies may not be enough to properly schedule a task. The resource(s) available to work on that task could also affect how long it will take to complete. Most often, those resources are individual team members (such as the Assignee in Jira), but they might also be a team or some other type of resource. Structure.Gantt uses Jira fields, such as the Assignee field or another custom field, to assign resources to tasks.
Each resource has several properties:
It is not necessary to configure resources for Structure.Gantt. By default, all tasks are assigned to "Default Resource" - this is simply a common resource settings used to properly schedule the unassigned tasks, so tasks will still be treated as unassigned and there were will not be any allocation info shown in the Allocation Chart. |
Resource Units determine how much work a resource can handle - it's capacity. In Structure.Gantt, resource capacity is based on a scale of 1 unit = 1 person with full availability. This means:
It is possible to further fine-tune resource capacity by specifying its Availability. Availability is specified in percents for a particular time range. For example:
Availability is calculated based on the resource capacity. For example, specifying 200% for a resource with a capacity of 2 units will temporarily increase its capacity to 4 units. |
The work calendar defines the work schedule, which includes working hours, weekends and national holidays. It defines the base schedules across multiple resources.
Time Zones are useful if you have global teams.
Resource Units determine the capacity of a resource, while Task Maximum Units determines what maximum part of a resource can be allocated for a task. This means:
The Resource Usage section of the Gantt chart shows how much of a resource's time is allocated during a set time frame. In the following screenshot, "Full Time Resource" is allocated for 8 hours each day, while "Part Time Resource" is allocated for only 4 hours.
The period of time each usage square represents depends on the chart's zoom level, so zooming out will show different values for the same resources and tasks:
You can also display resource allocation in terms of percentages - how much of each resource's total capacity is assigned during the set time. You'll notice that in this example, both resources are at 100% allocation, even though "Part Time Resource" is assigned half as much work as "Full Time Resource" at any given time - this is because "Part Time" has a lower resource capacity (see Resource Units above).
A resource is treated as underallocated if it still has the capacity to do more work during a block of time (it's allocation is less than 100%). A resource is considered overallocated if it's workload exceeds its capacity during a block of time (it's allocation is over 100%).
Resource Leveling allows you to automatically manage overallocation, while still respecting each task's duration and dependencies. When a resource is assigned to more work than it has the capacity to handle at a given time, Resource Leveling will shift some tasks forward on the timeline to reducing the resource allocation.
When you run Resource Leveling, Structure.Gantt looks for points of overallocation. It then takes the following steps to resolve each:
Read more about Resource Leveling.
Assigning Leveling Priorities for tasks helps Structure.Gantt decide which tasks are more important or should be completed sooner. Tasks with higher priorities are less likely to be moved by Resource Leveling.
The Leveling Delay is an offset that is added to a task to shift it forward when you run Resource Leveling. You can change a task's Leveling Delay to make adjustments to a Resource Leveling operation without making the task manually scheduled.
Leveling Delay values are stored in Structure.Gantt's own storage and are independent from other task properties, such as Manual Start Date or Manual Finish Date.
The Gantt configuration defines how items are scheduled and displayed within the Gantt chart. If your WBS includes items from multiple projects or teams, it may be necessary to have some custom setting for certain projects, teams, or issues. For example:
Configuration Slices allow you to define specific settings for a subset of items, thus overriding the main Gantt configuration. For example, you can set a unique Leveling Delay setting for one project, use different link types for another, and change the color of certain issue types to highlight them within the chart.
In the above screenshot, we've created a slice that affects all epics in the chart. If an item's issue type is Epic, the chart will:
Aside from these two custom settings, epics in our chart will follow all other setting from our main configuration.
If you have more than one slice applied to a configuration, they are processed from top to bottom and only one slice can be applied to an item at the same time. This means if an item matches the criteria for more than one slice, only the topmost matching slice will affect the item; all other slices will be ignored for that item. See Order of Operation for more information. |
Learn more about Slice-based Configurations.
Options for defining a calendar in Jira are limited to the number of hours in a working day and the number of working days in a single week. That's often not enough for real-world planning of multiple resources with different schedules, so Structure.Gantt allows you to:
Adding multiple work calendars to a Gantt configuration allows you to more precisely control common resource schedules and work with resources of different work schedules. This means you can easily track resources available 24 hours a day alongside resources only available during normal business hours.
Learn more about Calendars.
When creating multiple calendars, we recommend starting with a basic calendar that includes universal times or dates, such as national holidays. Using this as the base, you can then create multiple variations to define working hours for resources of different shifts, keeping the holidays the same.
Once you have several common calendars, specify individual vacations and other availability periods using Resource settings, rather than creating a unique calendar for every resource.
Jira allows you to specify a conversion for hours in a work day and working days in a week, which are used when you work with things like estimates, time spent and other time-related values. These conversion ratios are used across the entire app for representing time in a readable format (for example, 2d 1h instead of 17h). Structure.Gantt uses these same conversions for Day and Week, in order to maintain consistency within the Jira environment.
Even though Structure.Gantt provides its own calendars (which may contain a different number of hours per day or working days per week), all time values will still be converted into days and weeks using your Jira settings.
Let's see how this can affect your chart:
Even though this is a "1 day" task, before Structure.Gantt places it on the timeline, it first needs to convert it into hours, using your Jira settings - which say that 1 day = 8 hours. So that "1 day" task is actually an "8 hour" task, and since your half-time resource only works 4 hours per day, it will be scheduled for 2 days on your chart.
To learn more about creating and configuring a Gantt chart, see Creating a New Gantt Chart and 2021-12-08_16-30-23_Gantt Configuration.