Support multiple, automated Iteration Cadences
Iteration Cadences
Problems To Solve
- There are often times when many teams share one or more projects to track Issues. Right now, there is no way to allow teams with the flexibility to manage their own Iteration cadence in this scenario.
- Every iteration is intended to the same duration and there is an opportunity to make managing them easier through automated scheduling and rolling over issues from one iteration to the next.
- Some teams will prefer to continue manually managing their Iteration cadence.
- Currently as an MVC we implemented a way to define iterations at group level and validate that created iteration dates do not overlap with other iterations from parent groups. Whereas that gives the possibility to introduce iterations concept as an MVC it does not seem that is how iterations work and has some rigidity to it vs more flexibility that iterations would suggest.
Proposal
Define an Iteration Cadence (IC)
-
A Group may define one or more ICs. -
A Group may inherit 1 or more ICs from parent Groups (still in discussion) -
Only validate non-overlapping dates within a single cadence (iteration set) -
An Iteration Cadence is named. -
An IC may be disabled. If it is, it is disabled in all subgroups automatically. -
Disabling an IC removes current and future Iterations from Issues currently assigned to an Iteration within that cadence. Closed issues are not automatically updated. Disabled ICs disappear from all dropdowns / removed from Boards. -
A Board can be scoped to a specific IC. Until this scope is set, "scope to current Iteration" checkbox is disabled.
Automate Iteration Cadence
-
An IC can define a start date -
An IC can define the duration of a single Iteration in weeks -
Automated IC scheduling is a user configurable option defaulted to on for new Iterations. For existing ICs, it is defaulted to Off. -
A configurable option to allow automatically moving Issues from a newly closed Iteration to the next. -
A configurable option to specify how many future iterations to complete. Consider a range of 1-12. -
If automated scheduling is disabled, the configurable fields are not editable.
UX Concept
Old proposal:
- Instead of creating one iteration at a time, change the UI/UX for the user to only provide the cadence of the iteration (in weeks for starters) and a start date in future.
- At this step we should take care that the start date in future does not overlap with any running iteration. It can overlap with future iterations, which would mean that future iterations get overwritten(either deleted and new ones are created or start/end dates get updated according to new cadence)
- Iteration dates would care about not overlapping only at the level of the group that it is being defined, rather than care about parent groups or entire hierarchy.
- List iteration cadences defined at parent group levels, and opt to either use one of those or create a custom iteration cadence for this specific group, if the parent inheritance strategy allows for overwriting iteration cadence.
Some raw mockups of the idea
- Listing Iteration definitions(cadences) from different parent levels, when none of the parents enforces a specific cadence
- Creating a custom iterations cadence at subgroup level, if parent does not enforce a specific cadence
- Pick to enforce or not a specific cadence to subgroups
- Listing only iterations that are being enforced when parent group enforces its iteration cadence
-
A more generalized diagram from @gweaver & some takeaways
- There should only ever be a choice of subscribing to your direct parent or yourself.
- Syncing to parent should be on by default.
- When we enable this, if a group already has iterations defined in self for future or current dates, do not enable sync by default.
Backend perspective
iterations_cadence
DB table column | type | notes |
---|---|---|
id | integer | |
group_id | integer | The group for which this iteration cadence was defined |
duration | integer | Duration of an iteration in days, i.e. cadence |
is_enforced | boolean | Determines if this cadence is being enforce to any child groups/projects or child groups/projects can define their own cadence. Default: faslse. |
is_active | boolean | Determines if given iteration cadence is active. We need to be able to de-activate a cadence in case a top level group enforces a cadence. |
start_date | datetime | the date/time when iterations with this cadence should start |
next_run_date | datetime | the date time when next set of iterations should be created |
iterations_in_advance | integer | how many iterations in advance should we create. We can skip this column for now and just use a constant hardcoded in the code, so this is not configurable |
created_at | datetime | |
updated_at | datetime |
Iterations cadence and iterations workflow considerations
- create iteration cadence
- iteration cadences cannot be deleted and can only be created. When new iteration cadence needs to be defined, old iteration cadence becomes inactive and new iteration cadence record is being created. This should help audit any changes in the iteration cadence.
- allow creation of iteration cadence only if at the time of creation none of the ancestor groups enforces its iteration cadence
- Allow to set iteration cadence
start_date
at any date(past of future) if no iterations exist in the group where it is being defined or all defined iterations start in future - Set iteration cadence
start_date
to NEXT iterationstart_date
if there is a CURRENT iteration running in the group. - Allow to set iteration cadence
start_date
to LAST iterationdue_date
if all existing iterations are in the past or to any date after LAST iterationdue_date
- Iteration cadence is provided in days
- Iterations start/due dates are auto-computed from iteration_cadence#start_date + cadence
- All future iteration start/due dates need to be updated based on new cadence duration & start_date.
- Daily cron job to check
next_run_date
on active iteration cadences to create new iterations and updatenext_run_date
for respective iteration cadences. - By default
is_enforced
is set to false. - When a higher level group enforces an iteration cadence a warning should be shown if any of the subgroups already has an iteration cadence defined, notifying the user that the change will disrupt the workflow.
- In the scenario when a subgroup has an iteration cadence defined and any of its ancestors enforces a cadence, the subgroup's iteration cadence should be set to
active: false
- If a given group does not have an active iteration cadence it should lookup iterations at ancestor level
- Allow to create new iterations manually with a single click, if group has active iteration cadence. Use last iteration
due_date
to compute new iterationstart_date
and iteration cadence duration to computedue_date
. Update iteration cadencenext_run_date
accordingly. - Generate 3? iterations in advance of CURRENT iteration
- Validate that iteration dates do not overlap only at the group level where the iteration is defined instead of hierarchy wide.
Things to think about
- Investigate/discuss if a migration is need or we can introduce the iteration cadence concept on top of existing iterations implementation
- a migration would consider the duration of last iteration in order to set iteration cadence duration.
- determine if iterations are being used.
- check if iterations are spread across multiple groups in the hierarchy. How to prevent disruption ?
Edited by Gabe Weaver