Theme

Jira | Task flow guide

Written by

in

Issue creation

The PM creates an issue in Jira, and they should ensure, that the issue has the following fields filled in:

  1. Title: The PM should use a clear and concise title in a Summary field – it has to be a page name or a block name that will be later used in the admin panel.

image-20240409-145400.png

  1. Issue Type: Select the appropriate issue type

image-20240409-145516.png

  • Epic – is used for the complex pages or blocks that will be later broken into smaller tasks.

  • Story – is used for describing sections/blocks on pages, and other functional elements in the project.

  • Task – is used for general tasks.

  • Bug – is used for bugs spotted during QA review.

  • CB – is used for bugs that were noticed by the client, and are not billable.

  • CR – is for additional requests made by the client after review, and are billable hours.

  1. Description: Provide a detailed and clear description of the task.

Provide a detailed and clear description of the task with linking to the confluence page (Epic/Story).

image-20240409-145551.png

  1. Priority: Set the priority level (e.g., low, high, urgent).

image-20240409-145621.png

  1. Due Date: Set a deadline if needed.

image-20240409-150039.png

  1. Original Estimate: The PM should assign an estimate if provided by the developer.
    If the PM does not have an estimate, it must be added by a developer after they move the issue to ‘In progress’ status.

image-20240409-150224.png

  1. Assignee: The PM should assign the task to a team member.

image-20240409-150420.png

If any of the fields listed above is missing, here are short tips on how to add it.

How to add an issue type
image-20240429-143101.png
How to edit issue layout (adding a Due Date works the same way)
image-20240429-143634.png

Issue completion

  1. The developer should drag an issue to In Progress status.

  2. Before starting to work on the task, the developer should start tracking time using TimeDoctor.

  3. The developer should familiarize with the task requirements.

  • If clarification or additional resources are needed, the developer should move the task to Dev Blocked status, add a comment to the issue card, and add a message in the Slack channel of the project, tagging the PM and letting them know that the task is blocked.

If the issue is moved to Dev/QA Blocked, the developer/QA should briefly describe the blocker in the issue’s comments.

  • If the description is clear to the developer, they should add an Original Estimate (if missing) and start working on the task.

  1. Once the developer completes the task, they should add a comment with links to the merge request for the front end or stage for the backend.

When the task is moved from In Progress to Code review, the developer needs to provide a link to the merge-request, and briefly explain what has been done in the comments to the issue. Additionally, provide screenshots and instructions for QA in the QA Scope field.

  1. If the issue has been moved from Front-End developer to Back-End developer or vice versa: dev needs to briefly describe why it was moved and what was done, provide instructions to the team member

Code Review

  1. The developer should move the issue to Code Review status and assign the issue to the Team Lead.

Code review is performed for a page or block; bugs or small support tasks do not go through code review.

  1. The Team Lead reviews the task. They should:

  • Check the time spent and estimated time.

  • Conduct code review.

  • Provide feedback in the comments on the issue.

    • If satisfactory, the TL should assign the task to the PM and move it to Ready for QA status.
      The PM should assign the task to the QA when the block/page is ready for testing.

    • If changes are needed, assign the task back to the developer and revert to In Progress status.
      In this case, the developer should implement the comments provided and pass it for Code review again. This process repeats itself until all the comments from TL are fixed.

Quality Assurance (QA)

  1. The QA should review the task in Ready for QA and drag it to QA in Progress status.

  2. The QA should conduct the testing and create relevant issues (issue type – bug) for any bugs found. The issues should be linked to the original issue and assigned to the developer.

If the QA discovers bugs that belong to one section or scope, these bugs can be combined into one issue. In this case, the QA should describe every bug as separate paragraphs in the Description field and add a checklist to the issue.

  1. The task is in the QA in Progress status until all linked bugs are fixed and approved by the QA.

  2. When all linked bugs are fixed, the QA should drag the task to QA Approved status and assign the issue to the PM.

QA Approved status means that the issue is completed, fully tested, and ready to be released to live.

Once the issue has been moved from QA in progress to QA Approved, the QA should provide screenshots or videos that confirm the task has been completed, and provide information on the testing environment and devices.

Deployment

  1. The PM communicates with a client whether to deploy the task.

  2. When the decision is made, the PM should drag the task to Ready to Merge in Master and assign it to the developer.

When the issue is moved from QA Approved to Ready to Merge, the PM should provide brief instructions to the developer on the merge timing and important details.

  1. The developer deploys the task to the master branch, moves the issue to Deployed to Master, and assigns the QA.

  2. Once the QA tested the task or checklist on Live, the QA should move the issue to Done, and assign the PM/Client to the issue.

The developer deploys the task to the master branch, moves the issue to Deployed to Master, and assigns the QA.

  1. Once QA tested the task OR checklist on Live the ticket should be changed by QA to the status Done and assigned to the PM/Client.

The QA should also provide screenshots or videos that confirm the task has been completed, and provide information on the testing environment and devices. If the issue was checked using a common checklist for live, just report it.

  1. The QA or the PM should create a Release – responsibility for the Release creation should be discussed between project participants.

  2. The QA should review all tasks within the release on the production environment.

If any bugs are found post-deployment, the QA should create a separate issue with a scope of tasks, assign the issue to the developer, and link them to the original issue.

How to use the Releases feature?

Instruction

  1. On the sidebar, find the Releases page, and use the Create version.

image-20240410-224226.pngimage-20240410-224323.png

  1. When creating a new version, use a release date as a title – e.g. Version 15.05.24, add the dates, and save.

image-20240410-224407.png

  1. You have created an Unreleased Version with the following view.
    The driver is the person who created the Release.
    The driver should add Approvers, people on the team who will review the tasks that are going to be released.

image-20240410-224818.png

  1. The Driver should add issues to a Release. Type your project’s key to find the issues needed.

image-20240410-225110.png

  1. When the issues are added, the Driver will see the progress on the issues added to a Version. When the QA reviews all tasks within the release on the production environment, the version can be released in the top right corner of the Release page.

image-20240410-225659.png

Important communication aspects

  1. When the issue has been moved from FE developer to BE developer, or vice versa, the previous developer should briefly describe what has been done and why the issue has been moved in the issue’s comments in Jira.
    Provide brief instructions to the team member who you are passing the assignment to.

  2. If the developer provides any suggestions regarding the task, it should be written in the issue’s comments in Jira. It is also connected to cases, when the task needs to be postponed, other solutions are being proposed, etc.

  3. Any important questions and topics regarding tasks should be discussed in the issue’s comments in Jira, not in Slack.

  4. If a team member has any suggestions or questions, they should tag the team member who can answer your question. In case of urgency, also notify in the project’s channel in Slack.

Comments

Leave a Reply

More posts