When to add workflow stages to your issue tracker
You have issues in Open and Closed. Maybe a "Doing" column if you got fancy. It worked when the project was just you, or when the team was small enough that everyone knew what was happening. But now you're checking Slack to find out if that card is actually being worked on or just sitting there. The board isn't telling you enough.
That's the moment to add workflow stages to your issue tracker.
What are workflow stages in an issue tracker?
Workflow stages in an issue tracker are named columns or statuses that represent where a piece of work sits in your process. Instead of a binary Open/Closed system, you define stages like "In Progress," "In Review" or "Ready for Deploy" so the board shows what's actually happening with each item. They turn your tracker from a list into a map of how work moves.
TL;DR: If you're using Open/Closed and constantly asking "what's the status of this?", it's time to add workflow stages. Start with your handoff points, keep it between 4 and 7 stages and adjust after a few weeks. Don't copy someone else's workflow. Build one from what your team actually does.
How do you know it's time to add workflow stages to your issue tracker?
You don't need workflow stages on day one. They become necessary when the tracker stops answering basic questions. Here are the signals:
1. "In Progress" could mean anything. One card is being actively coded. Another is waiting for a designer to review the mockup. A third has been sitting untouched for a week but nobody moved it back. When a single column covers multiple states, people stop trusting what the board shows.
2. You ask for status updates outside the tracker. If you're asking in Slack, in standups or via email "hey, where is this?", the tracker has failed at its primary job. The board should answer that question at a glance.
3. Handoffs get lost. A designer finishes a mockup and moves the card to "In Progress." The developer doesn't realize it's their turn because nothing about the card's position changed. Without a "Ready for Dev" stage, the handoff is invisible.
4. Cards sit in one column for weeks. A card stuck in "Open" for three weeks could mean it's blocked, deprioritized or forgotten. You can't tell which without opening it and reading the comments. Workflow stages make these distinctions visible from the board.
5. You've invented workarounds. Labels like "BLOCKED" or "NEEDS REVIEW." Comment threads that serve as status updates. A separate spreadsheet tracking what the board can't. These are patches over a structural gap.
If two or more of these sound familiar, you've outgrown a flat tracker.
How to design stages that match your actual process
The mistake most teams make is copying a workflow template from a blog post or a tool's default setup. Your stages should reflect how your team actually works, not how a generic "agile team" is supposed to work.
Here's a practical approach:
- Follow one piece of work from start to finish. Pick a recent task and trace its path. Write down every point where it waited for someone or something before moving forward.
- Name each waiting point. "Waiting for code review" becomes "In Review." "Ready for the client to approve" becomes "Client Review." These waiting points are your natural stages.
- Define what "done" means for each stage. If you can't explain when work should leave a stage, the stage is too vague. "In Review" means someone is actively reviewing. When they approve, it moves to the next stage.
- Merge stages that involve the same person doing the same thing. If "Code Review" and "PR Review" always happen together by the same person, that's one stage.
Aim for 4 to 7 stages. Fewer than that and you're back to vague buckets. More than 8 and the board becomes a bottleneck map nobody wants to maintain.
The key distinction: stages should represent handoff points, not activities. "Writing code" isn't a good stage because it doesn't tell you what happens next. "In Development" is better because the exit condition is clear: the code is ready for review.
Before and after: a team moving past Open/Closed
A five-person development team has been using GitHub Issues with Open and Closed for eight months. They added a "Doing" label six months ago. During their Monday sync, they spend 20 minutes going through open issues because nobody can tell which ones are being worked on, which are waiting for review and which are blocked.
Before: flat tracker with labels as workarounds
| Open | Closed |
|---|---|
| Redesign settings page (label: Doing) | User auth |
| Fix CSV export bug (label: Doing) | Password reset |
| Add search filters (label: BLOCKED) | Onboarding flow |
| Update API docs (no label, unclear status) | |
| Implement notifications (label: Needs Review) |
Five open issues. Three different labels trying to communicate status. One issue with no label at all. The board tells you almost nothing.
After: workflow stages that show what's happening
| Backlog | In Development | In Review | QA | Done |
|---|---|---|---|---|
| Update API docs | Redesign settings page | Implement notifications | Fix CSV export bug | User auth |
| Password reset | ||||
| Onboarding flow |
Now the board answers questions without anyone opening an issue. The settings page is being coded. Notifications are waiting for review. The CSV bug is in QA. API docs haven't started. The Monday sync drops to 5 minutes because the board did the reporting.
The "BLOCKED" label for search filters? The team realized it was blocked on a third-party API and moved it to a separate "Blocked" label within the Backlog column. The stage still shows it hasn't entered development.
See pricing and try it yourself
What mistakes should you avoid when you add workflow stages to your issue tracker?
Getting workflow stages wrong is easy. Here are the patterns that trip teams up.
Copying another team's workflow. A workflow that works for a Scrum team with dedicated QA engineers won't work for a team of three generalists. Build your stages from observation, not imitation.
Adding too many stages upfront. Start with the minimum that removes ambiguity. You can always add a stage later when confusion shows you need one. You can't easily remove stages once people are used to them.
Creating a "Blocked" status. "Blocked" is a condition, not a position in your workflow. A card in "In Review" that's blocked is still in review. Moving it to a separate "Blocked" column means you lose track of where it was in the process. Use a label instead.
Building stages around tools instead of people. "In Figma" or "In GitHub" are tool locations, not workflow stages. What matters is the state of the work: is it being designed, reviewed or tested?
Never revisiting the workflow. Your process will change. A stage that made sense six months ago might be empty now. Review your workflow quarterly. If a column is always empty, remove it. If cards pile up between two stages, you might need a new one in between.
For a full setup guide, see our post on how to set up a project workflow from scratch.
Why do per-project stages matter more than global ones?
Not every project moves through the same steps. A marketing content project has stages like Draft, Editing, Approved and Published. A software project has Backlog, In Development, In Review and QA. Forcing both into the same set of stages recreates the original problem: the names stop matching reality.
This is where tools like GitHub Issues hit a wall. Labels are global, not per-project. You end up with a messy list of labels trying to serve every project at once.
Per-project stages let each workflow reflect its own process. Your development project gets stages with code review and QA. Your design project gets stages with client feedback loops. Neither compromises for the other.
In Eigenfocus, custom statuses are defined at the project level. Each project gets its own set of stages. There's no global configuration or admin permissions required. You open project settings, define your stages and they become your board columns immediately.
This pairs well with custom issue types. A "Bug" issue type can move through different stages than a "Feature" request within the same project. Learn more about this in our post on when GitHub Issues needs more structure.
How do workflow stages look across different views?
Once you define workflow stages, they aren't limited to a board. They work across every view your project uses.
Board view is the most natural fit. Each stage becomes a column and cards flow left to right. This is where you'll see the biggest immediate change from a flat Open/Closed setup.
Grid view lets you cross-reference stages with another dimension. Put stages on the columns and assignees on the rows. Now you can see who has work in which stage at a glance. This is useful for spotting bottlenecks: if the "In Review" column is full and the reviewer's row is packed, you know where to focus.
List view lets you filter by stage. Need to see everything waiting for QA? Filter to that stage and you have your queue.
The same stages power every view because views are projections of the same data. Move a card on the board and it updates in the grid. Filter by stage in the list and the results reflect the board's current state. For more on choosing the right view, read our post about when one board view isn't enough.
Getting started
Define your workflow in minutes. Open your project settings, create your stages and start using a board that reflects how your team actually works. No admin setup, no global configuration.
Pair your workflow stages with custom fields for tracking priorities, effort and phases. Or explore how to build a complete project setup with our guide on setting up a project workflow from scratch.
If you're building a dedicated bug workflow, see our guide on a simple bug triage workflow for dev teams.
You can also see how teams use Eigenfocus for software development or as a project management tool.
Frequently asked questions
When should I add workflow stages to my issue tracker?
When you find yourself asking for status updates outside the tracker. If Slack or standups are your primary way of finding out where work stands, the tracker isn't doing its job. Other signs include labels used as status workarounds, cards stuck in one column for weeks and handoffs getting lost.
How many workflow stages should I start with?
Four to seven covers most teams. Start with the minimum that removes status ambiguity. A common starting point for development teams is Backlog, In Development, In Review, QA and Done. Add stages only when their absence causes confusion. Remove them when a column stays empty for weeks.
Should I use the same stages across all projects?
Not usually. Different types of work have different checkpoints. A content project needs Draft and Editing stages that a development project doesn't. A client-facing project might need a "Client Review" stage that an internal project would skip. Per-project stages keep each workflow honest.
Can I change my workflow stages after I've started using them?
Yes. In Eigenfocus, you can rename, add or remove statuses at any time. Cards in a removed status get moved to the default status. Start simple and adjust after a few weeks of use. The first version of your workflow won't be perfect. That's fine.
What's the difference between stages and labels?
Stages represent position in your workflow. A card can only be in one stage at a time: it's either in development or in review, not both. Labels are tags for categorization (like "bug," "frontend" or "urgent"). A card can have multiple labels. Use stages for workflow position and labels for classification. Read more about this in our post on labels vs custom fields vs custom statuses.