Versions Compared

Old Version 133

changes.mady.by.user Yaroslav Ishchenko

Saved on

compared with

New Version 134

changes.mady.by.user Yaroslav Ishchenko

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Panel
borderColor#B5C6CA
bgColor#EBFAFE

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)




Panel
borderColor#B5C6CA
bgColor#EBFAFE

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



Panel
borderColor#B5C6CA
bgColor#EBFAFE

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 StatusDescriptionAssignee/Actions
DraftPO 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
OpenReady 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 ProgressDevelopment 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
BlockedDevelopment 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 ReviewPR 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 DeploymentPR 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 QAPR 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 ReviewUpdates 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
ClosedStory is accepted by PO and closed

Assignee: Developer

  • Updates has been demonstrated on System Demo and accepted by PO.