**Context**: Analysis of 5 interviews with Jira users across defense/innovation management, e-government (500 users), consulting, enterprise teams, and large-scale health organisation (900 users).

**Goal**: Understand how teams work in agile contexts in Jira in order to understand gaps and prioritise OpenProject development for smoother Jira-to-OpenProject migrations.

## Key Findings

There is significant variation in how teams use Jira, but **boards are where everyone does their day-to-day work**. The most critical migration needs are:

* **Flexible and automated board configuration** with quick filters (and then possibly swimlanes)

* sprint boards

* possibility to add wp to active sprints

* kanban boards

* default and customizable quick filters

* custom columns

* **Backlog and sprint buckets (incl. quick filters)** - sprints both as time-boxes _and_ organisational containers

* planning page with backlog and sprint buckets, where users can drag and drop issues

* defining sprints dates

* starting sprint

* default and customizable quick filters

* **Cross-project visibility** with intelligent status mapping (since different projects might use different custom statuses)

* **Reporting capabilities**

* burndown chart

* velocity chart (both with story points and days/hours)

* Time-in-status tracking (showing how long tickets spend in each state)

* **Additional features**

* labels for work packages (used in quick filters frequently) Begin of the insertion

* components

* roadmapsEnd of the insertion


In general: **Simple defaults** that work out-of-the-box, with progressive customisation and configuration

## Critical Patterns for OpenProject

### 1\. Sprint Management Flexibility

**Key Insight**: Teams need sprints to be both time-boxes _and_ organisational containers.

* BJ uses "fake sprints" as workflow stages (e.g., "To be checked", "Waiting for information")

* Teams need ability to have tickets in multiple sprints simultaneously

* Teams regularly change sprint scope mid-sprint (despite knowing it's "not by the book")


**Implication**: Don't force rigid sprint boundaries. Support both strict and flexible sprint models.

### 2\. Board Configuration is King

**This is where teams spend 80% of their time.** What they need:

1. **Swimlanes** - by epic, assignee, version, custom fields

2. **Quick filters** - easy one-click filtering within board view (not just search)

3. **Custom columns** - with status mapping from multiple projects

4. **Cross-project boards** - single view across projects with different workflows

5. **Multiple boards per project** - for different audiences/purposes


### 3\. Backlog Management

**Key features**:

* Drag-and-drop prioritisation (we already have this)

* Filter by version, epic, labels, custom fields (also have this) <mention class="mention" data-id="72513" data-type="user" data-text="@Parimal Satyal">@Parimal Satyal</mention> we don&#39;t have this on the backlog level though, right?

* Visual capacity planning (see workload per person <mention class="mention" data-id="72513" data-type="user" data-text="@Parimal Satyal">@Parimal Satyal</mention>?); each wp can show wither story points or days

* Easy movement between backlog and sprints


### 4\. Workflow Simplicity with Customization Option

**Differences in familiarity with tools:**

* New teams need simple defaults (To Do / Doing / Done)

* Mature teams need complex workflows with feedback loops

* **Solution**: Simple defaults + easy, iterative means of configuration


### 5\. Reporting for Different Audiences

**For Teams**:

* Burndown and velocity charts

* Time-in-status tracking


**For Management**:

* Portfolio views across projects

* Visual/gamified presentations

* Simple dashboards (no JQL required)


## Priority Matrix

**Critical for migration**

These features are dealbreakers. Without them, Jira users will feel too constrained to migrate.

<figure class="table op-uc-figure_align-center op-uc-figure"><table class="op-uc-table"><thead class="op-uc-table--head"><tr class="op-uc-table--row"><th class="op-uc-table--cell op-uc-table--cell_head"><p class="op-uc-p">Feature</p></th><th class="op-uc-table--cell op-uc-table--cell_head"><p class="op-uc-p">Why Critical</p></th><th class="op-uc-table--cell op-uc-table--cell_head"><p class="op-uc-p">Current Jira Usage</p></th></tr></thead><tbody><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p"><strong>Swimlanes</strong></p></td><td class="op-uc-table--cell"><p class="op-uc-p">Power users all mention this. By epic, assignee, version, custom fields</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Universal among advanced users</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p"><strong>Quick filters for backlog and boards</strong></p></td><td class="op-uc-table--cell"><p class="op-uc-p">Without them, boards/backlogs become unwieldy with 50+ tickets</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Essential for daily work</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p"><strong>Cross-project boards</strong></p></td><td class="op-uc-table--cell"><p class="op-uc-p">BJ: "If I don't set this up, I have to look at five different boards"</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Common in multi-project/team setups</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p"><strong>Status mapping</strong></p></td><td class="op-uc-table--cell"><p class="op-uc-p">Different projects have different status names; need unified column view</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Required for cross-project boards</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p"><strong>Multiple boards per project</strong></p></td><td class="op-uc-table--cell"><p class="op-uc-p">Different views for daily work, planning, management reporting</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Everyone creates 2-5 boards</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p"><strong>Flexible sprint scope</strong></p></td><td class="op-uc-table--cell"><p class="op-uc-p">Teams DO change scope mid-sprint regularly</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Stefan: "We know it's not meant to be done, but we do it"</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p"><strong>Drag-and-drop prioritisation</strong></p></td><td class="op-uc-table--cell"><p class="op-uc-p">Primary method for backlog grooming</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Expected baseline behavior</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p"><strong>Version/release management</strong></p></td><td class="op-uc-table--cell"><p class="op-uc-p">Track progress toward releases, associate tickets with versions; separate version from sprint</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Used for release planning</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p"><strong>Burndown charts</strong></p></td><td class="op-uc-table--cell"><p class="op-uc-p">Standard sprint tracking</p></td><td class="op-uc-table--cell"><p class="op-uc-p">BJ: "Most teams use burndown charts". Used in retrospectives</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p"><strong>Velocity charts</strong></p></td><td class="op-uc-table--cell"><p class="op-uc-p">Track team velocity after each sprint</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Used in retrospectives</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p"><strong>Customizable workflows per project</strong></p></td><td class="op-uc-table--cell"><p class="op-uc-p">Each team needs different statuses</p></td><td class="op-uc-table--cell"><p class="op-uc-p">MVS: "Each person who leads a team decides"</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p"><strong>Epic/Story/Task/Sub-Task hierarchy</strong></p></td><td class="op-uc-table--cell"><p class="op-uc-p">Standard issue type structure</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Universal</p></td></tr></tbody></table></figure>

### Differenciation opportunities (Nice to Have)

These features would give OpenProject competitive advantages where Jira struggles.

<figure class="table op-uc-figure_align-center op-uc-figure"><table class="op-uc-table"><thead class="op-uc-table--head"><tr class="op-uc-table--row"><th class="op-uc-table--cell op-uc-table--cell_head"><p class="op-uc-p">Feature</p></th><th class="op-uc-table--cell op-uc-table--cell_head"><p class="op-uc-p">Jira Pain Point</p></th><th class="op-uc-table--cell op-uc-table--cell_head"><p class="op-uc-p">Opportunity</p></th></tr></thead><tbody><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p"><strong>Time-in-status tracking</strong></p></td><td class="op-uc-table--cell"><p class="op-uc-p">Not available without plugins/complex setup <mention class="mention" data-id="72513" data-type="user" data-text="@Parimal Satyal">@Parimal Satyal</mention> ?</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Defense sector: "I want to see in which state the ticket was for how long (!!!)" - most explicitly requested</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p"><strong>Simpler onboarding</strong></p></td><td class="op-uc-table--cell"><p class="op-uc-p">Nils: "Learning curve is relatively high... need to know JQL"</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Work out-of-box, no query language required</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p"><strong>Smart notification defaults</strong></p></td><td class="op-uc-table--cell"><p class="op-uc-p">BJ: "Jira is very enthusiastic about sending email, you get emails for every little thing"</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Aggregate non-urgent, immediate for SLA-critical</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p"><strong>Board-issue relationship visibility</strong></p></td><td class="op-uc-table--cell"><p class="op-uc-p">Removing an item in one place can cause problems in other views, impossible to know where</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Show which boards use which issues</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p"><strong>Housekeeping dashboard</strong></p></td><td class="op-uc-table--cell"><p class="op-uc-p">Nils: "Thousands of old filters, custom fields... so much tech debt"</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Show unused filters/fields, suggest cleanup</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p"><strong>Built-in portfolio views</strong></p></td><td class="op-uc-table--cell"><p class="op-uc-p">Nils uses expensive plugins (Structure, Big Picture) or Excel</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Native hierarchical cross-project views</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p"><strong>Management-friendly dashboards</strong></p></td><td class="op-uc-table--cell"><p class="op-uc-p">Nils: "I can have exactly the data I want, but not necessarily in the form I want"</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Beautiful, visual, modern presentation</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p"><strong>Better mobile reading</strong></p></td><td class="op-uc-table--cell"><p class="op-uc-p">Almost unused, but opportunity if done well</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Lightweight ticket viewing on-the-go</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p"><strong>Organisational sprint containers</strong></p></td><td class="op-uc-table--cell"><p class="op-uc-p">BJ workaround: uses sprints as workflow stages</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Native support for sprint-like buckets beyond time-boxes</p></td></tr></tbody></table></figure>

### Future Consideration (Lower Priority)

Features mentioned but not critical for initial migration success.

<figure class="table op-uc-figure_align-center op-uc-figure"><table class="op-uc-table"><thead class="op-uc-table--head"><tr class="op-uc-table--row"><th class="op-uc-table--cell op-uc-table--cell_head"><p class="op-uc-p">Feature</p></th><th class="op-uc-table--cell op-uc-table--cell_head"><p class="op-uc-p">Notes</p></th></tr></thead><tbody><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p"><strong>Test management integration</strong></p></td><td class="op-uc-table--cell"><p class="op-uc-p">MVS needs XRay plugin; important for regulatory contexts but niche</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p"><strong>Gamification</strong></p></td><td class="op-uc-table--cell"><p class="op-uc-p">Nice but not essential</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p"><strong>Advanced capacity planning</strong></p></td><td class="op-uc-table--cell"><p class="op-uc-p">Most use external tools; integration opportunity but not blocking</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p"><strong>Automated cleanup suggestions</strong></p></td><td class="op-uc-table--cell"><p class="op-uc-p">AI-powered housekeeping; future enhancement</p></td></tr></tbody></table></figure>

## How Teams Actually Use Sprints

### The reality vs. &quot;by-the-book&quot;

**What Scrum says**: Fixed scope, time-boxed iterations, don&#39;t change mid-sprint (only for an important reason)

**What teams actually do**:

* Move tickets in/out during sprints regularly

* Stefan: &quot;We sometimes even move things out of the sprint... we know it&#39;s not what we&#39;re meant to do, but we do it&quot;

* &quot;Sprint scope was changing in the kanban board&quot;

* Many teams use &quot;Kanban with sprint concepts&quot; - not pure Scrum, but Scrumban


### Sprint as organisational buckets (critical insight)

**BJ&#39;s creative workaround**:

* Creates &quot;sprints&quot; that aren&#39;t really sprints: &quot;To be checked&quot;, &quot;Stories checked&quot;, &quot;Waiting for information&quot;, &quot;Tech debt&quot; (this could be done with labels or workflow status, but often teams do not have access to admins or admins do not want to introduce more workflows)

* Tickets move through multiple &quot;sprints&quot; as they&#39;re refined by different roles

* Only reaches &quot;actual&quot; sprint when ready for development (e.g. design works often in kanban style with a separate board before the development starts)

* Why? Because the actual status workflow is too rigid. Setting up quick filters sometimes difficult.


**What this reveals**: Teams need more flexible organisational primitives beyond just &quot;sprint = 2-week time-box&quot;

### Typical sprint workflow

**Before Sprint (Backlog Management)**:

1. Ideas come in from stakeholders

2. PM/PO creates tickets in backlog

3. Requirements engineering refines / backlog grooming

4. Prioritise by drag-and-drop

5. Estimate (story points, t-shirt sizes, days)

6. Filter by epic/version/label


**Sprint Planning**:

1. Review top of backlog

2. Check team capacity/availability

3. Discuss dependencies and blockers

4. Commit to sprint scope

5. Start sprint


**During Sprint**:

* Engineers self-organise

* Twice-weekly syncs (not daily - &quot;dailies were too often&quot;)

* Drag tickets across board columns

* Status updates automatically

* Use swimlanes and quick filters constantly


**Sprint Review**:

* Review completed work

* Jira prompts: move incomplete to backlog or next sprint

* Check burndown chart

* Most items completed (rare to have many incomplete)


**Retrospective**:

* Review velocity over 6+ months

* Discuss process improvements

* Look at board usage patterns


### Board Configuration Examples

**Simple (3 columns)**:

```text
To Do → In Progress → Done
```

**Standard (4-5 columns)**:

```text
To Do → In Progress → QS/Review → Done
```

**Complex (6+ columns with feedback loops)**:

```text
To Do → In Progress → QS/Review → Done
↓ ↓
[Blocked] [Clarification]
↓ ↓
back to In Progress
```

## Top Pain Points (prioritised)

### 1\. Configuration complexity

* BJ: &quot;Too many options to configure every little thing&quot;

* Nils: &quot;Learning curve is relatively high... need to know JQL&quot;

* &quot;Setting up dashboards was pain in the behind... sometimes you need a developer&quot;


### 2\. Housekeeping &amp; technical debt

* Nils: &quot;Thousands of tickets, old custom fields, old filters... so much tech debt&quot;

* &quot;Sometimes ridiculous. Like when I search for a custom field, there are 10 with the same name&quot;

* Filter proliferation over years


### 3\. Email overload

* BJ: &quot;Jira is very enthusiastic about sending email, you get emails for every little thing&quot;

* Fine for 1-2 projects, overwhelming for multi-project users

* Users added as watchers automatically


### 4\. Inflexibility when locked down

* Cannot modify workflows, &quot;very castrated&quot;

* &quot;Jira admins say it&#39;s not possible to provide different workflows&quot;

* &quot;It&#39;s the opposite of agile&quot;


### 5\. Board management complexity

* Context loss when navigating between boards

* Everyone can create boards → confusion

* BJ: &quot;I always ask teams to create one board that you all share&quot;


## What Jira Does Well

### 1\. Flexibility and customization

* Can create any board, filter, or workflow needed

* Nils: &quot;You can do almost anything with Jira&quot;

* Multiple views of same data


### 2\. Strong integrations

* Git (see individual commits in tickets)

* CI/CD (Jenkins, jFrog)

* Rich plugin marketplace


### 3\. Automatic updates

* Stefan: &quot;User automatically updated when things happen (e.g., when parent task closed, sub-tasks are too)&quot;

* Reduces manual work


### 4\. Industry standard

* Well-understood by developers

* 500-900 user instances common

* Large community and resources


## Summary

### Table Stakes (Must Do First)

Without these, migration is not viable:

* Kanban boards with custom and default columns

* Sprint planning with backlog

* Automated sprint boards

* Swimlanes (by epic, assignee, version, custom fields, labels)

* Quick filters (one-click filtering in board and backlog view)

* Cross-project boards with status mapping

* Multiple boards per project

* Drag-and-drop prioritisation in one page (backlog and multiple sprint buckets)

* Flexible sprint scope changes

* Version/release management

* Burndown &amp; velocity charts

* Customizable workflows per project

* Epic/Story/Task hierarchy


### Competitive Advantages (Do This Better Than Jira)

These features make OpenProject the better choice:

* **Time-in-status tracking** (most requested)

* Simple onboarding (no JQL required)

* Smart notification defaults

* Board-issue relationship visibility

* Housekeeping dashboard

* Built-in portfolio views (no expensive plugins)

* Management-friendly dashboards

* Organisational sprint containers (through good filters)


### Future Excellence

Long-term differentiation:

* Test management integration (native)

* Integrated capacity planning

* Advanced AI-powered suggestions (?)


## Key Quotes

**On Flexibility**:

> &quot;I would love to setup different boards for different use cases, e.g. for marketing, for sales... More flexibility using own workflows&quot; - Defense sector

**On Complexity**:

> &quot;Too many options to configure every little thing. More standardization would be good.&quot; - BJ

> &quot;The learning curve with Jira is relatively high. For some things, you need to know JQL... can be quite hard&quot; - Nils

**On Sprint Reality**:

> &quot;We sometimes even move things out of the sprint during the sprint itself. We know it&#39;s not what we&#39;re meant to do generally, but we do do it.&quot; - Stefan

**On Most Wanted Feature**:

> &quot; I want to see in which state the ticket was for how long (!!!)&quot;&nbsp;

**On Housekeeping**:

> &quot;When I have a Jira instance with 200 projects, then at some point, I have thousands of tickets, old custom fields, old filters... so much tech debt. Then people don&#39;t want to make more effort, have no desire to work with the tool.&quot; - Nils

**On What Works**:

> &quot;What&#39;s nice in Jira is that the user can be automatically updated when things happen (e.g., when a parent task is closed, the sub-tasks are as well)&quot; - Stefan

## Surprising Findings

1. **&quot;Sprints&quot; as organisational buckets**: Teams creatively use sprints as workflow stages, not time-boxes

2. **Everyone breaks the rules**: Regular mid-sprint scope changes despite &quot;knowing better&quot;

3. **Dashboards underused**: Too complex to set up or not visually appealing

4. **Mobile not a priority**: Almost no one uses mobile apps

5. **Email both critical and hated**: Teams rely on it but are overwhelmed

6. **Plugins expensive but necessary**: Structure, Big Picture, XRay should be core features

7. **Excel still relevant**: Used for portfolio management despite Jira&#39;s capabilities


## Universal Patterns

1. **Boards are central** - everyone lives in board views, not issue lists

2. **Swimlanes matter** - all power users mention them

3. **Quick filters essential** - boards become unwieldy without them

4. **Drag-and-drop expected** - baseline behavior for prioritisation

5. **Burndown charts standard** - teams expect these

6. **Git integration valuable** - not critical, but appreciated

7. **Velocity tracking over time** - 6+ month trends matter


## What Nobody Mentioned

* Begin of the deletion Roadmaps (surprisingly absent)

* End of the deletion Dependencies between tickets (rarely discussed)

* Time tracking (actively avoided in some cases)

* Customer feedback integration Begin of the insertion(to be hones, we didn&#39;t evaluate it during the interviews)End of the insertion