Page Comparison

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

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

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