Statuses and Workflows
Status is the heartbeat of a work item. It tells your team what's happening right now — not just whether something is done, but where it is in the process. Lifecycle ships with a comprehensive status system designed around the real complexity of software development.
The Status System
Lifecycle includes 20 statuses organized into 5 groups. Each group represents a phase of work, and each status within the group narrows the picture further.
These are the default statuses. Every board can customize which ones are active — toggle statuses on or off, reorder them within their group, and configure each board independently. You don't have to use all 20. Most teams enable 8–12 statuses that match their actual workflow.
Status Groups
Development (Blue Tones)
The core coding workflow.
| Status | When to use |
|---|---|
| Todo | Ready to be picked up. In scope, in sprint. |
| Working on it | Actively being developed. |
| Code Review | A PR is open and awaiting review. |
| Revision Required | Code review requested changes. Back to the developer. |
Deployment (Purple / Teal Tones)
Tracks movement through your deployment pipeline.
| Status | When to use |
|---|---|
| Pending Predev Deploy | Ready to deploy to the predev/staging environment. |
| Pending Dev Deploy | Ready to deploy to the dev environment. |
| Pending Production | Approved and waiting for production deploy. |
| Production Deployed | Live in production. |
QA (Yellow / Green Tones)
Lifecycle treats QA as a first-class citizen. Tasks have a dedicated QA assignee and QA estimated hours. The QA status group reflects that.
| Status | When to use |
|---|---|
| Pending QA | Development complete, waiting for QA to start. |
| Testing in Progress | QA is actively testing. |
| QA Review | QA has findings or questions for the developer. |
| QA Approved | QA has signed off. Ready to proceed. |
| QA Blocked | QA cannot proceed — environment issue, missing data, dependency. |
Blocked (Red / Orange Tones)
Visibility into why something isn't moving.
| Status | When to use |
|---|---|
| Dependency Block | Blocked by another work item. Link the blocker in the Dependencies section. |
| Pending Meeting | A decision or conversation is needed before work can continue. |
| Pending Translation | Waiting for content or copy in another language. |
| On Hold | Deliberately paused. Not blocked by an external factor — intentionally deferred. |
Tip: Blocked statuses are visibility tools, not blame assignments. When an item is blocked, the team knows to either help unblock it or update the timeline. Make it easy to mark things blocked — you'll get a clearer picture of where slowdowns actually happen.
Terminal (Gray / Green)
Work is done — one way or another.
| Status | When to use |
|---|---|
| Done | Complete. Accepted. Shipped. |
| Not a Bug | A bug report that turned out not to be a bug after investigation. |
| Cancelled | Work was abandoned. Keep the item for context; don't delete it. |
Items in terminal statuses are considered resolved and are typically excluded from active views by default.
Status and Levels
Not every status applies at every level.
- Stories use a focused subset: planning and progress statuses. The detailed QA and deployment statuses live at the task level where the actual work happens.
- Tasks use the full status set — including QA, deployment, and blocked statuses.
- Sub-tasks use a simplified set: Todo, Working on it, Done, and a handful of blocked statuses.
How Statuses Drive Views
- Kanban view: Each status is a column. Items flow left to right as they progress.
- Table view (grouped by status): Each status is a collapsible group. See all items in each status at a glance.
- Active sprint view: Filters to in-progress and blocked statuses by default. Terminal statuses are collapsed or hidden.
Status Changes and Automation
Every status change is recorded in the item's Activity tab with a timestamp and the user who made the change.
Status changes can also trigger:
- Activity log entries — always
- Notifications — if team members are watching the item or are assignees
- Automations — if configured (e.g., "When status changes to QA Approved, assign to deployer")
Customizing Statuses Per Board
Every board has its own independent status configuration — changes on one board don't affect others. You can:
- Enable or disable statuses — remove statuses your team never uses to reduce noise
- Reorder statuses within their group — match your team's exact flow
- Change colors — adapt visual language to your team's conventions
How to Customize
Open your board → click the gear icon → Statuses tab.
- Toggle statuses on or off with the enable switch
- Drag to reorder within each group
- Click the color swatch to change a status's color
Tip: When onboarding a new board, start with fewer statuses — maybe just Todo, Working on it, Code Review, Pending QA, QA Approved, Done, and Cancelled. You can always add more as the team identifies gaps. You don't have to use all 20; most teams find 8–12 statuses covers their entire workflow.
Status vs. Pipeline vs. Stage
Three fields track progress in different dimensions. They're designed to work together, not replace each other.
| Field | Answers | Applies to |
|---|---|---|
| Status | What's happening with this item right now? | All levels |
| Pipeline | Where is this story in the planning process? | Stories (R&D boards) |
| Stage | Which environment is this task targeting? | Tasks (R&D boards) |
A story can be in the Backlog pipeline (planning phase), Todo status (not started yet), and have tasks in the Predev stage (early environment). These three fields tell a complete story.