A Guide to Managing Issues in JIRA, Creating JIRA Workflow and JIRA Reports:
JIRA Sub-task was explained in our previous tutorial from the Series of JIRA Tutorials.
We have seen the different kinds of issues and how to create them in our earlier JIRA Tutorials.
This is the next JIRA tutorial in this series where we will learn how to use them, the workflow progress and the reporting feature of JIRA. JIRA issue travels through various states like ‘In Progress’ etc.
=> Click Here For Complete JIRA Tutorials Series
On its way, the user may keep on modifying the description, add additional comments, ask for further information about the issue and other various things.
Hence in this tutorial, we will take a detailed look at Issue workflow in JIRA – the lifecycle of an issue, Comment, Email/Share, and Watch options on a JIRA issue.
What You Will Learn: [hide]
Issue Workflow In JIRA
Once an issue is created in JIRA, it has its status as ‘To Do’ or ‘New’. This issue resides in the product backlog, which is normally handled by the Product Owner along with the Scrum Master in an Agile environment.
The product owner depending upon the criticality and importance of the issue decides which Sprint the issue should be worked on (For Example, SprintMay2018). Fix version in which the issue will be delivered is also decided and the same is updated on the issue in the ‘FixVersion’ field.
The product owner also decides which Scrum team will work on the issue depending upon the knowledge and competency within the scrum team. This is of course not a hard and fast rule that a team having sufficient knowledge of the area should work on a specific issue.
If sufficient time is available, knowledge transfer can be given to any team so that the team can look into the issue.
During sprint planning (of say SprintMay2018) the designated scrum team moves the issue in their Sprint Backlog.
Sprint Backlog
It is typically a list of issues which are committed for solving by a Sprint/Scrum team during the sprint planning
When the issue is in the sprint, one of the scrum team members assigns the issue to himself/herself. At times the issue is assigned to a person by the Scrum master. ‘Assignee’ field will now show the name of the person to whom the issue is assigned to.
The person checks the initial estimate on the issue and if the feeling is like the issue will require more time than the mentioned estimate, then it can be re-estimated after the discussions with the product owner and the scrum master.
These discussions are important because the scrum master can then take a call of one or more issues that are to be removed from the current sprint to match the total team capacity.
Modifications to the issue like a change in the description are done using the Edit button. In some versions of JIRA, each field can be edited separately using the pencil (edit) symbol.
The Assignee then moves the issue to ‘In Progress’ state by simply clicking the ‘Start Progress’ (‘In Progress’) button.
Once the assignee starts working on the issue, if he feels like the information provided in the issue description is not sufficient for him/her to continue, then the issue progress can be stopped by simply moving the issue to the ‘To Do’ state.
Some organizations have a’ Stop Progress’ button for this purpose. The assignee should write a proper comment describing why the issue is being stopped. Further to this, the issue status can be changed to ‘Awaiting Info.’ (some organizations might not have this customized status type).
Comment On Jira Issue
To get a free text field for Comment, simply click on the ‘Comment’ tool strip button which is located just below the name of the issue (‘test bug’ name of an issue in this case). This button is also available in the Activity section of the issue.
This will display a text field with formatting options, like the one displayed in the below image:
Click on the ‘Add’ button after writing a proper understandable comment, which will save the comment. Different formatting can be applied if required.
Visibility of the comment can be restricted by selecting a suitable option from the drop-down available near the padlock symbol. Choices typically will be like ‘All Users’, ‘Project Roles, ‘Developers’. This restriction is very important if the end customer has access to the JIRA.
The assignee can send an email to the creator of the issue through JIRA itself so that an early answer can be expected.
Email can be sent through the following options
#1) Using ‘Share this link…’ button available at the top right-hand corner of the page.
#2) Using the ‘Email’ menu item available from the menus available after clicking the ‘…’ button at the top right-hand corner of the page.
#3) Using ‘@’ functionality in the comment text field. After writing @ JIRA pops up a list of email ids and the user can choose one or more.
Note: Options 2 & 3 may only be available after customizing JIRA.
The Following popup dialog opens after clicking on the ‘Share’ button.
Username(s) or email id(s) are to be entered in the ‘Username or email’ field. Additional comments can be entered in the ‘Note’ field. Clicking on the ‘Share’ button on popup dialog will send an email to the mentioned users with a link to the JIRA issue.
The assignee can add him/her as a ‘watcher’ by using the ‘Watch issue’ option. By doing this watcher will receive notification for every single change on the issue, like a change in description, new comment and even log work too.
Watch Issue
This menu item gets displayed after clicking the ‘…’ button. After clicking this menu item, the user (assignee in this case) gets into the watcher’s list and the label of menu item changes to ‘Stop Watching’, which in turn can be used to stop watching the issue.
Any other team/project members can add themselves as watchers if they are interested to know what’s going with the issue, as a watcher does not have to explicitly open the issue to check the progress but notification(s) is received.
Once one or more users start watching the issue, the corresponding count will be displayed beside the label named as ‘Watchers’ (refer above image). Logged in user can stop watching the issue by clicking ‘Stop watching this issue’ link or by clicking ‘Stop Watching’ on the ‘Watchers’ list page.
In case, when someone is interested to know the names of the users who all are currently watching a particular issue, then click on the ‘Watchers’ menu item, which gets displayed after clicking the ‘…’ button. (Refer the below images).
Once the assignee is comfortable with the information, then the issue is restarted again. If the issue status was ‘To Do’, then the user can directly start the progress by clicking ‘Start Progress’ (‘In Progress’) depending upon the available button. The issue can again go into the same flow which means the progress can be stopped if required.
Assignee writes a proper understandable comment on the issue. It also adds ‘Log work’ (the time he invested working on the issue) at the end of each day. This facilitates the product owner and the other stakeholders to know the progress on the issue.
As soon as the assignee feels that the issue is solved and code review is done, the changes are unit tested. Once the solution is satisfactory to the assignee, the status of the issue is changed to ‘In Test’ (‘To Be Verified’).
Scrum team tester then assigns the issue to him/her & tests the changes and the surrounding areas.
If the tester finds an issue either in the changes or a regression issue then the test is failed and the issue status is changed back to ‘In Progress’ and assigned to the concerned developer. The tester will log the work with the number of hours utilized.
The developer will look into the new changes required, will fix the same, unit test it and then move the issue to ‘In Progress’. The tester will subsequently test the issue and once satisfied, will mark the issue status as ‘Resolved’ (Done).
The issue is resolved only after a proper demo to the stakeholders at the end of Sprint and all must feel that the DoD is met. Once the fix/product version is delivered the issue is closed.
It needs to be remembered that an issue, in case of a bug, can be closed directly, if it is found to be not reproducible.
There might be a case wherein after some time (days/months etc.) due to a problem triggered by the issue, and it might have to be reopened and which is then traversed through the same cycle.
Note: Button ‘…’ referred above may be named as ‘More’ and the places alongside the ‘Edit’ button in the tool strip on the left of the page, in some JIRA versions or customized ones.
In short, a JIRA issue travels from stages like New (Open) -> In Progress -> In Test -> Resolved (Done).
Along the way, the users/various stakeholders associated with getting the issue fixed add comments/descriptions on the issue accordingly.
Manage Issues In JIRA
The issue once created can be accessed by searching the ID, browsing the “Issues” menu item or going to the project details and checking the issues tab.
When you access an issue and click on its link, the details will be displayed. All the actions that can be performed on the particular issue are available in the header of an issue details screen:
We will go in sequential order from Right to left and discuss all the options.
#1) Edit: As the name suggests, this option lets you modify an issue created. Click on it and modify the information as desired. Choose ‘Update’ when done. This is similar to the “Create Issue” dialogue.
#2) Comment: This is a useful way to record the proceedings on an issue and to communicate with the concerned members. Enter your comments and choose the option to restrict viewership:
#3) Assign: This is the option you would need when you want to shift the ownership of an issue. Enter the Assignee information, comments (anything that you would want to communicate) and choose the viewership of the comment. Once an issue is assigned to the user, an automatic email is sent (if this option is chosen by the admin) and the issue appears on the assignee’s dashboard on login.
#4) More: The following options are available under the “More” menu item:
Agile Board, Rank to Top, Rank to Bottom -> Related to Agile Projects – the details of which are going to be coming up in a later article.
Attach Files, Attach Screenshots -> Lets you attach files to an issue. The screenshot option will auto-capture a screenshot. All you need to do is a print screen on your machine and you can directly copy it here into JIRA.
Add Vote, Voters, Stop watching, Watchers -> Voting is a process that JIRA users can perform to support the resolution of an issue favorably or unfavorably. The options in this section facilitate the same. You can also choose to watch an issue – when you do so, all the changes to it will be notified to you.
Create Sub-Task, Convert to Sub-task -> These are the options that help create and work with Sub-tasks. The details are available in tutorial #3 of the JIRA series.
Labels -> This concept is similar to the “Labels” that we find on various blogs and web pages. You can categorize issues based on Version and Component formally, but when in need of something more informal, this option can be used. For Example, all the issues raised to track peer review comments can be labeled “peer review” to view and track them easily.
#5) Log work: This is a way to track the progress on your issue in terms of time. When this option is used, the following dialogue opens up. As you can see, the detailed information about how much time is spent on an issue, how much is remaining, etc can be logged here.
#6) Move: JIRA issues can be moved across projects. However, the move from one project to another might mean a different target workflow, a different issue type, a new status, etc. It is therefore advisable to analyze thoroughly how the move is going to affect the issue before going ahead with this.
#7) Link: This is a very versatile feature of JIRA that allows you can logically link issues with one another and establish relationships/dependencies.
An example situation where this can be used in QA projects is when a certain defect prevents you from working a certain requirement. You can use this option to show dependency.
When this link is accessed, the following dialogue opens up. Using this dialogue is very simple:
The different kinds of associations can be chosen from the “This issue” list box. The list contains:
Alternately, you can choose to include a web-link as a reference.
#8) Clone: As the name implies you can create a duplicate of an issue.
When an issue is Cloned:
- The cloned issue’s summary begins with “CLONE” prefixed.
- There will be a link established between the parent issue and the cloned issue.
#9) Email Issue: Click on the icon.
Enter the information for the recipient of the issue information in the below dialogue that opens up. An email with the JIRA issue details will be sent.
10) Export: JIRA also provides a way to write the issue information to external files. To do so, click on the “Export” button at the rightmost corner and you will see the formats to which you can download a JIRA issue:
How To Move A JIRA Issue Through The Different Stages Of Workflow?
#1) An issue created in JIRA is always in the status “Open” upon creation.
#2) The workflow stages that it goes depends on the project type and the workflow assigned to the project while creation.
#3) Only Admin will be able to choose this and once chosen, it cannot be changed and all the issues under the project will go through the same workflow.
#4) When the “Start Progress” button is clicked the issue status changes to “In Progress “and button label changes to “Stop Progress” which when clicked will revert the status back to “Open”.
#5) Clicking on the “Workflow” button will display you a list box of the next stages that an issue can go to.
#6) If the issue needs to be set to “Resolved” directly, there is a “Resolve issue” button available. On clicking it you will be able to choose the reason for saying the issue is fixed.
#7) To view the workflow that a certain issue goes through, click on the “View workflow” link that is next to the status field of an issue in the issue details page. For Example, for my issue the workflow displayed is:
JIRA Reports
JIRA also comes with a robust reporting feature. There are many kinds of reports that it facilitates.
Browse through a project whose details you would want to get a report of and go to the “Reports” tab. Here you will see a list of all the reports that can present for you.
Choose the report and set the data criteria and you will have a custom made the report in hand within no time.
Also, for an incident management tool, a user would expect strong search features and JIRA fits the bill in this area too. So, be sure to leverage that to your benefit.
Conclusion
This brings us to an end the ‘JIRA- User’ part of the series. As always, we hope these JIRA tutorials in the series will not only help you use Atlassian JIRA issue tracking software successfully but also aids you in achieving the best results for your Project/Incident/Test/Defect management activities.
