...
§4: The workflow is generally (a) TO DO → (b) selected for development → (c) in progress → (d) in review → (e) done. The state "in review" is a bit badly named, but it is optional for teams to use and it describes the situation that a development team considers the item as done, but the PO (product owner or similar representative/delegate of the team) has not formally accepted it yet. As of Jan-2020 this state only used by team T4 (Avinoam).
§5.1: JIRA has a concept of releases (aka versions). We use this naming convention: Bronze-R3, Bronze-R4, Cherry-R5, Cherry-R6. R3 and R4 are the first and second half of Bronze. A release ZZZ_future is used to indicate items that are not yet planned to be worked on any time soon. A release ZZZ_never is used to indicate items we never plan to work on (Jira's Resolution field (with the state "won't do") is not used for anything). This way at least (new) epics that do not have any release version as "fix version", must be analyzed still on when they are to be worked on.
§5.2: For epics that were originally planned for release X, e.g., R4, but could not be completed, please keep the original fix version, i.e., “R4-Bronze” and add to that the release label for release X+1, e.g., R5-Cherry. This way we know that it is continued (left-over) work. We know the exact leftover content from the user stories that are mapped to the Epic, but not yet done. You could also add a summary of post-R4 leftovers into the description of the epic item. Note that this way the item will show up automatically in X+1 planing.
§6: Each team creates their own 3 week sprints (and names) as per the naming scheme below which is aligned with the Bronze (B) and Cherry (C) timeline. P1-P3 are mapped to "release planning sprints". D1-D6 to "release development (and integration) sprints".
...