Structure.Gantt Concepts Explained

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.

Data access and modification

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.

Work Breakdown Structure

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.

Chart elements

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.

Tasks - The deepest-level issues within your hierarchy become task bars, by default.
Groups - Non-issue items, such as Folders and Memos, as well as issues containing sub-issues, become Groups, by default. A group starts at the earliest start date of its sub-items and ends at the latest end date.
Milestones - Milestones allow you to mark key points within a project plan.
Dependencies - Dependencies allow you to visualize links between issues and other items. Issue dependencies are mapped to Jira Issue Links, based on your chart configuration. Changes to issue links in Jira will change your Gantt chart, and changes to dependencies within the chart will change the issue links in Jira.

Schedule

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:

Task duration and start or finish constraints
Dependencies between tasks
Project start day

While scheduling each particular task, Structure.Gantt does the following:

It takes the task and tries to determine its duration based on its properties (Work estimate, Resource assigned, etc.).
It looks for any start and/or finish constraints and schedules tasks based on those (see Automatic vs. Manual Scheduling).
If there is no start/finish constraints, it then looks for any dependencies that may affect its position and schedules accordingly (see Dependencies).
If there are no start/finish constraints or dependencies, the task is placed at the Project Start.
It repeats these steps for the next unscheduled task.

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.

Group Scheduling

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.

Task Adjustments Due to Non-working Time

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:

A task has a manual start or manual finish date that is set to non-working time. In this case, the start/finish date will be adjusted to the first or last available working day, respectively.
As you zoom in, non-working time can be collapsed, so that only working time is shown within a cell. For example, at a one-day zoom level, an 8-hour task will fill the entire cell (if you have an 8-hour schedule).

Automatic vs. Manual scheduling

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:

Tasks with start and/or finish dates listed within the Jira field(s) specified in the configuration will be scheduled based on those dates
If there are no values provided for a task, it will be automatically scheduled
Dragging a task within the chart will reschedule the task and update the associated Jira field
Manually-scheduled tasks will remain fixed on the timeline, even when tasks they depend on change

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 Levelingis run, if the leveling is set up to include manually-scheduled tasks.

Identifying automatic and 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.

Manual Scheduling Mode

If Manual Scheduling is enabled, a task is automatically treated as manually scheduled if:

It has a value in at least one of the configured Start or Finish date fields.
It was not explicitly switched to Automatic scheduling in the Task Details Panel(doing so tells Structure.Gantt to ignore an existing manual value)

Work Estimate vs. Task Duration

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:

Estimation phase: during this phase, a task is estimated without any particular knowledge about the work calendar or the resource assigned to it (this phase is done manually during a company/team's task estimation session)
Scheduling phase: during this phase, the task estimation, particular resource settings (including resource availability and capacity), work calendar and resource time zone are all used to schedule the task to get its calendar duration

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:

Fixed Duration

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:

Users can set a fixed duration by manually assigning a start and finish date, or by entering a fixed duration in the Task Details Panel.
Fixed durations will be assigned automatically when you use sprint-based scheduling.

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.

Resources

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:

Capacity
Availability
Work Calendar
Time Zone

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 (Capacity)

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:

A resource with a capacity of 1 can complete 1 hour of work per hour
If you have 8 hours of work time per day, such a resource will be able to complete 8 hours of work each day
A resource with 0.5 units (i.e. a part-time worker) can only complete 4 hours of work during an 8-hour day
A resource with 2 units (i.e. a team of 2) can complete 16 hours of work each day

Availability

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:

If a resource is on vacation, you can add an availability period with 0% availability for that time period.
If your team has an extra person joining for a particular period of time, you can create an increased team capacity period with the corresponding percentage, which will be higher than 100%.

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.

Work Calendar and Time Zone

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.

Task's Maximum Units

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:

If you have a resource with a capacity of 2 units and a task's maximum units is set to 1, that means that only 1 unit of the resource will be allocated for the task and the remaining unit will remain available.
If you have a resource with a capacity of 1 unit and a task's maximum units is set to 2, the full resource will be used on the task (1 unit) and the task duration will be calculated based on the capacity of this resource.
Assigning a resource with higher capacity will reduce the time needed to complete the task. If you assign a resource with a capacity of 2, the task will be done twice as fast. If you assign a resource with a capacity of 3, it won't speed up the completion further, since only 2 units of this resource will be allocated and one will remain available.

Resource Usage

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

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:

Identify all the tasks affected by the overallocation - those tasks assigned to the same resource at the same time
Determine which of the tasks have to be completed earlier (based on dependencies, their leveling priorities, completeness, etc.) and keep them in place
Shift other tasks forward to resolve the overallocation
If additional overallocations remain, repeat the process

Leveling Priority

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.

Leveling Delay

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.

Customizing the Chart with Configuration Slices

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:

Each project may use different custom fields to assign resources
Some teams may use different custom fields, link types, etc.
Sprints may have different names or timelines

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:

Color the item purple
Treat the item as a task even if they have child stories beneath them in the WBS

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.

Work Calendars

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:

Have several work calendars
Fine tune the availability for individual resources - see Availability above

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.

Best practices for creating 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.

Day and Week Conversions in Jira and in Structure.Gantt

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:

You have configured Jira to have 8 hours of work per day and 5 day of work per week
You have created a Structure.Gantt calendar for a half-time resource, with only 4 work hours per day
You create a task with a "1 day" work estimate
You assign that task to your half-time resource

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.