Jira Project Setup for Visibility: Choosing a Project Type and Initial Configuration

Why project setup choices affect visibility

A Jira project is more than a container for work: it defines how work is created, categorized, and reported. Early choices—template (Scrum vs Kanban), project type (team-managed vs company-managed), issue types, and required fields—determine whether you can answer basic PM questions later (e.g., “What’s in progress?”, “What’s blocked?”, “What did we deliver this sprint?”, “How much work is unestimated?”). This chapter focuses on decisions that improve coordination and reporting without requiring deep administrative configuration.

(1) Decision tree: pick a template based on delivery style

Use the following decision tree to select a template that matches how the team delivers. The goal is to align Jira’s default reporting and workflow expectations with your real operating model.

Template decision tree

• If you deliver in timeboxes (sprints) and commit to a sprint goal → choose Scrum. Typical signals: sprint planning, sprint review, velocity tracking, release planning based on completed points.
• If you deliver continuously and prioritize flow → choose Kanban. Typical signals: work pulled when capacity frees up, focus on cycle time, WIP limits, service-style intake.
• If you do both (mixed model) → decide which reporting you need most in the next 4–8 weeks:
  • Need sprint commitments, sprint scope control, sprint reporting → start with Scrum.
  • Need flow metrics, steady intake, less ceremony → start with Kanban.

Scrum vs Kanban: PM visibility implications

Team-managed vs company-managed: decision-level guidance

Both project types can work for PM visibility, but they differ in how standardized and scalable your setup is.

• Choose team-managed when: you need to start quickly, the team is relatively autonomous, and you can accept local variations in fields/workflows. PM benefit: faster setup and iteration. PM risk: cross-team reporting consistency can be harder if each team configures differently.
• Choose company-managed when: you need consistent reporting across multiple teams/projects, shared conventions (issue types/fields/workflows), or governance requirements. PM benefit: standardization supports portfolio-level reporting. PM risk: changes may require coordination with admins or governance processes.

PM rule of thumb: if your reporting needs are mostly within one team and you need speed, start team-managed. If you need comparable metrics across teams (same definitions of “Done”, same required fields), prefer company-managed.

(2) Step-by-step setup flow (naming, issue types, required fields)

This flow assumes you have permission to create a project. If you don’t, you can still use it as a checklist to request the right setup from an admin or project owner.

Continue in our app.

• Listen to the audio with the screen off.
• Earn a certificate upon completion.
• Over 5000 courses for you to explore!

Or continue reading below...

Download the app

Step 1: Define the project identity (for search and reporting)

• Project name: use a stable, recognizable name that matches how stakeholders refer to the initiative (e.g., “Payments Platform Delivery”). Avoid names tied to a single quarter unless the project is truly temporary.
• Project key: keep it short and durable (e.g., PAY, PLAT). Changing keys later can create confusion in links and external references.
• Lead/owner: set a clear accountable owner (often the delivery lead or PM). This helps stakeholders know who to contact and supports permission decisions.

Step 2: Choose the template (Scrum or Kanban)

Select based on the decision tree above. If you are unsure, choose the template that matches the next 1–2 reporting cycles you must run (e.g., upcoming sprint reviews vs continuous operations reporting).

Step 3: Choose project type (team-managed vs company-managed)

Make this choice based on whether you need standardization across teams. If you anticipate adding more teams later and want consistent reporting, company-managed is usually the safer long-term choice.

Step 4: Select issue types (keep them minimal and meaningful)

Issue types are categories of work. Too many issue types reduce consistency; too few can limit reporting. Start with a small set that maps to how you plan and report.

Recommended baseline issue types for PM visibility:

• Epic: large outcomes or deliverables spanning multiple pieces of work (e.g., “Checkout redesign”).
• Story / Task: the primary unit of planned work. Use one consistently if your team struggles to distinguish them; consistency matters more than semantics.
• Bug: defects that should be tracked separately for quality reporting.
• Spike / Research (optional): timeboxed investigation. Only add if you will report on it or it’s common in your delivery model.

Practical guidance: If stakeholders ask “How many epics are in progress?” or “How many bugs did we ship?”, those are signals that Epic and Bug should exist as distinct types. If no one uses a type, remove it to reduce noise.

Step 5: Decide which fields are required (minimum set for consistent tracking)

Required fields enforce consistency, but too many required fields slow down intake and lead to low-quality data (people enter placeholders). Focus on fields that directly support coordination and reporting.

Minimum recommended required fields:

• Summary: short, action-oriented title (e.g., “Add refund status to order details”).
• Description (or acceptance criteria): enough context to execute or triage. If you can’t require it, set a team norm for a minimum template.
• Priority: supports triage and stakeholder expectations.
• Assignee (or a clear alternative like “Unassigned” policy): enables accountability. If you avoid requiring Assignee, require a clear workflow step for triage/assignment.
• Epic link (for Stories/Tasks): ensures work rolls up to outcomes. If you don’t use epics, replace this with a component or label convention.

Fields to consider requiring only if you will use them in reporting:

• Story points / Original estimate: if you plan to forecast or track capacity.
• Due date: if you manage deadline-driven items (avoid setting due dates on everything).
• Component: if you need ownership by subsystem/team.

Permissions basics (PM perspective)

Permissions determine who can see and change work. From a PM standpoint, the goal is to prevent accidental disruption while keeping collaboration smooth.

• Visibility: confirm who can browse the project. If stakeholders need transparency, ensure they can view issues without needing edit rights.
• Creation: decide who can create issues. Options: everyone in the team, a wider intake group, or a controlled set (e.g., PMs/triage). If creation is open, ensure triage is strong.
• Editing: decide who can edit fields and transition statuses. Common pattern: team members can update their work; broader stakeholders can comment but not change scope/estimates.
• Transition control: if “Done” must meet a definition, restrict who can move items to Done or enforce checks via workflow rules (decision-level: you want a reliable Done state for reporting).

PM check: if your reports depend on status categories (To Do / In Progress / Done), ensure the team can transition issues easily and consistently, and that “Done” is not used as “we stopped working on it”.

(3) Minimum viable configuration (MVC) to start tracking

The minimum viable configuration is the smallest setup that still produces reliable visibility. Use this to start quickly and improve iteratively.

MVC checklist

• Template aligned to delivery style: Scrum if sprint-based; Kanban if flow-based.
• Issue types: Epic + (Story or Task) + Bug.
• Statuses: at least To Do, In Progress, Done. Add Blocked only if the team will actively use it; otherwise use a flag or label convention.
• Required fields: Summary, Priority, and one of: Description (preferred) or a team-agreed description template. For planned work, ensure a roll-up mechanism (Epic link or equivalent).
• Ownership: a clear policy for assignment (either required Assignee or a triage step that assigns within 24 hours).
• Access: team can create and update issues; stakeholders can view and comment.

Example: description template for consistent intake

If you can’t enforce a required Description field, standardize what “good enough” looks like with a template the team copies into new issues:

Problem / goal:  What are we trying to achieve? Why now?  Scope:  In scope:  - ...  Out of scope:  - ...  Acceptance criteria:  - Given ... when ... then ...  Dependencies / risks:  - ...  Notes / links:  - ...

(4) Validation exercise: create a sample project and test consistency

This exercise verifies that your configuration supports consistent creation, discovery, and updates across the team. Run it with at least one other team member (or a stakeholder) to confirm permissions and usability.

Exercise setup: create a sample project

• Create a new project named “Visibility Sandbox” with key VIS.
• Select the template you expect to use (Scrum or Kanban) and the project type (team-managed or company-managed) you chose.
• Ensure issue types include: Epic, Story/Task, Bug.
• Confirm your minimum required fields are in place (or document the team norm if not enforceable).

Create sample work items (data you will later search and report on)

Create the following issues to test the end-to-end flow:

• Epic: “Onboarding improvements”
• Story/Task 1: “Add progress indicator to signup” (link it to the Epic)
• Story/Task 2: “Reduce required fields on signup form” (link it to the Epic)
• Bug: “Signup fails on Safari 17” (set Priority to High)

For each issue, ensure Summary is clear, Priority is set, and Description includes at least problem + acceptance criteria.

Consistency checks (create, find, update)

• Create: Ask another team member to create a new Story/Task and link it to the Epic. Verify they can set Priority and add a Description without friction.
• Find: Verify that anyone who needs visibility can locate work consistently:
  • Search by project key (e.g., project = VIS).
  • Filter by issue type (e.g., Bugs only).
  • Find all work under the Epic (confirm the roll-up mechanism works).
• Update: Ask a team member to move one Story/Task to In Progress and add a comment. Confirm:
  • They can transition status.
  • They can edit fields they are expected to maintain (e.g., Description updates, Priority changes if allowed).
  • Stakeholders (view-only) can comment but cannot accidentally change scope-critical fields (if that is your intent).

Permission validation questions (PM checklist)

• Can the team create issues without needing elevated access?
• Can the team transition issues through the workflow without blockers?
• Can stakeholders browse issues and see status/progress?
• Is there a clear boundary between “can comment” and “can change scope/priority/status”?

Field validation questions (data quality checklist)

• Do newly created issues consistently have Priority set?
• Do planned items consistently roll up to an Epic (or another grouping) so progress can be summarized?
• Is the Description sufficient for someone else to pick up the work?
• Are there any required fields that cause low-quality placeholder entries? If yes, remove or replace with a team norm.