Spitfire - 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.
Make sure Development Team field is populated with Spitfire.
Make sure there are the following labels added: 'epam-spitfire' + 'back-end' or 'front-end'
Fill out Fix version(s) field (if empty):
- Select Unreleased Fix Version from the dropdown
- Contact your SM if you are not sure what to select
Make sure the work on a Story/Bug is not blocked/dependent and it conforms to the Definition of Ready. If a story is blocked, a blocker should be linked via "is blocked by'.
Make sure a Story/Bug is added to an active sprint (eHoldings Sprint [XX])
Assign a Story/Bug to yourself
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 from the backlog (otherwise, start it but keep in the next sprint)
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 UXPROD feature, and to any related stories which might provide additional/helpful context.
- Note: Contact your SM if you need help choosing a UXPROD feature to be linked
- Note: while linking related stories use the following link types:
  - has to be done after / has to be done before (to specify the dependencies and order of development)
  - is blocked by / blocks (to specify a blocker)
  - has to be done together with (to indicate dependencies that should be merged together to avoid breaking the envs)
  - relates to (to link to any related stories that can provide valuable info)

What should I do while working on a Story/Bug

Communicate to the team and PO on Standup in case you find out that estimate for the story is not valid any longer and get it updated if additional requirements/clarifications cannot be split into a separate story.
- 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
- Awaiting snapshot - PR is merged and pending deployment
- In QA - PR is merged and available on reference env
- In Review - PR is merged and ready to be reviewed by PO
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 PR is available in a Story/Bug
Merge PR when all comments are fixed and there are at least two approves from other developers
Make sure your updates are working as expected on env

What should I do before I assign a Story/Bug to PO for review or close a Story/Bug

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 is added to an active sprint (eHoldings Sprint [XX])
Make sure "RCA Group" field was filled out for a Bug
Move a Story/Bug to "In QA" if updates are available for review on reference env and can be checked by Tester.

JIRA Status	Description	Assignee/Actions
Draft	PO is defining the user story. Not ready for the team to review.	Assignee: PO (or Tech lead for back-end stories) Requirements to be finalized and added to story/bug Story/bug to be updated
Open	Ready for development team to groom.	Assignee: Unassigned Story/bug to be reviewed and discussed on Backlog Grooming Requirements to be clarified and confirmed Acceptance criteria to be understood and confirmed Estimation to be added
In Progress	Development is in progress	Assignee: Developer Requirements to be turned into working software Acceptance criteria to be met Tests to be added/updated to ensure 80% coverage Dev verification to be done Critical defects to be addressed "RCA Group" field is set in case of Bug
Blocked	Development is blocked	Assignee: Developer ( or Unassigned in case blocked by external teams) Blocker to be linked in JIRA via "is blocked by" (if any) Comment to be added to clarify what the blocker is (in case there is no blocking story)
In Code Review	PR is done and Code Review is in progress	Assignee: Developer PR to be reviewed by other developers Comments to be addressed At least 2 approvals of a PR are required PR to be merged
Prep Deployment	PR is merged and waiting to be available on ref env	Assignee: Developer Issue is waiting to be deployed to reference environment. Availability of delivered functionality in scope of the story/task/bug tested by developer In case of using Rancher, developers need to deploy changes ourselves and check availability
In QA	PR is merged and pending testing by QA	Assignee: Developer Updates are available on selected env. to be tested Test data (users, file examples, etc.) is presented by dev team, if possible Test Cases were created. Test Cases for automation were selected Test cases were executed All found issues were reported and assign to the corresponded developers All P1 and P2 bugs/issues were fixed by developer (Defect Priority Definition for Functional Issues)
In Review	Updates are ready for PO review	Assignee: Developer Story/Bug to be checked on http://folio-snapshot-stable.aws.indexdata.com Story to be closed if requirements are met and it conforms to the definition of done Story to be reassigned back to developer In Progress in case the requirements are not met Additional stories to be created in case additional requirements/updates are identified while review
Closed	Story is accepted by PO and closed	Assignee: Developer Updates has been demonstrated on System Demo and accepted by PO.