How to Design an Agile Workflow That Actually Delivers Results

Your Board Has Three Columns and Everything Is Stuck in “In Progress”

You’ve got a Jira board. It has three columns: To Do, In Progress, and Done. Twenty tickets sit in the In Progress column. Three developers are working on nine things at once. Nothing is actually getting finished.

This is what happens when a team adopts Agile tools without designing an actual workflow. The board exists, but it doesn’t reflect how work really flows through the team. And if your board doesn’t match reality, it can’t help you spot problems or improve delivery.

A good agile workflow makes the invisible visible. It shows you where work is, where it’s stuck, and what’s slowing your team down. Here’s how to build one that actually works.

Step 1: Visualise Your Current Process

Before designing anything new, map what’s actually happening. Not the process you wrote in a Confluence document six months ago. The real one. The way work actually moves through your team today.

Get the team together and trace a recent piece of work from the moment it was requested to the moment it was delivered. Write down every handoff, every waiting state, and every review step. Be honest about the informal stages too, like “sitting in someone’s inbox waiting for review” or “blocked because we’re waiting for design.”

You’ll probably discover that your real workflow has more stages than your board shows. That gap between the board and reality is where work gets lost.

Step 2: Map Your Stages

Take what you learned from the previous step and turn it into explicit workflow stages. Each stage should represent a meaningful state that work passes through.

A typical software development workflow might look like this:

• Backlog: Work that’s been identified but not yet committed to.
• Ready: Work that’s been refined, estimated, and has clear acceptance criteria.
• In Development: Someone is actively building it.
• Code Review: Development is done, waiting for peer review.
• QA/Testing: Being tested against acceptance criteria.
• Ready for Release: Passed testing, waiting for deployment.
• Done: Deployed and verified in production.

Your stages will vary based on your team and product. A design team’s workflow looks different from a development team’s. An operations team’s looks different again. The point is to reflect your actual process, not someone else’s template.

One rule of thumb: if work sits in a state for more than a few hours on a regular basis, that state probably deserves its own column on the board.

Step 3: Define “Done” at Each Stage

Every stage needs clear exit criteria. What has to be true before a piece of work can move to the next column? Without this, people move tickets forward based on feel, and the same work ends up bouncing back and forth between stages.

For example:

• Ready: Story has acceptance criteria, is estimated, and the team agrees it’s small enough to complete in one sprint.
• In Development: Code is written, unit tests pass, and the developer has run it locally.
• Code Review: At least one peer has reviewed the code and approved it. Comments have been addressed.
• QA/Testing: All acceptance criteria verified. No critical bugs. Regression tests pass.

Write these down and make them visible. Put them on the board or in the board’s configuration. When the whole team agrees on what “done” means at each stage, you eliminate ambiguity and reduce the back-and-forth that slows delivery.

Step 4: Set WIP Limits

WIP (Work in Progress) limits cap the number of items that can be in any given stage at one time. They’re the single most effective tool for improving flow, and most teams resist them at first.

Here’s why they matter. Without WIP limits, the natural tendency is to start new work when you get blocked on something. You’re waiting for a code review, so you pick up another ticket. Now you have two things in progress. Then you get blocked on the second one and start a third. Before long, you’re context-switching between five tasks and finishing none of them.

WIP limits force a different behaviour. When the Code Review column is full, the team can’t push more work into it. Instead, someone has to do a review before anyone can move new work forward. This might feel slow, but it dramatically reduces cycle time because work flows through the system instead of piling up in the middle.

Start with WIP limits that are slightly lower than what your team currently has in progress. If you typically have six items in development at once across three developers, try a WIP limit of four. Observe the effect. Adjust from there.

Step 5: Identify and Address Bottlenecks

Once your workflow is visualised and WIP limits are in place, bottlenecks become obvious. They show up as stages where work consistently piles up.

If items keep stacking up in Code Review, your team has a review bottleneck. The fix might be pairing up on reviews, setting dedicated review time, or reducing the amount of work that arrives in the review queue by lowering upstream WIP limits.

If items pile up in QA/Testing, you might need to shift testing earlier in the process (test automation, developer testing) or add testing capacity.

The point is that a well-designed workflow makes bottlenecks visible. You can’t fix what you can’t see. And you can’t see bottlenecks on a board that only has three columns.

Step 6: Iterate on the Workflow Itself

Your workflow isn’t a one-time setup. It should evolve as your team learns, your product changes, and your processes mature.

Review your workflow in retrospectives. Ask: Are items getting stuck in any stage? Do we have stages that don’t add value? Are our WIP limits too loose or too tight? Is the board still reflecting how we actually work?

Some teams add stages over time (splitting “Testing” into “Manual QA” and “Automated Testing”). Others remove them (merging “Code Review” and “QA” when the team starts doing reviews as part of testing). The workflow serves the team, so change it when it stops serving you.

Scrum-Style vs Kanban-Style Workflows

Both Scrum and Kanban teams need workflows. The mechanics of how work enters and moves through the workflow differ.

Scrum-Style Workflow

In Scrum, work enters the workflow during Sprint Planning. The team selects a batch of items from the product backlog and commits to completing them within the sprint. New work doesn’t enter mid-sprint unless the team agrees to it.

The workflow resets at sprint boundaries. At the end of each sprint, ideally everything in the workflow has moved to Done. In practice, carry-over happens, but the goal is to complete all committed work within the time-box.

Scrum workflows benefit from a “Sprint Backlog” column at the start, which holds the work committed to for this sprint but not yet started.

Kanban-Style Workflow

In Kanban, there are no sprints. Work flows continuously. New items enter the workflow when the team has capacity, controlled by WIP limits. There’s no batch commitment and no sprint boundary.

Kanban workflows tend to be more granular because the team optimises for flow rather than time-boxed delivery. Metrics like cycle time (how long an item takes from start to finish) and throughput (how many items complete per week) replace velocity as the primary measures of performance.

If your team handles a mix of planned work and unplanned requests (like a support team or an ops team), Kanban-style workflows often work better because they can absorb variable demand without the friction of sprint boundaries.

Common Workflow Anti-Patterns

Too Many Handoffs

Every handoff between people or teams is a delay and a potential communication gap. If your workflow has seven stages and each one involves a different person, work spends more time waiting than being worked on. Look for ways to reduce handoffs. Can the developer do their own testing? Can the designer and developer pair instead of doing sequential handoffs?

Invisible Queues

Some of the longest delays in a workflow are invisible because they happen between stages. Work is “done” with development but sits in someone’s review queue for three days. That waiting time doesn’t show up on a basic board.

Fix this by adding explicit “waiting” columns. Instead of one Code Review column, use “Awaiting Review” and “In Review.” This makes the queue visible, and visible queues get attention.

The “In Progress” Black Hole

A single “In Progress” column that contains everything from “just picked it up” to “almost done with code review” tells you nothing useful. Break it down into the actual stages work moves through. The more accurately your board reflects reality, the more useful it becomes.

No WIP Limits

A workflow without WIP limits is just a to-do list in columns. WIP limits are what turn a task board into a flow management system. Without them, there’s no mechanism to prevent overload, no signal to help when someone is stuck, and no incentive to finish work before starting new work.

Designing for the Ideal Instead of the Actual

Some teams design beautiful workflows that describe how they wish they worked rather than how they actually work. Then they’re surprised when nobody uses the board correctly. Start with reality. Make the current process visible, flaws and all. Then improve it incrementally.

Getting Started This Week

You don’t need a perfect workflow on day one. Start with these actions and build from there.

• Map your current process honestly. Include the waiting states and informal stages.
• Create board columns that match your actual stages. More than three, fewer than ten.
• Define exit criteria for each stage. Write them down where the team can see them.
• Set initial WIP limits. Start conservative and adjust based on what you observe.
• Review the workflow in your next retrospective. Ask what’s working and what needs to change.

A workflow that reflects reality and evolves with your team will always outperform a “best practice” template that nobody follows.

Frequently Asked Questions

What is an agile workflow?

An agile workflow is the sequence of stages that work moves through from request to completion within an Agile team. It defines how work enters the system, what happens to it at each stage, and what “done” means. Both Scrum and Kanban teams use workflows, though they manage them differently.

How many columns should my board have?

Enough to reflect the actual stages work moves through, but not so many that the board becomes hard to read. Most teams land between five and eight columns. If you have fewer than four, you’re probably hiding important stages. If you have more than ten, some columns might be redundant or too granular.

What are WIP limits and why should we use them?

WIP limits cap the number of items allowed in any workflow stage at one time. They prevent overload, reduce context-switching, and force the team to finish work before starting new work. Without WIP limits, teams tend to start many things and finish few, which increases cycle time and reduces predictability.

What’s the difference between a Scrum workflow and a Kanban workflow?

In a Scrum workflow, work enters in batches during Sprint Planning and the team aims to complete all items within the sprint time-box. In a Kanban workflow, work flows continuously and new items enter whenever the team has capacity. Scrum uses velocity to measure output. Kanban uses cycle time and throughput.

How do you identify bottlenecks in an agile workflow?

Look for stages where work consistently piles up. If your Code Review column always has more items than any other column, that’s your bottleneck. WIP limits make this even more visible because they create back-pressure when a stage is overloaded. Tracking cycle time by stage also shows you where items spend the most time waiting.

Should we use a physical board or a digital tool?

If your team is co-located, a physical board has real advantages. It’s always visible, easy to update, and creates natural conversations. For remote or hybrid teams, digital tools like Jira, Trello, or Azure DevOps are necessary. The tool matters less than the design of the workflow itself. A well-designed workflow on sticky notes beats a poorly designed one in expensive software.

How often should we change our workflow?

Review it in every retrospective, but don’t change it for the sake of change. Modify your workflow when you identify a specific problem: work getting stuck, stages that no longer reflect reality, or bottlenecks that need a structural fix. Small, incremental changes are better than major overhauls.

Can multiple teams share the same workflow?

Teams with similar work types can share a workflow design, but each team should have its own board. Sharing a single board across multiple teams makes it hard to set meaningful WIP limits and obscures who is responsible for what. If teams need to coordinate, use a separate program-level board that shows cross-team dependencies.