Content
View differences
Updated by Jens Ulferts over 1 year ago
**As** a project portfolio manager
**I want to** have stages and gates adjust automatically based on changes to preceding/succeeding stages and gates
**so that** administration is simpler and less error prone.
**Acceptance criteria**
* 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 work package) are not allowed.
* The lag (explicit distance between the end date of a preceding and the start date of a succeeding work package) 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.)
**Explanation on scheduling 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)
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
**Explanation on scheduling when date/duration were already provided before**
\[open\] When changing the start/end date of a completely defined stage, is the duration altered or the other date adapted?
* The attempt is to do it analogous to work packages. There:
* Duration is decreased if the start/due date is changed.
* Duration and the other date is removed if the start/due date is changed to a contradicting value (before/after start/due date)
Scenarios:
Currently this only describes the backend's behaviour and not what is to happen on the frontend.
The scenarios are currently being rewritten so this is work in progress.
* Scenarios where dates/duration of a stage/gate is manipulated:
* <br>
* Whenever
* With only duration already set on a stage (or a gate being manipulated which always has a duration of 0)
* With the start date being set by the user
* End date is set:
* provided start date + (duration - 1)
* Start date is set on a successor (if it exists)
* For a stage: provided start date + (duration - 1) + 1
* For a gate: provided start date + (duration - 1)
* End date is set on a predecessor (if it exists)
* For a stage: provided start date - 1
* For a gate: provided start date - 1
* Both, potential successor as well as potential predecessor continue to be scheduled and schedule in turn
* With the end date being set by the user
* Start date is set:
* provided end date - (duration - 1)
* Start date is set on a successor (if it exists)
* For a stage: provided end date + 1
* For a gate: provided end date
* End date is set on a predecessor (if it exists)
* For a stage: provided end date - (duration - 1) - 1
* For a gate: provided end date - (duration - 1) - 1
* Both, potential successor as well as potential predecessor continue to be scheduled and schedule in turn
* With only start date already set on a stage
* With the end date being set by the user
* Duration is set:
* Provided end date - start date + 1
* Start date is set on a successor (if it exists)
* For a stage: provided end date + 1
* For a gate: provided end date
* Both, potential successor as well as potential predecessor continue to be scheduled and schedule in turn
* <br>
* <br>
* <br>
* With dates and duration set on predecessor and successor
* With the predecessor being moved
* into the future or past
* with a stage following a stage
* Expected result: The succeeding stage's end date is on the next day relative to the preceding stage's end date.
* With a gate following a stage
* Expected result: The succeeding gate's date is on the same day as the preceding stage's end date.
* With a stage following a gate
* Expected result: The succeeding stage's start date is on the next day as the preceding gate's date.
* With a gate following a gate
* Expected result: The succeeding gate's date is on the same day as the preceding gate's date.
* With the successor being moved
* into the future.
* Expected result: A gap is added between predecessor and successor. The predecessor is not moved.
* into the past.
* There is no gap.
* Expected result: The successor cannot be moved as that would conflict with the predecessor. An error is displayed.
* There is a gap.
* Expected result: The successor can be moved as long as the change is smaller than the gap. The gap gets eaten up.
* With dates only on the predecessor. Successor does not have dates set.
* With the predecessor being moved
* into the future
* \[open\] Expected result: The dates of the successor are not set
* into the past
* \[open\] Expected result: The dates of the successor are not set
* With the successor receiving dates
* after the predecessor's dates
* Expected result: The successor receives those dates. There may be a gap between the predecessor and the successor. The predecessor is unchanged.
* before/overlapping the predecessor's dates
* \[open\] Expected result: An error is displayed. The successor's dates cannot be saved. The predecessor is unchanged.
<br>
Note from Attila: The current implementation allows overlap between a stage and a gate, but not between LifeCycleEvents of the same type.
* With dates only on the successor. Predecessor has no dates set.
* With the successor being moved
* into the future
* Expected result: The successor is moved. The predecessor does not receive any dates.
* into the past
* Expected result: The successor can be moved. The predecessor does not receive any dates.
* With the predecessor getting dates set
* With the dates being before the successor's dates
* \[open\] Expected result: The successor keeps its dates.
* With the dates overlapping/after the successor's dates
* Expected result: The successor is moved to start on the day after the predecessor's new end date.
* Without any dates set
* Predecessor gets its dates set.
* \[open\] Expected result: The predecessor gets the dates set. The successor does not receive any dates automatically.
* Successor gets its dates set.
* Expected result: The successor gets the dates set. The dates of the predecessor are not set automatically.
* Scenarios where a LifeCycleStep with an existing value is being enabled:
* when the value conflicts with the predecessor's date:
* \[open question\] Should we call rescheduling, or let the user solve the validation error on the dialog?
* when the value conflicts with the successor's date:
* \[open question\] Should we call rescheduling, or let the user solve the validation error on the dialog?
* 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:
* Reschedule the projects where the affected definitions are enabled and they have dates set.
\[open question\]: Set the new successor to be after the new predecessor maintaining the duration of the predecessor and eating the gap between the two?
Or leave it to the user to solve the validation error? (We agreed to let the user solve the error in <mention class="mention" data-id="60293" data-type="work_package" data-text="#60293">#60293</mention> , but maybe we want to revisit that)
* 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.
* <br>
**I want to** have stages and gates adjust automatically based on changes to preceding/succeeding stages and gates
**so that** administration is simpler and less error prone.
**Acceptance criteria**
* 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 work package) are not allowed.
* The lag (explicit distance between the end date of a preceding and the start date of a succeeding work package) 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.)
**Explanation on scheduling 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)
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
**Explanation on scheduling when date/duration were already provided before**
\[open\] When changing the start/end date of a completely defined stage, is the duration altered or the other date adapted?
* The attempt is to do it analogous to work packages. There:
* Duration is decreased if the start/due date is changed.
* Duration and the other date is removed if the start/due date is changed to a contradicting value (before/after start/due date)
Scenarios:
Currently this only describes the backend's behaviour and not what is to happen on the frontend.
The scenarios are currently being rewritten so this is work in progress.
* Scenarios where dates/duration of a stage/gate is manipulated:
* <br>
* Whenever
* With only duration already set on a stage (or a gate being manipulated which always has a duration of 0)
* With the start date being set by the user
* End date is set:
* provided start date + (duration - 1)
* Start date is set on a successor (if it exists)
* For a stage: provided start date + (duration - 1) + 1
* For a gate: provided start date + (duration - 1)
* End date is set on a predecessor (if it exists)
* For a stage: provided start date - 1
* For a gate: provided start date - 1
* Both, potential successor as well as potential predecessor continue to be scheduled and schedule in turn
* With the end date being set by the user
* Start date is set:
* provided end date - (duration - 1)
* Start date is set on a successor (if it exists)
* For a stage: provided end date + 1
* For a gate: provided end date
* End date is set on a predecessor (if it exists)
* For a stage: provided end date - (duration - 1) - 1
* For a gate: provided end date - (duration - 1) - 1
* Both, potential successor as well as potential predecessor continue to be scheduled and schedule in turn
* With only start date already set on a stage
* With the end date being set by the user
* Duration is set:
* Provided end date - start date + 1
* Start date is set on a successor (if it exists)
* For a stage: provided end date + 1
* For a gate: provided end date
* Both, potential successor as well as potential predecessor continue to be scheduled and schedule in turn
* <br>
* <br>
* <br>
* With dates and duration set on predecessor and successor
* With the predecessor being moved
* into the future or past
* with a stage following a stage
* Expected result: The succeeding stage's end date is on the next day relative to the preceding stage's end date.
* With a gate following a stage
* Expected result: The succeeding gate's date is on the same day as the preceding stage's end date.
* With a stage following a gate
* Expected result: The succeeding stage's start date is on the next day as the preceding gate's date.
* With a gate following a gate
* Expected result: The succeeding gate's date is on the same day as the preceding gate's date.
* With the successor being moved
* into the future.
* Expected result: A gap is added between predecessor and successor. The predecessor is not moved.
* into the past.
* There is no gap.
* Expected result: The successor cannot be moved as that would conflict with the predecessor. An error is displayed.
* There is a gap.
* Expected result: The successor can be moved as long as the change is smaller than the gap. The gap gets eaten up.
* With dates only on the predecessor. Successor does not have dates set.
* With the predecessor being moved
* into the future
* \[open\] Expected result: The dates of the successor are not set
* into the past
* \[open\] Expected result: The dates of the successor are not set
* With the successor receiving dates
* after the predecessor's dates
* Expected result: The successor receives those dates. There may be a gap between the predecessor and the successor. The predecessor is unchanged.
* before/overlapping the predecessor's dates
* \[open\] Expected result: An error is displayed. The successor's dates cannot be saved. The predecessor is unchanged.
<br>
Note from Attila: The current implementation allows overlap between a stage and a gate, but not between LifeCycleEvents of the same type.
* With dates only on the successor. Predecessor has no dates set.
* With the successor being moved
* into the future
* Expected result: The successor is moved. The predecessor does not receive any dates.
* into the past
* Expected result: The successor can be moved. The predecessor does not receive any dates.
* With the predecessor getting dates set
* With the dates being before the successor's dates
* \[open\] Expected result: The successor keeps its dates.
* With the dates overlapping/after the successor's dates
* Expected result: The successor is moved to start on the day after the predecessor's new end date.
* Without any dates set
* Predecessor gets its dates set.
* \[open\] Expected result: The predecessor gets the dates set. The successor does not receive any dates automatically.
* Successor gets its dates set.
* Expected result: The successor gets the dates set. The dates of the predecessor are not set automatically.
* Scenarios where a LifeCycleStep with an existing value is being enabled:
* when the value conflicts with the predecessor's date:
* \[open question\] Should we call rescheduling, or let the user solve the validation error on the dialog?
* when the value conflicts with the successor's date:
* \[open question\] Should we call rescheduling, or let the user solve the validation error on the dialog?
* 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:
* Reschedule the projects where the affected definitions are enabled and they have dates set.
\[open question\]: Set the new successor to be after the new predecessor maintaining the duration of the predecessor and eating the gap between the two?
Or leave it to the user to solve the validation error? (We agreed to let the user solve the error in <mention class="mention" data-id="60293" data-type="work_package" data-text="#60293">#60293</mention> , but maybe we want to revisit that)
* 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.
* <br>