/
Thunderjet - Jira Flow
Thunderjet - Jira Flow
What should I do before I start working on a Story/Bug
- Make sure the requirements and acceptance criteria are clearly expressed and there are no unanswered questions
- Make sure the estimation in story points is added to a Story/Bug;
- Note: estimate should be added to a Story/Bug itself and should include the effort of related sub-tasks if any. Estimates should not be added to sub-tasks as they won't be added to Velocity.
- Populate Development Team field to indicate Thunderjet
- Optional: Fill out Tester Assignee field for UI Stories/Bugs to indicate the PO responsible for final verification and closing of the stories item.
- Note: leave Tester Assignee field empty for back-end stories/bugs as they are to be verified and closed by any available team-members.
- Fill out Fix version(s) field:
- Select Unreleased Fix Version from the dropdown:
- Patch version (available if patch release is planned)
- Minor version (available if no major changes have been committed)
- Major version
- Select Unreleased Fix Version from the dropdown:
- Make sure the work on a Story/Bug is not blocked/dependent and it conform to the Definition of Ready
- Make sure a Story/Bug is added to an active sprint (ACQ Sprint [XX])
- Note: Make sure you have enough time to complete an additional Story/Bug by the end of current sprint before adding it to an active sprint; otherwise start working on it and keep it in the next sprint.
- Assign a Story/Bug to yourself
- Move a Story/Bug to In Progress as soon as you start working on it
- Ensure that the Story/Bug has links to an appropriate feature, and to any related stories which might provide additional/helpful context.
- Note: Contact SM or PO if you need help choosing a feature
- Note: It may be acceptable to omit epic/feature links on some bugs, but they should be provided when applicable
What should I do while working on a Story/Bug
- Communicate to the team and PO in case you find out that estimate for the story is not valid any longer and get it updated
- Note: try to avoid tweaking the original estimate during the sprint as it is considered as scope change
- Update the status of a Story/Bug accordingly:
- In Progress - work in progress
- Blocked - work is blocked
- In Code Review - PR is created and code review is in progress
- In Review - PR is merged and pending deployment
- In case a Story/Bug is moved to Blocked status, link corresponding blocker or indicate the reason in comments (if not blocked with some specific story)
- @Tag other people in comments if you need some feedback
- Add comments in case there was some additional valuable info found out while development or in case there were some important discussions on the appropriate solution - it can help other people to better understand what was done in scope of a Story/Bug.
- Make sure Major Fix Version is selected if you are going to introduce major changes;
- Updates to interface versions should be introduced together with corresponding code changes (without waiting until releases are to be created)
- Make sure PR is available in a Story/Bug and PR description is added
- Merge PR when all comments are fixed and there are at least two approvals from other developers
- Make sure your updates are working as expected on test env
What should I do before I assign a Story/Bug to PO for review
- Make sure the estimation in story points was added to a Story/Bug
- Make sure Development Team field was populated
- Make sure Fix version(s) field was filled out
- Make sure a Story/Bug was added to an active sprint (ACQ Sprint [XX])
- Add a comment with screenshots, gifs, videos to prove dev verification successfully done on reference env
- Re-assign a Story/Bug if updates are available for review on test env:
- Dennis Bridges or Ann-Marie Breaux (Deactivated) for UI Stories/Bugs
- @unassigned for Back-end Stories/Bugs
- Move story/bug to In Review
JIRA Status | Description | Assignee/Actions |
---|---|---|
Draft | PO is defining the user story. Not ready for the team to review. | Assignee: PO (or BE Lead for back-end stories)
|
Open | Ready for development team to groom. | Assignee: None
Assignee: BE Lead (for UI stories)
|
In Progress | Development is in progress | Assignee: Developer
|
Blocked | Development is blocked | Assignee: Developer
|
In Code Review | PR is done and Code Review is in progress | Assignee: Developer
|
In Review | PR is merged and updates are ready for review | Assignee: Developer
Assignee: PO or Unassigned/Developer (for back-end stories)
|
Closed | Story is accepted by PO and closed | Assignee: PO or Developer (for back-end stories)
|
, multiple selections available,
Related content
Thunderjet (ACQ) Team
Thunderjet (ACQ) Team
Read with this
Folijet. Jira Flow
Folijet. Jira Flow
More like this
BusyBee Developer Env Setup
BusyBee Developer Env Setup
Read with this
Spitfire - Jira Flow
Spitfire - Jira Flow
More like this
How-to articles
How-to articles
Read with this
Vega- Jira Flow
Vega- Jira Flow
More like this