1 Work item state basics

1.1 Definition and purpose of work item states

Work item states are predefined labels that describe the current standing of a unit of work—commonly a ticket, story, task, or issue—during its lifecycle. Teams use them to align on what “progress” means at a given moment, reduce ambiguity in communication, and provide a consistent basis for planning, coordination, and reporting. A state model typically pairs each state with rules about when work can enter or leave it, who is expected to act, and what conditions must be satisfied.

In practice, work item states support both operational use (routing tasks to the right person or team, triggering handoffs, coordinating review steps) and analytical use (measuring how long work spends in each stage and identifying delays).

1.2 State vs. status vs. phase (terminology)

Related terms are often used interchangeably, but they may refer to different levels of abstraction:

  • State usually denotes the immediate lifecycle position within a defined workflow, governed by explicit transition rules.
  • Status can be a broader term for the current condition of a work item; some systems use “status” as the name of the state itself, while others use it for additional qualifiers (e.g., priority, risk, or readiness).
  • Phase typically describes a higher-level grouping, such as “active work” or “review,” which may encompass multiple states.

A clear documentation approach often maps these terms so that teams do not interpret the workflow inconsistently—for example, treating a “phase” as if it were the same as a “state” with strict transition constraints.

1.3 Why state models matter for coordination

State models reduce coordination costs by making the workflow legible. When states are standardized, teams can rely on shared expectations such as:

  • Allowed next steps: stakeholders can anticipate what actions are valid from a given state.
  • Ownership signals: the state communicates whether work is under construction, waiting for someone else, or pending validation.
  • Handoff clarity: transitions create explicit boundaries between responsibilities (e.g., developer-to-reviewer, reviewer-to-author, author-to-tester).
  • Traceability: consistent definitions make it easier to follow work history for audit, debugging, and reporting.

Without a well-defined state model, teams often fall back on informal messaging, which can lead to lost context, stalled items, and misleading dashboards.

2 Core lifecycle phases

2.1 Intake and creation

The intake phase covers how a work item enters the system and becomes ready for execution. It often includes initial clarification, triage, and assignment decisions.

2.1.1 New and ready-to-triage

New items typically represent work discovered or proposed but not yet fully understood. “Ready-to-triage” (or an equivalent state) indicates that basic information exists to support prioritization and scoping.

2.1.1.1 Triage criteria and metadata completeness

Triage criteria define what must be present before work is considered suitable for routing. Typical requirements include a clear description, acceptance expectations (or a reference to them), relevant links or artifacts, and enough context to estimate size or impact. Metadata completeness may also involve correct categorization, component tagging, or an initial assignee/owner field when routing decisions depend on it.

Consistent triage reduces downstream rework by preventing items with missing requirements from entering active stages prematurely.

2.2 Active work

Active work includes the creation and refinement steps where the deliverable is produced. This phase can be subdivided into assignment and waiting behaviors.

2.2.1 In progress and assigned

An “in progress” state generally signals that work is underway and actively being worked on. “Assigned” emphasizes responsibility: a named owner or team is expected to advance the item. Some models separate these ideas (e.g., “assigned” without active coding) to better represent waiting for resources or environment readiness.

A robust model ties “in progress” to observable activity, such as having started development, drafting changes, or updating the work item with progress notes.

2.2.2 Blocked and waiting

Blocked states represent work that cannot proceed due to an external constraint. Examples include missing dependencies, approvals from another team, environment failures, or unresolved questions. “Waiting” can be used when the dependency is not strictly blocked (for instance, awaiting a scheduled review window or a response from a stakeholder).

These states are valuable because they separate lack of progress from lack of action. Teams can filter reports to distinguish stalled items due to impediments from those that are simply neglected.

2.3 Review and validation

Review and validation states cover peer examination, correctness checks, and preparation for release or acceptance. This stage often includes iterative loops.

2.3.1 In review

“In review” denotes that the work product is ready for examination by another party, such as a peer developer, a reviewer, or a product approver. The key idea is that execution responsibility transitions: the author or implementer pauses (or reduces activity) while review feedback is sought.

Some workflows use additional qualifiers to differentiate types of review (design review vs. code review) or readiness signals (review requested vs. review scheduled).

2.3.2 Changes requested and rework

When reviewers identify gaps, they may request modifications. A “changes requested” state indicates that feedback has been received and the item is back in an editing cycle. Rework states are often explicit to prevent the item from being treated as still “in review” while changes are being made.

Clear rework rules support repeatable iteration: the work returns to active implementation, and then re-enters review when the required adjustments are complete.

2.4 Completion

Completion indicates that the work item has reached an end condition. The model distinguishes successful closure from other terminal outcomes.

2.4.1 Testing/verification

Testing and verification states represent that the deliverable is being validated against requirements. This can include unit tests, integration tests, staging checks, or user acceptance verification. Separating verification from completion helps prevent premature closure and makes it easier to diagnose issues that emerge late in the pipeline.

Models often distinguish between “ready for testing,” “testing in progress,” and “verification passed” (though the exact structure varies).

2.4.2 Done/closed and outcomes

A “done” or “closed” terminal state indicates acceptance according to the organization’s criteria. Outcomes typically include confirmation that acceptance conditions are met, relevant test results, documentation updates, and any release notes references when applicable.

To preserve interpretability, completion should capture why the work is considered complete. Some organizations require links to evidence artifacts (test runs, approvals, demos) to support later auditing.

2.4.3 Cancelled/invalid and disposition rules

Not all items reach productive completion. “Cancelled” and “invalid” terminal states cover work withdrawn due to changing priorities, duplication, or failure to meet feasibility conditions. Disposition rules specify what must be recorded when cancellation occurs, such as a reason category, a link to a decision record, and whether there is an alternative plan.

Clear disposition rules prevent abandoned work from being mislabeled as complete or left in limbo.

3 Workflow mechanics

3.1 Allowed transitions and transition rules

Allowed transitions specify which state changes are valid. Transition rules may include prerequisites such as required fields, evidence attachments, review approvals, or specific user roles. Together, these rules enforce consistency and prevent arbitrary movement that undermines reporting quality.

A common practice is to define transitions at a manageable level of specificity: for instance, allowing “in review” to transition to either “changes requested” or “done,” while disallowing direct transitions from “new” to “done” without passing through defined validation steps.

3.2 Entry and exit criteria

Entry criteria describe conditions that must be true when a work item enters a state. Exit criteria define what must be satisfied before leaving it. Together, they define operational meaning.

For example, entering “in review” might require that changes are pushed to a shared branch and that the acceptance criteria are addressed; leaving “testing/verification” could require a passing test suite or sign-off from designated stakeholders. When criteria are measurable, state changes become more reliable.

3.3 State ownership and handoffs

Ownership defines responsibility while a work item resides in a state. Handoffs occur when ownership changes due to a transition—such as from implementation to review.

State ownership often includes:

  • Primary responsible role (author, reviewer, QA, product)
  • Service expectations (e.g., response time targets)
  • Communication channel (which team is notified on entry/exit)

When ownership is implicit or poorly documented, states can become less informative and more prone to neglect.

3.4 Automated vs. manual state changes

Workflows may change states automatically based on events (e.g., test pipeline completion) or manually based on human judgment (e.g., review approval). Many systems blend both.

Automated transitions can improve accuracy and reduce latency, but they require careful design to avoid premature moves caused by partial signals. Manual transitions provide flexibility, but can introduce inconsistency if reviewers interpret criteria differently. A well-designed model identifies which transitions can be automated safely and which require explicit human confirmation.

3.5 Parallel streams (e.g., development and QA)

Parallel streams allow parts of the lifecycle to proceed concurrently. For example, development might continue while QA prepares test plans, or documentation can be updated during implementation.

State models that support parallelism typically avoid forcing a single linear narrative. Instead, they may:

  • Use separate state fields for different streams (implementation state vs. QA state)
  • Represent composite readiness (e.g., “ready for verification” only when both development and prerequisites are complete)
  • Employ additional states that capture coordination points

The central goal is to prevent misleading status where one stream is complete but another is not.

4 State design considerations

4.1 Granularity: too few vs. too many states

The number of states affects both clarity and overhead. Too few states can collapse meaningful distinctions, making it difficult to locate where delays occur. Too many states can create cognitive load, increase the chance of misclassification, and complicate reporting.

A practical approach is to select states that correspond to real decision points or handoffs. Each state should either represent a meaningful responsibility boundary or encode a measurable condition in the workflow.

4.2 Naming conventions and clarity

State names should be unambiguous and action-oriented. Clear naming improves communication and reduces the temptation to use informal explanations in comments.

Conventions may include:

  • Consistent verbs (e.g., “in review,” “waiting,” “testing”)
  • Avoiding overlapping terms that look similar but mean different things
  • Using established terminology aligned with team roles (review, verification, approval)

Consistency is especially important when multiple teams or products share a tracking system.

4.3 Handling uncertainty and partial progress

Work items often begin without full context. A state model can address this by including states for uncertainty and partial readiness, rather than forcing work into “in progress” prematurely.

Common patterns include:

  • A triage-ready state that indicates minimum information is present
  • A waiting state for clarified requirements
  • Explicit “changes requested” to represent partial completion after review

By representing partial progress explicitly, teams reduce frustration caused by ambiguous status and improve the quality of metrics.

4.4 Backward compatibility and migrations

Over time, organizations refine their workflow and revise the state model. Migrations are needed when new states are introduced or old ones are merged.

Backward compatibility concerns include:

  • Mapping historical state histories to new definitions
  • Deciding whether to preserve original semantics for reporting
  • Handling work items created under an old workflow

A migration plan often defines deterministic mapping rules and a strategy for dashboards so that trends remain interpretable rather than suddenly distorted.

5 Metrics and reporting with states

5.1 Cycle time and lead time by state

State models enable timing analytics by tracking when items enter and exit states. Cycle time typically measures time spent from a starting point (often “in progress” or “ready for execution”) to completion, while lead time may measure from intake or creation through completion.

Segmenting by state helps pinpoint where time accumulates. For instance, a long duration in “blocked” may indicate dependency issues, while extended time in “in review” can signal reviewer capacity constraints.

5.2 Work-in-progress (WIP) limits

WIP limits restrict how many items a team can actively manage in certain states. States often define the boundary for WIP measurement, such as limiting the number of items allowed to be simultaneously “in progress” or “in review.”

Properly configured WIP limits can reduce multitasking, smooth flow, and highlight bottlenecks when limits are frequently reached.

5.3 Throughput and aging indicators

Throughput measures the rate at which work items complete over time, while aging indicators highlight how long items have remained in their current state.

A state model improves the usefulness of these indicators by providing consistent definitions. Aging dashboards can also be tailored by state: for example, aging in “in review” may require escalating reviewer bottlenecks, whereas aging in “blocked” may call for dependency resolution.

5.4 Cumulative flow and bottleneck detection

Cumulative flow diagrams show the distribution of work across states over time. They help visualize whether the workflow is expanding or compressing, whether states accumulate backlog, and where the largest “layer” of work is forming.

Bottlenecks are often associated with states where work accumulates faster than it moves forward—commonly due to limited capacity, unclear criteria, or recurring rework loops.

6 Governance and quality practices

6.1 State definitions as documentation

State models function best when definitions are treated as living documentation. Each state should have a clear description, entry/exit criteria, and examples of appropriate usage.

When definitions remain informal, teams may interpret them differently, leading to inconsistent tracking that undermines reporting and coordination. Documentation also supports onboarding and reduces the likelihood that “tribal knowledge” replaces workflow rules.

6.2 Regular workflow audits

Audits examine whether state usage aligns with intended semantics. Auditing can include sampling work items for correct transitions, reviewing outliers (e.g., items stuck in a state for excessive durations), and validating whether transition rules are being bypassed.

A useful audit approach includes both compliance checks (did the item follow allowed transitions?) and effectiveness checks (does the state model reveal meaningful delays or is it too coarse?).

6.3 Training and onboarding for consistent usage

Teams often require training to use states consistently, especially when workflows include nuanced distinctions like “blocked” vs. “waiting” or “in progress” vs. “assigned.”

Onboarding materials typically cover:

  • How to choose the next state
  • What evidence is required for entry/exit
  • How to communicate during handoffs

Consistency improves both day-to-day coordination and the accuracy of derived metrics.

6.4 Common anti-patterns (e.g., “In progress” never leaving)

Anti-patterns reduce the informational value of states. Common examples include:

  • “In progress” never leaving: work items remain active even when blocked or awaiting review, obscuring true bottlenecks.
  • Premature completion: items enter “done” without meeting verification expectations, creating downstream defects or confusion.
  • State inflation: using extra states inconsistently or inventing unofficial sub-states through comments.
  • Missing transition ownership: allowing items to transition without assigning responsibility, leading to silent stalls.

Mitigation typically involves tightening entry/exit criteria, improving training, and enabling automated checks that enforce required fields or transitions.

7 Tooling and implementation patterns

Many issue tracking or project management platforms support configurable workflows. Conceptually, state models map to:

  • A list of states (the workflow)
  • Transition permissions (who can move what to where)
  • Required fields or conditions per transition
  • Hooks for notifications or integrations

Even when products use different terminology (status, stage, workflow step), the underlying concepts—explicit transitions and standardized semantics—remain the same.

7.2 Custom workflows and configuration

Organizations tailor state models to match their delivery process. Configuration often includes role-based permissions, required fields, and custom transition conditions.

Customization should balance flexibility with reporting integrity. If teams frequently adjust the workflow without a governance process, metrics may lose continuity across time.

7.3 Webhooks, events, and audit trails

Event mechanisms such as webhooks can notify external systems when a state changes. Audit trails record who changed a state, when it happened, and what changed, which supports debugging and accountability.

Good implementations ensure:

  • Reliable delivery of events
  • Idempotent processing in downstream systems
  • Retention policies that allow historical analysis

Audit trails also help detect misuse, such as back-and-forth state switching that bypasses criteria.

7.4 Integration with CI/CD and test systems

Modern workflows often integrate state transitions with automated pipelines. Examples include:

  • Moving an item to verification once a build is produced
  • Transitioning to done after tests pass and artifacts are published
  • Switching to blocked when pipeline failures indicate missing dependencies

Integration quality depends on defining clear signals (what constitutes “tests complete” and “verification passed”) and handling flaky tests or partial results without creating misleading state changes.

8 Examples and templates

8.1 Minimal three-state model

A minimal model can be useful for small teams or lightweight work. One common structure is:

  • New: item exists but is not yet ready for execution
  • In progress: implementation is underway
  • Done: work is accepted and complete

While this model is easy to maintain, it provides limited diagnostic power. It can also blur the difference between actively building, waiting for review, and performing verification.

8.2 Typical five-to-seven-state software workflow

A typical software-oriented workflow may include:

  • New
  • Ready for triage
  • In progress
  • In review
  • Changes requested (or “Rework”)
  • Testing/verification
  • Done and/or Cancelled

This structure supports iteration and provides clearer insight into where delays occur, especially when review and testing are separated from implementation.

8.3 State model for non-software work (lightweight adaptation)

Non-software processes can adopt the same principles while adjusting the meaning of states. A lightweight adaptation might use:

  • Intake/New
  • Ready for execution
  • In progress (doing the work)
  • Review/approval (validation by stakeholders)
  • Blocked/Waiting (dependencies)
  • Completed
  • Cancelled/Invalid

The key is to preserve entry/exit criteria that match how work is actually accepted in that domain—for instance, approvals might be a signed form, a manager sign-off, or a client confirmation.

8.4 Example transition matrix template

A transition matrix lists valid “from” and “to” state pairs, often indicating conditions or required approvals. A template can be represented as a table with columns such as:

  • From state
  • To state
  • Required role/permission
  • Required evidence or fields
  • Automation trigger (if any)
  • Notes (e.g., whether the transition is reversible)

An example layout might include rows for transitions like:

  • New → Ready for triage
  • Ready for triage → In progress
  • In progress → In review
  • In review → Changes requested
  • In review → Testing/verification
  • Testing/verification → Done
  • Any non-terminal state → Cancelled (with reason required)

This structure helps teams confirm that the workflow is both enforceable and understandable.