Page tree
Skip to end of metadata
Go to start of metadata

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
    • 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 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 test 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])
  • Re-assign a Story/Bug to PO if updates are available for review on test env and can be checked by PO. Keep the story assigned to yourself In Review in case it cannot be verified by PO and upi are going to demo it while Sprint Review.

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
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
In ReviewPR is merged and updates are ready for review

Assignee: Developer

Assignee: PO (or Developer in case updates cannot be veryfied by PO)

  • Story/Bug to be checked on
  • 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: PO (or Developer in case updates cannot be veryfied by PO)

  • Updates has been demonstrated on System Demo and accepted by PO.
  • No labels
Write a comment…