Run Your First Sprint in Jira

Plan and run a full Scrum sprint in Jira, from backlog to retrospective.

Introduction

30 Second Summary

Every team has a to-do list. But when that list grows across multiple people, deadlines, and competing priorities, you need a system to keep everyone aligned and shipping work on time.

In this project, you will run a complete sprint in Jira, the industry-standard tool for Agile project management. You will create user stories, plan a sprint, track daily progress, and hold a retrospective.

What You'll Build

You will build a fully functional Scrum project in Jira that simulates managing a mobile app development team through a complete sprint cycle.

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

A product backlog with prioritized user stories, acceptance criteria, and story point estimates.
A completed sprint demonstrating the full Scrum workflow from planning through execution to retrospective.
Sprint reports including a burndown chart and velocity metrics that prove you can run a sprint end-to-end.
Secret Mission: Build an automation rule that auto-transitions parent issues when all sub-tasks are completed.

Are there any prerequisites?

You need a free Jira Cloud account to complete this project. The Free plan supports up to 10 users and includes everything you need: Scrum boards, backlog management, agile reporting, and automation.

Create Your Scrum Project

Every Scrum team needs a home base where they can track work, plan sprints, and measure progress.

In this step, you will create a team-managed Scrum project in Jira, explore its default board structure, and set up the scenario you will manage throughout this project.

In this step, get ready to:

Create a team-managed Scrum project called TaskFlow App.
Explore the Scrum board and backlog views.
Understand the team scenario you will manage.

Create a team-managed Scrum project

A team-managed project gives you full control over your board, workflow, and settings without needing a Jira administrator.

In the left sidebar of your Jira Cloud dashboard, find Spaces.
Next to Spaces, select Create space.
In Choose space type, select team-managed.
Under template, select Change template and choose Scrum.
Enter TaskFlow App as the space name.
Click Create space.

You will land on an empty backlog view.

What is a team-managed project?

Jira offers two project types: team-managed and company-managed.

Team-managed projects are self-contained. Any user can create one without admin privileges, and changes to the board or workflow only affect that project. This makes them ideal for learning and small teams.

Don't see Create space?

If Spaces is not visible in the sidebar, you may need to customize your navigation bar and add it. Jira recently renamed "Projects" to "Spaces," so look for the new label.

If you see Spaces but no plus icon or Create space option, your Jira admin may have disabled team-managed project creation. On the Free plan where you are the admin, this should not be an issue.

help me find the Create space option in Jira

Explore the Scrum board structure

Your new project comes with a board and a backlog. The board is where your team tracks active work during a sprint. The backlog is where you collect and prioritize all upcoming work.

In the left sidebar, click Board.
Notice the three default columns: To Do, In Progress, and Done.
Click Backlog in the left sidebar to return to the backlog view.

Why can't I create work items on the board?

With the Sprints feature enabled on team-managed Scrum templates, you can only create work items in the backlog. You then add them to a sprint before they appear on the board. This enforces the Scrum workflow of planning before executing.

Understand the project scenario

For this project, you will role-play as the Project Manager for a 4-person team building "TaskFlow," a mobile productivity app.

Your team includes: 1 Product Owner (you, wearing both hats), 2 Developers, and 1 Designer.
Your goal is to plan and run your team's first sprint to deliver the core login and onboarding features.

Why am I playing the Product Owner too?

In real Scrum teams, the Product Owner decides what to build and the Scrum Master facilitates how. Wearing both hats lets you experience the full decision-making process of prioritizing work, estimating effort, and managing a sprint end-to-end.

Your Scrum project is ready to go. Next up, you will fill your backlog with user stories that represent the features your team needs to build.

Build Your Product Backlog

Your Scrum project is set up and ready for work. The next step is to fill it with a product backlog of clearly defined tasks your team will tackle.

A product backlog is a prioritized list of everything the team needs to build. Each item is written as a user story that describes what a user wants and why. In this step, you will create 6 user stories for your TaskFlow app, estimate their effort using story points, and prioritize them so your team knows what to work on first.

In this step, get ready to:

Create 6 user stories with acceptance criteria.
Add story point estimates to each story.
Prioritize the backlog by drag-and-drop ordering.

Create user stories with acceptance criteria

User stories follow a specific format that captures who the user is, what they want, and why it matters. The official format is:

"As a {type of user}, I want {goal} so that I {receive benefit}"

You will create 6 user stories for the TaskFlow app, then add detailed acceptance criteria to each one. Acceptance criteria define exactly what "done" looks like for each story.

In the Backlog view, scroll to the bottom and click + Create work item.
Type the following title and press Enter: As a new user, I want to create an account so that I can save my tasks.
Repeat the same process (click + Create work item, type the title, press Enter) for each of the remaining 5 stories:

As a returning user, I want to log in so that I can access my saved tasks
As a new user, I want a guided onboarding tour so that I understand the app features
As a user, I want to create a task so that I can track my to-dos
As a user, I want to mark tasks as complete so that I can track progress
As a user, I want to organize tasks into categories so that I can find them easily

You should now see 6 work items listed in your backlog.

Now add acceptance criteria to each story by clicking into it and writing the description.

Click the first story title ("As a new user, I want to create an account...") to open it.
In the description field, type the acceptance criteria listed below.
Click the X or press Esc to close the work item and return to the backlog.
Repeat for each of the remaining 5 stories.

Here are the acceptance criteria to add for each story:

Account creation:

Email/password registration works.
Confirmation email sent.
User redirected to dashboard.

Email/password login works.
Error shown for wrong credentials.
Session persists for 7 days.

Onboarding tour:

3-step tour highlights key features.
Can be skipped.
Completion tracked.

Create task:

Title and description fields.
Due date picker.
Task appears in list immediately.

Mark complete:

One-tap completion.
Visual strikethrough.
Completed count updates.

Organize into categories:

Create/edit/delete categories.
Assign task to category.
Filter by category.

What are user stories and acceptance criteria?

A user story captures a feature from the user's perspective. It forces you to think about who benefits and why, not just what to build.

Acceptance criteria define the specific conditions that must be true for the story to be considered complete. They remove ambiguity so developers and testers know exactly what "done" means.

Don't see the Story point estimate field?

The Estimation feature needs to be enabled for your space. Click More actions (three dots) next to your space name in the sidebar, then Space settings. Select Features and ensure Estimation is toggled on with Story points selected.

Help me enable estimation in my Jira team-managed project.

Add story point estimates

Story points measure relative effort, not hours. Teams use a Fibonacci-like scale to estimate because it forces you to think in buckets of complexity rather than precise time.

Click into the first story (Account creation) to open it.
Find the Story point estimate field on the work item detail view.
Enter 5 and press Enter.
Close the work item and repeat for each remaining story with the following estimates:

Account creation: 5 points (moderate complexity, involves email service).
Login: 3 points (straightforward, reuses account infrastructure).
Onboarding tour: 3 points (UI-focused, no backend).
Create task: 5 points (core feature, needs database design).
Mark complete: 2 points (simple state change).
Organize into categories: 8 points (complex, multiple CRUD operations).

Your total backlog should now be 26 story points (5 + 3 + 3 + 5 + 2 + 8).

What are story points?

Story points measure the relative effort of a task compared to other tasks. A 5-point story is roughly twice as complex as a 3-point story, but not necessarily twice the hours.

Teams use Fibonacci-like sizing (0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100) because the gaps between numbers grow as uncertainty grows. The bigger the task, the harder it is to estimate precisely.

Prioritize the backlog

A backlog is only useful if items are ranked. The highest-priority stories sit at the top so the team always knows what to work on next.

Return to the Backlog view if you are not already there.
Drag and drop the stories into the following priority order (highest at top):

As a new user, I want to create an account so that I can save my tasks (must have first, everything depends on it).
As a returning user, I want to log in so that I can access my saved tasks (required for returning users).
As a user, I want to create a task so that I can track my to-dos (core value proposition).
As a user, I want to mark tasks as complete so that I can track progress (complements create task).
As a new user, I want a guided onboarding tour so that I understand the app features (enhances experience but not blocking).
As a user, I want to organize tasks into categories so that I can find them easily (nice-to-have, highest effort).

Why this priority order?

Account creation comes first because every other feature depends on it. Login naturally follows because it reuses the same user infrastructure. The task creation and completion features deliver the app's core value. Onboarding and categories are important but do not block the others from working.

In real Scrum teams, the Product Owner owns this priority order and revises it every sprint based on stakeholder feedback and market changes.

Your backlog should now show all 6 stories ranked from top to bottom with story point estimates visible next to each title.

Your product backlog is now ready for sprint planning. Next up, you will select stories from this backlog, set a sprint goal, and kick off your first sprint.

Plan and Start Your Sprint

Your product backlog is loaded with 6 prioritized user stories and 26 story points of work. Now it's time to decide what your team will actually deliver in the next week.

In sprint planning, you select the highest-priority stories your team can realistically finish, commit to a sprint goal, and break work into daily-sized tasks. This is where the backlog transforms from a wish list into a concrete plan.

In this step, get ready to:

Create a sprint and commit the top 4 user stories to it.
Break stories into sub-tasks so your team knows exactly what to build each day.
Document sprint planning decisions including capacity and risks.

Create and plan the sprint

A sprint is a fixed time period where your team commits to finishing a set of stories. You will pull the top 4 stories from your backlog into a 1-week sprint.

In the Backlog view, click Create sprint at the top of the page.
Drag the top 4 user stories into the sprint section: Account creation (5 pts), Login (3 pts), Create task (5 pts), and Mark complete (2 pts).
This gives you 15 story points committed to the sprint.
Click Start sprint.

A dialog will appear asking you to configure the sprint details.

Set the sprint name to Sprint 1 - Core Task Management.
Set the duration to 1 week.
Set the sprint goal to: Deliver working account creation, login, task creation, and task completion features.
Click Start.

What is a sprint goal?

A sprint goal is a one-sentence statement that describes the outcome your team is aiming for. It keeps everyone focused on a shared objective, even if individual stories change mid-sprint.

Your goal of delivering core account and task features means that any story contributing to that outcome is on track. Stories unrelated to the goal stay in the backlog for a future sprint.

Why 15 story points and not all 26?

A common mistake for new teams is overcommitting in their first sprint. Since you have no historical velocity data yet, 15 points is a conservative target for a 4-person team.

After this sprint, you will have a real velocity number to base future planning on.

Jira takes you to the Board view, where your 4 committed stories appear in the To Do column.

Don't see your stories on the board?

Make sure you dragged stories into the sprint section before clicking Start sprint. If the sprint started empty, you can add stories from the backlog while the sprint is active.

Click Backlog in the left sidebar, then drag stories from the backlog into the active sprint at the top.

Help me troubleshoot this

Break stories into sub-tasks

User stories describe what the user wants, but your developers need smaller, actionable work items. Sub-tasks break a story into the individual pieces of work that different team members will pick up each day.

From the Board view, click into the Account creation story to open its detail panel.
Click + Add a child issue to create the first sub-task.
Type Design registration form UI and press Enter.
Add the second sub-task: Build registration API endpoint.
Add the third sub-task: Set up email confirmation service.

Assigning sub-tasks to team members

In a real sprint, you would assign each sub-task to a team member. For this project, think of the assignments as: Designer handles UI tasks, Developer 1 handles API tasks, and Developer 2 handles service integrations.

Now repeat the same process for the Login story.

Click the back arrow or navigate to the Board view and click into the Login story.
Add a child issue: Design login screen UI.
Add a child issue: Build authentication API.
Add a child issue: Implement session management.

Why only sub-tasks for Account creation and Login?

Stories with 5 or more story points usually need sub-tasks because they involve multiple people or multiple technical components. The Create task (5 pts) and Mark complete (2 pts) stories are small enough that one developer can handle each without further breakdown.

In practice, you might still add sub-tasks to the 5-point Create task story. For this project, you will keep it as a single work item to see both patterns.

Your board should now show the 4 stories in the To Do column, with the Account creation and Login stories displaying their child sub-tasks.

Sub-tasks not showing on the board?

Check that you created sub-tasks inside the correct parent story. Click into the parent story and look for the child issues listed below the description.

If you accidentally created a standalone story instead of a sub-task, delete it and use + Add a child issue from within the parent story's detail panel.

Help me fix my sub-tasks

Document your sprint planning decisions

Real sprint planning meetings end with documented decisions about capacity, commitment, and risk. Recording these helps you evaluate sprint performance later during the retrospective.

Click into the sprint goal area or add a comment on any sprint story to document the following planning notes.
Sprint capacity: 4 team members x 5 working days = 20 person-days available.
Committed velocity: 15 story points (conservative for first sprint).
Key risk: Email service integration may take longer than estimated.

What is sprint capacity?

Capacity is how much total time your team has available during the sprint. You calculate it by multiplying team members by working days, then subtracting any holidays or known absences.

Comparing your committed story points against available capacity helps you spot overcommitment before the sprint starts.

Your sprint is live and your team knows exactly what to build. Next up, you will simulate daily progress across the sprint and watch the burndown chart track your team's momentum.

Execute the Sprint and Track Progress

Your sprint is live and the board is loaded with 15 story points of committed work. Now comes the part that defines your role as a Project Manager: tracking daily progress and catching problems early.

In a real sprint, team members update the board each day as they complete tasks. You will simulate five days of progress by dragging work items across the board columns. Then you will use Jira's built-in reporting tools to assess whether the sprint is on track.

In this step, get ready to:

Simulate five days of team progress on the Scrum board.
Track sprint health with the burndown chart.
Review the sprint report to confirm delivery.

Simulate daily progress (Days 1-3)

You are going to play the role of a team updating its board during the daily standup. Each day, team members finish tasks and pick up new ones. You will simulate this by dragging sub-tasks and stories between the To Do, In Progress, and Done columns.

Start with Day 1. Your Designer begins work on UI mockups for both the registration and login screens.

On the Board view, find the "Account creation" story and expand its sub-tasks.
Drag Design registration form UI to the In Progress column.
Find the "Login" story and expand its sub-tasks.
Drag Design login screen UI to the In Progress column.

On Day 2, the Designer finishes both mockups and your two Developers start building backend endpoints.

Drag Design registration form UI to Done.
Drag Design login screen UI to Done.
Drag Build registration API endpoint to In Progress.
Drag Build authentication API to In Progress.

On Day 3, the authentication API wraps up and the Login story is fully delivered.

Drag Build authentication API to Done.
Drag Implement session management to In Progress, then immediately to Done. (This small task is completed within the same day.)
Drag the Login parent story to Done. All three of its sub-tasks are now complete.

What is a daily standup?

A daily standup is a 15-minute meeting where each team member answers three questions: What did I complete yesterday? What will I work on today? Am I blocked by anything?

The board updates you just made mirror what a real team does after each standup. The Scrum Master watches the board for bottlenecks and helps remove blockers.

Simulate daily progress (Days 4-5)

The remaining work wraps up quickly. Day 4 sees the registration backend finishing while the team picks up the core task features.

Drag Build registration API endpoint to Done.
Drag Set up email confirmation service to In Progress.
Drag the Create task story (no sub-tasks) to In Progress.

On Day 5, the final stories are delivered and the sprint is complete.

Drag Set up email confirmation service to Done.
Drag the Account creation parent story to Done. All three of its sub-tasks are now complete.
Drag the Create task story to Done.
Drag the Mark complete story to In Progress, then immediately to Done. This small 2-point story is completed within the same day.

Your board should now show all four stories in the Done column. No work remains in To Do or In Progress.

Stories not showing in Done?

If a parent story is still sitting in To Do or In Progress after you moved all its sub-tasks to Done, you need to drag the parent story itself to the Done column. Jira does not automatically transition the parent when sub-tasks are completed (unless you set up automation, which you will do in the Secret Mission).

If you accidentally skipped a sub-task, click into the parent story and check which sub-task is still open. Help me figure out why my story isn't in Done.

View the burndown chart

With all work in Done, it is time to check Jira's reporting tools. A burndown chart shows how much work remains in the sprint over time. A healthy sprint shows remaining work steadily decreasing toward zero.

In the left sidebar, click Reports.
Select Burndown chart from the reports dropdown.
Observe how the chart shows remaining work decreasing over the sprint duration.

Why does my burndown look different from textbook examples?

Since you moved all the work items in a single session, your burndown chart will show progress concentrated into one point rather than spread across multiple days. In a real sprint, the line would slope gradually downward over the full week.

The key thing is that remaining work reaches zero. That means your team delivered everything committed.

While still in Reports, select Sprint Report from the dropdown.
Review the report summary showing completed vs. incomplete work.

Your sprint report should show all 4 committed stories (15 story points) as completed with 0 incomplete.

What is the sprint report?

The sprint report is a summary Jira generates at the end of each sprint. It breaks down which stories were completed, which were incomplete, and which were added mid-sprint.

Project Managers use this report in sprint reviews to show stakeholders exactly what was delivered. It is also the basis for calculating your team's velocity over time.

Reports not showing data?

Make sure your sprint is still active (you have not clicked "Complete sprint" yet). The burndown chart and sprint report are only available for active or completed sprints.

If you see a blank chart, confirm that at least one story has been moved to Done. Help me find my sprint reports in Jira.

All 15 story points have been delivered. Next up, you will officially close the sprint and run a retrospective to reflect on what went well and what to improve.

Complete the Sprint and Hold Retrospective

Your sprint board is clear. Every story you committed to has been delivered, and your reports confirm it. Now it is time to formally close the sprint and reflect on how the team performed.

In real Scrum teams, the sprint does not just end when the work is done. Two ceremonies close it out: the sprint review (demonstrating what was delivered) and the sprint retrospective (reflecting on the process). You will complete both in this step.

In this step, get ready to:

Complete the active sprint in Jira and review the completion summary.
Document a sprint retrospective with what went well, what could improve, and action items.
Review velocity metrics and plan ahead for Sprint 2.

Complete the sprint

Completing a sprint formally closes it in Jira, locking in the delivered work and generating your first velocity data point.

In the left sidebar, click Board to switch to the Board view.
Click Complete sprint in the top-right area of the board.
If prompted about incomplete issues, you can choose to move them to the backlog. In this case, all 4 stories should already be in Done, so no action is needed.
Review the sprint completion summary showing what was delivered.

What happens when you complete a sprint?

Jira moves all completed work items out of the active sprint view. Any incomplete items would be sent back to the backlog or moved to a future sprint.

Once completed, the sprint becomes a historical record. Its data feeds into reports like the Velocity Chart, helping you forecast future sprints.

You should see a completion summary confirming that all 4 stories (15 story points) were delivered in Sprint 1.

Don't see the Complete sprint button?

Make sure you are on the Board view, not the Backlog view. The button appears in the top-right area when a sprint is active.

Also confirm that all stories are in the Done column (the rightmost column on your board). If any story is still in To Do or In Progress, drag it to Done first.

help me find the Complete sprint button in my team-managed Jira project

Document the sprint retrospective

A sprint retrospective is a meeting where the team reflects on what went well, what could improve, and what concrete actions to take into the next sprint.

In the left sidebar, click Backlog to return to the backlog view.
Click the + Create work item button to create a new work item.
Title it: Sprint 1 Retrospective.
Click into the work item to open it, then add the following in the description field:

Under What went well, write:

Team completed all 15 story points committed. Login feature delivered ahead of schedule.

Under What could improve, write:

Email service integration was underestimated. Consider adding a spike story next sprint for unknowns.

Under Action items for next sprint, write:

Break complex stories (5+ points) into sub-tasks before sprint starts. Add a Code Review column to the board.

Why document a retrospective?

This is the format real teams use in sprint retrospectives. The three questions come from the official Scrum framework: What did we do well? What could we have done better? What are we going to do better next time?

Documenting these in Jira creates a searchable history. When your next sprint starts, you can reference these action items to make sure the team actually follows through.

Review velocity and plan ahead

Velocity measures how many story points your team completes per sprint. After your first completed sprint, Jira records your first data point.

In the left sidebar, click Reports.
Select Velocity Chart from the report options.
Observe your first data point showing 15 story points completed in Sprint 1.

What is velocity?

Velocity is the average number of story points completed per sprint. After a few sprints, this metric helps you forecast how much work to commit to in future sprints. The more sprints you complete, the more accurate the forecast becomes.

Right now you only have one data point (15 points), so the average equals 15. After Sprint 2 and Sprint 3, this number stabilizes into a reliable planning tool.

Click Backlog in the left sidebar to view your remaining stories.
Note the 2 remaining stories: Onboarding tour (3 points) and Organize into categories (8 points), totaling 11 story points.

Based on your Sprint 1 velocity of 15 points, you could confidently commit to both remaining stories in Sprint 2. That is 11 points of work against a proven capacity of 15.

Velocity builds confidence over time

One sprint of data gives a rough baseline. Real teams use the average of 3-5 sprints to make reliable commitments. The Velocity Chart becomes more valuable with each completed sprint.

Secret mission

Build an Automation Rule

You've run a complete sprint from planning to retrospective. But what if Jira could handle some of the board management for you? In this secret mission, you'll build an automation rule that detects when all sub-tasks are done and automatically transitions the parent story to complete.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses the Jira Cloud Free plan, so there are no ongoing costs for keeping your project active.

Resources you used:

TaskFlow App project in Jira Cloud (includes all user stories, sprints, automation rules, and reports).

Keep everything running

No action needed. Choose this if you're still actively building on the project or want to reference it in the future.

Your TaskFlow App project stays on the Jira Cloud Free plan at no cost.
Your automation rule will continue to use flow runs (up to 100 per month on the Free plan) any time sub-tasks transition to Done.
Your burndown chart, sprint report, and velocity data remain available in the Reports section.

Pause - I'll come back to this later

Disable your automation rule to preserve your monthly flow runs while keeping the project intact.

In your TaskFlow App project sidebar, click the three-dot menu (More actions), then select Space settings.
Select Automation from the left panel.
Find your "Auto-complete parent when sub-tasks done" rule and disable it by toggling it off.
Your project, stories, sprint history, and reports all remain untouched.

Delete - I don't want to use this again

Remove the entire TaskFlow App project from your Jira Cloud instance.

In your TaskFlow App project sidebar, click the three-dot menu (More actions), then select Space settings.
In Space settings, navigate to Details.
Scroll to the bottom and select the option to move the space to trash.
Confirm the deletion when prompted. This removes all user stories, sprints, automation rules, and reports associated with the TaskFlow App project.

Nice Work!

You just ran a complete Scrum sprint in Jira, from building a product backlog to completing a sprint retrospective. This is the core competency hiring managers test for in PM interviews.

You've learned how to:

Built a team-managed Scrum project with a prioritized product backlog of 6 user stories, each containing acceptance criteria and story point estimates.
Planned and executed a full sprint cycle by committing stories, breaking work into sub-tasks, and moving issues across the board from To Do through In Progress to Done.
Analyzed sprint performance using the burndown chart, sprint report, and velocity metrics, then completed a sprint retrospective identifying improvements for the next sprint.
Secret Mission: Created a Jira automation rule that auto-transitions parent issues when all sub-tasks are complete, demonstrating workflow optimization skills.

Ready to quiz yourself?