Project management workflow briefly, the one that makes it.

Short answer: A project management workflow is the repeatable sequence of states a piece of work moves through from idea to shipped — usually six or fewer. The short version: pick the smallest set of states your team actually uses, write a one-sentence exit criterion for each, and stop redesigning the board. Most workflow failures are not a missing state; they are too many states, work-in-progress with no limit, and a queue nobody owns.

A project management workflow describes the various states a task goes through from the moment you ideate till it’s shipped.  This is the exhaustive definition. In the remainder of the article, we will discuss which statuses earn their place, which are decoration, and why most teams have at least three more columns than they need.

The most cost-effective part of project management is workflow design. It also the element that consumes the most time. The template on Notion is updated. The Jira screen configuration changes. The retro produces a new column called “Blocked” that, like magic, turns into a parking lot for stories nobody wants. A six-week follow-up retro added a column “Blocked – External” to distinguish it from the regular kind of blocked. The workflow has become a graveyard for bygone disputes.

This guide is for engineers, anchors, and PMs who'd rather get that time shipping. It discusses the bare minimum approach to use in practice, how to size it for the actual work that you really do, where to put work-in-progress limits on it, and the three failure modes you will see before anyone ever admits the fault lies with the workflow.

A project management workflow, plainly explained

A project management workflow consists of a finite-state machine. A workspace accepts input in first state which is the workstate, it progresses to next state based on a condition and finally exits the workspace when the work is shipped. The columns on the board represent the states. The rules for moving a card from one column to the next are transitions.  That is all there is.

Most teams overlook both sections.

• Exit criteria. A column without an exit criterion is a holding pen. "Doing" with no definition of done turns into "stuff a person is sort of working on." Write one sentence per column that ends the ambiguity.
• An owner per state. Every column should have exactly one role responsible for moving cards out of it. If "Code Review" has no owner, code review is where stories go to age.

The reason most work-processes feel busy is not that the work is busy. The reason is due to lack of exit criteria on the workflow itself, and lack of ownership, so each card is living in 3 columns simultaneously, and the standup becomes a status broadcast instead of a planning meeting. A solution is not just cultural but also structural.

The six states every workflow needs

Most practical project management workflows will collapse to six states or fewer. The titles change. The form does not.

Here are some notes about this shape.

The blocked status requires only a tag and not a column. A story that is blocked will remain where it is; it is more important to know it is blocked, and who will unblock it. By including a Blocked column, we conceal the original state and allow stories to reside there indefinitely. Request the team to keep the card where it was; just flag it instead.

There is probably no need to have a separate column for “QA” either. QA is either part of Review or part of Accept. When a standalone column is created, it effectively adds a hand-off step. However, this step earns its keep only when there is a separate QA team running on a different cadence. For a product team of size six, Review suffices.

There is a reason that Idea and Ready are two distinct states. Idea is the icebox   anything written down anywhere by anyone. The ready queue contains stories that are ready to be picked by the developers.  They are grooming each other to bridge the gap. A grooming session is one where you learn what ideas won’t survive ten minutes of discussion.  It’s a "feature," not a bug. For the mechanics of pruning the icebox before it turns into a graveyard, see LiteTracker on grooming your backlog.

Any workflow with more than six states begs the question “why?” for each extra state. The reason usually boils down to one of three: (a) a hand-off between teams, (b) a compliance step, or (c) a column added in a retro that nobody ever removed. Two of those three things are worth retaining. The third is a Jira ticket for technical debt.

Pick the workflow type before you draw the board

The workflow of project management can either be linear or iterative, with the latter accounting for almost everything. Choose before you sketch the board.

Linear workflow progresses from one phase to another without any commencement until completion of the previous phase. Suitable for proving prescribed order or sequence when there is a deadline imposed by a regulatory body e.g. banking. A linear workflow is detrimental for software engineering because, contrary to its linear approach, software goes through a user feedback loop. (21 words) The Agile Manifesto is the canon. Essentially, it’s just a list of things linear workflows are bad at.

The team goes through them in a fixed iteration every week or two. Same six states.  A tangible product is delivered at the end of each cycle. Most software teams should adopt this approach. The Scrum Guide talks about one implementation; you do not have to run it to the letter but the iteration cadence is the heavy lifting idea. LiteTracker covers the trade-offs in choosing the right iteration length — one and two weeks both work, four weeks rarely does.

Inside iterative, we have two sub-shapes worth knowing.

• Time-boxed (Scrum-style). Two-week sprints, planned upfront, no scope changes mid-iteration. Works well when the team is new to agile and needs the scaffolding. Adds ceremony tax.
• Pull-based (Kanban-style). No fixed sprint. Work-in-progress limits per column. Pull the next story when capacity opens. Works well for mature teams and for support / maintenance work. The Kanban Guide is two pages and worth reading; it's mostly about limits.

A team with less than 15 engineers may benefit the most from light-time-boxed iterations with some semblance of Scrum, dropped as ceremony stops paying for itself. Don’t choose Kanban first because someone read a blog. A kanban board that has no WIP limits is just another trello board with more columns. LiteTracker takes on getting started with agile while making the same argument from a different angle.

Work-in-progress limits, or you don't have a workflow

Putting a number above each column is the highest-leverage change you can make to any project management workflow. That number represents the maximum work-in-progress. The team has the license to carry a maximum of that number of cards in that column at once. If adding the card will put the column over limit then the team will have to finish or move something before pulling the new one

This should not be viewed as negotiable. It transforms a paddle into flow from status dashboard to workflow.

Appropriate initial constraints for a six engineer design team for iterative development.

The calculations are simple. In case the board has five cards on it and the team has four engineers, at least one cards is being worked on by zero people. Somebody was blocked on the card so they moved their attention to something else. If there is no WIP limit, it's invisible. Implementing a work-in-progress limit means that the team can’t begin something new until the old one moves along, creating the conversation that will surface the blocker.

The LiteTracker system is designed just like that: engineers can only work on one story at a time, no points until acceptance, and velocity is only calculated on accepted work. When batch sizes are reduced significantly, cycle times can be reduced from days to hours, enabling teams to reach users almost 14× faster. Just a number, marketing on its own. The number accompanying the WIP-limit mechanism is analysis.

If your current board does not have numbers above the columns, add it this week. Numbers that are arbitrary will work too. The constraint is the point, not the precision.

Map the workflow to the work, not the work to the workflow

The optimal place to begin workflow design is with the team. A template is opened, columns are picked, and then the team's actual work is tried to fit into those columns. A team's workflow should describe the template, not the people involved.

Reverse the order in which you do it. Dedicate an hour with the team and list the last ten pieces of work that were delivered. Document every state of each one along with the time stamps. You will see 4 things.

1. Some columns nobody uses. The "Design Review" column had three cards in it across ten stories. It's not a state; it's a tag on the rare stories that need it. Cut it.
2. Some columns where work piles up. "Review" had cards sitting for an average of four days. That's the bottleneck. Either lower the WIP limit upstream, raise the headcount on review, or shrink the stories so review is faster. Pick one.
3. Hand-offs nobody documented. "Doing" cards quietly went to "Design QA" for two days that don't show up on the board. That's a hidden column. Make it visible or kill it.
4. States that should exist but don't. If a card in "Accept" frequently bounces back to "Doing", you're missing an explicit "Needs Rework" tag. Not a column — a tag. The card stays in Doing; the tag says why.

This exercise seems time-consuming. The team generally saves 25% of every standup for 6 month after spending ~90 minutes together. It pays for itself with standup-time recovery. LiteTracker argues in setting a goal for your iteration that when the cadence of your iterations (e.g., 2 weeks) does not match the shape of wall columns (which usually a month or longer), either the cadence of iterations or the shape of wall columns will lie.

A senior anchor I worked with anchored a team last year that had eleven columns. They reduced it to six in one afternoon. After implementing the changes, the average working days for an average story got reduced to five within two iterations. Not due to increased speed among engineers. The workflow has halted for a reason as it pretended five columns exist.

The ceremony tax — and the only ceremony that earns it back

Most ceremonies that come with project management workflows don’t earn their place. A weekly status meeting where everyone reads what’s on the board is a status broadcast, not a meeting. The board exists, reading it aloud don’t make it better.

The retrospective is the one ceremony worth its salt on every team I’ve worked on. In particular, have a thirty-minute retro at the end of each iteration with one rule: change at most one thing about the workflow per retro.  One column was added, one column was removed, one WIP limit was adjusted. When there are multiple changes, it gets difficult to understand which one did the job.

The benefits are genuine and gradual. LiteTracker works under the hypothesis that scrupulous management of iterations has a compounding effect: that teams which run a tight retro ship between 20% to as much as 70% more value by their 8th iteration – because workflow shapes itself to work, one small change at a time. A lot to learn to reach week one. You will arrive at that point starting from week sixteen. For the underlying maths, read LiteTracker on a healthier approach to estimating velocity, which explains how to track the curve without micromanaging.

Eliminate all ceremonies until something goes wrong. Stop wasting time at the sprint reviews when the same six people are still discussing the same work that was already discussed at the standup. Eliminate the lengthy planning of an iteration’s sprint if the stories have already been groomed two days ago. The Scrum Guide is not a holy book. It cannot arrest you, technically.

The only time it is excepted is if that ceremony is the only place a cross-team conversation takes place. During sprint review, if engineering and support interact with each other for the only time - it’s doing real work, even if it feels boring. Avoid dropping that one. Look for a more affordable alternative instead.

When workflows fail — three tells

A failing project management workflow does not crash. It decays. Three indicators.

Standup meetings should not exceed 15 minutes. Above all, it is a planning meeting, not a status meeting. If it’s running long, people are explaining state that the board should already show. Correct the board and not give standup more time is the cure.  Further details can be found in the daily standup is a planning meeting.

The board does not match reality. The cards in Doing are not being done by anyone. Cards in the overflowed “Done” section from two iterations ago that nobody archived.  The “Blocked” column has increased more rapidly than the “Done” column for three iterations. When the board isn’t telling the truth, every meeting after that will also not be telling the truth. At the beginning of each standup, mandate a fifteen-minute board cleanup until the lag clears.

Velocity is increasing but the shipped value is not. Story points are crawling. The team is awarding points for fixing bugs. When a retro stops talking about velocity as a forecasting tool and starts talking about it as a target. The smell of a workflow that's optimising for the chart instead of the work. The remedy is what it’s always been – only count accepted user-visible stories for velocity, and ignore the chart except for planning.

All three stem from the same root cause: what started out as a description of how work moves is now a layer that the team performs for someone else. Either the team reports on behalf of the PM, the PM reports on behalf of the exec, or everyone reports on behalf of the tool (the Kanban board or whatever). By and large, a performance workflow deteriorates quickly. A solution exists in structure: fewer columns, real WIP limits, an exit criterion.

Map the workflow to a real tool

Although your choice of tools is less important than how you design your workflow, it does still matter a small amount. A poor tool will always counter a good workflow.

The stark reality for software teams in 2026:

LiteTracker focuses on the 20% of functionalities that drive 80% of effects. Anything more is the long tail of larger enterprise tools. If you're already at iteration work and want a board where you won't be able to bend it into a Gantt chart, that's the pitch.  If you’re looking for configurable approval flows with a custom workflow for the compliance team, you want Jira. Choose the tool that encodes your process rather than the one that you would be a little proud to flaunt on your CV.

LiteTracker is not disruptive to XP/Scrum flow, as stated by reviewers on Capterra. In other words, it’s “loved by XP/Scrum practitioners”. The ideal tool is one that doesn’t interfere with the disagreements in your workflow.

When NOT to design a workflow yet

This section of the article typically encourages the end-user to sign up for the service, product or offering. Instead   the situations where you ought not to.

If your team has less than 3 engineers, you don’t need project management work flow! A shared document and a five-minute phone call every morning is a must. When put on a two-engineer 6-column board it it a tax on attention with no payback.  It will cost more to manage the board than to lose the board altogether.

If you have never shipped something real to a real user, I would say to design the workflow after you ship the first thing. The initial workflow will always be incorrect because you are not yet certain what the team's work looks like. The original action was completed, I have difficulty accessing it, and I will attempt to use it when everything is capable.

If you alter the workflow after each sprint, cease doing so. Choose the simplest iteration and deploy it for an entire quarter, without any modifications or adjustments. Observe how the work shapes up in the meantime. When a workflow is redesigned repeatedly, it means the team is bored with the workflow, not that it is wrong. The artefact is the actual work and not the board.

LiteTracker has a free tier that doesn’t charge per seat. This means you can wait until the workflow is the bottleneck before signing up. That’s intentional. The tools that don’t need to exist yet are how tools get a bad reputation.

Frequently asked

What is a project management workflow?

A work item is anything that needs to get done, e.g. user stories, bugs, etc. It consists of states that it goes through from idea to shipped. A typical definition looks like a sequence of 6 or fewer columns in a board, exit criteria written in a single sentence, and a single owner (not multiple).

How many steps should a project management workflow have?

Not more than six. The standard framework consists of: Idea, Ready, Doing, Review, Accept, and Done. A number greater than six is an indicator of a hand-off step which hasn’t been questioned in over a year.

What's the difference between a linear and an agile workflow?

A linear workflow produces completed outputs before entering the next state. An agile workflow cycles through the same states every one to two weeks. Software constantly requires iteration after iteration as it is dependent on a user feedback loop that can’t exist yet before release.

Do I need a "Blocked" column on my board?

No. The term 'Blocked' refers to a tag not a state. When a card gets blocked, leave it where it is, and flag it. This surfaces the original state, as well as makes blockers visible without giving them a permanent home.

What's a work-in-progress (WIP) limit?

Each column has a number that indicates the maximum cards that are allowed in that column at one time. The absence of WIP limits means the board is not a workflow; it’s merely a status dashboard. Hence, WIP limits create a workflow.

How do I know my workflow is failing?

If the stand-up takes longer than 15 minutes, the board doesn’t match what’s actually happening and velocity is going up but shipped value is not. Each one points to structural issues that the workflow can fix.

Should I copy a workflow template?

Just a starting point only. The proper workflow is the one through which the last ten pieces of work done by the team actually flowed through. It is better to determine the columns from the work rather than defining the work from the columns.

How often should I change the workflow?

Only one change should be introduced in each retrospective, for example, adding one column, removing one column, or adjusting one WIP limit. If the code is too long, you’ll get confused about what works and what doesn’t. Typically, teams tend to change them too often.

Still stuck

Most of the benefits of project management systems is already captured if there are six states or fewer in the workflow, the columns all have exit criteria, the team owns each state, and the WIP limits are real numbers. The tool accounts for the final 10%.

LiteTracker is built for you if you want a board that accepts stories only when they’ve been accepted and keeps a restriction of one story in flight per engineer, without having to do the policing yourself. No demo call, no time limit, unlimited users, free tier. If other tools like a Trello board or Discord ping are serving you use that instead. We prefer if you don’t compensate us for a friction you never had.

Whatever the case: halt the redesign of the workflow and commence its execution.