Modules
A module is a deliverable: "Checkout redesign", "iOS launch", "Q3 data migration". It groups the work items that make up one meaningful thing, gives it a lead and a status, and tracks it to completion — however many sprints that takes.
Modules are switched on per project (Project settings → Features → Modules).
What you can do
- Group work items into a named deliverable.
- Give it a lead, a team, a target date and a status.
- Track completion with a burn-down/burn-up chart and a breakdown by person, label and state.
- Keep a module running across many cycles.
- Add links (specs, designs) to the module itself.
Modules vs cycles
This is the only thing you really need to understand, so it goes first.
| Cycle | Module | |
|---|---|---|
| Answers | When? | What? |
| Shape | A date range | A named deliverable |
| Lifetime | Fixed, short, repeating | As long as it takes |
| How many at once | One active per project | As many as you need |
| Per work item | One cycle | One or more modules |
| Ends when | The end date passes | You mark it Completed |
Rule of thumb: if you'd describe it with a date range, it's a cycle. If you'd describe it with a noun, it's a module.
They're designed to be used together. A work item can be in Sprint 12 and in the Checkout redesign module. A healthy sprint pulls work from several modules — that's how you see, at a glance, how much of this fortnight went to the launch and how much went to keeping the lights on.
Getting started
Create a module
- Open a project and click Modules in the sidebar (shortcut G M).
- Click the create button, or press N then M.
- Fill in:
- Name — the deliverable, as a noun.
- Description — what "done" means. Worth writing.
- Start date and target date — optional, but they're what makes the progress chart meaningful.
- Status — Backlog, Planned, In progress, Paused, Completed or Cancelled. New modules start in Backlog.
- Lead — the one person accountable.
- Members — who's working on it.
- Create it.
📷 Screenshot: the create-module dialog with name, date range, status, lead and members.
Add work items
Open the module. From the empty state you can either create work items directly in it, or add existing work items — a search dialog over the project, where you can select many at once.
You can also set an item's Modules property from its own sidebar, or drag cards onto modules when a board is grouped by module.
Unlike cycles, a work item can belong to several modules at once. A shared API change can legitimately be part of both the iOS launch and the web redesign.
Status
A module's status is set by hand — it doesn't follow dates the way a cycle's does.
| Status | Use it for |
|---|---|
| Backlog | Agreed in principle, not planned |
| Planned | Scoped and scheduled, not started |
| In progress | Being worked on now |
| Paused | Deliberately stopped — the honest one |
| Completed | Shipped |
| Cancelled | Abandoned |
Paused is the useful one. Work that has quietly stalled is the most expensive thing on a board; a module you can point at and say "we stopped this on purpose" is worth a lot.
Tracking progress
Open a module and look at the sidebar panel:
- A progress chart — burn-down or burn-up against the module's date range.
- A breakdown of completion by assignee, by label and by state.
As with cycles, progress is counted by state group — anything in a completed state counts as done. See Projects → States.
The Modules list shows every module with its status, lead, dates and a completion bar, so you can see the shape of the whole project in one screen. There's also a timeline layout for modules, which lays them out against the calendar.
📷 Screenshot: the modules list showing several modules with status, lead, dates and completion bars.
You can attach links to a module — a spec, a design file, a tracking doc — so the context lives with the deliverable rather than in someone's bookmarks.
Completing a module
Set the status to Completed when the deliverable ships. Unlike a cycle, nothing is forced on you: there's no transfer step, because a module has no deadline to fall off.
If a module still has open work items when you complete it, that's a signal — go and look at them. Either they matter (so the module isn't done) or they don't (so close them).
Completed modules can be archived from the module's context menu; they move to the project's Archives → Modules and can be restored.
Tips
- One lead per module. Two accountable people means none.
- Write the description as a definition of done. Six weeks in, it's the only thing that settles arguments.
- Group your board by module for a quick read on where the sprint's effort is actually going.
- Don't create a module for every feature. A module should be worth reporting on — if nobody would ask "how's it going?", it's just a label.
- Use a module's target date even when it's a guess. A chart with no reference line tells you nothing.
Limits & good to know
- Modules are per-project. There is no cross-project module — for a deliverable spanning several projects, you'll need one module in each.
- Module status is manual. Nothing moves it for you, and a stale "In progress" is on you.
- A module has no built-in scope lock, so it will happily absorb new work items — which is exactly why you check the burn-up chart, not just the burn-down.
- Progress depends on your state groups being correct.
Related
- Cycles — the when to a module's what.
- Core concepts
- Work items
- Projects — turning Modules on.