Project scheduling is a process that organizes tasks on a timeline. Viewing it from a low-level perspective, it boils down to setting start and end dates for a task. Therefore, you can see it as a roadmap of tasks you must complete within specific dates throughout the project lifecycle.
Today, we will discuss project scheduling with BigPicture for Jira. Specifically, we will focus on the Gantt chart, which you can use for Agile, Classic, and Hybrid projects. You will learn all the necessary concepts and methods to get started with project scheduling in no time.
Not a BigPicture user yet? Start your free 30-day trial today. Or visit our demo page to play with the app straight in your browser — no registration or installation needed.
Setting issue start and end dates
The first thing worth mentioning when discussing project scheduling is the task dates. As a native Jira user, you manually set your tasks’ start and end dates. To be more specific, you define dates for each issue and enter them into the respective Jira field on the issue screen.
In addition, you can use the scheduling automation plugins for Jira, like ScriptRunner, to make the date-setting process more efficient.
Handling start/end dates in BigPicture
How does the date-setting process look for BigPicture users? Since it is a Jira-based software, you can manually add start/end dates to your tasks in the same way as in plain Jira. But there is more. BigPicture gives you a lot of flexibility and automation options.
After all, no project schedule is set in stone, and your task dates can change. It may also happen that you want to add project tasks first and the dates later. Whichever it is, BigPicture will support you.
Direct operations on a taskbar
Naturally, those default dates are not necessarily the dates you want. The next step is to change them, which you can do in a few very convenient moves. Either by dragging the taskbar to change its start/end dates. Or by stretching or shortening the task to change its period.
In the video above, you can see a demonstration of basic scheduling actions in BigPicture (taskbar stretch and move). Note how the Start Date, End Date, and Duration Calendar Days columns automatically update.
Inline editing of task dates on WBS
Apart from the taskbar operations and manual update on the issue screen, you can easily edit the start/end dates for your work breakdown structure elements. Every issue field native to Jira and BigPicture can be represented as a column on a WBS, and the start and end date fields are no exception.
To customize column views, simply add the Start Date and End Date columns (and many others you may need). Then, double-click the start or end date field on a task you want to edit and enter the date (by hand or with the help of a date picker).
Task Period Alignment
The BigPicture’s scheduling mechanism can adjust the task’s start and end dates to fit the date range of the project it belongs to. In other words, the app will ensure the task does not start before you initiate your project and does not finish after you close the project.
There are more “scheduling limitation” features (period mode types) that check whether a certain date is acceptable, and we will cover them in detail later in this article.
What is a task period in project scheduling?
A task period is a timeframe, or a time interval, during which a certain task should be completed. There are two factors that determine it. The first one is the start date, and the second is the number of working days allocated for task completion.
What about the end date? The end date is the natural result of these two factors. In other words, if the task takes X working days, the end date will equal the start date plus the number of working days plus days off (e.g., weekends or absences).
There is a convenient shortcut for looking up the task duration (apart from inspecting each task individually).
BigPicture has two native fields you can add to your WBS view: Duration Working Days and Duration Calendar Days. The Calendar Days column displays the total number of days the task takes, including non-working days.
Furthermore, you can inline edit the values in the Duration Working Days, which will give the same results as the taskbar resize operation. When you edit the period value on the Working Days column, the app will automatically calculate and update the task’s end date.
What impacts the task period?
The factors that impact the task period are probably the most important aspects of project scheduling. After all, the job of scheduling is to control everything that could influence the period. It also allows us to set the period according to our expectations. Therefore, it is important to be aware of factors that could cause the scheduling to return the results you do not expect.
User’s actions
Intentional user actions are one of the factors that have the greatest impact on the task period. As we have mentioned, you can resize the taskbar on one or both ends to change its start, end, or start and end dates. Or you can move it along the timeline. The app will update the task start and/or end dates, respectively (depending on the intent of your actions).
In short, when you:
- Resize the taskbar on a Gantt chart, you change the number of days you want to allocate for a given task. When resizing, you can change one or both dates.
- Move the taskbar on a Gantt chart, you also affect its start and end dates but not the duration.
- Inline edit the start/end dates on your project WBS.
- Inline edit duration values in the Duration Working Days column.
However you choose to make the changes to the task period, these are the intentional actions you take that are meant to affect your schedule in a way you want.
Accidental user’s actions
What about unintentional changes you or one of your project resources made by mistake?
If you notice changes to your tasks’ dates you do not recognize, you can review them in the Infobar section under the Change history. The log lists the type of change, the change date, and the person who has introduced the change. So whether you meant to do something or not, the change log will tell you what happened.
Additionally, if you happen to accidentally move or resize the taskbar, use the Undo button (or ctrl+z/ cmd+z keyboard shortcut) to undo this action. You can undo only the most recent action.
Holiday plan
The task period is a sum of working and non-working days. Therefore, when you work on your project scheduling, days like individual absences, public holidays, and weekends will extend the task duration. How does BigPicture know when a given assignee is absent or there is a holiday in your country? From the Holiday plans. You can customize a default one for the whole company and assign individual plans to each of your resources.
See also: Leave and absence planning: handling resource unavailability in Jira
Dependency links
When two tasks are dependent on each other, it means that one of them must start or finish first to allow another task also to start or finish. There are four types of task dependencies, so-called Strong dependencies in BigPicture, and all of them impact the schedule.
Let’s say you have Task B that cannot start until Task A finishes (End to Start dependency). For example, the QA team cannot start testing before the development team finishes the feature. Here, Task A is the source task and Task B is the target task. So in logical terms, Task B’s start date cannot be earlier than Task A’s end date. Or, in other words, the source task determines the target tasks’ period.
Let’s take a closer look at how dependencies control the task period.
Strong dependencies vs task period
We created an epic for building a “Mobile app feature.” It has two children: “Development” and “Testing” whom we connected with an End to Start dependency link. Indeed, Testing, based on its position on a timeline and start date on WBS, starts soon after the Development has finished.
When we tried moving testing to an earlier date (so that it would start before the development has finished), the taskbar returned to its initial position. Precisely, the dependency prevented the change of the target task’s period.
Then, we moved the testing ahead of development. This time, this project scheduling operation was allowed since the start date of the target task was still later than the end date of the source task. And finally, we moved the development ahead of the testing—the app has auto-rescheduled the testing to ensure it does not start earlier than the dependency allows.
ASAP mode and Lag time
The rules governing the four dependency types are not the only dependency rules that can affect the period. In the previous example, we moved testing a few days ahead of development because this is how we dropped this taskbar on a Gantt chart. But there are two more business cases we can consider.
ASAP mode
What if you wanted the testing to start immediately after development? In such a case, you can enable an ASAP mode that will cause the target task to act immediately based on the dependency rules and the target task’s start/end date. This way, no matter how close or far you drop the target task away from the source task, it will stay right next to the source task (and auto-schedule for the next working day).
Lag time
The opposite situation is possible, too. You can set the target task to start X calendar days after the source task starts or finishes. This rule is called a Lag time. So if you set the Lag time to 3 days, the testing task will start a minimum of 3 days after the completion of the development task.
Why minimum? Without the ASAP mode, the testing can start 4, 5, or more days later, depending on how far you move the taskbar. If you want the tasks’ periods to be exactly 3 days apart, you need to enable the ASAP mode.
Task status
In Jira, and naturally also in BigPicture, you can assign different statuses to a task depending on their progress. Those statuses are: To Do, In Progress, and Done. The last one, in particular, will not affect the task period or project schedule. Why? Simply because the task is complete. In other words, its period will not change anymore (unless you re-open the issue and change its status back to “To Do” or “In Progress”).
Period mode types and task structures in project scheduling
With a scheduling mode, you determine whether you want to schedule a task manually or automatically. This way, you can decide how much control you want over the task scheduling in your project. Period mode depends on the task structure. Precisely on the relationship between the parents and their children. In other words, the task mode decides how parents affect their children and how children affect their parents.
Let’s review the parent-children structure concept quickly.
Task structures
In the picture above, you can see a tree-like graph representing a simplified project structure. The structure next to it is the same but visualized in Jira. Depending on your structure builder settings, this tree can look different. But for our mini project, we chose a typical Project>Epic>Sub-task structure. Here, the Project is a parent to its children Epic A and Epic B, just like Epic A and Epic B are parents to their respective children (Stories A, B, C, D).
What if you wanted to continue adding children and grandchildren to stories? There is no limit to how many nesting levels you can have in BigPicture. It means you can build as complex and simple project structures as you need. To keep up with your WBS, you can add the Outline level column to your view that will show you the number of nesting levels for each structure element.
We mentioned that parents and children can mutually influence their task period. They can do so in four different ways, depending on the task mode: bottom-up, top-down, locked, and manual.
Auto bottom-up
Based on what we have reviewed about the task structure, the parents are positioned above their children. Therefore, when we talk about the bottom-up period mode, it means that the lower WBS elements (children) determine the period of the upper elements (parents). Naturally, the parent element must have children for this mode to become effective.
Example:
In the example above, each epic and story in our project is set to the auto bottom-up period mode. Since here, the parents adjust their period to their children’s, let’s change the period of one of the children and see what will happen.
We stretched Story A by an additional 9 calendar days, giving 10 days in total. Epic A automatically adjusted its duration and now also shows 10 days. And since Story A has no children of their own, we can freely extend or shorten its period.
Auto top-down
The top-down mode means the parent determines the duration boundaries for their children. So if the parent is set to a certain number of days, none of their children can have their period longer than the one of their parent. However, in practice, you can extend the child’s end date beyond the end date of their parent.
Example:
So first, we tried to move the story beyond their parent’s period twice. The auto top-down period mode prevented us from letting this happen. Next, we enabled the “Period warnings” option in the view and stretched the story past the epic’s period. The app allowed us to do so but also prompted the period warning saying that the period of the parent and the child do not match.
Please notice how we could fiddle with the story’s end date (hence why we were allowed to stretch it). But the top-down mode did not let us move the story to start earlier or later than the epic (that is why we could not move it).
Locked mode
Task mode set to “Locked” means you cannot change the period of such task or story. A Locked task also sets the period boundaries for their children (the same way as the auto top-down). No automation rules will apply either. In other words, the app will not automatically reschedule a Locked task, even if there is a dependency that impacts the period of such a task.
Also, please note that a task in a Locked mode will also undo date changes you have made for that task on the Jira side.
Example:
You can change the stories’ end dates but cannot change their start dates (move them)—the Locked mode restricts the children the same way as the auto top-down does. The difference is that when you try to change the epic’s start/end dates (e.g., by inline editing them), the period mode will revert the changes to the original epic’s dates.
Manual
The manual mode is the most flexible one. In this case, no scheduling rules apply to the task period, which means you can move and stretch a “manual” parent or child as you please (the app will ignore the active task structure). It also means that the app will not automatically re-schedule tasks in a Manual mode based on the calendar or task dependencies.
Example:
The parent Epic B is in the top-down mode and the child Story C is in the manual. Theoretically, parent prevents their children from changing their period. However, Story C is in manual mode, which means it can misbehave and act as you want it, even allowing you to change its start date. (The parent is top-down which would otherwise not allow for this to happen.) Also, you can see there is a period warning reminding about Story C sitting beyond their parent period.
