⚙️ Setup & First Project

Setup & First Project: Opening a new Jira project is like choosing the lock system of a laboratory.

Opening a new Jira project is like choosing the lock system of a laboratory. There are two options: keep the key inside the room (team-managed -- the team configures its own fields, statuses and permissions) or use a central key cabinet (company-managed -- schemes are governed centrally and all projects run on the same rules). The question worth pausing on: why is an architectural decision like "project type" pushed onto a tester who only wants to log a bug, on day one? Because it is the one decision that is expensive to undo -- fields, statuses and reports are all built on top of it. Compare: in Java you can freely build a list with `new ArrayList<>()`, or bind to a shared, unmodifiable collection. The first is fast and flexible, the second is consistent and reduces surprises across a large codebase. That is exactly the team-managed versus company-managed difference. The cost for QA: if two teams created projects of different types, the request "let us compare the bug density of the two teams" becomes impossible six months later -- fields carrying the same name are not the same thing. The decision made during setup draws the boundary of every report you will ever write.

🧭 What You Will Set Up in This Tab

You will go from a free Jira Cloud account all the way to logging your first bug: creating the account, picking the right project type, defining the team and roles, understanding why the permission scheme blocks some transitions for you, and creating the first issue with a sound key convention. Every step will have an expected output and a verification check -- moving on before seeing that a step truly succeeded is the most common setup mistake.

🎬 From an Empty Jira Project to the First Bug

Project Type Decision

SHOP-1 (First Issue)

The account was just created with one email and password. The screen is empty: no project yet, no issue. In this film you will follow the path from that empty state to the first real bug record.

Step 1 -- The project-type decision: the system asks "team-managed or company-managed?" This is the one decision that is expensive to undo -- every field, workflow and report will be built on top of it.

Step 2 -- The project is born: the "SHOP" project and its key prefix (SHOP) are set. That prefix will now be the first part of every issue's identity -- it cannot easily be changed afterward.

Step 3 -- The team is invited: Ayse (QA), Mert (developer) and Deniz (PO) are added to the project and each gets a role. Role is the first layer of who can perform which transition.

Step 4 -- The permission scheme kicks in: a rule is added so only the QA role can perform the "Done" transition. This rule works invisibly -- Mert will never see the "Done" button on his screen at all.

Finale -- Ayse logs the first bug. The system automatically assigns the key SHOP-1. Every setup step (project type, team, permission scheme) works silently behind this single record -- the user sees none of them, yet all are there.

1️⃣ B1. Opening a Free Jira Cloud Account

Step by Step: Opening a Free Jira Cloud Account