Run Your First Agile Sprint in Jira

Simulate a full Scrum sprint cycle in Jira, from backlog to sprint report.

Introduction

30 Second Summary

Every software team ships features in short cycles called sprints. If you want to work as a developer, you need to know how these cycles run day-to-day, not just in theory.

In this project, you will run a complete Agile sprint cycle in Jira for a fictional recipe-sharing app. You will write user stories, estimate work, plan a sprint, move tasks across a board, and review your results with real metrics.

What You'll Build

You will simulate being a developer on a Scrum team, managing a full sprint from an empty backlog to a delivered increment with a burndown chart and velocity metric.

By the end of this project, you'll have:

A Jira Scrum project with a prioritized product backlog of user stories written in standard format.
A completed sprint with tasks moved across the board, estimated using story points and the Fibonacci sequence.
A sprint report showing your burndown chart and velocity that you can reference in interviews.
Secret Mission: add Epics to group related stories and create a sprint goal strategy tied to business value.

Are there any prerequisites?

None. You only need a web browser. This project walks you through creating a free Jira Cloud account from scratch. No coding experience or credit card is required.

Create Your Jira Account and Scrum Project

Before you can practice Scrum as a developer, you need a tool to manage your work items, sprints, and board. That tool is Jira, the industry-standard platform used by the majority of Agile teams.

In this step, you will create a free Jira Cloud account and set up a Scrum project for your fictional recipe-sharing app, RecipeBox. By the end, you will have a project space with a backlog, board, and timeline ready to fill with user stories.

In this step, get ready to:

Create a free Jira Cloud account.
Set up a new Scrum project called RecipeBox.
Explore the Backlog, Board, and Timeline views.

Sign up for a free Jira Cloud account

Jira Cloud has a free plan for up to 10 users. No credit card is required.

Open your browser and go to the Jira signup page:
https://www.atlassian.com/try/cloud/signup?bundle=jira&edition=free
Sign up using your email address, or choose one of the alternative options: Google, Microsoft, Apple, or Slack.
When prompted, choose a site name for your Jira instance. This becomes your URL (e.g., yourname.atlassian.net). Pick something short and memorable.
Verify your email if prompted, then follow the onboarding prompts until you reach your Jira dashboard.

Why does the site name matter?

Your site name cannot be changed on the free plan after creation. It forms the permanent URL for your Jira instance. Use something like your name or a short alias you will remember.

Site name rejected?

Some site names are already taken or restricted. Try a different variation (e.g., add a number or abbreviation). If the page is unresponsive, try an incognito window or disable browser extensions.

help me troubleshoot my Jira signup

Create your RecipeBox Scrum project

Jira organizes work into spaces (previously called projects). You will create a team-managed Scrum space that gives you a backlog, sprint board, and timeline out of the box.

In the left sidebar, hover over Spaces and click the Create space (+) icon.
Under the template library, select the Scrum template.
Click Use template.
When asked for the space type, select team-managed.
Enter RecipeBox as the space name.
Click Create.

What is a team-managed space?

Team-managed spaces let any user configure their own workflow, columns, and settings without needing a Jira administrator. This is perfect for learning because you have full control over your board and backlog.

Company-managed spaces are locked down by admins and used for larger organizations with strict governance. You do not need one for this project.

Why Scrum and not Kanban?

Scrum uses time-boxed sprints with planning, review, and retrospective ceremonies. This structure gives you more to practice and discuss in interviews. Kanban is a continuous flow model that works best with real ongoing work and is harder to simulate solo.

Jira's new navigation

Jira rolled out a new navigation in 2025 that renamed "projects" to "spaces." Many tutorials and interview resources still use the term "project." The underlying concepts (backlog, sprint, board) remain identical. If an interviewer says "Jira project," they mean the same thing as a Jira space.

Explore the project layout

Now that RecipeBox exists, take a moment to orient yourself in the Jira interface. You will use three views throughout this project.

In the left sidebar (or the horizontal tabs at the top of your space), click Backlog. You should see an empty backlog with a Create sprint button.
Click Board to switch to the board view. This shows columns for To Do, In Progress, and Done.
Click Timeline to see the timeline view. This is where Epics display as horizontal bars (you will use this in the Secret Mission).

What should I see?

Your Backlog view should be empty with a Create sprint option visible at the top. The Board should show three empty columns. The Timeline should be blank since you have not created any work items yet.

Can't find the Backlog or Timeline?

In the new Jira navigation, space views appear as horizontal tabs at the top of the space page (Backlog, Board, Timeline, etc.). If you do not see all tabs, click the More actions (three dots) next to your space name and check your space settings.

help me find the Backlog and Timeline views in my Jira space

Your Jira workspace is ready. Next up, you will fill that empty backlog with user stories that describe what RecipeBox needs to do.

Build Your Product Backlog with User Stories

Your RecipeBox project is set up and ready to go. Now it's time to fill it with the work items that represent what your app needs to deliver.

In Scrum, all planned work lives in a product backlog. Each item is a user story that describes a feature from the user's perspective, making sure the team always builds what matters most.

In this step, get ready to:

Write 8 user stories in standard format.
Add acceptance criteria to define when each story is done.
Prioritize the backlog so the most valuable work comes first.

Write your user stories

User stories follow a specific format that keeps the focus on who benefits and why. The format is: "As a [user type], I want [goal] so that [reason]."

You will create 8 stories for RecipeBox that cover the core features a recipe-sharing app needs. Each story captures one feature from the perspective of a home cook using the app.

In your RecipeBox project, click Backlog in the left sidebar to open the Backlog view.
Click + Create at the bottom of the backlog section.
Type the following as the issue summary: As a home cook, I want to log in so that I can access my saved recipes.
Press Enter to create the story.

Speed up story creation

After pressing Enter, Jira keeps the inline create field open so you can immediately type the next story. You can create all 8 stories in a row without clicking any extra buttons.

Create the remaining 7 stories by typing each summary and pressing Enter:

Type: As a home cook, I want to view all recipes so that I can browse what is available.
Type: As a home cook, I want to search recipes by ingredient so that I can use what I already have.
Type: As a home cook, I want to view a recipe detail page so that I can see full instructions.
Type: As a home cook, I want to save a recipe to my favorites so that I can find it quickly later.
Type: As a home cook, I want to create a profile so that I can personalize my experience.
Type: As a home cook, I want to rate a recipe so that I can share my feedback.
Type: As a home cook, I want to share a recipe link so that I can send it to friends.

You should now see 8 stories listed in your backlog.

Why this format?

The "As a... I want... so that..." format forces you to think about who benefits, what they need, and why it matters. This prevents teams from building features nobody asked for.

In interviews, hiring managers look for candidates who can articulate requirements from the user's perspective. This format is the industry standard.

Don't see + Create?

Make sure you are in the Backlog view, not the Board view. The inline create option appears at the bottom of the backlog section. If it still doesn't appear, try clicking the Create button in the top navigation bar instead.

Help me find where to create issues in Jira

Add acceptance criteria to each story

Acceptance criteria define when a story is truly finished. They use the Given/When/Then format, which describes the starting condition, the user action, and the expected result.

Click on the first story ("As a home cook, I want to log in...") to open it.
Find the Description field in the issue detail view.
Type the following acceptance criteria into the Description field: Given a registered user, When they enter valid credentials, Then they are logged in.
Click Save or click away from the field to confirm your changes.

Now repeat this process for the remaining 7 stories. Add the following acceptance criteria to each:

View all recipes: Given a logged-in user, When they navigate to the recipes page, Then they see a list of all recipes.
Search by ingredient: Given a logged-in user, When they enter an ingredient in the search bar, Then they see recipes containing that ingredient.
View recipe detail: Given a logged-in user, When they click a recipe, Then they see the full recipe with ingredients and steps.
Save to favorites: Given a logged-in user, When they click the save button on a recipe, Then it appears in their favorites list.
Create a profile: Given a new user, When they complete the profile setup, Then their name and preferences are saved.
Rate a recipe: Given a logged-in user, When they submit a star rating, Then the rating is saved and displayed.
Share a recipe link: Given a logged-in user, When they click share, Then a shareable link is copied to their clipboard.

What makes good acceptance criteria?

The Given/When/Then format removes ambiguity. A developer reading "Given a logged-in user, When they enter an ingredient in the search bar, Then they see recipes containing that ingredient" knows exactly what to build and how to test it.

In real teams, the Product Owner writes these criteria with input from the developers. Vague criteria like "search should work well" lead to endless debates about what "done" means.

Can't find the Description field?

Click on the story title in the backlog to open the full issue view. The Description field appears below the summary at the top. If you see a pencil icon or "Add a description" placeholder text, click it to start editing.

Help me find where to add a description in Jira

Prioritize your backlog by dragging stories into order

A prioritized backlog tells the team what to build first. The most valuable stories go to the top because they deliver the features users need before anything else can work.

Go back to the Backlog view by clicking Backlog in the left sidebar.
Drag the "log in" story to the very top of the backlog. Users need to log in before they can do anything else.
Drag the "view all recipes" story to second position. Browsing recipes is the core experience.
Drag the "search recipes by ingredient" story to third position. Search builds on browsing.
Drag the "view a recipe detail page" story to fourth position.
Drag the "save a recipe to my favorites" story to fifth position.
Drag the "create a profile" story to sixth position.
Leave the "rate a recipe" story in seventh and "share a recipe link" in eighth position. These are nice-to-have social features that depend on the core app working first.

How do you decide priority?

Think about what a minimum viable product (MVP) needs. Users must be able to log in, see recipes, and search before they can save favorites, rate things, or share links. Each feature builds on the ones above it.

In real teams, the Product Owner owns this ordering. They balance business value, user need, and technical dependencies to decide what the team works on first.

Your backlog should now show all 8 stories in priority order, with login at the top and sharing at the bottom.

Stories not staying in order?

Make sure you are dragging stories within the Backlog section (not into a sprint). You can also right-click a story and select Move to top or Move to bottom for quicker repositioning.

Help me reorder my backlog in Jira

Your backlog is full of well-written, prioritized stories ready for estimation. Next up, you'll assign story points to each one so you know how much work fits in a sprint.

Estimate Stories with Story Points

Your backlog is full of well-written user stories with clear acceptance criteria. But before you can plan a sprint, you need to answer one crucial question: how much work can your team actually handle in a week?

This is where story points come in. Story points measure relative effort, not hours. A story that is twice as complex as another gets roughly twice the points. In this step, you will estimate all your stories and define what "Done" actually means.

In this step, get ready to:

Add story point estimates to all 8 user stories using the Fibonacci sequence.
Review your estimates for relative consistency across stories.
Document a Definition of Done for your project.

Add story point estimates to each user story

Story points use the Fibonacci sequence (1, 2, 3, 5, 8, 13) instead of linear numbers. The gaps between numbers force you to make a decision rather than splitting hairs between a 6 and a 7.

What do the numbers mean?

A 1 is trivially simple (like changing button text). A 5 involves multiple components and some unknowns. A 13 is so complex it should probably be broken into smaller stories.

These numbers measure relative complexity, not hours. A 5-point story is not five hours of work. It is roughly 2.5 times more complex than a 2-point story.

In the Backlog view, click on your first story (the login story) to open it.
Look for the Story Points field on the right-hand detail panel. If you do not see it, click Story point estimate or look for an estimate field in the issue details.
Enter 3 as the story point estimate for the login story. Login involves authentication logic, session management, and error handling.
Close the story and repeat for each remaining story, using these estimates:

View all recipes: 2 points (straightforward list display).
Search recipes by ingredient: 5 points (search logic, filtering, edge cases).
View recipe detail page: 3 points (layout, data fetching, formatting).
Save recipe to favorites: 3 points (user-specific data, toggle state).
Create a profile: 5 points (form validation, preferences, storage).
Rate a recipe: 2 points (simple input, save to database).
Share a recipe link: 1 point (copy URL to clipboard, minimal logic).

Don't see the Story Points field?

In some Jira layouts, the field may be labeled Story point estimate instead of Story Points. If you still cannot find it, click the three-dot menu on the issue and select Configure to check which fields are visible.

help me find the Story Points field in my Jira issue

Review your estimates for consistency

Estimation is about relative sizing. If two stories feel equally complex, they should have the same points. Take a moment to compare your estimates side by side.

Scan through your backlog and compare stories at the same point level. Your two 5-point stories (search by ingredient and create profile) should feel similarly complex. Your two 2-point stories (view all recipes and rate a recipe) should feel similarly straightforward.
Ask yourself: does "share a recipe link" at 1 point feel significantly simpler than "view all recipes" at 2 points? If yes, your scale is consistent.
Adjust any estimates that feel off. Click the story, update the points, and move on. There is no perfect answer here. Consistency across stories matters more than any single number.

Why relative sizing instead of hours?

Humans are bad at estimating absolute time but good at comparing. You might not know if a story takes 4 hours or 6 hours. But you can confidently say "this one is about twice as hard as that one."

Over multiple sprints, your velocity (total points completed per sprint) becomes a reliable predictor of how much work your team can handle. This is what interviewers want to hear you explain.

Create a Definition of Done for your project

A Definition of Done is a shared checklist that every story must satisfy before it counts as complete. Without one, "done" means something different to every team member.

In your RecipeBox project, click Create at the top of the backlog to create a new issue.
Set the issue summary to Definition of Done.
Open the issue and add the following text in the Description field:

Code written, tests passing, code reviewed, deployed to staging, acceptance criteria met.

Save the issue. This is now your team's quality gate. Every story that moves to "Done" must pass all five criteria.

Why document the Definition of Done?

In real teams, the Definition of Done prevents half-finished work from being called "complete." It protects quality and sets expectations for every sprint.

When an interviewer asks "how does your team define done?", you want a clear, specific answer. The five criteria above cover the full delivery lifecycle from writing code to verifying it works in a real environment.

Keep it visible

Some teams pin their Definition of Done to the board description or project summary page. Wherever you put it, make sure everyone on the team can find it without asking.

Your backlog is now estimated and your quality bar is set. Next up, you will pull the highest-priority stories into a sprint and kick off your first week of simulated development.

Plan and Start Your Sprint

You have a prioritized backlog with consistent estimates. Now comes the moment that kicks off real work: sprint planning.

Sprint planning answers one question: what can we realistically deliver in the next time box? You will select a subset of your backlog, commit to a goal, and start the clock.

In this step, get ready to:

Create a sprint and fill it with your highest-priority stories.
Write a sprint goal that connects your work to user value.
Start the sprint and see your board columns come to life.

Create a sprint and add stories to it

A sprint is a fixed time box (usually 1-2 weeks) where you commit to delivering a set of stories. The stories you pull in become your sprint backlog.

In the left sidebar of your RecipeBox project, click Backlog to open the Backlog view.
Click Create sprint at the top of your backlog.

A new empty sprint section appears above your backlog stories.

Drag your top 4 stories into the sprint section. These are the stories at the top of your prioritized backlog:

Log in (3 points).
View all recipes (2 points).
Search recipes by ingredient (5 points).
View recipe detail page (3 points).

Your sprint now contains 13 story points. This is your team's commitment for the sprint.

Why these 4 stories?

These stories form the core browsing experience for RecipeBox. A user needs to log in, see recipes, search them, and view details. Together they deliver a coherent slice of functionality rather than scattered, disconnected features.

Keeping the total around 10-15 points makes the sprint achievable without overcommitting. You can always pull in more work mid-sprint if you finish early.

Can't drag stories into the sprint?

Make sure you are in the Backlog view (not the Board view). The drag-and-drop only works from the backlog list into the sprint section above it.

If dragging feels unresponsive, try clicking the three-dot menu on the story and selecting Move to sprint instead.

Help me move stories into my sprint in Jira

Write a sprint goal

A sprint goal is one sentence that explains why you are building these stories this sprint. It keeps the team focused on the outcome, not just checking off tickets.

Click the pencil/edit icon next to your sprint name at the top of the sprint section.
In the Sprint goal field (or the sprint description area), type:

Users can browse and search the recipe catalog.

What makes a good sprint goal?

A good sprint goal describes a user outcome, not a list of tasks. It answers: "If we finish this sprint, what can users do that they couldn't before?"

In interviews, being able to articulate sprint goals shows you think about delivering value, not just completing tickets.

Start the sprint

Starting the sprint locks in your commitment and activates the sprint board. From this point, the clock is ticking.

Click the Start sprint button in the top-right corner of your sprint section.

A dialog appears asking you to configure the sprint duration.

Set the Duration to 1 week.
Confirm that the Sprint name and start/end dates look correct.
Click Start.

Jira automatically switches you to the Board view. You should see three columns: To Do, In Progress, and Done. All 4 of your sprint stories appear as cards in the To Do column.

What do these columns mean?

The three columns represent workflow stages. To Do means work not yet started. In Progress means someone is actively working on it. Done means the story meets your Definition of Done.

Moving cards across these columns is how you signal progress to your team every day.

Don't see the board columns?

If you are still looking at the Backlog view after starting the sprint, click Board in the left sidebar to switch views.

If the board shows no stories, make sure you actually clicked Start in the dialog (not just closed it). Go back to the Backlog view and check whether the sprint still shows a Start sprint button.

Help me troubleshoot my Jira sprint board

Your sprint is live. Next up, you will simulate actual development by moving stories across the board and completing them.

Execute the Sprint and Move Work Across the Board

Your sprint is live and the clock is ticking. You have a board with four stories sitting in To Do, a clear sprint goal, and a one-week timebox.

Now you will simulate what a developer actually does during a sprint: pick up work, signal progress on the board, verify acceptance criteria, and close stories. You will also experience what happens when a sprint ends with unfinished work.

In this step, get ready to:

Move stories across the board from To Do through In Progress to Done.
Add comments verifying acceptance criteria on completed stories.
Complete the sprint and handle incomplete work.

Pick up your first story

On a real Scrum team, developers pull work from the top of the sprint backlog each day. Moving a card to In Progress signals to your teammates that you are actively working on it.

Open the Board view from the left sidebar of your RecipeBox project.
Find the "Log in" story in the To Do column.
Drag it to the In Progress column.
Click on the story card to open it.
Scroll down to the Activity section and click Add a comment.
Type a progress update such as: "Building the login form component and connecting to authentication service."
Click Save to post your comment.

Why add comments to tickets?

Comments create a written trail of decisions, blockers, and progress. On a real team, your Scrum Master and teammates check the board daily. Comments help everyone stay aligned without needing a meeting for every update.

Your board should now show one card in In Progress and three remaining in To Do.

Can't drag the card?

Make sure you are in the Board view, not the Backlog view. You can also click on the story, then change the Status dropdown at the top of the issue detail to move it between columns.

Help me move my Jira story between columns

Complete stories and verify acceptance criteria

Now simulate 2-3 days of development. You will move stories to Done one at a time, adding a comment each time that confirms the acceptance criteria have been met.

Drag the "Log in" story from In Progress to Done.
Click on the story and add a comment verifying the acceptance criteria. For example: "Verified: user can log in with email and password, sees error message on invalid credentials, and is redirected to homepage on success."
Click Save.

Repeat this process for the next two stories.

Move "View all recipes" from To Do to In Progress, then to Done.
Add a comment: "Verified: recipes display in a grid, each showing title and thumbnail, and pagination works for more than 10 results."
Move "Search recipes by ingredient" from To Do to In Progress, then to Done.
Add a comment: "Verified: search returns matching recipes when ingredient is entered, shows 'no results' for unknown ingredients, and handles multiple ingredient searches."

Leave the "View recipe detail page" story in To Do or move it to In Progress. Do not move it to Done.

Why leave one story incomplete?

Sprints rarely finish perfectly clean. Leaving one story incomplete simulates real life where unexpected complexity, blockers, or shifting priorities prevent 100% completion. How a team handles unfinished work is a key part of the Scrum process.

Your board should now show 3 stories in Done and 1 story still in To Do or In Progress.

Complete the sprint

The sprint timebox is up. In real life, a sprint review happens at this point where the team demonstrates completed work to stakeholders. Now you will end the sprint in Jira and see how it handles unfinished stories.

Click Complete sprint in the top-right corner of the board view.

Jira displays a dialog showing how many stories were completed and how many are still open. It asks where you want to move the incomplete stories.

Select Backlog as the destination for incomplete issues.
Click Complete to finalize.

What happens to incomplete stories?

Moving unfinished work back to the backlog mirrors real Scrum. The Product Owner re-prioritizes it against new work in the next sprint planning session. It does not automatically carry over because priorities may have changed.

Open the Backlog view from the left sidebar.
Confirm that the "View recipe detail page" story is back in the backlog alongside your other unstarted stories.

You have now completed an entire sprint cycle. Your velocity for this sprint is 10 story points (3 + 2 + 5 from the three completed stories).

Don't see the Complete sprint button?

The Complete sprint button only appears in the Board view, not the Backlog view. Switch to the Board using the left sidebar. If you still do not see it, make sure you are the project admin (you should be if you created the project).

Help me find the Complete sprint button in Jira

Your first sprint is in the books. Next up, you will review your sprint report, examine the burndown chart, and hold a retrospective to reflect on what you would improve.

Review Your Sprint Results and Hold a Retrospective

You just completed your first sprint. Three stories shipped, one bounced back to the backlog. That is a realistic outcome on any Scrum team.

Now it is time to look at the data. Every sprint ends with two things: a sprint review (examining what was delivered and the metrics) and a sprint retrospective (reflecting on how the team worked). These habits are what separate a developer who "does Agile" from one who just moves tickets around.

In this step, get ready to:

Examine your Sprint Report with burndown chart and velocity metric.
Document a sprint retrospective answering three reflection questions.
Review your backlog and re-prioritize the incomplete story for the next sprint.

Open the Sprint Report and examine your metrics

The Sprint Report shows two key metrics: your burndown chart (how quickly work was completed over time) and your velocity (total story points delivered). These numbers help you plan better sprints in the future.

In the left sidebar of your RecipeBox project, find and click Reports.
Select Sprint Report (also called Burndown Report in some views).
Look at your burndown chart. This line graph shows how much work remained each day of the sprint. The ideal line slopes downward evenly. Your line likely dropped in chunks as you moved stories to Done.
Check the velocity summary at the top. You committed 13 story points and delivered 10. That gap of 3 points (the incomplete story) is valuable data for planning your next sprint.

What is velocity?

Velocity is the total number of story points your team completes in a sprint. Over multiple sprints, velocity stabilizes into a predictable number that helps you forecast how much work fits in future sprints.

Your velocity this sprint is 10 points. If it stays consistent, you know not to commit more than 10-12 points next time. This is one of the most common metrics interviewers ask about.

What is a burndown chart?

A burndown chart plots work remaining (in story points) on the Y-axis against time (sprint days) on the X-axis. The ideal guideline is a straight diagonal line from your total committed points down to zero.

If your actual line is above the guideline, work is being completed slower than expected. If it flatlines and then drops sharply, it means stories were finished in batches rather than steadily.

Jira navigation may vary

Jira has been rolling out updated navigation in 2025-2026. If you do not see Reports in the left sidebar, look for it under a More menu or try clicking the project name to expand the full navigation.

Document a sprint retrospective

A sprint retrospective is a ceremony where the team reflects on how they worked together. Even as a solo developer, building this habit shows interviewers you understand continuous improvement.

Go back to your Backlog view by clicking Backlog in the left sidebar.
Click Create issue (or press C on your keyboard) to create a new issue.
Title the issue Sprint 1 Retrospective.
Open the issue and add the following three sections in the Description field:

Answer these three retrospective questions in the Description field:

What went well? Example: "Completed core search and login features. Acceptance criteria helped clarify what Done means."
What could be improved? Example: "Better story sizing to avoid incomplete work. The 3-point story was harder than expected."
What will we change next sprint? Example: "Commit to fewer points (closer to 10) to ensure full completion. Break complex stories into smaller tasks."

Click Save on the description to confirm your retrospective is saved.

Why do retrospectives matter in interviews?

Interviewers frequently ask "Tell me about a time you improved a process" or "How does your team handle things that go wrong?" Your retrospective answers give you concrete examples to reference.

The key is showing you identified a specific problem (over-committing points), proposed a concrete change (commit fewer points), and would measure whether it helped (compare velocity next sprint).

Review your backlog and re-prioritize

After every sprint, the backlog gets a fresh look. Stories that did not finish come back, new priorities emerge, and the team decides what matters most for the next cycle.

Click Backlog in the left sidebar.
Find your incomplete story ("View recipe detail page") in the backlog. It should already be there from when you completed the sprint.
Drag it to the top of the backlog. Since this story was already in progress, it makes sense to finish it first in the next sprint.
Look at the rest of your backlog below it. You should see your remaining stories (save to favorites, create a profile, rate a recipe, share a recipe link) ready for future sprint planning.

Why is this iterative?

This is the core loop of Scrum: plan a sprint, execute it, review results, reflect on how to improve, then start the next sprint with better information. Each cycle makes the team more predictable and effective.

Your velocity of 10 points, your retrospective insights, and your re-prioritized backlog all feed into the next sprint planning session. Nothing is wasted.

You should now see your backlog with the "View recipe detail page" story at the top, followed by the remaining unstarted stories below it.

Can't find your incomplete story in the backlog?

When you completed the sprint in Step 5, Jira asked what to do with incomplete stories. If you chose a different option, the story may be in a different location. Check the Board view to see if it is still showing there, or use the search bar at the top to search for the story title.

Help me find my incomplete story after completing a sprint.

Secret mission

Add Epics and a Sprint Goal Strategy

You've completed one sprint. But real Scrum teams organize their work into larger themes called Epics. In this secret mission, you'll create Epics, link your stories to them, run a second sprint, and compare your velocity across both sprints.

Clean Up Your Resources

Decide whether to keep your Jira project running, leave it idle, or delete it entirely. This project uses the Jira free tier, so there are no ongoing costs regardless of which option you choose.

Inactivity policy

Atlassian reserves the right to deactivate free sites due to prolonged inactivity. If you plan to reference your sprint history in future interviews, log in occasionally to keep your site active.

Resources you used:

Jira Cloud account (your-name.atlassian.net).
RecipeBox Scrum project.
8-10 user stories with acceptance criteria and story point estimates.
Completed sprint with sprint report and burndown chart.
Definition of Done documentation.
Sprint retrospective notes.

Keep everything running

No action needed. Choose this if you want to keep your Jira project as a reference for interviews or future learning.

Your Jira site stays active at your-name.atlassian.net.
Your sprint history, reports, and backlog remain accessible.
Log in occasionally to prevent inactivity deactivation.

Pause - I'll come back to this later

Since this is a free cloud tool, there is nothing to shut down or pause. Your project stays available whenever you return.

Bookmark your Jira site URL so you can find it again easily.
Log in once every few months to keep the free site active.

Delete - I don't want to use this again

Remove your Jira project and optionally delete your entire Atlassian site.

To delete just the project: open your RecipeBox project, click the gear icon for project settings, scroll to the bottom, and select the option to delete the project.
To delete your entire Atlassian site: go to admin.atlassian.com, select your site, navigate to site settings, and choose to permanently delete the site.
Site deletion is permanent and cannot be undone.

That's a Wrap!

Nice work! You just ran a complete Agile sprint cycle in Jira, from an empty backlog all the way to a delivered increment with real metrics.

Here's what you learned:

Built a product backlog of user stories in standard format, estimated them with story points, and prioritized them for a minimum viable product.
Planned and executed a sprint with a clear goal, moved work across the board from To Do through In Progress to Done, and completed the sprint with realistic outcomes.
Reviewed your burndown chart and velocity metric, then held a sprint retrospective to identify improvements for the next iteration.
Organized stories into Epics, ran a second sprint, and compared velocity across sprints to measure team performance over time.

You can now confidently discuss Agile practices in interviews and know what your first day on a Scrum team will look like.

Ready to quiz yourself?