JIRA Projects
A JIRA project is a container that holds all the issues, boards, sprints, and reports for a specific piece of work. Every issue in JIRA must belong to a project. Think of a project as a folder on a computer — it keeps related items together and separate from everything else. Understanding how projects work is essential because every JIRA activity happens inside a project.
What Defines a JIRA Project?
Each JIRA project has a set of properties that make it unique. These properties control how the project behaves, who can access it, and how work flows through it.
| Property | Description | Example |
|---|---|---|
| Project Name | A full descriptive name for the project | Mobile Banking App |
| Project Key | A short uppercase code used as a prefix for all issue IDs | MBA (so issues become MBA-1, MBA-2...) |
| Project Type | Software, Service Management, or Business | Software |
| Template | Scrum, Kanban, or Bug tracking setup | Scrum |
| Project Lead | The main person responsible for the project | Priya Sharma (Project Manager) |
| Access Level | Private (specific team) or Public (all users) | Private |
Types of JIRA Projects
JIRA supports three project types. Each type comes with different built-in views, issue types, and workflow options.
Software Project
A Software project suits development teams working in Agile. It includes Scrum boards, Kanban boards, sprints, backlog management, and release tracking. This is the most feature-rich project type.
Service Management Project
A Service Management project suits IT helpdesks and customer support teams. It includes a customer portal, SLA timers, queues for agents, and approval workflows. Customers submit tickets through the portal, and agents handle them in JIRA.
Business Project
A Business project suits non-technical teams like HR, legal, and marketing. It uses simple list views, forms, timelines, and calendar views. Sprints and story points are not used in this type.
| Feature | Software | Service Management | Business |
|---|---|---|---|
| Scrum Board | Yes | No | No |
| Kanban Board | Yes | Yes | No |
| Sprints | Yes | No | No |
| Customer Portal | No | Yes | No |
| SLA Tracking | No | Yes | No |
| Backlog | Yes | No | No |
| List View | Limited | Queue view | Yes |
| Timeline / Roadmap | Yes (with plan) | No | Yes |
Project Templates
When creating a new project, JIRA asks the user to choose a template. A template pre-configures the project with suitable workflows, issue types, and board settings. This reduces manual setup time.
| Template Name | Project Type | Best Used For |
|---|---|---|
| Scrum | Software | Dev teams doing sprint-based delivery |
| Kanban | Software | Teams with continuous flow of work, no sprints |
| Bug Tracking | Software | Teams focusing only on bug management |
| IT Service Management | Service Management | Internal IT helpdesk teams |
| Customer Service | Service Management | External customer support teams |
| Project Management | Business | General project tracking for business teams |
| HR Operations | Business | Employee onboarding, HR requests |
How to Create a JIRA Project
Creating a new project in JIRA follows a simple step-by-step process. Only JIRA Administrators or users with "Create Projects" permission can complete this action.
| Step | Action | Notes |
|---|---|---|
| 1 | Click Projects in the top navigation bar | Opens the projects dropdown |
| 2 | Click Create Project | Opens the template selection screen |
| 3 | Select a project type and template | e.g., Software → Scrum |
| 4 | Click Select to confirm the template | Moves to the project details form |
| 5 | Enter the Project Name | e.g., "Payment Gateway Integration" |
| 6 | Review or edit the auto-generated Project Key | e.g., PGI — must be unique across all projects |
| 7 | Set the Access Level (Private or Public) | Private = only invited members can view |
| 8 | Click Create | Project is created and the board opens |
Understanding the Project Key
The project key is a short uppercase identifier that JIRA assigns to every issue in the project. When a project key is PGI, the issues in that project get IDs like PGI-1, PGI-2, PGI-3, and so on. These IDs are permanent and unique. Teams use them to reference specific issues in emails, meetings, and code commit messages.
Example: A developer writes a commit message: "Fixed null pointer exception — PGI-47". Anyone on the team can search "PGI-47" in JIRA and immediately see the issue that this commit addresses.
Project Roles and Members
Each project has its own set of members with different roles. The project lead assigns these roles through Project Settings.
| Role | Permissions Included |
|---|---|
| Administrator | Full control: configure settings, delete issues, manage members |
| Developer | Create issues, edit issues, log work, transition statuses |
| Viewer | Read-only access: view issues and boards but cannot edit |
Managing Project Settings
Project Settings is the control panel for every project. Access it from the bottom of the left sidebar when inside a project. Here is what each setting section controls.
| Section | What It Controls |
|---|---|
| Details | Project name, key, description, project lead, avatar |
| Access | Who can view and join the project |
| People | Add or remove team members and change their roles |
| Notifications | Set up which events send email alerts to which roles |
| Issue Types | Choose which issue types are available in the project |
| Workflows | Map issue types to specific workflow diagrams |
| Screens & Fields | Control which fields appear on create, edit, and view screens |
| Permissions | Define what each project role can do |
| Components | Create sub-sections of the project for grouping issues |
| Versions | Set up release versions for tracking deliverables |
Company-Managed vs Team-Managed Projects
JIRA Cloud offers two management models for projects. Choosing the right model affects how much flexibility and control the team has over configuration.
Company-Managed Projects (Classic)
A JIRA Administrator controls all configuration. Workflows, screens, and fields are shared across multiple projects. Changes to these shared elements affect all projects that use them. This model suits large organizations where standardization matters.
Team-Managed Projects (Next-gen)
Any project admin can configure the project independently. Settings apply only to that project. No knowledge of global JIRA administration is needed. This model suits smaller teams or teams that want speed and simplicity.
| Aspect | Company-Managed | Team-Managed |
|---|---|---|
| Who configures it | JIRA Administrator | Project Admin (any team member) |
| Workflow flexibility | High (custom multi-step workflows) | Limited (simplified workflows) |
| Shared configurations | Yes — shared with other projects | No — isolated to this project only |
| Setup speed | Slower (more configuration) | Fast (template-driven) |
| Best for | Enterprise, regulated environments | Small teams, quick starts |
Example Project Structure
Here is a realistic example showing how a company might organize multiple JIRA projects.
| Project Name | Project Key | Type | Template | Team |
|---|---|---|---|---|
| Mobile Banking App | MBA | Software | Scrum | Dev Team A |
| Payment Gateway | PGW | Software | Kanban | Dev Team B |
| IT Support Desk | ITS | Service Management | IT Service | IT Team |
| Marketing Campaigns | MKT | Business | Project Management | Marketing Team |
| Employee Onboarding | EMP | Business | HR Operations | HR Team |
Summary
JIRA projects are the top-level containers that organize all work. Each project has a unique key, a type, a template, and a team. Company-managed projects suit large organizations needing standardized configurations. Team-managed projects suit smaller teams needing quick setup. With a project created and configured, the next step is learning about the issues that live inside it — the actual units of work tracked in JIRA every day.