Task lifecycle

Apps, modules, submodules and tasks all move through one delivery lifecycle. This page explains each stage, who moves work between them, and what QA Sync does automatically.

Delivery and QA are tracked separately

A task’s workflow stage says where the work is in delivery. Its QA status says what testing found. They influence each other (a passing QA run moves the task forward) but they are separate fields. See QA execution and evidence.

The stages

Stage	Meaning	Progress weight
Draft	A raw idea that still needs scope, owner and planning data.	0 %
Backlog	Refining scope, ownership and release intent before committing.	10 %
Planned	Approved and scheduled; engineering hasn’t started.	20 %
In Progress	Being built.	45 %
In Review	Internal review of code, behaviour and release notes before QA.	60 %
Staging	On a staging build and visible to testers.	75 %
Ready to Ship	Cleared QA; waiting for approvals and the release decision.	90 %
Production	Shipped. Treated as a live record.	100 %
Deprecated	Retired. Kept for history only.	excluded

Who moves work

Developers

Developers move their own assigned tasks with action buttons on My Work:

Backlog ──Commit to Plan──▶ Planned ──Start Work──▶ In Progress ──Send to Review──▶ In Review ──Send to QA──▶ Staging
                                                        ▲                              │                       │
                                                        └──────Return to Build─────────┘                       │
                                                        └──────────────────Resume Build────────────────────────┘

Developers can’t move tasks to Ready to Ship, Production or Deprecated.

Testers (through QA)

Testers don’t move tasks directly. Their QA results do:

QA result	Task moves to
Passed	Ready to Ship
Failed	In Progress
Blocked	stays in Staging

Admins

Admins can set any stage except Production, from the task editor or by dragging cards on the Kanban board, with two guards:

• A task can move to Ready to Ship only if its latest QA result is Passed.
• Production is reached only through promotion on the release board. See Approvals and releases.

Admins also set stages on apps, modules and submodules, optionally cascading the change to their children.

What happens automatically

When…	QA Sync…
A task enters Staging	creates a pending QA run and puts the task in the queue of its tester groups. If the previous run failed or was blocked, the new run is marked as a retest.
A QA run passes	moves the task to Ready to Ship, creates the approvals your rules require, and recalculates readiness.
A QA run fails	moves the task back to In Progress and notifies the developer.
Any task changes stage	recalculates its submodule, module and app status and progress.
An item is promoted	sets it to Production and records who released it and when.
A stage changes	records it in the item’s status history and notifies the item’s owner, reviewer, QA owner and assigned developer.

Legacy task status

Older screens and records also show a simpler task status derived from the stage:

Stage	Legacy status
Draft, Backlog, Planned	Not Started
In Progress, In Review	In Progress
Staging, Ready to Ship	Submitted
Production, Deprecated	Closed

Blockers and dependencies

An item is blocked when it has a blocked reason set or depends on something that isn’t finished.

• Dependencies link an item to another app, module, submodule or task it waits on. A dependency is complete once the item it waits on reaches Ready to Ship, Production or Deprecated.
• The task details show Waiting On (what this item depends on) and Blocking (what depends on it).
• Moving a blocked item asks for confirmation.
• Blocked items and incomplete dependencies lower release readiness.

History

Every item keeps:

• a status history: each stage change, who made it and when;
• an activity timeline: audited changes to the item;
• comments.

Admins see these in the task details; product managers and stakeholders see them on release candidates.