Workflow #

In software engineering, a workflow is often thought of as just a sequence of steps: backlog → development → testing → release. But such a narrow definition hides something far more important — a workflow is how the team thinks and coordinates to turn ideas into real value for users. Teams with good workflows not only move faster, they also redo wrong work less often. This article covers what a workflow is in the Scrum context, why it matters, and how to design one that’s healthy and adaptive.

What Is a Workflow in Software Engineering? #

A workflow is the work-flow pattern a team agrees on to turn requirements into ready-to-use software. But in practice, a workflow covers more than just a sequence of stages:

• How an idea or need enters the system and gets prioritized
• When and how a developer starts working on a task
• How code changes are tested, reviewed, and eventually released
• How user feedback returns to the team and affects the next priorities

Within the Scrum framework, a workflow lives between the official Scrum artifacts and events:

flowchart LR
    PB[Product Backlog] --> SP[Sprint Planning]
    SP --> EX[Sprint Execution]
    EX --> SR[Sprint Review]
    SR --> RT[Retrospective]
    RT -->|priorities updated| PB

    EX -.->|bugs, internal feedback| EX
    SR -.->|stakeholder feedback| PB

A workflow isn’t Scrum itself — it’s how the engineering team leverages Scrum so daily work stays structured without losing the flexibility to adapt.

Workflow ≠ Rigid Process #

The most common mistake in designing workflows is treating them as permanent rules that must never be touched. A healthy workflow is the opposite: it evolves as the team and product grow.

// ANTI-PATTERN: workflow as fixed rules that can't change

"Our process was set at the start of the year, just follow it"
→ The team works around the process, not with it
→ Bottlenecks are visible but nobody dares to change
→ Retrospectives discuss the same problems sprint after sprint

// CORRECT: workflow as a living agreement, continuously evaluated

"We follow this workflow as the default, but we evaluate it every sprint"
→ The team feels ownership of the workflow
→ Small changes are made when problem signals appear
→ The workflow reflects the team's actual condition

There’s a spectrum between too rigid and too loose — both are equally dangerous:

A healthy workflow sits in the middle: structured enough to be predictable, flexible enough to be adaptive.

Why Workflows Matter to Engineering Teams #

Before designing a workflow, it’s important to understand why it matters. A workflow isn’t an administrative ritual — it provides concrete value the team feels daily.

Creating Predictability #

One of the questions stakeholders ask most often is: “When will this feature be done?” Without a consistent workflow, the answer is always a guess. With a good workflow, the team can answer based on data:

Without a clear workflow:
  Stakeholder: "When will the new checkout feature be ready?"
  Developer: "Maybe... two weeks? Depends on testing."
  → No reliable basis for estimation

With a consistent workflow:
  Stakeholder: "When will the new checkout feature be ready?"
  PM: "The story is in the sprint; based on our historical velocity,
       we estimate it's ready to demo at next week's Sprint Review."
  → Data-based estimation, not intuition

Predictability isn’t about always-accurate estimates — it’s about a work flow consistent enough that patterns can be observed and used as a planning basis.

Reducing Developer Cognitive Load #

Without a clear workflow, developers spend mental energy on decisions that the process should already answer:

// Questions that arise without a clear workflow

"Is this story ready to work on, or does it still need PO clarification?"

"Should I wait for testing to finish before starting the next story?"

"Do I need approval before deploying to staging?"

"Who should I ask for a code review?"

// Questions that DON'T need re-answering when the workflow is clear
→ The DoR explains when a story is ready to work on
→ The board shows every task's status in real time
→ The DoD explains when a story is truly Done
→ The workflow determines who reviews and what the turnaround is

Every small decision eliminated by a workflow is mental energy left over for solving the actual technical problems.

Maintaining Quality Without Slowing the Team Down #

Without a workflow, quality often becomes a separate phase at the end — “QA will check it later”. This is expensive because bugs are found too late. A mature workflow integrates quality control into the flow, not as a standalone checkpoint:

flowchart LR
    subgraph ImmatureWorkflow
        A1[Dev finishes] --> B1[Send to QA]
        B1 --> C1[Bug found]
        C1 --> D1[Back to Dev]
        D1 --> E1[QA again]
    end

    subgraph MatureWorkflow
        A2[Dev finishes] --> B2[Self-test + unit test]
        B2 --> C2[Code review]
        C2 --> D2[QA — acceptance criteria]
        D2 --> E2[Done]
    end

A mature workflow isn’t slower — it avoids the rework iterations that are actually far more expensive.

Being a Team Communication Medium #

A documented, visualized workflow becomes a shared language between all roles:

Between Product and Engineering:
  The PO knows when a story can be taken into a sprint (DoR)
  The PO knows when a story counts as finished (DoD)
  No ambiguity of "it's done but not deployed yet"

Between Engineering and QA:
  QA knows when a story enters the testing queue
  QA knows which acceptance criteria must be met
  No handoffs depending on verbal communication

Between the Team and Stakeholders:
  Stakeholders can see progress on the board without asking
  Work status is transparent and doesn't depend on manual reports

When the workflow is clear, inter-role conflicts often decrease because problems appear as system problems — not individual problems.

The Anatomy of a Healthy Engineering Workflow #

Before discussing design principles, it’s important to know what a good workflow looks like. An engineering workflow generally consists of several stages with clear transitions:

stateDiagram-v2
    [*] --> Backlog : Story created
    Backlog --> Ready : Passes DoR
    Ready --> InProgress : Developer picks up
    InProgress --> InReview : Code review
    InReview --> InProgress : Changes needed
    InReview --> Testing : Code approved
    Testing --> InProgress : Bug found
    Testing --> Done : Passes acceptance criteria
    Done --> [*]

Each transition above must have clear criteria — when a story may move from one status to the next. Without transition criteria, board statuses become empty labels that don’t reflect the actual condition.

// Example of clear transition criteria
Backlog → Ready:
  □ Acceptance criteria written and validated by the PO
  □ Story estimated in Story Points
  □ Dependencies identified

InProgress → InReview:
  □ Implementation finished in the local environment
  □ Unit tests written and passing
  □ PR/MR created with a complete description

InReview → Testing:
  □ At least 1 reviewer approved
  □ No unresolved requested changes
  □ CI pipeline passed

Testing → Done:
  □ All acceptance criteria met
  □ No open critical or major bugs
  □ Feature deployed to staging

Workflow Design Principles #

1. Start from Problems, Not Tools #

Workflows most often fail not because of wrong tool choices, but because they’re designed from tool to problem — not the other way around.

// ✗ The wrong approach: workflow follows the tool

"We use Jira, so our workflow is To Do → In Progress → Done"
→ A generic workflow that doesn't reflect how the team actually works
→ Board statuses aren't informative because there are no transition criteria

// ✓ The right approach: workflow answers real problems
Ask first:
  - Where does work most often get stuck?
  - Which stage produces the most rework?
  - Where does communication most often break between roles?
Then design the workflow to answer those questions
→ The tool follows the workflow, not the other way around

2. Visualize the Work Flow #

An invisible workflow is hard to evaluate and hard to follow. Visualization isn’t just about making a pretty board — it’s about making work status transparent to the whole team.

Good visualization principles:

✓ Every stage has a meaningful name (not just "In Progress")
✓ The status count isn't excessive — 5-7 statuses are enough for most teams
✓ Status transitions have documented criteria
✓ WIP (work in progress) is clearly visible at every stage
✗ Don't have statuses that are "never used" — remove them if irrelevant
✗ Don't have ambiguous statuses like "Waiting" without context for what's being waited on

3. Limit Work in Progress (WIP) #

This is the most often ignored principle with the biggest impact. Without WIP limits, everyone is busy but nothing finishes.

// ANTI-PATTERN: No WIP limit
5-developer team, 18 stories "In Progress" at once
→ Everyone context-switches
→ Nothing finishes mid-sprint
→ Code reviews pile up because nobody can focus on reviewing

// CORRECT: WIP limit applied
5-developer team, WIP limit: max 2 stories per developer
→ Each developer focuses on finishing 1-2 stories before starting new ones
→ Blockers surface faster because WIP doesn't hide them
→ Code reviews finish faster because there's slack time

flowchart TD
    A{"Do you have a task\nalmost finished?"} -- Yes --> B["Finish it first\nbefore starting something new"]
    A -- No --> C{"Is your WIP\nalready at the limit?"}
    C -- Yes --> D["Help teammates who\nneed reviews or unblocking"]
    C -- No --> E["Pick the next story\nfrom the Ready queue"]

The right WIP limit differs per team. Start with a simple rule: no more than 2 active tasks per developer at once — then adjust based on observation.

4. Make the Definition of Done a Workflow Guardian #

The DoD and the workflow must reinforce each other. A DoD not integrated into the workflow will be violated under sprint pressure.

// ✗ A DoD that exists but isn't integrated into the workflow
DoD lives in Confluence, never read
Developers move cards to "Done" based on intuition
QA often finds "Done" stories not yet deployed to staging

// ✓ DoD as a gate in the workflow
Cards must not move to "Done" without the DoD checklist checked
The board is configured to show the DoD checklist on every card
Review happens at the Sprint Review — if a story doesn't meet the DoD, it can't be demoed

5. Design Fast Feedback Loops #

Scrum emphasizes inspect and adapt — and the workflow must support that. The slower feedback arrives, the higher the cost of mistakes.

sequenceDiagram
    participant Dev as Developer
    participant CI as CI Pipeline
    participant QA as QA
    participant PO as Product Owner
    participant User as End User

    Dev->>CI: Push code
    CI-->>Dev: Feedback in minutes (tests, lint, build)
    Dev->>QA: Story ready for testing
    QA-->>Dev: Feedback in hours (bugs, edge cases)
    QA->>PO: Story ready for validation
    PO-->>Dev: Feedback in days (acceptance criteria)
    PO->>User: Feature released
    User-->>PO: Feedback in a sprint (usage, pain points)

Each slower feedback layer has a larger cost. The workflow must be designed to shorten every one of these loops.

6. Review the Workflow Periodically #

A workflow isn’t a one-time decision. It must be reviewed regularly — and the best place for that is the retrospective.

Questions for evaluating the workflow at retrospectives:
  □ Which stage was the most frequent bottleneck this sprint?
  □ Is there a board status never used or always ambiguous?
  □ Is there a workflow step that feels redundant or provides no value?
  □ Are there recurring problems because the workflow doesn't prevent them?
  □ Is our workflow today still relevant to the team's current size and maturity?

Workflow Anti-Patterns to Avoid #

The following anti-patterns are the most common in engineering teams — and often unnoticed because they’ve been running too long.

// ✗ Too many approval gates
A story must be approved by: TL, Senior Dev, Scrum Master, PO, and QA Lead
before it can enter a sprint
→ Overhead bigger than the value produced
// ✓ Approval gates only exist at points that truly add value
For example: code review by 1 senior developer is enough, not the whole team

// ✗ Workflow differs between theory and practice
The board says there are 6 stages, but the team never fills
in all statuses correctly
→ The board doesn't reflect reality → nobody trusts the board
// ✓ Simplify the workflow until the team can follow it naturally

// ✗ Workflow used as a control tool, not a helping tool
The manager monitors the board to measure individual productivity
→ Developers fill in board statuses to "look busy", not to collaborate
// ✓ Workflow is a team coordination tool, not a surveillance tool

// ✗ Workflow never changes even though the team has grown

"This is the workflow we've used for two years, don't change it"
→ The workflow no longer matches the team size, tech stack, or domain
// ✓ Review the workflow at least once per quarter or at significant changes

Checklist for Designing a Healthy Workflow #

INITIAL DESIGN:
  □ Workflow designed from real problems, not following tools
  □ All roles (Dev, QA, PO) involved in designing the workflow
  □ Every stage has a meaningful name and clear transition criteria
  □ Status count doesn't exceed 7

WIP & FLOW:
  □ WIP limits applied per stage or per developer
  □ A mechanism exists to detect bottlenecks (tasks stuck too long)
  □ The finish-before-start principle applied and understood by the team

QUALITY:
  □ Definition of Done integrated into the workflow, not a separate document
  □ Automatic gates (CI pipelines) exist that can't be bypassed
  □ Code review is part of the flow, not an optional step

FEEDBACK:
  □ The workflow supports fast feedback loops at every layer
  □ Bugs found in testing return to the same developer the same day
  □ Stakeholder feedback at the Sprint Review directly enters the backlog

PERIODIC EVALUATION:
  □ The workflow evaluated every retrospective (at minimum ask: any bottlenecks?)
  □ Workflow changes tracked and their effects observed the next sprint
  □ No status or step is never used (remove if present)

Summary #

• A workflow is how the team coordinates, not a list of steps — it covers how requirements enter, how work is distributed, and how feedback returns to the team.
• Start from problems, not tools — design the workflow to answer real bottlenecks, then choose tools that support it.
• WIP limits are the most important and most ignored principle — a few fully finished tasks are far better than many almost-finished ones.
• Every status transition must have criteria — without transition criteria, the board is just empty labels that don’t reflect the actual condition.
• The Definition of Done must be integrated into the workflow — not a separate document read once and forgotten.
• Workflows must support fast feedback loops — the slower the feedback, the higher the cost of mistakes.
• A workflow that never changes is an obsolete workflow — evaluate periodically at retrospectives and don’t be afraid to change what doesn’t work.
• Too rigid and too loose workflows are equally dangerous — find the balance that’s structured enough to be predictable, but flexible enough to be adaptive.

← Previous: Sprint   Next: RFC →