---
title: Project Management
---

<head>
    <title>Project Management</title>
    <meta name="description" content="Learn about Jan's project management approach, including roadmap management, organization of epics and tasks, and Kanban board usage."/>
    <meta name="keywords" content="Jan AI, project management, roadmap, epics, tasks, Kanban board"/>
    <meta property="og:title" content="Project Management"/>
    <meta property="og:description" content="Learn about Jan's project management approach, including roadmap management, organization of epics and tasks, and Kanban board usage."/>
    <meta property="og:url" content="https://jan.ai/project-management"/>
    <meta name="twitter:card" content="summary"/>
    <meta name="twitter:title" content="Project Management"/>
    <meta name="twitter:description" content="Learn about Jan's project management approach, including roadmap management, organization of epics and tasks, and Kanban board usage."/>
</head>

We use the [Jan Monorepo Project](https://github.com/orgs/janhq/projects/5) in Github to manage our roadmap and sprint Kanbans.

As much as possible, everyone owns their respective `epics` and `tasks`.

:::tip
We aim for a `loosely coupled, but tightly aligned` autonomous culture.
:::

## Quicklinks

- [High-level roadmap](https://github.com/orgs/janhq/projects/5/views/16): view used at at strategic level, for team wide alignment. Start & end dates reflect engineering implementation cycles. Typically product & design work preceeds these timelines.
- [Standup Kanban](https://github.com/orgs/janhq/projects/5/views/25): view used during daily standup. Sprints should be up to date.

## Organization

[`Roadmap Labels`](https://github.com/janhq/jan/labels?q=roadmap)

- `Roadmap Labels` tag large, long-term, & strategic projects that can span multiple teams and multiple sprints
- Example label: `roadmap: Jan has Mobile`
- `Roadmaps` contain `epics`

[`Epics`](https://github.com/janhq/jan/issues?q=is%3Aissue+is%3Aopen+label%3A%22type%3A+epic%22)

- `Epics` track large stories that span 1-2 weeks, and it outlines specs, architecture decisions, designs
- `Epics` contain `tasks`
- `Epics` should always have 1 owner

[`Milestones`](https://github.com/janhq/jan/milestones)

- `Milestones` track release versions. We use [semantic versioning](https://semver.org/)
- `Milestones` span ~2 weeks and have deadlines
- `Milestones` usually fit within 2-week sprint cycles

[`Tasks`](https://github.com/janhq/jan/issues)

- Tasks are individual issues (feats, bugs, chores) that can be completed within a few days
- Tasks, except for critical bugs, should always belong to an `epic` (and thus fit into our roadmap)
- Tasks are usually named per [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/#summary)
- Tasks should always have 1 owner

We aim to always sprint on `tasks` that are a part of the [current roadmap](https://github.com/orgs/janhq/projects/5/views/16).

## Kanban

- `no status`: issues that need to be triaged (needs an owner, ETA)
- `icebox`: issues you don't plan to tackle yet
- `planned`: issues you plan to tackle this week
- `in-progress`: in progress
- `in-review`: pending PR or blocked by something
- `done`: done

## Triage SOP

- `Urgent bugs`: assign to an owner (or @engineers if you are not sure) && tag the current `sprint` & `milestone`
- `All else`: assign the correct roadmap `label(s)` and owner (if any)

#### Request for help

As a result, our feature prioritization can feel a bit black box at times.

We'd appreciate high quality insights and volunteers for user interviews through [Discord](https://discord.gg/af6SaTdzpx) and [Github](https://github.com/janhq).
