Implementing the Scrum framework using Atlassian Jira

Hey everyone 👋🏾😊! Some time ago, I released 2 articles explaining the Agile model of project management and how to implement the Agile model into the software development lifecycle using the Scrum framework; click here to view the article on the Agile model, and here to view the article on the Scrum framework.

In this article, I’ll provide an in-depth explanation on Jira, a platform which can be used to implement the Scrum framework in the Software development lifecycle. I’ll go through how to sign up on the platform, create team projects, create User stories, Epics, arrange the Product backlog, conduct Sprints, and analyze the Burndown chart for a particular Sprint.

What is Jira 🤔?

Jira is a widely used project management software developed by Atlassian. It serves as a centralized platform for teams to plan, track, and manage their work throughout the entire project lifecycle. Jira is similar to a digital whiteboard where teams can organize tasks, collaborate, and monitor progress in real-time.

Implementing Scrum in Jira

Think of Scrum as a recipe for baking a delicious cake. Jira acts as your kitchen assistant, making sure you have all the ingredients (tasks), tools (features), and timelines (sprints) to whip up that scrumptious treat (completed project). Here are some of the features that Jira offers:

1. Backlog Management:
   In Jira, the product backlog is like your shopping list for the cake ingredients. It lists all the tasks (ingredients) needed to complete the project (cake). You can prioritize tasks, add details, and estimate their effort, just like you would organize your shopping list.
2. Sprint Planning:
   Picture sprint planning as the pre-baking preparation. You gather your ingredients from the backlog (shopping list), deciding which ones to include in your current sprint (baking session). Jira helps you select and prioritize tasks for the sprint, ensuring you have a clear focus for the upcoming work.
3. Daily Stand-ups:
   Daily stand-ups are like quick check-ins during the baking process. Each team member updates their progress, identifies any obstacles, and adjusts their plan accordingly. Jira’s agile boards provide a visual representation of tasks, making it easy to see who’s doing what and where things stand.
4. Sprint Review and Retrospective:
   Once the cake is out of the oven, it’s time for the taste test! Similarly, at the end of each sprint, the team gathers to review what was accomplished and reflect on how things went. Jira allows teams to track their velocity (how much work they completed) and gather feedback for continuous improvement.
5. Burndown Charts and Reports:
   Burndown charts in Jira are like the oven thermometer for your cake. They show how quickly you’re progressing through the sprint tasks, helping you stay on track to meet your goals. Additionally, Jira provides various reports and metrics to analyze team performance and project health.

Creating a project for your team on Jira

To begin, visit https://www.atlassian.com/software/jira, then click the Get Jira free button.

You will be redirected to Jira’s sign-up page. Sign up with your preferred method (Google, Microsoft, Email, etc…), or sign-in if you already have an account. You will be taken to a page which will require you to enter your preferred site name. Enter a unique name in the text field, then click Agree and start now.

You’ll see a page requesting information about yourself, you can skip this process or proceed with it. Afterward, you will be asked to select a template for your project; select SCRUM.

You will be taken to your project dashboard. Congratulations you’ve created your Jira project 🥳!

User stories

User stories are concise, user-centered descriptions of desired functionality or features from an end-user’s perspective. They serve as a communication tool between stakeholders and development teams, capturing the “who,” “what,” and “why” of a requirement in a simple format. Think of user stories as narrative snippets that paint a vivid picture of what users need and why it’s important.

Imagine you’re building your dream home. Before construction begins, you don’t just dive into building walls and adding fixtures randomly. Instead, you start with detailed blueprints that outline every aspect of your home, from the number of bedrooms to the placement of windows. User stories are like these blueprints, capturing the essential features and functionality your users desire in a clear, structured manner.

Let’s delve deeper into the structure of user stories:

• As a [Role]:
  User stories start with a role, representing the type of user or stakeholder who will benefit from the feature. This helps provide context and clarity about who the feature is intended for.
• I need [Feature/Functionality]:
  This is the essence of the user story, describing the desired feature or functionality from the user’s perspective. It outlines what the user wants to accomplish or achieve with the product or system.
• So that [Reason/Benefit]:
  The “so that” clause explains the rationale or benefit behind the requested feature. It clarifies the user’s underlying need or goal, helping the development team understand the purpose of the feature and make informed decisions during implementation.
• The Details/Assumption:
  This part elaborates on the features or functionalities described in the user story. It may provide more specific details, or technical considerations that are relevant to understanding and implementing the features. Think of it as expanding on the main idea presented in the user story body. Sometimes, some external factors or dependencies impact the implementation or scope of a user story. The details/assumption section allows the team to document any assumptions made during the creation of the user story. These assumptions could relate to certain conditions, constraints, or expectations that need to be met for the user story to be valid. For example, if a user story depends on the availability of a third-party API, the assumption section could note this dependency.
• The Acceptance Criteria:
  The “Acceptance Criteria” section of a user story outlines specific conditions or criteria that must be met for the user story to be considered complete and satisfactory. It serves as a checklist or set of guidelines that define the expected behavior or outcomes of the feature described in the user story. The Acceptance Criteria uses the Gherkin Syntax to describe the features to be implemented for a User story to be considered ‘complete’.
  The Gherkin syntax is simply a structured language used for writing acceptance criteria and automated tests in behavior-driven development (BDD). It provides a human-readable format that allows stakeholders, developers, and testers to collaborate effectively by describing the expectations of a completed User story.

Example User Story:

Let’s put it all together with an example user story:

Creating a User Story in Jira

Navigate to the issues page by clicking on the Issues button on the side navigation section to the left. Afterward, click the Create button at the top-left side of the page. A modal will pop up with text fields requiring the details of your User story, e.g. It’s type, summary, description, etc.

Your project has been automatically selected in the Project Select field. In the Issue Type Select field, select the Story option if it wasn’t automatically selected. Enter a short yet suitable summary for your User story in the Summary text field, e.g. Learn Jira.
In the Description text area, enter the text below

We’ll add the Acceptance criteria to the User story later. Your form should look similar to that below.

Afterward, click the Create button, and reload the page. You should be able to view your newly created User story in the list of created issues. You can click on it to view the User story details.

Epic

In Scrum, an Epic is a large body of work that can be broken down into smaller, more manageable user stories. Epics are typically too big to be completed in a single sprint and often span multiple iterations or releases. They represent huge initiatives or objectives that contribute to the overall goals of the project or product. Think of Epics as the major chapters in a book, each containing a series of smaller stories that collectively tell the larger narrative.

Creating an Epic in Jira

To create an Epic, click the Create button at the top-left section of the page. The same modal which was displayed when we created a User story will pop up. Select your current project in the Project Select field, but, select the Epic option in the Issue Type Select field. Enter a suitable summary for the Epic in the Summary text field, e.g. Learn and practice the hands-on tutorial on Jira.
In the Description text field, enter the below:

Your form should look similar to that below

Click the Create button, and refresh the page to view our newly created Epic. You should be able to view your Epic in the list of created issues. You can click on it to view the Epic details.

The above action adds the Learn Jira User story to the Learn and practice the hands-on tutorial on Jira Epic.

Product Backlog

The product backlog is a prioritized list of all the features, enhancements, bug fixes, and other work items that need to be addressed in a product. It serves as the single source of truth for what needs to be built, maintained, or improved upon to meet the needs of customers and stakeholders. It evolves continuously throughout the project or product lifecycle, reflecting changing requirements, priorities, and feedback from stakeholders.

Imagine you’re planning a dinner party, and you need to make a list of all the ingredients you’ll need to buy from the grocery store. Your list might include items like vegetables, meats, spices, and beverages, prioritized based on their importance and availability. The Product Backlog functions similarly to your shopping list, capturing all the items (features or tasks) you need to acquire to complete your project (dinner party). Just as you regularly update your shopping list based on what’s needed and available, the product backlog is continually refined and adjusted based on changing requirements and priorities.

Managing your Product Backlog in Jira

In this section, we’ll create more User stories in the Product Backlog and add the previously created Epic as a parent to each of them.

Create a User story for each of the following features, with each list title as its summary.

• Organize your Product backlog, arranging User stories in order of importance, with the most important at the top of the list

• Plan your Sprint by creating a Sprint within the project, and selecting some User stories from the top of the Product Backlog into the Sprint

• Assign story points/estimates to the User stories within the Sprint, and add the Acceptance criteria for each User story using the Gherkin syntax.

• Add a sprint goal and a timeline of 1 week to the selected Sprint, afterward begin the Sprint.

• Move each User story across the Kanban board, from the Todo section to the Done section

• Study the Sprint Burndown chart to understand the progress of the current Sprint

At the end, the list containing the User stories you created should look similar to that below

Before we conclude this section, click on the Learn and practice the hands-on tutorial on Jira Epic once more. You should be able to see all the User stories you created added as Child issues.

Organizing the Product Backlog

Now that we have all our User stories in the Product Backlog, it’s time to arrange them in order of importance, giving the most urgent User stories the highest priority, and moving them to the top of the list.

We’ll begin with the most prioritized User story which is Learn Jira, click on the Learn Jira User story, towards the right side of the webpage, you’ll click the Details dropdown, and search for the Priority field/option. If it’s not available, click on the Configure link to edit the fields in a User story.

You should be able to view a dashboard that enables you to edit the template of your User stories and the fields they can have. Towards the right side of the page, type Priority in the search bar, under the System fields the Priority field will be displayed, click on it to add it to your User story templates.

You can leave the Priority field in the Description fields section, or you could drag it down to the Context fields section. Click the Save changes button to save your new template, then click the Project Settings button on the side navigation bar towards the left side of the page

If you see the dashboard of your project, simply click the Back to project link which is located in the same position where the Project settings link was.

Navigate to the Issues dashboard by clicking the Issues link at the side navigation bar towards the left side of the page, under the list of your created User stories, click the Learn Jira user story. Towards the right side of the Learn Jira story, click the Priority field, and select Highest option from the dropdown.

Perform the same action for the below User stories, assigning each the priority in bold

• Organize your Product backlog, arranging User stories in order of importance, with the most important at the top of the list — Highest
• Plan your Sprint by creating a Sprint within the project, and selecting some User stories from the top of the Product Backlog into the Sprint — Highest
• Assign story points/estimates to the User stories within the Sprint, and add the Acceptance criteria for each User story using the Gherkin syntax — High
• Add a sprint goal and a timeline of 1 week to the selected Sprint, afterward begin the Sprint — High
• Move each User story across the Kanban board, from the Todo section to the Done section — Medium
• Study the Sprint Burndown chart to understand the progress of the current Sprint — Low

Congratulations we’re done with organizing our Product Backlog. To view the Product Backlog, navigate to the Backlog dashboard by clicking the Backlog link located at the side navigation bar towards the left side of the page.

Sprints

A Sprint in Scrum is a time-boxed iteration during which a Scrum Team works to complete a set of prioritized backlog items and deliver a potentially shippable product increment. Sprints typically have a fixed duration, usually ranging from one to four weeks, with the most common duration being two weeks. Each Sprint begins with Sprint Planning and ends with a Sprint Review and Sprint Retrospective, providing opportunities for the team to plan, inspect, adapt, and continuously improve.

Imagine you’re embarking on a road trip with your friends. Each Sprint is like a leg of your journey, with a clear destination and a set timeframe to reach it. Here are some aspects of Sprints you need to know about:

• Destination (Sprint Goal):
  Just as your road trip has a specific destination you aim to reach, each Sprint has a clear goal or objective that the Scrum Team strives to achieve. This Sprint goal represents the overarching outcome or value the team aims to deliver by the end of the Sprint. It provides direction and focus, guiding the team’s efforts and ensuring alignment with the overall product vision and stakeholder expectations.
• Planning and Execution (Sprint Planning and Sprint Execution):
  At the beginning of your road trip leg, you gather with your friends to plan your route, allocate driving responsibilities, and set expectations for the journey ahead. Similarly, each Sprint begins with Sprint Planning, during which the Scrum Team collaborates to select backlog items, define the Sprint goal, and create a plan for achieving it. Once the plan is in place, the team executes the work according to the Sprint backlog, focusing on completing the selected items and delivering a potentially shippable product increment by the end of the Sprint.
• Review and Reflection (Sprint Review and Sprint Retrospective):
  As you reach your destination at the end of the road trip leg, you gather with your friends to reflect on the journey, celebrate achievements, and discuss any challenges or lessons learned. Likewise, each Sprint concludes with a Sprint Review and Sprint Retrospective, providing opportunities for the Scrum Team to inspect the product increment, gather feedback from stakeholders, and reflect on their performance and processes. The Sprint Review focuses on demonstrating the completed work to stakeholders and gathering feedback, while the Sprint Retrospective focuses on continuous improvement, identifying strengths, weaknesses, and actionable improvements for future Sprints.

Organizing Sprints in Jira — Sprint Planning

To create a Sprint in Jira, navigate to the Backlog dashboard, if no Sprint section is present above the Product Backlog section, click the Create Sprint button towards the right side of the page

After the successful creation of your Sprint (that is if none existed before), begin to drag and drop each User story from the Product Backlog section to the Sprint section. Normally, we would only move the User stories with the highest priority to the Sprint. However, since this is just a demo project and a tutorial, we will move all items from the Product Backlog to the Sprint because we intend to implement them all during the upcoming Sprint.

Your Backlog dashboard should look similar to that above.

Assigning Story points/estimates to User stories

Now we need to assign story points/estimates to each User story in order to understand the difficulty level of each User story in the Sprint. Click the Learn Jira User story in the list of User stories in the Sprint. A section will be displayed towards the right side of the page which displays details concerning the User story, scroll down within that section to Details and search for the Story point estimate field.

The value we enter in the story point estimate field determines the difficulty/complexity of the feature a User story presents. For instance, if a User story’s feature is not bulky/difficult we could enter a low value like 3 into the story point estimate, however, if it’s extremely bulky/difficult we could enter a value of 13. One could use a different range of values to represent the difficulty level of the User story, however, it’s advisable to use values similar to clothes sizes, i.e. 3 for smallest/least difficult, 5 for medium/average, 8 for difficult/large/little bulky, and a 13 for really difficult/bulky. For the Learn Jira User story, we’ll enter the value 3 into its story point estimate since it has little to no difficulty. For other User stories within the Sprint, enter the story points below:

• Organize your Product backlog, arranging User stories in order of importance, with the most important at the top of the list — 8 (because, this involved us creating extra user stories, and organizing them according to priority in the Product Backlog).
• Plan your Sprint by creating a Sprint within the project, and selecting some User stories from the top of the Product Backlog into the Sprint — 5 (this was average, it only involves creating 1 Sprint and moving all User stories from the Product Backlog to the Sprint)
• Assign story points/estimates to the User stories within the Sprint, and add the Acceptance criteria for each User story using the Gherkin syntax — 8 (this was a little complex, it requires us to assign story point estimates and the Acceptance criteria to each User story within the Sprint)
• Add a sprint goal and a timeline of 1 week to the selected Sprint, afterward begin the Sprint — 3 (This only requires us to edit the Sprint’s details by adding a timeline, and Sprint goal)
• Study the Sprint Burndown chart to understand the progress of the current Sprint — 3 (this is low, since, it only requires we analyze the progress of the current Sprint)
• Move each User story across the Kanban board, from the Todo section to the Done section — 3 (this is also low because we only have to move each User story across the Kanban board according to their current state)

Your Sprint should look similar to that below

Adding the Acceptance Criteria to each User story within the Sprint

Now we are done adding the story points to each User story, we’ll begin writing the Acceptance Criteria for each User story — what must be achieved before the User story can be considered completed/done.

Click on the Learn Jira story, a new section will be displayed on the right with the User story details, double click on the description section until it becomes editable, I.e. Changes to a text area, then type ``` into the text field (at the bottom), a code-like box will appear allowing you to write some code snippets, then append the below into it

Given "I visited Atlassian Jira"
Then "I should be signed in to the platform"
When "I visit the /your-work URL"
Then "I should see at least 1 project in the list of projects"

If you’re prompted to select a language, select JavaScript from the dropdown (normally, we’re meant to select Gherkin, however since the Gherkin language option is unavailable in Jira, we use JavaScript). Finally, click the Save button.

Repeat this step for the rest of the User stories within the Sprint, adding the following Acceptance criteria

• Organize your Product backlog, arranging User stories in order of importance, with the most important at the top of the list:
  Given “I visited my project in Atlassian Jira”
  When “I navigate to the Backlog dashboard”
  Then “I should view a total of 7 User stories organized from the highest to the lowest Priority”
• Plan your Sprint by creating a Sprint within the project, and selecting some User stories from the top of the Product Backlog into the Sprint:
  Given “I visited my project in Atlassian Jira”
  When “I navigate to the Backlog dashboard”
  Then “I should view my Sprint with a total of 7 User stories added to it”
• Assign story points/estimates to the User stories within the Sprint, and add the Acceptance criteria for each User story using the Gherkin syntax :
  Given “I visited my project in Atlassian Jira”
  When “I navigate to the Backlog dashboard”
  Then “I should view my Sprint, with each User story within the Sprint and their assigned story points”
  And When “I click on any User story”
  Then “I should see its acceptance criteria within its description”
• Add a sprint goal and a timeline of 1 week to the selected Sprint, afterward begin the Sprint:
  Given “I visited my project in Atlassian Jira”
  When “I navigate to the Backlog dashboard to edit the existing Sprint”
  Then “I should see a Sprint goal and a 1 week timeline added to the Sprint”
• Study the Sprint Burndown chart to understand the progress of the current Sprint:
  Given “I visited my project in Atlassian Jira”
  When “I visited the Report dashboard”
  Then “I should view the Burndown chart for the existing Sprint, and it’s progress so far”
• Move each User story across the Kanban board, from the Todo section to the Done section:
  Given “I visited my project in Atlassian Jira”
  When “I navigate to the Kanban board”
  Then “All User stories should be completed/moved to the ‘Done’ column”

Your User stories should look similar to that below

Adding a goal and timeline to the Sprint, and commencing the Sprint

Go ahead and click the Start sprint button located at the same level as your Sprint title at the top-right side of the page. A modal will pop up allowing you to edit your Sprint, define its goal, and set a timeline for the Sprint. In the Duration field, select 1 week from the dropdown, we intend to make this Sprint short, seeing the features to be implemented are not much. In the Goal text area, enter the below

Your form should look similar to that below

After you’re done filling out the form, click the Start button. Your Sprint has begun, and you’ll be redirected to your Kanban board, where you can move each User story across depending on its current state — Todo, in progress, or completed.

Sprints — Kanban board

During the Sprint, we move User stories across the Kanban board to indicate their current state. Stories in the Todo column, are User stories that are yet to be commenced, those in the In Progress column are in progress, while those in the Done column are completed, i.e. their acceptance criteria have been met. Currently, all the User stories are in the Todo column because, the Sprint just began, as we progress, we’ll move each user story across the board.

However, before we begin moving the User stories; during Sprints, developers in the development team usually assign each User story they wish to work on to themselves according to their capacity. Therefore, let’s begin by assigning the Learn Jira story to ourselves.

Assigning User stories to ourselves during the Sprint

In the Todo column of the Kanban board, click on the user icon on the Learn Jira story, this should cause a small dropdown to be displayed, click the Assign to me option which has your name beside it; doing that will assign that User story to you. You could also assign a User story to other individuals within your team, i.e. If you aren’t the only one in your team. Jira allows us to add more individuals as team members to our project, however, we won’t cover that in this tutorial.

Moving each User story across the Kanban board

Now that we’ve successfully assigned the Learn Jira story to ourselves, we can move it to the Done column, because, we’ve successfully created our Jira project (the first step in this tutorial); repeat the same action for the following stories:

• Organize your Product backlog, arranging User stories in order of importance, with the most important at the top of the list
• Plan your Sprint by creating a Sprint within the project, and selecting some User stories from the top of the Product Backlog into the Sprint
• Assign story points/estimates to the User stories within the Sprint, and add the Acceptance criteria for each User story using the Gherkin syntax
• Add a sprint goal and a timeline of 1 week to the selected Sprint, afterward begin the Sprint

The above stories have all been implemented, therefore, we can move them to the Done column (in a real-world scenario, this is hardly the case, the stories are moved across the board according to their state, and sometimes this could take a while; e.g. A user story started today might not be completed immediately, it could take some time ranging from a few hours to up to a week. Some might not be completed during the ongoing Sprint due to some factors, and they’ll end up having their story points reduced, and added to the next Sprint). Your Kanban board should look similar to this

Analyzing the Sprint Burndown chart

We’ve successfully moved some User stories to the Done column, let’s analyze our Burndown chart. Before we commence, let’s assign the Study the Sprint Burndown chart to understand the progress of the current Sprint User story to ourselves, and move it to the In Progress column.

Navigate to the navigation bar at the left side of the page, and click the Reports link, if it’s nowhere to be found, follow the next steps, else ignore them:

• Click the Add view button at the same navigation bar, and a dialog will be displayed, lookout for Reports within the dialog, if it’s not there click the More views link.

• You’ll be redirected to a page which will display the Features of Jira and available dashboards, e.g. Boards, Backlog, etc… Search for the Reports feature, and click the toggle/switch button

• Click on the Back to project link at the navigation bar towards the left side of the page.
• You should now see a Reports link at the navigation bar

Click the Reports link, you should be taken to a page that displays the available charts/reports relating to your sprint, e.g. Sprint Burnup report, Burndown chart, etc. Click the Sprint Burndown chart.

You should be taken to a dashboard which displays the progress of the ongoing Sprint on a graph

The grey line which is diagonal represents the Guideline — The Ideal burn rate. It represents the amount of work that should ideally be completed by the end of the sprint in order to meet the sprint goal.

The red line represents the number of story points left to complete this Sprint. If we hover over the red line, we’ll see some circles on it; if we hover over those circles, it displays some information, e.g. hovering on the first circle displays the total number of story points a Sprint had when it commenced; the second indicates that the User story SCRUM-1 was moved to the Done column, thereby reducing 3 story points from the Sprint.

If we scrolled down, we would see 2 tables indicating the completed, and remaining User stories in the ongoing Sprint

We can also view the Burndown chart for previous Sprints by selecting the Sprint of our choice from the Sprint Select field

We have finished analyzing the Sprint Burndown chart. You can now explore other features on the dashboard, such as filtering the estimation field by Issues count.

You can move the Study the Sprint Burndown chart to understand the progress of the current Sprint User story to the Done column since we’re done analyzing the Sprint Burndown. Assign the last story in the Todo column to yourself, and move it to the Done column. Your Kanban board should look similar to this

Hence, all User stories in the Sprint are finished, we can conclude it. Normally, if there is extra time left and all User stories are done, the Scrum team may incorporate additional stories from the Product Backlog. Otherwise, they can wrap up the Sprint.

Concluding the Sprint

In a Scrum team, the Sprint review is conducted just before the ongoing Sprint is concluded; during the Sprint Review meeting, the team demonstrates the functionality that was developed during the sprint and gathers feedback from stakeholders. This feedback can then be used to refine the Product backlog and existing or new User stories.

To conclude the current Sprint, go to the top-right corner of the page and click the Complete sprint button. A modal will appear asking if you want to finish the Sprint. You will also have the option to link your Jira account to Confluence for creating your Sprint Retrospective. Check the box and click the Complete sprint button on the modal if you want to connect to Confluence, otherwise, just click the Complete sprint button.

You should be redirected to your Backlog dashboard after successfully concluding the Sprint. Usually, the Sprint retrospective is conducted after the Sprint has been concluded, where the Scrum Team reflects on the previous sprint, focusing on what went well, what could be improved, and what actions can be taken to make the next sprint more effective and enjoyable. Jira assists us in conducting a Sprint retrospective by integrating with Confluence, enabling us to document what went well during the Sprint and what we would like to improve upon. However, since this is a tutorial, and we don’t have a Scrum team, we will skip the retrospective.

Before we wrap it up, navigate to your Issues dashboard by clicking the Issues link in the navigation bar on the left side of the page. Search for the Learn and practice the hands-on tutorial on Jira Epic in the search bar, and click on the Epic to display its details. Scroll down, and you’ll notice the progress bar beneath the Child issues subheading is now at 100%, indicating that the Epic has been completed.

Conclusion

Congratulations 🥳! You’ve conducted your first Sprint using Jira. In this tutorial, we went through what Scrum was and how Jira helps implement it, we created an account and a project on Jira, organized and prioritized our Product backlog, created User stories and Epics, planned and created our first Sprint, and analyzed the ongoing Sprint’s Burndown chart.

If you need to learn more about the Agile model and Scrum framework, you can take any of these courses

Scrum Master Certification Specialization — LearnQuest, Coursera:

https://www.coursera.org/specializations/learnquest-certified-scrum-master

Introduction to Agile Development and Scrum — IBM, Coursera:

https://www.coursera.org/learn/agile-development-and-scrum?specialization=devops-and-software-engineering

Agile project management — Google, Coursera:

https://www.coursera.org/learn/agile-project-management