.NET Daily

JIRA

JIRA Workflow for Web Development Example: Simple and Effective

Posted on .

JIRA Workflow for Web Development Example: Simple and Effective

Introduction

By using a fairly simple JIRA workflow, you have good parts and of course bad parts. One of the good part is that everyone can understand the workflow in minutes. One of the bad parts is that the visibility over a task lifecycle or project progress is not good at all.

In web development projects, there are several stages where a certain feature might go to: code review, staging server, production server, etc. And because of that, there is a real need to represent them in a workflow in order to get that good visibility that the stakeholder might request.

Given the context, I’ve spent some time to design a minimum sufficient workflow which I would say is simple enough to be understood by team member and should help as well management get good visibility over project.

Below you can find an image of the workflow:

JIRA Workflow for Web Development

Workflow Breakdown

The workflow contains the following steps:

  • Open. This is the default status of the task. It has only one option of transition: Start Progress. This moves the status of the task to In Progress.
  • Reopened. This status can be seen as the second starting point when a task is being rejected during other steps. It has a different name from Open only to reflect that the task is in the middle of the lifecycle and not just being created. It has only one transition: to In Progress.
  • In Progress. This status signifies that work has been started on the task. It has the following transitions:
    • Stop Work. The user can move the task back to Open status, in case they decided not to pursue the implementation, or simply, they started progress by mistake.
    • Mark for Code Review. This moves the status of the task to Code Review. It means that the work has been completed on the task and the code is ready to be reviewed.
    • Mark for Deploy. This moves the status of the task to Ready for Deploy. It means that the work has been completed and approved and it is ready to be moved to the staging server or it could stay in a CI environment for a preliminary check.
    • Mark as Completed. This moves the status of the task to Done. Not all the tasks need to be code reviewed or published to a certain server. For example, installing a certain tool on the staging server doesn’t need to pass all the steps in the workflow. As such, the users need to be able to have a shortcut to Done status.
  • Code Review. This status signifies that the code review is in progress. It has the following transitions:
    • Reject Task. This moves the task to Reopened status. It means that issues were found in the submitted code and the developer needs to address them.
    • Approve Task. This moves the task to Ready for Deploy status. It means that the work has been approved and the code is ready to be deployed on the staging server.
  • Ready for Staging. This status signifies that the work on the task is completed and it is ready to be deployed on the staging environment. It has the following transitions:
    • Restart Progress. This moves the task back to In Progress. It means that additional work needs to be performed on the task.
    • Start Testing on Staging. This moves the task to Testing on Staging status. It means that the task is moved to the staging environment and it is ready to be taken over under the QA’s team responsibility.
  • Testing on Staging. This status signifies that QA is doing the necessary testing in order to validate the task. All the testing happens in the staging environment. It has the following transitions:
    • Issues Found. This resets the task to Reopened status and it needs to be again rescheduled for implementation as issues were found during testing.
    • Mark for Prod Deploy. This moves the task to Ready for Prod status where the work needs to gain approval and acceptance from the stakeholders as no issues have been found.
  • Ready for Prod. This status signifies that the stakeholders of the task are doing a final review and provide acceptance so that the task can be scheduled for deployment on production. It has the following transitions:
    • Issues Found. This resets the task to Reopened status and it needs to be again rescheduled for implementation as issues were found during testing.
    • Start Testing on Prod. This moves the task to Testing on Prod status. It means that the task has been approve and it can be deployed and tested into the production environment.
  • Testing on Prod. This status signifies that QA is doing the final smoke testing on the production environment. It has the following transitions:
    • Issues Found. This resets the task to Reopened status and it needs to be again rescheduled for implementation as issues were found during testing.
    • Mark as Completed. This moves the task in Done status and it means the work is completed.
  • Done. This signifies that the task is completed. It has only one transition: to Reopen status in case extraordinary issues are found.

Roles Assignment

In terms of team roles responsibility, this is how I see the repartition of statuses based on a typical web development task:

Status Responsible Roles
Open All Roles
Reopened All Roles
In Progress Developer
Code Review Solutions Architect
Ready for Staging Developer
Testing on Staging QA
Ready for Prod QA/PM/PO/DEV
Testing on Prod QA
Done All Roles

Please let me know if you think this workflow could fit well within your company or it still lacks important statuses or transitions.

Darius

Darius

Darius Dumitrescu is a creative Senior CMS Consultant with in depth .NET knowledge, focused on Web Development and Architecture Design.

There are no comments.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

View Comments (0) ...
Navigation