3.6 KiB
3.6 KiB
| title |
|---|
| Project Management |
We use the Jan Monorepo Project 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: 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: view used during daily standup. Sprints should be up to date.
Organization
Roadmap Labelstag large, long-term, & strategic projects that can span multiple teams and multiple sprints- Example label:
roadmap: Jan has Mobile Roadmapscontainepics
Epicstrack large stories that span 1-2 weeks, and it outlines specs, architecture decisions, designsEpicscontaintasksEpicsshould always have 1 owner
Milestonestrack release versions. We use semantic versioningMilestonesspan ~2 weeks and have deadlinesMilestonesusually fit within 2-week sprint cycles
- 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
- Tasks should always have 1 owner
We aim to always sprint on tasks that are a part of the current roadmap.
Kanban
no status: issues that need to be triaged (needs an owner, ETA)icebox: issues you don't plan to tackle yetplanned: issues you plan to tackle this weekin-progress: in progressin-review: pending PR or blocked by somethingdone: done
Triage SOP
Urgent bugs: assign to an owner (or @engineers if you are not sure) && tag the currentsprint&milestoneAll else: assign the correct roadmaplabel(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 and Github.