Versions Compared

Old Version 5

changes.mady.by.user Taisiya Trunova

Saved on

compared with

New Version 6

changes.mady.by.user Ruslan Lavrov

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;
    • 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;
    • If a Story/Bug needed to be tested by QA, include QA effort into estimation. Note: if a QA needs to write test plans and etc (work not related to testing of a Story/Bug) a separate task should be created, groomed and estimated in story points;
    • In case there are uncertainties or risks, include them into estimation by increasing the number of story points; confidence factor is used to indicate that the level of uncertainly but not estimation
  •  Populate Development Team field to indicate Folijet
  •  Optional: Fill out Tester Assignee field for BE and UI Stories/Bugs to indicate the PO/QA responsible for final verification and closing of the stories item. 
  •  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
  •  Make sure the work on a Story/Bug is not blocked/dependent and it conform to the  (Folijet. 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




Panel
borderColor#B5C6CA
bgColor#EBFAFE

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
    • In case the effort on a Story/Bug was found to be underestimated, communicate with the PO and team on the ways to close the item (review Description or Acceptance Criteria), create Story/Bug for the additional effort, groom, estimate, put it into either next sprint or product backlog
  •  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 Testing - PR is merged and pending testing by QA. Note: In case QA finds a bug, the Story should be re-assigned to the developer and moved back to In Progress to fix the bug; as soon as the bug is fixed, the item is re-assigned to QA for verification 
  •  
    • In Review - PR is tested by QA 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



Panel
borderColor#B5C6CA
bgColor#EBFAFE

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 or QA verification successfully done on reference env
  •  Move story/bug to In Review
  •  After QA verified a Story/Bug, it should be re-assigned to Ann-Marie Breaux (Deactivated) for final verification or demoed at Daily Scrum to PO




JIRA StatusDescriptionAssignee/Actions
DraftPO is defining the user story. Not ready for the team to review.

Assignee: PO (or BE Lead for back-end stories)

OpenReady for development team to groom.

Assignee: None

  • Story/bug to be reviewed and discussed on Backlog Grooming
  • Requirements to be clarified
  • Acceptance criteria to be understood
  • Estimation to be added

Assignee: BE Lead (for UI stories)

  • Back-end story to be created to support UI. Unassign UI story as soon as BE story is added to backlog and linked to UI story.
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
BlockedDevelopment is blocked

Assignee: Developer

  • 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 approves of a PR are required
  • PR to be merged
In testingPR is merged and pending testing by QA

Assignee: Tester

  • 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 (/wiki/spaces/DQA/pages/2657909)
In ReviewPR is merged and updates are ready for review

Assignee: PO or Unassigned/Developer (for back-end stories)

    • Story/Bug to be checked on http://folio-snapshot-stable.aws.indexdata.com
      • UI/BE stories checked by QA
      • If a QA is not available BE stories checked by any available developer and should be assigned to a dev as soon as they are picked up for verification
      • Back-end Story/Bug: the API Tests should be run from master branch or a branch with prepared PR to make sure no regression introduced and new tests meet Acceptance Criteria. If all is okay, the PR is approved and merged to master by Tester Assignee.
    • Story to be closed if requirements are met and it conforms to the Folijet - 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: PO

  • Updates to be demonstrated on System Demo