Most startup Jira setups die from over-configuration in week 1. Some PM reads a Best Practices article, configures 12 issue types, 8 custom fields, 4 workflows, and 3 boards. Six weeks later half the team is creating issues in Linear or Notion because Jira is too heavy. The fix: start with 3 issue types, 1 board, 2 workflows. Resist additions until the pain is real.
The minimal setup
3 issue types
Task — engineering work that isn't a bug or user-facing feature. Required fields: Summary, Assignee.
Bug — defects in shipped code. Required fields: Summary, Assignee, Reproduction steps, Severity.
Story — user-facing features tied to product goals. Required fields: Summary, Assignee, Acceptance criteria.
That's it. Task, Bug, Story cover 95% of engineering work for a startup.
1 board: Kanban
Not Scrum. Scrum requires sprint ceremony — planning, retro, demo, refinement — that small teams cannot sustain. Kanban with a WIP limit (typically 2 per engineer) forces focus without weekly meetings. Add columns only when something is genuinely blocked there.
2 workflows
Software workflow (Task, Story): To Do → In Progress → In Review → Done. Four states. Transitions: open, start, submit, merge.
Bug workflow: To Do → In Progress → In Review → Done. Same as Software but with Severity required at creation and an automation that pings the team lead on Severity 1.
That's it. No "Reopened" state (just create a new bug). No "Verified" (the reviewer's approval is verification). No "Blocked" (use a label, don't pollute the workflow).
What NOT to configure in week 1
Each of these creates ceremony you don't need yet and slows ticket creation, with no upside until you've shipped 6+ months and proven a real bottleneck:
- Epic / Sub-task. Add when 10+ related stories exist and someone asks how they fit together.
- Sprints. Add when the team is 8+ engineers AND retros yield concrete improvements.
- Story points. Add after 3 sprints of completion data when you actually want to compare velocity.
- Components. Add when you have 4+ distinct product areas needing separate filters.
- Versions / Releases. Add when you actually do versioned releases (most SaaS does not).
- Custom fields. Add when you've tried to filter on it 3+ times without success.
- Multiple workflows. Add when Bug and Task workflows genuinely diverge.
- Approval steps. Add only if compliance requires (most startups never).
Automation rules to set up in week 1
Three rules every startup should configure:
1. Auto-assign reporter when status changes to In Progress. Trigger: Issue transitioned. Condition: status is "In Progress". Action: Assign to current user. Saves the click every time someone picks up a ticket.
2. Slack notification on Severity 1 Bug. Trigger: Issue created. Condition: Issue Type is Bug AND Severity is "Sev1". Action: Send Slack message to #eng-alerts with summary and link.
3. Auto-close stale tickets. Trigger: Scheduled (weekly). JQL: status = "To Do" AND updated < -30d. Action: Comment "Auto-closed due to 30 days of inactivity. Reopen if still relevant." Then transition to Done.
When to evolve the setup
- "I can't find tickets about the payment flow" → add Label or Component
- "We don't know what's shipping this month" → add Fix Version / Release
- "We have 30 tickets in To Do and don't know which matter" → add Priority (High/Med/Low only, not 5 levels)
- "PM wants to see all work toward Q3 OKR" → add Epic
- "Retro: we need to estimate better" → add Story Points (after 3 sprints of data)
Cost of over-configuration
We've audited 15+ startup Jira instances. The pattern is consistent: setups configured in week 1 with 8+ issue types and 6+ workflows end up with 60-70% of issues using only 3 types and the default workflow. The rest is dead weight that confuses new joiners and slows ticket creation.
A 10-engineer team that takes an extra 30 seconds per ticket due to over-configuration burns roughly 4 hours per week across the team. That's 200 hours per year, or about 15,000 euro in engineer time at a fully loaded cost of 75 euro per hour.
Comparison
| Don't add | Reason | Add when |
|---|---|---|
| Epic / Sub-task | Hierarchy overhead | 10+ related stories AND someone asks how they fit |
| Sprints | Requires ceremony | Team is 8+ AND retros yield improvements |
| Story points | Useless without 3-4 sprints data | After 3 sprints you want to compare velocity |
| Components | Premature categorization | 4+ distinct product areas |
| Versions / Releases | Adds gating | You actually do versioned releases |
| Custom fields | Each one slows creation | You've tried to filter on it 3+ times |
| Multiple workflows | Maintenance burden | Bug and Task genuinely diverge |
| Approval steps | Adds latency | Compliance requires |
FAQ
Why only 3 issue types?
Task, Bug, Story cover 95% of engineering work. Add types only when a real workflow needs them, not preemptively.
What's wrong with the default Jira workflow?
Too many states (To Do, In Progress, In Review, Reopened, Resolved, Closed). Use 4: To Do, In Progress, In Review, Done.
When should we add Epics?
When you have 10+ stories sharing a goal AND the team is asking how they fit together. A label like 'feature-payments' is enough until then.
Do we need story points from day 1?
No. Story points are useful after 3-4 sprints when you want to compare velocity. Day 1: just count tickets.
Need help configuring Jira without over-engineering it?
We set up Jira for 30+ startups. Fixed-price audit + minimal setup in 1 week. Book a discovery call.
Book a discovery call