Using Kanban Boards for Task Management

Unlike a push system, where work is pushed onto teams regardless of their capacity, pull systems prevent team overburden and increase workflow efficiency. Teams pull work as they finish what they started while keeping their focus on the highest priorities. Kanban pull systems significantly improve productivity and decrease delivery times. To implement and maintain a pull system with the Kanban Method, you need to follow four main steps: visualize your workflow, establish a pull system, limit work in progress, and apply pull signals. Dive deeper into how maintaining a Kanban pull system and using analytics to spot bottlenecks early, prevents delays and improves flow efficiency.

From 87 days to 16 days - an 82% reduction I’m working with a client who, as part of my assignment, put me in charge of a support team for one of its enterprise applications. When I was officially given the reigns of the team, the average open ticket age was 87 days. I had already done some work with the team that reduced that number prior to being put in the leadership role, but 87 is the first measurement I have. (Note to self: get better at collecting “before metrics - always bites me.) As of this morning, we are at a 16 day average. That’s an 82% reduction in the average age of open tickets - achieved in roughly 3 months. We’ve also: *Reduced the quantity of open tickets by 67% *Reduced cycle time by ~70% *Increased customer satisfaction *Increased throughput How did we (I say “we” bc I couldn’t have done it without the fabulous team sticking with me through multiple small changes) achieve this? * Simplify the workflow. When I first saw the workflow the team was using in Jira, it looked like a bunch of scribbles on a page. It was impossible to understand how work flowed through their system. We moved to a very simple, left to right flow. * “Blocked” is a state, not a workflow step. It means we need to resolve the block, not that we put it in the closet and forget about it. * Clarify next action to be taken when a team member frees up: we work items on a Kanban board sorted by priority and date. We work top to bottom, right to left. * Remove sub queues: each team member only “owns” tickets they are actively working. Also, we leave comment trails so any team member can work a ticket at any stage in the workflow. Team members being sick, taking vacation, etc. doesn’t mean tickets stop being processed. * Removed SLAs. The team had SLAs to “respond” to tickets within a small time window. This led to tickets being responded to immediately, causing distraction and leaving tickets owned by whoever responded first. A customer would be told “we’re working on this” but in reality no work was being done- often for weeks or months. These changes aren’t huge or revolutionary, but they allow focus. They ensure we “stop starting and start finishing.” If you’ve got a struggling team or two and could use help to deliver more effectively, let’s chat!

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.

Looking for a more innovative way to stay on top of your projects? Here’s a productivity hack to help you manage your workload and get a clear view of what’s coming next: 👉 Create a Personal Kanban Board with Strategic Columns (and WIP Limits). Here’s how to set it up for maximum oversight: 1. Set Up Columns Like These:   - "Backlog" for upcoming projects and ideas.   - "Prioritized" for tasks you're ready to tackle next.   - "In Progress" to track active projects.   - "Review" for projects needing approval or feedback.   - "Completed" to celebrate wins and capture lessons learned. 2. Add WIP Limits: Keep your workload manageable and focused without overcommitting. 3. Maintain Oversight: Visualizing tasks across these stages helps track projects, identify bottlenecks, and manage incoming requests without feeling overwhelmed. Bonus: Building your Kanban board is a skill in itself. As you refine it, you’ll discover the nuances—from setting the right WIP limits to designing columns that suit your workflow. It’s not just about managing tasks but mastering the process. Make your Kanban board a central tool for oversight, not just task tracking. Your projects—and productivity—will thank you. What's your experience with Kanban boards? Share your thoughts below! Like this post if you're ready to take control of your workflow, and follow me for more productivity tips! 🚀

Increase Flow By Reducing Work in Progress ‘Many teams struggle to get sufficient flow because they work on too many things at the same time. …the problem with this is that there’s just too much going on in the Doing column. Encourage your team to reduce their work-in-progress or work on fewer things simultaneously. In spite of the many indications that reducing work-in-progress actually makes us deliver more, faster, as humans, we often feel that starting work is a sign of progress; the reality is it’s an illusion. In many cases, starting work prematurely will actually slow you down because now you incur the costs of context switching. When you focus on reducing work-in-progress, don’t forget to take your stakeholders on the journey. If you don’t, expect to face pressure from them when they see you suddenly not starting additional work—in the past, for them, starting work was an indication of progress, now that you are mobbing, they need to re-calibrate. While the stakeholders are still re-calibrating, expect them to occasionally put you under pressure to start multiple pieces of work. At times like this, you need to stand firm, reassure them that you believe you’re working in the most effective way possible (you really do need to believe this) and that your priority is to finish features faster, not start features sooner. Often, all it takes for them to be comfortable is reassurance from you that you’re doing what you’re doing for the right reasons. When your team starts to reduce work-in-progress and focus on flow, it helps to have a guide or set of principles they can operate by. When considering a set of principles, keep these in mind: • Finishing “in-flight” work is better than starting new work. • Working together is better than working alone. • Sharing knowledge is better than being the expert. Different development methodologies support these principles more than others; for mobbing to work, it’s important that your overall development methodology supports flow. While Mob Programming works well with a variety of processes (see Mob Programming and Scrum, Kanban, Waterfall, etc., on page 68), it works particularly well with kanban. Over 50% of respondents on my industry survey of Mob Programming indicated that they were using a kanban methodology. Kanban is all about explicitly limiting work-in-progress with the idea that the fewer things in flight, the quicker they’ll get done. If you’re not familiar with kanban, it may be worth checking it out to see if it’s a good match for your team’s overall development needs. It’s quite possible, through mobbing, for a team to get to this…’ ― Mark Pearl https://lnkd.in/gi6JPFVb #MobProgramming #EnsembleProgramming