Tips For Customizing Kanban Boards For Your Team

Kanban: We Should Be "Done" With "In-Progress" One of the best ways to use Kanban is by visualizing meaningful work states on your board. Thoughtfully designed boards can transform how teams deliver value, spot inefficiencies, and improve collaboration. Unfortunately, many teams miss these opportunities by relying on vague, catch-all columns like “In-Progress.” Let’s talk about why “In-Progress” is practically useless, and how breaking it into clearer work states is a smarter strategy. Why “In-Progress” Fails The term “In-Progress” might seem harmless, but it’s so broad that it adds little value. “In-Progress” doesn’t explain what’s actually happening. Is a task being coded, reviewed, or tested? Without specifics, delays and inefficiencies stay hidden. A generic column hides bottlenecks. For example, slow code reviews go unnoticed when everything sits under “In-Progress.” Vague statuses make it harder to know who should act next. Confusion leads to reduced accountability, delays, and misaligned expectations. Without data showing where tasks spend the most time, teams can’t identify trends or resolve inefficiencies. The Case for Clarity Replacing “In-Progress” with specific work states turns a Kanban board into a powerful tool for managing flow and driving improvement. For example, a software development team might use: Backlog: Items awaiting prioritization. Ready for Development: Work ready to start. In Development: Developers are actively working. Ready for Code Review: Development is complete, awaiting review. In Code Review: Review process underway. Ready for Testing: Code is ready for QA. In Testing: QA is actively testing. Ready for Deployment: Testing is complete, awaiting release. Done: Work is completed. Each state reflects a clear step in the workflow (not necessarily a handoff). This improves visibility, accountability, and makes bottlenecks easier to spot. Your team’s context might call for different states, but the goal stays the same: clarity. Spotting Bottlenecks Granular states make delays visible. If tasks sit too long in “Ready for Code Review,” reviewers may be overloaded or not prioritizing reviews. A backlog in “Ready for Deployment” could mean release processes need work. Tasks stuck “In Testing” might point to unclear requirements or a stretched QA team. Tracking time-in-state reveals where delays occur, helping teams reallocate resources or refine processes. Collaboration Benefits Meaningful work states improve collaboration. When a task moves to “Ready for Testing,” testers know it’s their turn to act. This reduces idle time and makes transitions smoother. Be Done With “In-Progress” Create columns for key steps in your workflow. Don’t overcomplicate things. Aim for enough granularity to reveal bottlenecks without overwhelming your team with administrivia. Set clear entry and exit criteria for each column. Kanban isn’t just about making work visible; it’s about making the right work visible.

Stop overcomplicating your statuses in ClickUp. This is one of the most common mistakes we see teams make inside ClickUp. You want to create cool Board views, so you start creating different statuses for different services, clients, teams, etc. For example, web development has different statuses, SEO has different statuses, and your design team has different statuses. Why this fails... ⚙️ Statuses start to become the source of truth for where a project is at. ➝ This will lead to things slipping through the cracks, tasks remaining open for too long, and unless each status definition is documented, there will be some confusion across the team. ⚙️ Dashboards and views are impossible to make. ➝ Go create a dashboard and try to filter and break up something by status. You'll have thousands of options, and it'll be a nightmare. ⚙️ "Task closing anxiety" ➝ Your team loses the ability to confidently close tasks. ➝ Different teams try to work with your team but get lost in the workflow because of the number of statuses they're supposed to use. ✅ Here's how to avoid this mistake Create a more organized workspace by... 1️⃣ Building a status template ➝ Build a status structure that will be used consistently across your workspace, save it as a template, and deploy it everywhere else. 2️⃣ Using statuses sparingly ➝ Statuses should not become your source of truth for progress. And if you need a cool board view, feel free to use a custom field instead. 3️⃣ Building your current statuses into subtasks ➝ Instead of "Review draft #1" as a status, make that a subtask and assign it to someone to complete. ➝ Pass work through subtasks, NOT statuses and automations ---------- ✋ What have you done to simplify statuses?

Some of y'all really love your Blocked column on your kanban boards. If something is working well for your team, it doesn't matter what I or anyone else thinks about it, obviously. I mean, unless I'm on your team. But since we're sharing, I don't like having a column for Blocked items. 1) "Blocked" is not a stage of transformation all work items go through (I hope!!!). It is a state a work item can experience in any stage. 2) Moving an item into Blocked loses the context in which the item was Blocked. I don't know if it was Blocked while we were trying to flesh out the requirements of the item, while we were coding it, during deployment, etc. Yes, you can add notes to the card, but I lose the visual reference that's so helpful when the team is planning their day as well as the useful metric of how many items were Blocked for how long in a particular stage. 3) If you pull flow metrics from your system or generate Cumulative Flow Diagrams, having an item zip in and out of a Blocked column really screws that up. It also screws up cycle time calculations per stage. 4) We generally want to prioritize Blocked items that are closer to delivery than newer items. It's hard to see that in a Blocked column. 5) It looks hilarious when the very next stage after "Doing" is "Blocked." Talk about pessimism! Here's what I like to do instead: - Make "Blocked" a label or a flag or a status or something we can use to designate that an item is blocked without moving it anywhere - Make sure blocked items are visually indicated - special icon, card turns red, etc. - If you really want to elevate visual attention to Blocked items, create a swim lane at the top of your board and move your Blocked items there, leaving them in the same column. Hopefully you don't have blocked items often enough that this would be useful, but it's an unmissible visual indicator. Ultimately, what you want is to have blocked items always in your team's face, a way to have data on frequency and impact of blockers so you can improve, and you want the flow data of your system to be accurate. I think all those goals are better served without a Blocked column.