This page refers to Portfolio classic plans. If you are currently running Portfolio 2.0, please check this link to access the latest page version.
Along with dependencies, it is possible to model time constraints for automatic scheduling. Portfolio for JIRA supports the concept of earliest start dates as time constraints.
Earliest start date constraints can be defined in the backlog table for each issue in the backlog. The earliest start constraint guarantees that an item is not scheduled before a defined date, even if it has higher priority relative to other backlog items, or there are free resources.
Start by showing the earliest start column, which is hidden per default:
Here are some examples of earliest start date constraints and how they impact the schedule:
|1||Earliest start constraint on an epic - Applies to all stories within the epic, so all the stories can be scheduled from 01/Aug/2014 at the earliest. In practice, they might be scheduled even a few day later, with the beginning of the next sprint (if using iteration-based scheduling).|
|2||Earliest start on a story within an epic that has a start date constraint: The setting on story level overwrites the setting on epic level, so this story can only start on Oct 1st.|
|3||Earliest start constraints on story level - Apply only to the particular stories, other stories within the epic are not influenced, so if another story is scheduled earlier, the whole epic can start earlier than the start date constraint of some of its child stories.|
Using the earliest start constraint in association with dependencies gives the possibility to work with situations when teams need to consider external deliverables, for example: other teams or suppliers are expected to deliver required components by a defined date. Yet, these external resources might not be known and modeled on the roadmap. Using the earliest start constraint in association with dependencies gives the possibility for an easy workaround for this feature:
Example: "Component A" needs to be delivered by someone else and is expected for July 1st. Then just add a backlog item (Epic or Story) for component A, without any estimate, but with an earliest start date of July 1st. Since there is no estimate, the item will be completed (delivered) straight on July 1st, and now other backlog items can have a regular dependency to "component A" to be scheduled only after July 1st. the benefit is that you have the delivery deadline managed in a central place.