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.