Many organizations use JIRA as a one-shot solution to automate their processes, and JIRA has almost become synonymous with Agile. Even organizations that don’t deploy it across all levels use it for at least some of their projects. Such is the popularity of JIRA. So, what exactly makes it so popular? JIRA provides a simple and easy-to-use solution for project management tasks, right from gathering requirements to maintaining releases and generating all sorts of reports and metrics. The best part of the tool is that it is highly customizable, attending to the needs of one and all. If it is said that there isn’t a thing that one cannot do using JIRA in terms of project management, then that is not an understatement.
Since Agile is the buzzword now and most organizations are opting for it, this article will provide users with a detailed insight on how to carry out their project management tasks and software development activities by using a Scrum framework.
Before moving ahead, there are two basic pre-requisites that the user who intends to use JIRA must have and they are:
The first and most important thing is to create a project in JIRA under which we will be carrying out our activities and tracking the progress of those. There are two ways a user can create a project.
Step 1: Log in to JIRA using your credentials. Once you are logged in, you will land on the project dashboard which will look something like this.
Step 2: Click on Settings icon and select the Projects option as highlighted in the image below.
Step 3: Select “Create Project” option as shown in the image.
Step 4: After clicking on “Create Project”, you will be prompted with two options to select from.
Step 5: Once you have selected the type of project, you will be asked to enter the Project name. You will also have the option to change the type of template i.e Scrum, Kanban or Bug Fixing, depending on the purpose for which you wish to use JIRA. Once done, you must click on the “Create” button.
And voila, it’s that simple. Once you have clicked on the create button, you will land on the project dashboard with the name of the project highlighted on the top left. As we can see in the image below, project name “My Scrum Project” is visible. Method 2.
The steps remain the same, only difference is that instead of navigating through settings, once you have logged in, you will have the option to navigate via “Projects” link as depicted in the pic.
Once the project has been created the second important step is to define requirements in a backlog. As you can see in the pic below, there is the option to select “Backlog” from the left side panel/navigation pane to navigate to the backlog section.
Here you can start creating backlog items. This backlog serves as the “Product Backlog”. Users can outline requirements in terms of Epics, User Stories, Tasks and Bugs which are known as “issue types” in JIRA. In short, everything that is created is an issue in JIRA. Please note that for ease of understanding and reference, I am sticking to the most basic issue types as mentioned above.
Step 1: To create issues in JIRA, all that is needed to be done is to click on the “Create” button on the top most navigation bar. This bar remains visible at all times by default, no matter whichever page you navigate to. Step 2: Once the user clicks on “Create”, a dialog box to enter details of the issue will open.
The two most important fields in this are:
Project: This field, by default, is populated with the name of the project you are in. But in case you wish to change the project field, the same can be selected from the dropdown
There are two types of fields on the dialog box; Mandatory and Non-Mandatory. Mandatory fields are marked with a red Asterix. Also, these fields change on change of the issue type i.e. on basis of what is applicable to the issue type being selected.
As already mentioned, JIRA is highly customizable and a JIRA admin can add or change more issue types based on what terminology is being used by the project and/or organization on the whole. E.g. Issue type of Features can also be added in case teams follow a feature-based development approach wherein features are divided across teams and encompass the hierarchy of epics and stories.
In a similar manner, issue type “Story” can be amended to be displayed as “User Story” or at times to be more specific, something like “Functional User story” and/or “Technical User story”.
In addition to this, the fields are also customizable. New fields can be added and the rule of mandatory and option field can also be altered depending on what works best for the team.
To make these changes, the JIRA admin needs to navigate to the settings section and then to the desired settings type to change them. Please note that these settings will only be available to the user who either is a JIRA admin or has permission to perform these activities. Permissions are issued by the JIRA admin to the user.
Coming back to the topic of creation of backlog, once you fill up the details and click on “Create” at the bottom of the dialog box, a new issue is created in JIRA that now starts reflecting in the backlog.
Issues can also be created by using the short cut link available in the backlog section as highlighted below.
Once you click on “+” icon, you will be able to select the type of issue to create and provide a summary for the same.
After entering the summary details, you are required to click enter and the issue is created. To enter other details, you will have to navigate to the created issue by clicking on it in backlog or opening the same in a new tab and then doing the needful.
As soon as an issue is created, the same starts reflecting in the backlog. Here you can see two stories and one bug that were created, are visible in the backlog.
We all know the hierarchy of requirements goes something like Epics > Stories > Tasks. JIRA gives us the capability to link one issue type with another. To start with as a very basic ask, stories will fall under the epics and thus need to be linked with the correct epic. This linkage is something which replaces the requirement traceability of traditional models. When everything is perfectly linked then it can be easily known which requirement from the customer was covered under which epic and if we go into a granular level, under which story and even tasks the requirements fall under. Similarly, if a bug is found in the story while working on it, the bug can also be logged and linked against the story.
To link issues, the steps below can be performed.
Epic Link: To link stories under an epic, JIRA specifically provides the field “Epic Link” in stories. The field at most times is made mandatory by organizations to make sure that every story that is created in JIRA is by default linked to the epics. Here the epic becomes the parent issue of the story and thus it also becomes easy to make sure that every requirement has been worked upon.
Step 1: There are two ways to create the Epic link. While creation of the story, you will have the option to mention Epic link or if the story is created using shortcut link, the same can be added by opening the story and then mentioning the epic in the epic link field as shown below.
Step 2: Once selected the same starts reflecting in the story details.
Step 3: To see the linkage, you need to navigate back to backlog. The link starts displaying in the backlog.
Once the bugs are created, they can be used to block user stories in a similar fashion, though there is no specific field like epic link in case of bugs, they can be linked using the “Link issue” option.
Step 1: Once the bug is created, note the issue ID and open the story which needs to be blocked and select the “Link Issue” option. Step 2: By default, “is blocked by” option is selected, indicating that the story is blocked due to the following issue. As soon as you enter the bug issue id and click on link, the story is linked with the bug or to be more specific, the story is marked ‘blocked’ by the bug. In this way multiple stories can be blocked with a single bug and vice versa.
Note – Stories can be linked to other stories to showcase linkage, to mark dependency, to display duplicity/redundancy etc in the same manner, all that is needed is to select the correct option from the dropdown after selecting “Link issue”.
As the rule goes, the product backlog must be prioritized at all times i.e. the issue with the highest priority should be at the top and the issue with least priority should be at the bottom of the backlog, so that the teams working on the backlog have a clear idea about the work they need to pull in once the next iteration starts or to understand if they have capacity for more during the ongoing sprint. Keeping the backlog prioritized also helps the team to keep working as per the product roadmap in the absence of the product owner and as such the team does not get blocked.
JIRA also provides the capability to keep the backlog prioritized at all times by the simple function of dragging and dropping the issue above or below the other ones. Below images will give you an idea of the same.
Scenario 1: Once you start creating issues in the backlog, the issues start reflecting in the ascending order of their Issue IDs i.e. the order in which they are created. For ease of reference, the issues have been named as 1, 2, 3, 4 and placed one after the other.
Now assume that the priority of Story 4 is the highest and thus it should be at the top of the backlog, followed by test story 2, followed by 1 and 3 respectively. Thus, they should be placed in order of 4,2,1 and 3 in the backlog. This can be done by simply dragging the items to bring them in the desired order.
Scenario 2: Below image gives you a backlog which is sorted on the basis of prioritization of stories as per the priority defined by the PO.
Bugs too can be dragged and placed at the relevant position in the backlog depending on their severity and priority. All these activities of creation and prioritization of backlog are done primarily by the PO. In case the PO is supporting multiple teams and there are BAs supporting individual teams or acting as proxy POs for the teams, then POs can leverage them for backlog management. Scrum master needs to ensure that the backlog is prioritized, properly detailed and at least the stories for the immediate next sprint remain in a ready state.
Once the backlog has been created, the next step for the team is to gather and hold the sprint planning event. PO can open the stories and discuss the details and Acceptance Criteria with team members. Once all the stories have been discussed, the team can start pulling the stories in the sprint and for that to happen the team will need a sprint in JIRA. It is again very simple.
Step 1: In the backlog section, there is a “Create Sprint” button. Step 2: Once you click on the button; a sprint is created, starting from sprint 1 with a prefix of project ID as shown in the image below. You have the option to create issues directly in the sprint using the quick link as mentioned above for the backlog or the issues can be dragged and dropped in the sprint created. All the issues dragged and dropped in the sprint created, as discussed in sprint planning, will serve as the sprint backlog.
Step 3: Once all the issues are dragged and dropped in the sprint, the sprint is ready to be started. As an example, we see that test story 4 and 2 as well as a bug have been dragged to sprint 1 as displayed in the image below.
Please note as part of sprint planning session, details like Story Assignee, story points and hourly estimates can be filled in the stories using the fields available. Also, in case the story owner wants to highlight the individual tasks they intend to perform as part of working on the story like Analysis, Coding, Review etc or in case multiple team members are working on a single story then to highlight individual work assignments, the option of creating tasks can be used. Tasks can be created just like stories, as mentioned above. It is similar to work breakdown in traditional models.
What needs to be made sure is that before marking the sprint planning as being complete, all the stories have been pulled in sprint and assigned and estimated in terms of story points or hours or both, according to the approach the teams have decided to take. All the sub tasks that have been created, can optionally be assigned. If desired, these subtasks can also be estimated. Once all this is done, the Scrum Master can then mark sprint planning as complete and proceed to start the sprint.
As we know that before sprint planning, a goal is provided by the PO to the team. The same goal can be added in the sprint. Just select the three dots option besides the sprint on right side and select edit sprint and you will be able to enter the sprint goal.
Once the planning is complete and activities like estimations, assignments and tasking have been done, it is time to start the sprint. This is simple to do. In the backlog, there is a “Start Sprint” button. Once you click on it, a dialog box appears where you can verify sprint goal and set a duration for the sprint. After reviewing the details, you can click on “Start” and we are good to go.
Once the sprint has started, you can navigate to the “Active Sprint” section to visualize the progress on the stories in the sprint. Team members can update the stories to depict statuses from “To Do”, “In Progress” and “Done” and also update their daily hours in the stories in case teams are estimating in terms of hours.
On the last day of the sprint, it is important to mark the ongoing sprint as closed in JIRA so that next sprint can be planned and started.
All the items which are marked done are considered complete. Anything pending to be completed is either moved to the next sprint or to backlog in consultation with the PO.
Step 1: In the “Active Sprint” section. On the top right corner, you need to click on “Complete Sprint” button.
Step 2: Once the “Complete Sprint” button is clicked, a dialog box appears with details of issues that have been completed and the ones which are pending. Select the place where you wish to move the pending items to, either to the backlog or next sprint which is to be started.Step 3: Once you select the desired value under “Move to” field and click on “Complete” button the Sprint is marked as complete.
Your email address will not be published. Required fields are marked *
85 percent of respondents say Scrum continues to... Read More