Plan a Sprint Like a Tech PM

Build a Jira sprint board and Notion TPM portfolio with real Agile artifacts.

Introduction

30 Second Summary

Every app, website, and feature you use was delivered by a team running on deadlines, priorities, and tradeoffs. The person making sure it all ships on time is the Technical Project Manager.

In this project, you will plan and manage Sprint 1 of a fictional task management app called TaskFlow. You will use Jira to build a sprint board and Notion to write professional documentation, producing a full set of portfolio-ready TPM artifacts.

What You'll Build

A complete Agile sprint delivery simulation with a configured Scrum board, product backlog, project charter, risk log, and status report.

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

A Jira Scrum project with epics, user stories, acceptance criteria, and a completed sprint with velocity metrics.
A professional project charter defining scope, stakeholders, timeline, and success criteria in Notion.
A RAID log and weekly status report in the green/yellow/red format used at tech companies.
Secret Mission: Write a sprint retrospective and package everything into a portfolio case study with the format hiring managers look for.

Are there any prerequisites?

None. You will create free accounts for Jira and Notion as part of Step 1. No coding or prior project management experience is required.

Set Up Your Jira and Notion Workspace

Every software sprint needs two things before work begins: a board to track tasks and a place to document decisions.

In this step, you'll create a Jira Scrum project to manage your sprint backlog, and a Notion workspace to hold your project documentation.

In this step, get ready to:

Create a Scrum project in Jira with a sprint board.
Set up a Notion documentation workspace with pages for your project charter, RAID log, and status reports.
Verify both tools are ready for the next steps.

Create a new Scrum project in Jira

A Scrum board gives you columns to move work through stages. You'll create a team-managed project that comes pre-configured with a board and backlog.

Open your browser and go to https://atlassian.net.
Sign in to your Jira Cloud account.
In the left sidebar, hover over Spaces and click the + icon that appears to open Create space.
Browse the templates and select the Scrum template.
Click Use template.
When prompted for the space type, select team-managed.
Enter TaskFlow Mobile App as the space name.
Change the auto-generated space key to TF.
Click Create.

Your board should now appear with the default columns: To Do, In Progress, and Done.

What is a Scrum board?

A Scrum board is a visual tool that shows work items as cards moving through columns. Each column represents a stage in your workflow.

The team-managed Scrum template comes with recommended defaults for work types, statuses, and views. It also includes sprint and backlog features already enabled, so you can start planning work immediately.

Why team-managed instead of company-managed?

Team-managed projects are simpler to configure and don't require company-level admin permissions. They're ideal for learning and for smaller teams (up to about 10 users).

Company-managed projects offer more cross-project standardization, but only Jira admins can create them. For this portfolio project, team-managed gives you full control.

Confirm you can access the Backlog view by clicking Backlog in the left sidebar of your project.

Don't see the Create space option?

If you don't see the Create space option in the sidebar, your account may not have the required permission. On free Jira plans, all users should be able to create team-managed spaces by default. Try logging out and back in, or check that you're on the correct Atlassian site.

help me troubleshoot why I can't create a new space in Jira Cloud

Set up your Notion documentation workspace

Your Notion workspace will hold three key TPM documents that complement the Jira board. Each document gets its own sub-page for easy navigation.

Open Notion in your browser.
In the left sidebar, click the + icon next to Private to create a new page.
Title the page TaskFlow - TPM Portfolio.
Inside the page body, type /page and press Enter to create a sub-page.
Title this first sub-page Project Charter.
Click the back arrow or click your TaskFlow - TPM Portfolio page in the sidebar to return to it.
Repeat the process: type /page and press Enter to create a second sub-page titled RAID Log.
Return to the parent page and create a third sub-page titled Status Reports.

What are these three pages for?

The Project Charter defines what your project delivers, who's involved, and what's out of scope. The RAID Log tracks Risks, Assumptions, Issues, and Decisions throughout the sprint. Status Reports hold your weekly updates in the green/yellow/red format used at tech companies.

Together, these three documents demonstrate a TPM's core communication and risk management skills.

Can't find the /page command?

Make sure you're typing inside the body of the page (below the title), not in the title field itself. The slash command menu only appears in the page body. Type / and you should see a dropdown of options appear.

help me create sub-pages in Notion

Verify your setup

Before moving on, confirm that both tools are configured correctly.

Switch back to Jira and click Board in the left sidebar. You should see three columns: To Do, In Progress, and Done.
Click Backlog in the left sidebar. You should see an empty backlog ready for user stories.
Switch to Notion and expand the TaskFlow - TPM Portfolio page in the sidebar. You should see three sub-pages listed: Project Charter, RAID Log, and Status Reports.

Your workspace is ready. Next up, you'll fill in the Project Charter to define what your sprint delivers and who's involved.

Write the Project Charter

Your tools are ready. You have a Jira board waiting for work and a Notion workspace ready for documentation.

Before you start filling that backlog with tasks, you need a document that answers the most basic question any stakeholder will ask: what are we building, for whom, and by when? That document is the project charter.

In this step, get ready to:

Define the project overview, business goal, and stakeholders.
Write scope, success metrics, non-goals, and dependencies.
Review the charter for clarity and completeness.

Define the project overview and stakeholders

A good charter starts with the basics: who owns the project, what is the business trying to achieve, and who needs to be kept informed. These details give every team member a shared starting point.

Switch back to your Notion workspace.
Open the Project Charter sub-page inside your TaskFlow - TPM Portfolio page.
Type a heading called Project Overview at the top of the page.
Below the heading, add the following lines (each on its own line):

Type Project Name: TaskFlow Mobile App - Sprint 1.
Type Project Manager: followed by your name.
Type Business Goal: Deliver core task management features (create, edit, complete tasks) for beta testing.
Type Stakeholders: Engineering Lead, Product Manager, UX Designer, QA Lead.
Type Timeline: 2-week sprint followed by a start date (today) and an end date (14 days from today).

What is a project charter?

A project charter is a one-page document that defines what a project will deliver, who is involved, and what constraints exist. It acts as the single source of truth for stakeholders who need to understand the project quickly.

In a real TPM role, your charter is what you present at a kickoff meeting. If a stakeholder can read it in 90 seconds and understand the project, it has done its job.

Why are the stakeholders fictional?

In this project, you are simulating a real sprint delivery. The stakeholders (Engineering Lead, Product Manager, UX Designer, QA Lead) represent the typical cross-functional team a TPM coordinates. Naming them in your charter shows hiring managers you understand the communication structure of a product team.

Define scope, success metrics, and non-goals

The overview tells people what the project is. The next sections tell them what it will and will not deliver. This is where you draw the boundary that prevents scope creep later.

Add a new heading below your project overview called Scope.
Under Scope, list what Sprint 1 will deliver: user authentication, task CRUD operations, basic UI.

Add a heading called Success Metrics.
Add three bullet points underneath:

All user stories completed and accepted.
Zero critical bugs at sprint end.
Sprint velocity established.

Add a heading called Non-Goals.
List what is explicitly out of scope: push notifications, team collaboration features, analytics dashboard.

Add a heading called Dependencies.
Add two bullet points: Backend API must be available by Day 3. UX mockups delivered before sprint start.

Why do non-goals matter?

Non-goals protect you from scope creep. When a stakeholder asks "can we also add notifications?" you point to the charter and say it is explicitly out of scope for this sprint.

In TPM interviews, hiring managers look for candidates who can say no with documentation. A clear non-goals section proves you think about boundaries proactively.

Review your charter

Your charter is now complete. Take a moment to read it top to bottom as if you were a stakeholder seeing it for the first time.

Scroll to the top of your Project Charter page.
Read the entire page from top to bottom.
Confirm that your page has all five sections: Project Overview, Scope, Success Metrics, Non-Goals, and Dependencies.
Check that any stakeholder could read this in 90 seconds and understand what the project delivers, when it delivers, and what is out of scope.

The 90-second test

A strong charter fits on roughly one page. If yours is much longer, trim any sections that repeat information. If it is too short, make sure each section has enough detail for someone unfamiliar with the project to understand the boundaries.

Not sure if your charter looks right?

Double-check that you have a timeline with specific dates (not just "2 weeks"). Make sure your non-goals list items that are related to the project but excluded from this sprint. If a section feels empty, add one more concrete detail.

Help me review my project charter for completeness and clarity.

Your charter is locked in. Any stakeholder can now read this single page and understand what Sprint 1 will deliver. Next up, you will fill your Jira backlog with the epics and user stories that bring this charter to life.

Build the Product Backlog in Jira

Your project charter gives stakeholders a clear picture of what Sprint 1 will deliver. Now you need to turn that high-level scope into a structured list of work that a development team can actually pick up and build.

A product backlog is the single, prioritized list of everything a team might work on. In this step, you will populate your Jira backlog with epics (large feature areas) and user stories (small, deliverable pieces of value), then prioritize them so the most important work rises to the top.

In this step, get ready to:

Create three epics to organize your features in Jira.
Write user stories with acceptance criteria under each epic.
Prioritize the backlog by dragging stories into value order.

Create epics in your Jira backlog

Epics are large containers that group related user stories together. For TaskFlow, you will create one epic per major feature area so that sprint work stays organized.

In your Jira project sidebar, click Backlog to open the backlog view.
On the Backlog page, look for the Epic panel on the left side. If you do not see it, click the Epic filter dropdown and enable the Epic panel toggle.
In the Epic panel, click + Create Epic.
Name your first epic User Authentication and press Enter.
Click + Create Epic again and name the second epic Task Management.
Create a third epic named Core UI.

What do these epics cover?

User Authentication covers login, signup, and password reset.
Task Management covers creating, editing, deleting, and completing tasks.
Core UI covers navigation, the task list view, and the task detail view.

You should now see all three epics listed in the Epic panel on the left side of your backlog.

Don't see the Epic panel?

Make sure you are in the Backlog view, not the Board view. Epics cannot be created from the board directly.

If Backlog is not in your sidebar, click the + icon in your project navigation and select Backlog to add it.

Help me find the Epic panel in my Jira project.

Write user stories with acceptance criteria

User stories describe a feature from the end user's perspective. Each story follows the format: "As a [user], I want to [action], so that [benefit]." This keeps the team focused on delivering value rather than just completing tasks.

In the Epic panel, click the User Authentication epic to select it.
At the bottom of the backlog list, click + Create work item.
Type the story title: As a user, I want to sign up with email, so that I can create an account.
Press Enter to create the story.
Click on the newly created story to open it.
In the Description field, add acceptance criteria. For example: "Given I am on the signup page, when I enter a valid email and password and tap Sign Up, then my account is created and I am taken to the task list."
Close the story detail and repeat this process to create 2-3 stories for each epic (7-10 stories total).

Example stories for each epic

Here are example stories you can use. Feel free to adjust the wording to match your style.

Task Management epic:

"As a user, I want to create a new task, so that I can track my to-dos" (3 points).
"As a user, I want to mark a task as complete, so that I can track my progress" (2 points).
"As a user, I want to edit a task title and description, so that I can update my plans" (2 points).

User Authentication epic:

"As a user, I want to sign up with email, so that I can create an account" (3 points).
"As a user, I want to log in, so that I can access my tasks" (2 points).
"As a user, I want to reset my password, so that I can recover my account" (3 points).

Core UI epic:

"As a user, I want to see a list of all my tasks, so that I can review my workload" (3 points).
"As a user, I want to tap a task to see its details, so that I can view the full description" (2 points).
"As a user, I want to navigate between screens, so that I can move around the app" (3 points).

Now add story point estimates to each story. Story points represent relative effort using the Fibonacci-like sequence: 1, 2, 3, 5, or 8.

Before adding estimates, make sure estimation is enabled. Click the three dots ••• next to your project name in the sidebar, then select Space settings.
Select Features and enable Estimation. Choose Story points when prompted.
Return to your Backlog view.
Click on a story to open it.
Find the Story point estimate field and enter a value (1, 2, 3, 5, or 8).
Repeat for every story in your backlog. Aim for a total of approximately 20-25 story points across all stories.

What is a story point?

Story points measure the relative complexity and effort of a piece of work, not the number of hours. A 2-point story is roughly twice the effort of a 1-point story.

Teams use the Fibonacci-like sequence (1, 2, 3, 5, 8) because the gaps between numbers get larger as complexity grows. This reflects real-world uncertainty: the bigger the task, the harder it is to estimate precisely.

What makes good acceptance criteria?

Write acceptance criteria in the "Given... When... Then..." format. This structure makes it clear what state the user starts in, what action they take, and what result they should see.

For example: "Given I am on the task list, when I tap 'Add Task', then a form appears with title and description fields. When I submit, the task appears in my list."

Don't see the Story point estimate field?

You need to enable estimation first. Click ••• next to your project name, then Space settings, then Features. Make sure the Estimation toggle is on and set to Story points.

Help me enable story point estimation in my Jira project.

Prioritize the backlog

A backlog is only useful if the most important work is at the top. You will now reorder your stories so the team knows exactly what to tackle first.

In the Backlog view, drag stories up or down to reorder them by priority.
Place the highest-value, lowest-risk stories at the top. Authentication stories are a good starting point since other features depend on users being logged in.
Confirm you have 7-10 total user stories across your three epics, totalling approximately 20-25 story points.

Prioritize by value and dependencies

Ask yourself: "What must exist before anything else can work?" Authentication is typically the foundation. Task management depends on a logged-in user. UI polish can come last because it has fewer dependencies.

Your backlog should now show prioritized stories grouped under epics, each with story points and acceptance criteria.

Your backlog is structured and ready for sprint planning. Next up, you will select stories from this backlog, start Sprint 1, and simulate progress through the board.

Plan and Run Sprint 1

Your backlog is built. You have epics, prioritized user stories, acceptance criteria, and story point estimates ready to go.

Now it is time to bring those stories to life by running a sprint. A sprint is a fixed timebox (usually 1-2 weeks) where the team commits to completing a set of stories. You will create Sprint 1, pull stories into it, simulate the team's daily progress on the board, and then close the sprint to generate your first velocity report.

In this step, get ready to:

Start Sprint 1 with a sprint goal and a set of committed user stories.
Simulate a 2-week sprint by moving stories across the board columns.
Complete the sprint and review the velocity report Jira generates.

Start the sprint

Sprint planning is where the TPM and team agree on a sprint goal and select which backlog items they will commit to delivering. You will pull approximately 20 story points into Sprint 1 and set a clear goal.

Switch back to your Jira project and select the Backlog tab from the sidebar navigation.
You should see your prioritized user stories listed under the backlog section.
Click Create sprint to create a new sprint container above the backlog list.
Drag your highest-priority user stories into the sprint until you have approximately 20 story points total.
Click Start sprint.

What happens when you click Start sprint?

Jira will ask you to set a sprint name, start date, end date, and sprint goal. Fill these in during the next step.

In the dialog that appears, set the sprint duration to 2 weeks.
In the Sprint goal field, enter: Deliver core task creation and authentication flows.
Click Start.

Your board now shows the selected stories in the To Do column. Stories you did not pull into the sprint remain in the backlog.

What is a sprint goal?

A sprint goal is a single sentence that describes the outcome the team is working toward. It gives the team focus and helps stakeholders understand what to expect at the end of the sprint.

In a real project, you would write this collaboratively during sprint planning. Here, you are setting it as the TPM to demonstrate how goals guide delivery.

Simulate sprint progress

In a real sprint, the team moves stories across the board as they work on them each day. You will simulate 10 days of progress by dragging stories through the columns in a realistic pattern.

On your sprint board, drag 2 authentication stories from To Do to In Progress. This simulates Days 1-3.
Move those 2 authentication stories from In Progress to Done. This simulates Days 4-5.
Drag 2 task management stories from To Do to In Progress.
Move those task management stories to Done. This simulates Days 6-8.
Move your UI stories from To Do to In Progress.
Move all remaining stories to Done except one. Leave 1 story in In Progress to simulate realistic incomplete work.

Why leave one story incomplete?

Real sprints almost never finish with 100% completion. Leaving one story incomplete demonstrates that you understand how scope is managed. It also creates a more realistic velocity metric and gives you something to discuss in a retrospective.

Next, you will add comments to a few stories to simulate team communication.

Click on one of your authentication stories to open it.
Scroll to the comment section and add a comment: Blocked on API endpoint - raised with backend team.
Open a second story (any completed story) and add: QA approved - meets acceptance criteria.
Optionally, open a third story and add a comment of your choice that simulates realistic team discussion.

Comments show collaboration skills

In your portfolio, these comments demonstrate that you understand how teams communicate within Jira. Hiring managers look for evidence of cross-functional coordination, not just task completion.

Complete the sprint and review metrics

Completing a sprint closes the timebox and triggers Jira to generate reports. This is where you get your velocity data, which is the foundation of future sprint planning.

On your sprint board, click Complete sprint in the top right area of the board.
Jira will ask what to do with incomplete stories. Select Backlog to move the unfinished story back to the backlog.
Click Complete.

What happens when a sprint is completed?

Jira moves all completed stories out of the active sprint. Stories left in progress or to-do get moved to the backlog or a future sprint, depending on your choice.

Jira then generates sprint reports showing how many story points were committed versus delivered. This is your velocity metric.

Now review the sprint report that Jira generated.

After completing the sprint, Jira may show a sprint completion summary. Note the number of stories completed and story points delivered.
Navigate to the reporting section of your project. For team-managed projects, look for the Sprint burndown chart or Velocity report under your project's built-in reports.
Note the key metrics: stories completed, story points delivered, and any stories moved back to the backlog.

What is velocity?

Velocity is the average amount of work a scrum team completes during a sprint, measured in story points. Teams use velocity to predict how quickly they can work through the backlog in future sprints.

With only one sprint completed, your velocity equals the story points you delivered this sprint. After 3-4 sprints, the average becomes a reliable forecasting tool.

Not seeing the Complete sprint button?

Make sure you are on the board view (not the backlog view). The Complete sprint button only appears on the active sprint board.

If the button appears greyed out, check that at least one story is still in the To Do or In Progress column. Jira requires at least one non-Done story to enable the button.

Help me find the Complete sprint button in Jira

Your sprint is complete and your first velocity metric is established. Next up, you will build your RAID log and write a professional status report to round out your TPM artifact set.

Create the RAID Log and Status Report

Your sprint is done and the velocity metrics are in. Now it's time to build the documentation artifacts that prove you can manage risk and communicate progress.

A RAID log tracks Risks, Assumptions, Issues, and Decisions throughout a project. Paired with a weekly status report, these two artifacts show hiring managers that you can spot problems early and keep stakeholders informed.

In this step, get ready to:

Build a RAID log database in Notion with categorized entries.
Write a weekly status report in green/yellow/red format.
Capture portfolio screenshots of your complete artifact set.

Build the RAID log in Notion

A RAID log is one of the most powerful artifacts a TPM maintains. It gives your team and stakeholders a single place to track everything that could affect delivery.

In Notion, return to your TaskFlow - TPM Portfolio page.
Open the RAID Log sub-page.
Type /database and select Table - Inline to create a new database table on the page.

Now configure the table columns. You need seven columns total to capture all the critical information for each entry.

Rename the default first column to ID.
Click the + button to add a new column. Name it Category and set the type to Select.
Add four options to the Category column: Risk, Assumption, Issue, and Decision.
Add a column called Description with type Text.
Add a column called Owner with type Text.
Add a column called Status with type Select. Add three options: Open, Closed, and Mitigating.
Add a column called Impact with type Select. Add three options: High, Medium, and Low.
Add a column called Date Raised with type Date.

Why these specific columns?

Each column serves a purpose in project tracking. Category lets you filter by type. Owner creates accountability. Status shows whether the item still needs attention.

Impact helps you prioritize which items to discuss in stakeholder meetings. High-impact risks get attention first.

Now populate the table with realistic entries. Add at least 2-3 entries per category to demonstrate thorough project tracking.

Add a new row with these values for your first Risk entry:

ID: R-001.
Category: Risk.
Description: Backend API delivery may slip past Day 3, blocking frontend stories.
Owner: Engineering Lead.
Status: Mitigating.
Impact: High.
Date Raised: today's date.

Add a second row for your first Assumption entry:

ID: A-001.
Category: Assumption.
Description: UX mockups are approved and will not change during sprint.
Owner: Product Manager.
Status: Open.
Impact: Medium.
Date Raised: today's date.

Add a third row for your first Issue entry:

ID: I-001.
Category: Issue.
Description: Authentication library has a known bug with password reset on Android.
Owner: Engineering Lead.
Status: Open.
Impact: Medium.
Date Raised: today's date.

Add a fourth row for your first Decision entry:

ID: D-001.
Category: Decision.
Description: Team agreed to use token-based authentication over session-based.
Owner: TPM.
Status: Closed.
Impact: Low.
Date Raised: a date from early in the sprint (e.g. the sprint start date).

Add 4-8 more rows to reach at least 2-3 entries per category. Use your imagination to create realistic project scenarios.

Make entries feel realistic

Think about what would actually go wrong in a mobile app sprint. A second Risk might be "QA environment unstable during regression testing." A second Decision might be "Agreed to defer push notifications to Sprint 2."

The more specific your entries, the stronger this looks in a portfolio review.

Write the weekly status report

Status reports keep stakeholders informed without requiring them to attend every meeting. The green/yellow/red format is standard at tech companies because it lets a busy executive understand project health in seconds.

Return to your TaskFlow - TPM Portfolio page in Notion.
Open the Status Reports sub-page.

Create the report using the following structure. Type each section as a heading or bold label, followed by the content underneath.

Add a heading: Weekly Status Report - Sprint 1.
Add Report Date: followed by today's date.
Add Overall Status: Yellow. This is realistic because one story was incomplete at sprint end.
Add Sprint Progress: Write something like "18 of 22 story points completed (82%)." Use numbers that match your actual Jira sprint report.
Add Summary: Write 1-2 sentences describing overall progress. Example: "Sprint 1 delivered core authentication and task management features on schedule. One UI story carried over due to a dependency on finalized mockups."

Now add the detailed sections that give stakeholders the full picture.

Add a section called What was accomplished this week with a bullet list of completed stories. Pull these from the stories you moved to "Done" in Jira.
Add a section called What is planned next week with a bullet list of remaining work. Include the incomplete story and any Sprint 2 preparation.
Add a section called Blockers/Risks that references specific RAID log items. Example: "R-001: Backend API delay risk is being mitigated. I-001: Auth library bug under investigation."
Add a section called Decisions needed listing any open questions for stakeholders. Example: "Need Product Manager approval on revised task detail screen layout by Wednesday."

Why Yellow instead of Green?

Choosing Yellow shows hiring managers you understand realistic reporting. A TPM who always reports Green either has perfect projects (unlikely) or hides problems (dangerous).

Yellow means "on track with risks to monitor." It demonstrates you can flag concerns early without causing panic.

Review your complete artifact set

You now have four portfolio-ready artifacts that demonstrate end-to-end sprint management. Take a moment to capture them for your portfolio.

Switch to your Jira project.
Navigate to your Board view and take a screenshot showing the completed sprint board.
Navigate to your sprint report (click Reports in the left sidebar, then select Sprint report) and take a screenshot showing your velocity metrics.
Save both screenshots somewhere you can find them later. These are evidence of your sprint management skills.

What should I see at this point?

Your complete artifact set should include: a Jira board with sprint history and velocity data, a project charter in Notion, a RAID log database with 8+ entries across four categories, and a status report in green/yellow/red format.

Any stakeholder or hiring manager could review these in 90 seconds and understand what the project delivers, what risks exist, and where things stand.

Your documentation game is strong. You have a full set of TPM artifacts that tell a cohesive story from planning through execution. Next up, you will package everything into a format that hiring managers actually evaluate in interviews.

Secret mission

Write Your TPM Case Study

You have all the artifacts. Now package them into the format hiring managers actually evaluate in TPM interviews. Write a sprint retrospective and build a portfolio case study using the Context, Problem, Role, Execution, Outcome structure.

Clean Up Your Resources

This project uses Jira Free and Notion Free, so there are no ongoing costs. Decide whether to keep your resources as portfolio artifacts, or delete them to start fresh.

Resources you used:

Jira Scrum project "TaskFlow Mobile App" (key TF) with epics, user stories, and completed sprint.
Notion page "TaskFlow - TPM Portfolio" with sub-pages: Project Charter, RAID Log, Status Reports, and Case Study.

Keep everything running

No action needed. Choose this if you plan to use these artifacts in your TPM portfolio or want to continue building on them.

Your Jira project and Notion pages remain accessible at no cost.
You can share your Jira board and Notion pages directly with hiring managers or link them in your resume.
Both Jira Free and Notion Free have no time limits on stored projects.

Pause - I'll come back to this later

Since both tools are free cloud services with no running processes, there is nothing to pause. Your data stays available whenever you return.

Your Jira project remains in your Jira Cloud workspace with no storage pressure (Jira Free includes 2 GB).
Your Notion pages remain in your workspace with unlimited blocks on the Free plan for individual use.

Delete - I don't want to use this again

Remove all project resources from both tools. This cannot be undone once you empty the trash.

Delete the Jira project:
Delete the Notion pages:

Nice Work!

You just planned and delivered a full software sprint as a Technical Project Manager. You now have a complete set of portfolio-ready artifacts that demonstrate real Agile delivery skills to hiring managers.

You've learned how to:

Build a complete Jira Scrum project with epics, user stories, acceptance criteria, and a completed sprint with velocity metrics.
Write professional TPM documentation in Notion including a project charter, RAID log, and green/yellow/red status report.
Run the full Agile/Scrum workflow that TPMs use daily: backlog grooming, sprint planning, board management, sprint completion, and reporting.
Secret Mission: Package your work into a reusable case study format (Context, Problem, Role, Execution, Outcome) that you can use in TPM interviews.

Ready to quiz yourself?