Type of Issues
Bug - The issue is either a missing or incorrect implementation of a requirement. Maybe submitted by a user or a developer or a tester.
Feature - The issue represents a new requirement or use case. Should be submitted by a user as approved by the project subsystem scientist.
Engineering Task - The issue represents a refactoring of an existing implementation that does not change the requirement. Normally submitted by a developer.
Research Request - Request investigation of an issue but does not commit to any work effort beyond the investigation. May be submitted by a user or developer.
Epic - Issue is used to organize other issues that belong to a similar requirement or use case. May be submitted by developer or by planners.
Priority
Trivial - The issue doesn't impact the ability of the user to complete their task, either because the problem issue is not required, or there is a workaround.
Minor - The issue doesn't impact the ability of the user to complete their task, but requires extra work for the user or a workaround is possible but not desirable.
Major - The issue is serious either aborting the task or application or making it impossible for the user to continue. The severity needs to be assessed as to whether this needs an immediate hotfix or if a fix can wait to the next release (this also includes the case where an immediate release may not be desirable).
Critical - The issue is severe and needs to be addressed. The resolution, whether further investigation or a hotfix, needs to be communicated to the reporting user and any other relevant parties as soon as possible and agreement to the plan for resolution.
Blocker - For testing, this means that testing cannot progress without a fix and this should be the priority. For a production application, this means that required operations of the observatory are halted. An immediate fix is required, unless there is an agreement to an alternate plan by the parties involved. If you are submitting a Blocker for a production application BE AWARE that the developers will interpret this as a requirement to continue to work after hours until a satisfactory resolution is agreed upon.
Workflow States
Viewing Tickets (Slices)
There are several useful ways to view the tickets (depending on your role).
- By release (stakeholders, planners, developers): This allows you to view all tickets assigned to a release. When a release is schedule all tickets which are 'Pending Release'.
- By sprint (planners, developers): The Agile Board for the quarter (e.g., 2020-Feb-Apr) allows you to see all tickets grouped by Sprint / Backlog in the Backlog view or tickets in the active sprint in the Active Sprint View. There are quick filters by developer and release that can be used to further filter the tickets
- By Epic (planners, stakeholders): The active sprint also has headers for Epics and tickets associated with the Epic under them. This allows stakeholders to track the progress of individual Epics (major featues)