Skip to content

02. Issue lifecycles

Jump to bottom
wkmor1 edited this page Sep 3, 2025 · 1 revision

Lifecycle of an Epic

flowchart TB
  CI((Create Issue)) --> |Set type to _Epic_| SNP[/"Status: New/Needs Prioritising"\]
  subgraph EB [EPICS BOARD]
    subgraph BR [Refinement Meeting]
      SNP -->|Maybe worked on in future| IB[/Status: Icebox\] 
      SNP -->|Set priority level| P[Priority Set]
      SNP -->|Not an Epic| T[Set to Task type, <br>connect to an Epic]
      P -->|Maybe worked on in future| IB
    end
    P -->|Will be worked on| NU[/Status: Next Up/On Hold"\]
    SCRM ---> |Maybe worked on in future| IB
    SCRM ---> |Needs to be reprioritised| SNP
    subgraph SCRM [Scrum Meeting]
      NU -->|Needs planning| PLN[/Status: Planning\]
      PLN -->|Planning finnished| R[/Ready for development\]
      R -->|Development starts| D[/Status: In Development\]
      D -->|Development is paused| NU
      C -->|Progress is paused| NU
      NU -->|No planning needed| R
      PLN -->|Planning finnished| C[/Status: In Progress\]
      NU -->|No planning needed| C
      NU -->|Is blocked| BLK[/Status: Blocked\]
      PLN -->|Is blocked| BLK
      D -->|Is blocked| BLK
      C -->|Is blocked| BLK
      BLK -->|Unblocked| D
      BLK -->|Unblocked| C
      D -->|Work done| A[/Status: Pending Approval\]
      A -->|More work needed| NU
      C -->|Work done| A
      A -->|Owner approves| DN[/Status: Done\]
    end
  end
Loading
  • Epics are high level planning units and are issues of type "Epic".
  • Epics enter the "Epics" project via the "New/Needs prioritising" status/column.
  • Epics can enter the project as true "Epics" or possible "Epics" (to be determined if they are true Epics at a later point).
  • "New" epics are "prioritised" in Bi-weekly Product Owner meetings where:
    • New epics are asssessed if they are a true epic or should be demoted to a "task" and moved to the Tasks project.
    • True new epics are given a priority (Number from 1 to 3, where 1 is high and 3 is low)
    • True new epics are considered for transfer to the Icebox (may be worked in the future). Epics that will be worked on in upcoming sprints remain in the "New/Needs Prioritising" status/column.
  • Epics are tracked as a group in a Bi-weekly scrum meeting following the product owners meeting.
  • New Epics are considered in order of priority to change status to "Next Up/On Hold" (will to be work on at the next available opportunity), "Planning" (will be planned in the current sprint to be developed in a future sprint). "Ready for development" (planning is complete), "In Development" or "In Progress" (worked on in the current sprint).
  • Epics that cannot be worked on due to extraneous circumstances have status "Blocked".
  • Completed Epics will be given status "Pending Approval" awaiting the "product owner" to approve the completion of the tasks.
  • Approved Epics will be assigned the status "Done".

Lifecycle of a Task

flowchart TB
  CI((Create Issue)) --> |Set type to _TASK_| SNP[/"Status: New/Needs Prioritising"\]
  subgraph EB [TASKS BOARD]
    SNP -->|Maybe worked on in future| IB[/Status: Icebox\] 
    SNP -->|Is an Epic| T[Set to EPIC type]
    IB -->|If reassessed| SNP
    SNP -->|Will be worked on| BL[/Status:Backlog\]
    BL -->|Progress starts| IP[/Status: In Progress\]
    SNP -->|Is blocked| BLK[/Status: Blocked\]
    BL -->|Is blocked| BLK
    IP -->|Is blocked| BLK
    BLK -->|Unblocked| BL
    IP -->|Work done| A[/Status: Needs Approval\]
    A -->|More work needed| IP
    A -->|Approved by owner| R[/"Status: Approved/Needs Review"\]
    R -->|Code reviewed if needed| AR[/"Status: Approved/Reviewed"\]
    AR -->|Code changes needed| R
    AR -->|Task closed| DN[/Status: Done\]
  end
Loading
  • All "issues" that have a "type" are tasks unless they are an "Epic".
  • Tasks can be of type: Chore, Improvement, Refactor, Bug or Feature.
  • Tasks are not prioritised as a group in the "Product Owners" and "Biweekly Scrum" meetings.
  • Tasks may or may not be assigned as a sub-issue of an "Epic".
  • Tasks may or may not include code changes and one or more associated "pull requests".
  • Tasks enter the "Tasks" project/board with status "New/Needs Prioritising".
  • Tasks have an owner and a developer/actor.
  • The tasks author shall assign the task an owner (often but not always the author of the task).
  • It is the responsibility of the task "owner/author" to assign the task to a "developer/actor".
  • The owner and developer/actor can be the same person.
  • It is the responsibility of the task "owner/author" to prioritise the task and change its status to "Backlog" (will be worked on) in consultation with the "developer/actor" or set its status to "Icebox" if appropriate (it may be worked on in the future).
  • It is the responsibility of the developer/actor to indicate a Task has begun to be worked on by setting the status to "In Progress".
  • It is the responsibility of the developer/actor to indicate a Task requires owner approval by setting the status to "Needs Approval".
  • It is the responsibility of the owner to indicate that the Task is approved by setting the status to "Approved/Needs Review" if the task has an associated "pull request" or "Approved/Reviewed" if it does not.
  • It is the responsibility of the developer to assign a code reviewer when the task has an associated "pull request".
  • It is the responsibility of the developer/actor to close the task (assign status "Done") when the task is complete.
  • If the task will not be worked on the task can be closed "as not planned".
  • It is the responsibility of the developer/actor to indicate the "Sprint" the task is or will be worked on. And to update the "Sprint" indicator when needed.

Clone this wiki locally