Overview
A cycle is a time-boxed iteration within a board. Think of it as a sprint, milestone, release, phase, or iteration — the terminology is flexible. Each cycle has a start date, end date, and its own budget in hours.
Every board must have at least one cycle. Items are planned into cycles as cards, assigned to resources or job roles, and tracked through color-coded statuses.
Cycle settings
Each cycle is configured with the following properties:
| Property | Description |
|---|
| Name | Display name for the cycle |
| Description | Rich-text summary of the cycle’s goals |
| Parent cycle | Optional parent for hierarchical organization |
| Budget | Hours allocated to this cycle |
| Start | Cycle start date |
| Finish | Cycle end date |
| Locked | Prevents changes to the cycle’s data |
| Closed | Marks the cycle as complete and finalizes time entries |
| Deleted | Removes the cycle from the system |
Parent/child cycles
Cycles can be organized into parent/child hierarchies. A parent cycle acts as a grouping — for example, a “Research” parent might contain “Cycle 2” and “Research Extended” as children.
Use parent cycles to model multi-phase work within a single board. For example, a board representing a product launch might have parent cycles for “Research”, “Design”, and “Build”, each containing more granular child cycles.
Budget
Each cycle has its own budget in hours, separate from the board budget. The cycle budget represents the hours allocated specifically to that iteration.
The cycle view displays budget alongside actuals so you can track progress:
- Budget — allocated hours for the cycle
- Estimated — total estimated effort across all planned items
- Logged — actual hours logged by resources
Planning items into cycles
You plan items into a cycle by assigning them to a board and cycle. Each planned item becomes a card on the cycle view. Items can only be planned from containers approved on the board.
Assigning to a resource
You can assign a planned item to a specific person from the board’s approved resource list. This records who is responsible for delivering the work in that cycle.
Assigning to a job role
Alternatively, you can assign an item to a job role placeholder — for example, “Senior Developer” or “QA Engineer.” This is useful for capacity planning before specific people are assigned, letting you model the work needed without committing individuals.
The cycle view provides Resource and Job Role filter dropdowns to help you focus on a specific person’s or role’s workload.
Card colors
Cards are color-coded by status for an at-a-glance view of where work stands:
| Color | Status |
|---|
| Gray | Open |
| Green | Working |
| Red | Review |
| Amber | Invalid |
| Blue | Closed |
Status zones
Items within a cycle are grouped into four status zones:
| Zone | Description |
|---|
| In Progress | Items actively being worked on |
| Open | Items ready for work but not yet started |
| Closed | Items that have been completed |
| Blocked | Items that cannot proceed due to dependencies or issues |
Time approval by zone
Each zone has a Time button that opens a time entry review for all items in that zone. This lets board managers approve or reject time entries in bulk by work status rather than reviewing each item individually.
The time review panel shows entries grouped by item, with each entry displaying:
- Duration — hours and minutes logged
- Time type — the category of work (Internal, Development, QA, R&D, PMO, Sales, Marketing)
- Status — whether the entry is approved or pending
- Description — what the work involved
- Person and date — who logged the time and when
You can approve or reject individual entries using the thumbs up/down controls, or use Approve to approve all entries in the zone at once.
Review time entries by zone before closing a cycle. The In Progress zone typically has the most entries to review, while Blocked items may have time logged against investigation work.
Closing a cycle
Closing a cycle is a significant, irreversible action that finalizes all time data for the iteration.
What happens when you close
- All time entries for items in the cycle are automatically approved — including any entries previously marked as rejected
- No further time can be logged against items in the cycle
- Approved time flows into billing and profitability reports
The close action requires confirmation: you must type YES in a confirmation dialog to proceed.
Closing a cycle auto-approves all time entries, including rejected ones. Review and resolve any rejected entries before closing if you do not want them approved.
Locked vs. closed
These are distinct states with different effects:
| State | Effect |
|---|
| Locked | Prevents changes to the cycle’s items — no additions, edits, or removals. Time entries can still be logged and reviewed. |
| Closed | Finalizes the cycle completely — all time entries are approved and no further time can be logged. |
Board and cycle hierarchy
Board (e.g., "Dotcom Refresh")
├── Budget: 300 hours
├── Items: 63
├── Containers: [Next-gen App, Support Desk]
├── Resources: [Developers, Support]
│
├── Research (parent cycle)
│ ├── Budget: 10h | Estimated: 159h 5m | Logged: 342h 51m
│ ├── Dates: 12/02/2026 – 22/02/2026
│ ├── Items: 26
│ │
│ ├── Cycle 2 (child) — 0 items
│ └── Research Extended (child) — 0 items
│
├── Design — 20 items
└── Build — 17 items
