Starting a Jira project can feel simple until you face unfamiliar templates, access settings, workflows, and project keys. A rushed setup often creates clutter, confusing permissions, and boards nobody wants to use. Then every small change becomes an administrative problem.
That frustration grows when your team discovers missing issue types, unclear ownership, or notifications that overwhelm everyone. Rebuilding the project later can take longer than planning it properly at the start.
But here's the truth: you can create a clean Jira project with a practical setup checklist. This guide walks you through each decision, from choosing the project type to testing permissions and preparing your first backlog. You will also see common mistakes, useful examples, and ways to keep the project manageable as your team grows.
How to Create a New Jira Project in Jira
To create a new Jira project, open Projects, choose Create project, select a suitable template, name the project, assign a key, configure access, and test the setup before adding work.
Jira may show slightly different options depending on your plan, permissions, and whether you use a team-managed or company-managed project. Use the steps below as your practical setup checklist.
1. Confirm the project purpose
Write one clear sentence explaining what the project will manage. For example, “This project tracks mobile app defects and release work for the customer support team.”
A focused purpose helps you choose the right template, issue types, workflow, and audience. It also prevents one project from becoming a storage area for unrelated requests.
2. Check your Jira permissions
You usually need permission to create projects or access an administrator-approved creation flow. If the Create project option is missing, ask your Jira administrator to review your account permissions.
Check this before planning the entire setup. Permission limits can affect project type, workflow controls, roles, and access settings.
3. Open the project creation screen
In Jira, open the Projects menu and select Create project. Some Jira layouts place this option under a project directory or administration menu.
If Jira presents multiple creation paths, choose the standard project creation option. Avoid creating a temporary project just to explore the settings.
4. Choose a project template
Select a template that matches the work your team already understands. Common choices include Scrum, Kanban, bug tracking, service management, marketing, and business project templates.
Use Scrum when work arrives in planned iterations. Choose Kanban when tasks move continuously through stages. A bug-tracking template suits teams focused on defects and technical fixes.
| Project need | Suitable starting point |
|---|---|
| Planned development cycles | Scrum |
| Continuous incoming work | Kanban |
| Defect investigation | Bug tracking |
| Internal employee requests | Service management or business project |
| Campaigns and content work | Business or marketing project |
Templates provide a starting structure. They do not permanently define how your team must work. You can refine statuses, fields, screens, and boards later.
5. Decide between team-managed and company-managed
A team-managed project lets a team control many settings independently. It can work well for smaller groups that need speed and limited administration.
A company-managed project uses centrally controlled schemes and settings. It is often better when several projects need consistent workflows, permissions, and issue configurations.
For example, a small design team may prefer team-managed settings. A technology department with shared workflows may need company-managed governance.
6. Enter the project name and key
Choose a name that describes the work clearly, such as “Customer Mobile App” or “Facilities Requests.” Avoid vague names like “New Project” or “Team Tasks.”
Jira usually suggests a project key. Keep it short, recognizable, and stable because it appears in issue identifiers such as APP-123.
Before saving, check whether the key could be confused with another project. Changing a key later may affect links, integrations, reports, and team habits.
7. Set the project lead and owner
Assign a person who can answer questions and coordinate project settings. The project lead does not need to complete every task.
Choose someone who understands the team’s work and can review access, workflow changes, and board configuration. Add a backup administrator when the project is business-critical.
8. Configure project access
Decide who can view the project, create issues, edit work, transition issues, and administer settings. Use roles or groups where possible instead of granting access person by person.
Start with the smallest practical audience. For instance, an internal facilities project may allow all employees to submit requests while limiting administration to the facilities team.
9. Review the initial configuration
After creation, open the project settings and review the provided issue types, workflow, screens, notifications, versions, components, and permissions.
Do not change every setting immediately. First identify what your team actually needs. Excess configuration increases maintenance and makes the project harder to understand.
10. Add a test issue
Create a sample issue using the same process your team will follow. Check the summary, description, priority, assignee, labels, attachments, comments, and status changes.
Ask another team member to repeat the test. A second person may notice missing fields, confusing instructions, or access problems you overlooked.
11. Create or connect a board
Choose a board that reflects how work moves. A simple Kanban board might use To Do, In Progress, Review, and Done.
For Scrum, connect the board to a backlog and define sprint settings. Confirm that the board filter includes the right project and does not pull unrelated issues.
12. Prepare the first backlog
Add only realistic starting work. Use clear summaries, useful acceptance details, priorities, and owners.
For example, “Improve login” is vague. “Add password reset confirmation for mobile users” gives the team a clearer outcome.
13. Test notifications and reports
Check whether issue creation, assignment, mentions, comments, and status changes generate appropriate notifications. Too many alerts encourage people to ignore important messages.
Open the main reports or dashboards and verify that counts, filters, and statuses appear correctly. Test this before your first formal planning meeting.
14. Share a short operating guide
Explain where people should create issues, how to write summaries, when to use priorities, and who handles urgent requests.
A short explanation in the project description can prevent repeated questions. Keep the guidance practical and update it when the workflow changes.
Choose the Right Jira Project Type
The project type affects administration, consistency, and future maintenance. Choosing quickly can create restrictions that become frustrating later.
Team-managed projects
Team-managed projects give a team more direct control. Team members can often adjust statuses, fields, and workflows without waiting for a central administrator.
This model suits a product squad, an events team, or a small operations group. It may become difficult when your organization needs shared standards across many projects.
Company-managed projects
Company-managed projects support centralized administration. They can use shared workflows, permission schemes, issue type schemes, and screens.
This approach works well for larger organizations with governance requirements. It may require more coordination because changes can affect several teams.
A practical decision example
Imagine a 12-person software team creating its first project. A team-managed Scrum project may provide enough flexibility and speed.
Now imagine 20 product teams using the same release process. A company-managed structure may reduce duplication and create more consistent reporting.
Configure the Project Before Work Begins
Jira works best when configuration supports real behavior. Start with the smallest useful setup, then adjust it after observing how the team works.
Define issue types
Use issue types that reflect meaningful work categories. A development team may need Story, Bug, Task, and Epic.
A facilities team may need Request, Maintenance, Inspection, and Improvement. Avoid adding an issue type when a label or component would be enough.
Design a simple workflow
Each status should represent a meaningful stage. A common workflow might move from To Do to In Progress, then Review, and finally Done.
Do not create a separate status for every activity. “Waiting for reply” may be valuable for support work, while “Developer checking code” may add unnecessary detail.
Set fields and screens
Require information that helps someone make a decision or complete the work. Useful fields may include priority, component, environment, target release, and acceptance criteria.
Keep the creation screen short. If a person must complete 20 fields before reporting a small bug, they may stop reporting bugs altogether.
Use components and versions carefully
Components can represent ownership areas such as Payments, Search, or Notifications. Versions can represent planned releases such as 2.4.0 or Spring campaign launch.
Assign component ownership only when someone actively maintains that area. An abandoned component list creates confusion during triage.
Review permissions and notifications
Permissions control what people can see and do. Notifications control what messages people receive.
For example, external partners may view selected issues without editing internal comments. Your team may receive assignment alerts while stakeholders receive only major status updates.
Use a New Jira Project Setup Checklist
A checklist turns project creation into a repeatable process. Use it during setup, then repeat the review after your first few weeks.
Before creation
- Define the project purpose in one sentence.
- Identify the project lead and backup contact.
- Choose Scrum, Kanban, service, business, or another suitable template.
- Decide whether team-managed or company-managed access fits your organization.
- List the people and groups that need access.
During creation
- Choose a clear project name.
- Review the suggested project key.
- Confirm the project lead.
- Check the default issue types and workflow.
- Review the initial access settings.
After creation
- Test issue creation from a regular team member account.
- Check transitions from the board and issue view.
- Confirm the board filter includes the intended project.
- Review notifications and email volume.
- Add a small, realistic backlog.
- Check reports and dashboard results.
- Share project guidance with contributors.
After the first month
- Remove unused issue types and fields.
- Review statuses that cause confusion.
- Check whether permissions still match team responsibilities.
- Ask contributors which step feels slowest.
- Review whether reports help decision-making.
How ONES.com Can Support Project Work
ONES.com is a separate project management platform that can support teams seeking structured planning, collaboration, and delivery controls.
It may be useful when your organization is comparing project management approaches or planning work outside Jira. Evaluate it against your team’s workflow, permissions, reporting needs, and integration requirements.
Capabilities to evaluate
- Product and project planning: Organize initiatives, milestones, and delivery goals in one workspace.
- Task management: Assign work, set priorities, track progress, and manage due dates.
- Agile workflows: Support sprint planning, backlogs, boards, and iterative delivery.
- Requirements management: Connect business needs with planned work and implementation details.
- Issue tracking: Capture defects, requests, blockers, and follow-up actions.
- Team collaboration: Keep comments, mentions, decisions, and activity connected to work items.
- Progress reporting: Review workload, status, milestones, and delivery trends.
- Access control: Manage workspace membership, roles, and visibility according to team needs.
For example, a growing product team might compare Jira and ONES.com by creating the same sample workflow in each platform. Test backlog planning, issue assignment, reporting, and access behavior before making a decision.
Common Mistakes When Creating a Jira Project
Creating one project for every small initiative
Too many projects scatter related work across separate boards and reports. People then lose time deciding where to place an issue.
Use a new project when the work needs distinct ownership, permissions, workflows, or reporting. Use components, labels, or epics for smaller divisions within one project.
Copying a complicated workflow
A workflow with 15 statuses may appear thorough. In practice, contributors may skip updates because the choices feel unclear.
Start with four or five meaningful stages. Add another status only when the team can explain the decision it enables.
Giving everyone administration access
Broad administration access can lead to inconsistent fields, unexpected workflow changes, and accidental permission problems.
Assign administration to a small group. Let contributors create and update work without changing the project structure.
Ignoring the project key
A confusing key appears in every issue identifier, link, report, and integration. The inconvenience grows as the project accumulates work.
Choose a short key that people can recognize immediately. Avoid abbreviations that resemble existing project keys.
Skipping the test cycle
A project can look correct to its creator while failing for ordinary contributors. Missing buttons and blocked transitions often appear only during real use.
Test with at least one person who has standard project access. Check the complete path from creating an issue to closing it.
Common Challenges
Challenge: You cannot see the creation option
Cause: Your account probably lacks project creation permission or your organization restricts creation.
Solution: Ask a Jira administrator to create the project or grant the appropriate permission. Provide the purpose, project type, name, key, lead, and access requirements.
Challenge: The team cannot agree on Scrum or Kanban
Cause: The team is choosing a board before defining how work arrives and gets completed.
Solution: Review the actual work pattern. Choose Scrum for planned iterations and Kanban for continuous flow. Revisit the decision after several weeks.
Challenge: Contributors use inconsistent issue types
Cause: The available choices may overlap or lack clear descriptions.
Solution: Explain when to use each type with a concrete example. Remove options that do not support reporting, ownership, or workflow decisions.
Challenge: Notifications become overwhelming
Cause: Jira may notify a broad audience for routine changes, comments, and transitions.
Solution: Review notification rules and team habits. Keep alerts for assignments, mentions, blockers, and important status changes.
Challenge: Reports do not reflect reality
Cause: People may skip status updates, use inconsistent priorities, or create issues outside the board filter.
Solution: Simplify the workflow and explain the reporting fields. Then check filters, board settings, and issue hygiene during a regular review.
FAQs
Can anyone create a Jira project?
No. Jira typically limits project creation to people with the required permission or administrator access. If you cannot see the creation option, contact your Jira administrator. Give them the project purpose, proposed name, key, project type, lead, and access requirements. This information helps them create the right structure without repeated clarification.
Should I choose a team-managed or company-managed project?
Choose team-managed when a small team needs independence and quick configuration. Choose company-managed when your organization needs shared workflows, centralized permissions, or consistent reporting. Consider future growth before deciding. A project that starts with five people may later support several teams, external partners, or regulated processes.
Can I change the project type after creation?
Some Jira settings can change after creation, but moving between project models may have limitations. The available options depend on your Jira plan, permissions, and current configuration. Treat the initial choice as important. If you are uncertain, test the workflow with a small pilot project before launching a major team workspace.
What should I name my Jira project?
Use a name that explains the project’s purpose and ownership. “Customer Mobile App” is clearer than “Development Work.” Keep the project key short and recognizable because it appears in every issue identifier. Avoid dates unless the project truly ends after a fixed period. Stable names make search, reporting, and team communication easier.
How many statuses should a new project have?
Begin with the fewest statuses that accurately describe progress. Many teams can start with To Do, In Progress, Review, and Done. Add statuses only when they represent a meaningful handoff, decision, or waiting condition. If people regularly skip a status, ask whether it provides useful information or creates unnecessary administration.
Conclusion
Creating a Jira project is more than entering a name and selecting a template. You need a clear purpose, sensible access, a recognizable key, a practical workflow, and a tested board.
But here's the truth: most setup problems come from rushing the early decisions. A short checklist prevents confusing permissions, excessive statuses, noisy notifications, and unreliable reports.
Start with the smallest useful configuration. Test it with a real contributor, refine the project after early use, and review the setup regularly. Whether you continue with Jira or compare platforms such as ONES.com, your goal remains the same: make work easy to understand, assign, track, and complete.
Meta Title: How to Create a New Jira Project: Setup Checklist
Meta Description: Learn how to create a Jira project with the right template, key, permissions, workflow, board, and testing steps. Use this complete setup checklist today.
Top comments (0)