Content
View differences
Updated by Niels Lindenthal about 1 year ago
**As** a project portfolio manager
**I want to** have stages and gates adjusted adjust automatically based on changes of preceding to preceding/succeeding stages and gates
**so that** rescheduling of stages and gates administration is simpler and less error prone.
### **Acceptance criteria**
* <br>
The duration (added in ##61353) as well as the start and finish dates (added in ##61355) within the project lifecycle administration (reworked in ##61304) are editable.
* \[open\] Either it is always in edit mode or the user first needs to click to turn it into edit mode.
* \[open\] The project start and finish date (introduced in ##61355) needs to follow the same UX pattern.
* Duration can be filled independently from a stages dates.
* The duration can be set independently from the start and end date. In other words, stage might have a duration without having a start/end date set.
* The duration has to be an integer value of at least 1.
* The duration is the number of days a stage includes. Start and end date are included in that interval.
* Stages and gates are automatically (re)scheduled to the extend the information provided by the user allows for.
* See the **Scenarios** section for a detailed specification.
* \[open\] Are all the scenarios correct?
* Automatic scheduling happens as soon as two values out of the three involved attributes (start date, end date & duration) are set (analogous to work packages).
* For gates, as they have a fixed duration of 0 and only one date, that date is the only value that needs to be filled.
* Project start/finish dates behave similar to gates.
* Scheduling a predecessor (by providing two out of the three values, or the one value for a gate), can lead to the successor being rescheduled in turn (e.g. a succeeding stage/gate receives a start date) which can continue as long as each successor is completely specified.
* Since gates and also project finish dates only require a single value to be scheduled, they will always be scheduled once a predecessor is complete.
* Scheduling a successor (by providing two out of the three values, or the one value for a gate), can lead to the predecessor being rescheduled in turn (e.g. a preceding stage/gate receives a finish date) which can continue as long as each successor is completely specified.
* Since gates and also project start dates only require a single value to be scheduled, they will always be scheduled once a successor is complete.
* Stages do not receive a single date when being automatically scheduled. e.g. if a preceding gate is set, the succeeding stage does not receive a start date.
* However, if two values are then available (see above), the stage will be scheduled.
* The reason for this is that stages always require two dates to be defined.
* The date the stage would inherit from its neighbour is displayed in the table (grayed out).
* The date the stage would inherit from its neighbour is preselected in the date picker. The user can choose to select a different value.
* Active stages/gates are considered to be following each other based on the sort order in the administration.
* In case a stage/gate is inactive in a project, the next active stage/gate is considered to be the successor. Multiple inactive stages/gates can be ignored that way.
* Stages/gates not active in the project are not scheduled. In case a stage/gate is inactivated, it keeps its dates.
* The project start date is considered to be the first gate for the sake of automatic scheduling.
* The project finish date is considered to be the last gate for the sake of automatic scheduling.
* Non working days
* Are displayed in the date picker
* Are allowed values for start and end date and do not count towards the duration.
* This is subject to change, see "out of scope".
* Gaps (implicit distance between the end date of a preceding and the start date of a succeeding lifecycle step) are not allowed.
* The lag (explicit distance between the end date of a preceding and the start date of a succeeding lifecycle step) is for now always 0.
* This is subject to change in a later feature.
* The lag of 0 means
* A stage succeeding another stage will have a start date that is on the next working day relative to the end date of the preceding stage's end date.
* A gate succeeding a stage will have a date that is on the same date as the preceding stage's end date.
* A stage succeeding a gate will have a start date that is on the next working day relative to the date of the preceding stage's date.
### **Scenarios**
(Within the scope of the scenarios, when gates are mentioned, this includes the project start and finish date but not the other way around.)
#### **If the dates/duration were not filled completely before**
As stated in the acceptance criteria, scheduling happens when:
* For stages: two out of three values (start date, end date, duration) are set (one might have been set before)
* For gate: the date is set
Since active life cycle steps are always considered to be in a follows relationship, scheduling a step can lead to the successor/predecessor receiving the necessary information to be automatically scheduled in turn. Scheduling can thus propagate both along the line of successors as well as along the line of predecessors. This continues until a stage is met that has then only one value set or until the end of the chain is reached. Gates, since they only require a single value are always continued to be automatically scheduled and will schedule successors/predecessors in turn:
* If scheduling a succeeding gate: Its date will be on the date (for a preceding gate) or the end date (for a preceding stage)
* If scheduling a preceding gate: Its date will be on the date (for a succeeding gate) or one date before the start date (for a succeeding gate)
If a stage is met it will receive :
* If scheduling a succeeding stage: Its start date will be 1 day after the date (for a preceding gate) or one 1 day after the end date (for a preceding stage)
* If scheduling a preceding stage: Its end date will be on the date (for a succeed gate) or one day before the start date (for a preceding stage)
(\[open\] will the value be persisted in the database in case the stage would end up with only the start or finish date. The fontend is to display that date grayed)
The stage thus receiving a start/end date might then have two out of the three necessary values, and will be rescheduled and might continue to schedule in turn:
* If the stage used to have a duration only, it will then get its start/end date calculated:
* start date + (duration - 1)
* end date - (duration - 1)
* If the stage used to have a start/end date only, it will get its duration calculated:
* end date - start date + 1
#### **If date/duration were already provided before**
Updating an already completely specified stage can be done in three ways and each leads to a different rescheduling of the successor/predecessor:
If the start date is updated, the duration is increased/decreased accordingly. Because a date range picker is employed, the user's intend is clear. The preceding stages/gates are updating accordingly without changing their duration.
If the finish date is updated, the duration is increased/decreased accordingly. Because a date range picker is employed, the user's intend is clear. The succeeding stages/gates are updating accordingly without changing their duration.
If the duration is increased/decreased, the finish date is updated accordingly. Then, the succeeding stages/gates are moved by the same amount without changing their duration.
For gates and the project start/finish date, the rescheduling of the predecessors/successors happens accordingly.
#### If a dates/duration is removed
If the dates of a stage is removed, the duration is removed. If the duration is removed, the dates are removed. Then, the succeeding and preceding stages also might loose their dates and duration. A gate encountered like this, will always return its date. A preceding stage will loose its end date and duration. A succeeding stage will lose its start date and duration.
(\[open\] same as for when receiving dates but not having enough data to reschedule, it is unclear whether the stage should also loose its other date in the backend or wether to still keep. In either case it is to be displayed grayed out in the frontend)
The removal will not continue on after a stage is met.
#### If a stage/gate is deactivated
If a gate is deactivated, no rescheduling needs to take place. The gate will loose its date.
If a stage is deactivated, its start/finish date are removed but its duration is kept. The succeeding stage/gate and its successors are moved into the past so that no lag between the disabled stage's predecessor and successor remains.
(\[open\] This currently contradicts the figma files)
#### If a stage/gate is activated
If a gate is activated the gate receives the predecessors finish date (stage) or date (gate) for its own date.
If a stage is activated, it receives the day after the predecessors finish date (stage) or date (gate) as its start date. Its finish is the start date plus the potentially stored duration. If no duration is stored, a duration of 1 is assumed so the finish date is on the same date of the start date. Succeeding stages and gates are rescheduled into the future accordingly.
(\[open\] This currently contradicts the figma files)
#### Other scenarios
* Scenarios where the LifeCycleDefinitions are modified:
* When a definition is added:
* Expected result: No rescheduling.
* When a definition is deleted:
* Expected result: No rescheduling.
* When 2 definitions are reordered:
* Currently, no automatic rescheduling happens. But the first time the user touches the lifecycle, the out of order lifecycle steps are reordered keeping their duration unchanged.
* Scenarios where Non Working days or Non Working weekdays are modified:
* When a Non Working Day or Weekday is added or removed:
* Expected result: No rescheduling.
**Out of scope**
* Non working days are for now available start/end dates and count towards the duration.
* This is subject to change but doing so would increase the complexity.
* Adding a lag value other than 0 will be implemented later.
**I want to** have stages and gates adjusted
**so that** rescheduling of stages and gates
* <br>
* \[open\] Either it is always in edit mode or the user first needs to click to turn it into edit mode.
* \[open\] The project start and finish date (introduced in ##61355) needs to follow the same UX pattern.
* Duration can be filled independently from a stages dates.
* The duration can be set independently from the start and end date. In other words, stage might have a duration without having a start/end date set.
* The duration has to be an integer value of at least 1.
* The duration is the number of days a stage includes. Start and end date are included in that interval.
* See the **Scenarios** section for a detailed specification.
* \[open\] Are all the scenarios correct?
* Automatic scheduling happens as soon as two values out of the three involved attributes (start date, end date & duration) are set (analogous to work packages).
* For gates, as they have a fixed duration of 0 and only one date, that date is the only value that needs to be filled.
* Project start/finish dates behave similar to gates.
* Scheduling a predecessor (by providing two out of the three values, or the one value for a gate), can lead to the successor being rescheduled in turn (e.g. a succeeding stage/gate receives a start date) which can continue as long as each successor is completely specified.
* Since gates and also project finish dates only require a single value to be scheduled, they will always be scheduled once a predecessor is complete.
* Scheduling a successor (by providing two out of the three values, or the one value for a gate), can lead to the predecessor being rescheduled in turn (e.g. a preceding stage/gate receives a finish date) which can continue as long as each successor is completely specified.
* Since gates and also project start dates only require a single value to be scheduled, they will always be scheduled once a successor is complete.
* Stages do not receive a single date when being automatically scheduled. e.g. if a preceding gate is set, the succeeding stage does not receive a start date.
* However, if two values are then available (see above), the stage will be scheduled.
* The reason for this is that stages always require two dates to be defined.
* The date the stage would inherit from its neighbour is displayed in the table (grayed out).
* The date the stage would inherit from its neighbour is preselected in the date picker. The user can choose to select a different value.
* Active stages/gates are considered to be following each other based on the sort order in the administration.
* In case a stage/gate is inactive in a project, the next active stage/gate is considered to be the successor. Multiple inactive stages/gates can be ignored that way.
* Stages/gates not active in the project are not scheduled. In case a stage/gate is inactivated, it keeps its dates.
* The project start date is considered to be the first gate for the sake of automatic scheduling.
* The project finish date is considered to be the last gate for the sake of automatic scheduling.
* Non working days
* Are displayed in the date picker
* Are allowed values for start and end date and do not count towards the duration.
* This is subject to change, see "out of scope".
* Gaps (implicit distance between the end date of a preceding and the start date of a succeeding lifecycle step) are not allowed.
* The lag (explicit distance between the end date of a preceding and the start date of a succeeding lifecycle step) is for now always 0.
* This is subject to change in a later feature.
* The lag of 0 means
* A stage succeeding another stage will have a start date that is on the next working day relative to the end date of the preceding stage's end date.
* A gate succeeding a stage will have a date that is on the same date as the preceding stage's end date.
* A stage succeeding a gate will have a start date that is on the next working day relative to the date of the preceding stage's date.
### **Scenarios**
(Within the scope of the scenarios, when gates are mentioned, this includes the project start and finish date but not the other way around.)
#### **If the dates/duration were not filled completely before**
As stated in the acceptance criteria, scheduling happens when:
* For stages: two out of three values (start date, end date, duration) are set (one might have been set before)
* For gate: the date is set
Since active life cycle steps are always considered to be in a follows relationship, scheduling a step can lead to the successor/predecessor receiving the necessary information to be automatically scheduled in turn. Scheduling can thus propagate both along the line of successors as well as along the line of predecessors. This continues until a stage is met that has then only one value set or until the end of the chain is reached. Gates, since they only require a single value are always continued to be automatically scheduled and will schedule successors/predecessors in turn:
* If scheduling a succeeding gate: Its date will be on the date (for a preceding gate) or the end date (for a preceding stage)
* If scheduling a preceding gate: Its date will be on the date (for a succeeding gate) or one date before the start date (for a succeeding gate)
If a stage is met it will receive :
* If scheduling a succeeding stage: Its start date will be 1 day after the date (for a preceding gate) or one 1 day after the end date (for a preceding stage)
* If scheduling a preceding stage: Its end date will be on the date (for a succeed gate) or one day before the start date (for a preceding stage)
(\[open\] will the value be persisted in the database in case the stage would end up with only the start or finish date. The fontend is to display that date grayed)
The stage thus receiving a start/end date might then have two out of the three necessary values, and will be rescheduled and might continue to schedule in turn:
* If the stage used to have a duration only, it will then get its start/end date calculated:
* start date + (duration - 1)
* end date - (duration - 1)
* If the stage used to have a start/end date only, it will get its duration calculated:
* end date - start date + 1
#### **If date/duration were already provided before**
Updating an already completely specified stage can be done in three ways and each leads to a different rescheduling of the successor/predecessor:
If the start date is updated, the duration is increased/decreased accordingly. Because a date range picker is employed, the user's intend is clear. The preceding stages/gates are updating accordingly without changing their duration.
If the finish date is updated, the duration is increased/decreased accordingly. Because a date range picker is employed, the user's intend is clear. The succeeding stages/gates are updating accordingly without changing their duration.
If the duration is increased/decreased, the finish date is updated accordingly. Then, the succeeding stages/gates are moved by the same amount without changing their duration.
For gates and the project start/finish date, the rescheduling of the predecessors/successors happens accordingly.
#### If a dates/duration is removed
If the dates of a stage is removed, the duration is removed. If the duration is removed, the dates are removed. Then, the succeeding and preceding stages also might loose their dates and duration. A gate encountered like this, will always return its date. A preceding stage will loose its end date and duration. A succeeding stage will lose its start date and duration.
(\[open\] same as for when receiving dates but not having enough data to reschedule, it is unclear whether the stage should also loose its other date in the backend or wether to still keep. In either case it is to be displayed grayed out in the frontend)
The removal will not continue on after a stage is met.
#### If a stage/gate is deactivated
If a gate is deactivated, no rescheduling needs to take place. The gate will loose its date.
If a stage is deactivated, its start/finish date are removed but its duration is kept. The succeeding stage/gate and its successors are moved into the past so that no lag between the disabled stage's predecessor and successor remains.
(\[open\] This currently contradicts the figma files)
#### If a stage/gate is activated
If a gate is activated the gate receives the predecessors finish date (stage) or date (gate) for its own date.
If a stage is activated, it receives the day after the predecessors finish date (stage) or date (gate) as its start date. Its finish is the start date plus the potentially stored duration. If no duration is stored, a duration of 1 is assumed so the finish date is on the same date of the start date. Succeeding stages and gates are rescheduled into the future accordingly.
(\[open\] This currently contradicts the figma files)
#### Other scenarios
* Scenarios where the LifeCycleDefinitions are modified:
* When a definition is added:
* Expected result: No rescheduling.
* When a definition is deleted:
* Expected result: No rescheduling.
* When 2 definitions are reordered:
* Currently, no automatic rescheduling happens. But the first time the user touches the lifecycle, the out of order lifecycle steps are reordered keeping their duration unchanged.
* Scenarios where Non Working days or Non Working weekdays are modified:
* When a Non Working Day or Weekday is added or removed:
* Expected result: No rescheduling.
**Out of scope**
* Non working days are for now available start/end dates and count towards the duration.
* This is subject to change but doing so would increase the complexity.
* Adding a lag value other than 0 will be implemented later.