Why Web Teams Need Kanban More Than Ever
Web development projects are chaotic by nature. Between client change requests, bug fixes, feature development, content updates, and deployment schedules, the average web team juggles 15-25 active tasks at any given moment. Without a clear system to visualize and manage this work, teams drown in context-switching and missed deadlines.
Kanban — a Japanese word meaning “visual signal” — offers a deceptively simple solution: make all work visible, limit how much you do at once, and optimize the flow. Originally developed by Toyota in the 1940s for manufacturing, Kanban has been adapted brilliantly for knowledge work, particularly software and web development.
Teams that implement Kanban correctly report 25-50% reductions in lead time and significant improvements in predictability. At Lueur Externe, where we’ve managed complex web development projects since 2003, we’ve seen firsthand how transitioning from ad-hoc task management to a disciplined Kanban system transforms delivery speed and team morale.
Let’s explore how to set up and run a Kanban system tailored for web teams.
The Core Principles of Kanban
Before diving into board configurations and tools, it’s essential to understand the four foundational principles that make Kanban work:
- Visualize the workflow — Every piece of work must be represented as a card on a board.
- Limit work in progress (WIP) — Set explicit caps on how many items can be in each stage simultaneously.
- Manage flow — Monitor how work moves through the system and identify stalls.
- Continuously improve — Use data to make incremental process adjustments.
These principles sound simple, but their power lies in rigorous application. Many teams create a board but ignore WIP limits — that’s not Kanban, that’s just a to-do list with columns.
Designing Your Web Team’s Kanban Board
Mapping Your Actual Workflow
The first step is honest: map what actually happens to a task from inception to completion. Don’t design an idealized process. Observe your real workflow for a week, noting every handoff and waiting state.
For most web development teams, the workflow looks something like this:
| Column | Description | Typical WIP Limit |
|---|---|---|
| Backlog | All requested work, prioritized | No limit |
| Ready | Refined, estimated, ready to start | 5-8 items |
| Design/UX | Visual design or wireframing in progress | 2-3 |
| Development | Active coding | 3-5 (depends on team size) |
| Code Review | Peer review pending or in progress | 2-3 |
| QA/Testing | Quality assurance and cross-browser testing | 2-3 |
| Staging | Deployed to staging, awaiting approval | 2 |
| Done | Live in production | No limit |
Adding Waiting States
One critical improvement most teams miss: distinguish between active and waiting states. For example, split “Code Review” into “Code Review (Active)” and “Waiting for Review.” This makes bottlenecks painfully visible.
When you see 6 items stacking up in “Waiting for Review” but only 1 in active review, you know exactly where the problem is — and you can address it immediately.
Swim Lanes for Different Work Types
Web teams typically handle multiple work categories simultaneously:
- Feature development — New functionality or pages
- Bug fixes — Urgent and non-urgent defects
- Maintenance — Updates, security patches, plugin upgrades
- Content — Copy changes, media updates, SEO optimizations
Using horizontal swim lanes separates these streams visually. A common configuration reserves a dedicated “expedite” lane at the top for critical bugs that bypass normal WIP limits.
Setting Effective WIP Limits
The Math Behind WIP Limits
WIP limits are Kanban’s secret weapon. Without them, you just have a pretty task board. The principle is rooted in queueing theory: the more items in progress simultaneously, the longer each one takes.
Here’s a practical formula for starting WIP limits:
WIP Limit per column = Number of people working in that stage × 1.5
Example:
- 3 developers → Development WIP limit = 4-5
- 2 QA testers → Testing WIP limit = 3
- 1 designer → Design WIP limit = 2The 1.5 multiplier allows for some slack (waiting on feedback, blocked items) without enabling overload. Adjust after 2-3 weeks of data collection.
What Happens When You Hit the Limit
When a column reaches its WIP limit, no new work can enter until something moves forward. This creates productive pressure:
- Developers can’t start new tasks, so they help with code reviews
- The team swarms on bottlenecks instead of ignoring them
- Managers stop adding “just one more thing” because the system visibly resists
This is uncomfortable at first. Teams accustomed to starting everything immediately feel constrained. But within 2-4 weeks, delivery speed improves measurably because items stop aging in the system.
Kanban Metrics That Matter for Web Teams
Lead Time vs. Cycle Time
These two metrics are your primary health indicators:
- Lead time — Total time from when a request enters the backlog to when it’s deployed to production. This is what clients care about.
- Cycle time — Time from when active work starts to completion. This is what your team controls.
For web projects, healthy benchmarks look like:
- Small bug fix: 1-2 days cycle time
- Standard feature: 3-7 days cycle time
- Complex page build: 5-15 days cycle time
If your cycle times exceed these ranges significantly, your board will show you exactly where work is stalling.
Cumulative Flow Diagram
The cumulative flow diagram (CFD) is the most powerful Kanban analytics tool. It plots the number of items in each column over time. A healthy CFD shows relatively parallel bands. When bands widen, work is accumulating. When they narrow, you’re draining a backlog.
Most tools (Jira, Trello with plugins, Linear) generate CFDs automatically. Review yours weekly.
Throughput
Throughput measures how many items your team completes per week. Unlike velocity in Scrum (which requires story points), throughput is simply a count. Over time, it becomes remarkably predictable and enables data-driven forecasting:
- “We complete 8-12 items per week on average”
- “There are 30 items in the backlog”
- “Therefore, we’ll clear the backlog in approximately 3-4 weeks”
This probabilistic forecasting is far more honest than deterministic Gantt chart promises.
Choosing the Right Kanban Tool
The tool matters less than the process, but here’s a comparison of popular options for web teams:
| Tool | Best For | Price (per user/month) | Key Strength |
|---|---|---|---|
| Trello | Small teams, simplicity | Free - $10 | Intuitive drag-and-drop |
| Jira | Larger teams, detailed reporting | $7.75 - $15.25 | Advanced analytics, CFDs |
| Linear | Developer-focused teams | Free - $8 | Speed, keyboard shortcuts |
| Notion | Teams wanting docs + boards | Free - $8 | All-in-one workspace |
| GitHub Projects | Open-source or GitHub-native teams | Free | Tight code integration |
| Kanbanize | Enterprise Kanban purists | $149/15 users | True WIP enforcement |
Our Recommendation
For web agencies and development teams under 15 people, Linear or Jira typically offer the best balance of Kanban features and developer experience. For client-facing boards where non-technical stakeholders need visibility, Trello’s simplicity wins.
At Lueur Externe, we often configure hybrid setups: an internal board in Linear or Jira for the development team, with automated status syncing to a simplified client-facing board. This gives the team the detail they need without overwhelming clients.
Implementing Kanban: A Step-by-Step Approach
Week 1-2: Discovery and Setup
- Observe your current workflow for 5 days without changing anything
- Document every stage work passes through, including waiting states
- Create your board with columns matching reality (not aspiration)
- Set initial WIP limits using the formula above
- Move all current work-in-progress onto the board
Week 3-4: Stabilization
- Hold daily 10-minute standups focused on board flow, not individual status reports
- Ask: “What’s blocked? What’s been in this column the longest? Where are we at the WIP limit?”
- Track cycle time for every completed item
- Resist the urge to change WIP limits — gather data first
Week 5-8: Optimization
- Analyze your first month of data
- Identify the column where items spend the most time
- Adjust WIP limits (tighten if work moves too fast with quality issues, loosen if the team is idle)
- Add or merge columns based on observed patterns
- Establish service level expectations (e.g., “85% of bug fixes complete within 48 hours”)
Ongoing: Continuous Improvement
Hold a bi-weekly or monthly retrospective focused specifically on flow:
- What types of work are taking longer than expected?
- Are there recurring blockers?
- Should we adjust WIP limits?
- Is any column consistently empty (merge it) or overflowing (split it)?
Common Kanban Mistakes Web Teams Make
Mistake 1: No WIP Limits
A board without WIP limits is a glorified to-do list. It provides visibility but doesn’t improve flow. Enforce limits even when it feels painful — especially when it feels painful.
Mistake 2: Too Many Columns
Starting with 12 columns creates overhead and confusion. Begin with 5-6 and add complexity only when data justifies it.
Mistake 3: Ignoring Blocked Items
When a card sits in one column for days, it should trigger action — not become invisible wallpaper. Flag blocked items visually (red label, blocked indicator) and discuss them daily.
Mistake 4: Using Kanban for Everything
Kanban works beautifully for ongoing operational work. For large, multi-month projects with complex dependencies, you might need additional planning layers. Kanban handles execution; you still need roadmap-level planning above it.
Mistake 5: Not Involving the Whole Team
Designers, developers, QA engineers, and project managers all need to own the board together. If only the PM updates cards, you lose the real-time accuracy that makes Kanban valuable.
Kanban for Client Communication
One underrated benefit of Kanban for web agencies: client transparency. When clients can see a board (even a simplified version), several problems disappear:
- “Where is my project?” emails decrease by 60-80%
- Scope creep becomes visible — clients see what adding items does to the queue
- Priority discussions become concrete — “Which of these 5 items should move to Ready next?”
- Trust increases because progress is demonstrable, not just claimed
We’ve found at Lueur Externe that sharing a read-only Kanban view with clients transforms the agency-client relationship from adversarial (“Are they even working on this?”) to collaborative (“I can see exactly what’s happening and where I can help unblock things”).
Integrating Kanban with Your Development Pipeline
For maximum effectiveness, connect your Kanban board to your technical infrastructure:
# Example: GitHub Actions workflow that moves Kanban card on deployment
name: Move Card to Done on Deploy
on:
push:
branches: [main]
jobs:
update-board:
runs-on: ubuntu-latest
steps:
- name: Move linked card to Done
uses: your-kanban-integration/move-card@v1
with:
api-key: ${{ secrets.KANBAN_API_KEY }}
target-column: "Done"
trigger: "commit-message-contains-card-id"This automation ensures the board always reflects reality. When a developer merges code and it deploys to production, the card moves automatically. No manual updates, no stale boards.
Other valuable integrations include:
- Pull request opened → Card moves to “Code Review”
- Tests pass in CI → Card moves to “QA/Testing”
- Client approves in staging → Card moves to “Ready to Deploy”
Scaling Kanban Across Multiple Projects
Web agencies rarely work on a single project. When managing 5-10 active client projects simultaneously, you need a multi-level Kanban approach:
- Portfolio level — One board showing all projects as cards, with columns like “Proposal,” “Active,” “Maintenance,” “Completed”
- Project level — Individual boards per project with the workflow described above
- Personal level — Optional personal boards for individuals managing cross-project tasks
The portfolio board helps leadership allocate resources and identify when the agency is over-committed. The project boards help teams execute. Both are essential at scale.
Conclusion: Start Simple, Improve Continuously
Kanban’s greatest strength is its low barrier to entry. You don’t need certifications, role changes, or process overhauls to start. Tomorrow morning, you could:
- Draw 5 columns on a whiteboard (or create a Trello board)
- Write your current tasks on sticky notes
- Set a WIP limit of 3 in your “In Progress” column
- Commit to not starting new work until something finishes
That’s a valid Kanban system. Everything else — metrics, automation, swim lanes — is optimization on top of these fundamentals.
For web teams specifically, Kanban aligns perfectly with the continuous, varied nature of the work. Unlike Scrum’s sprint commitments, Kanban accommodates the reality that clients call with urgent requests, production servers throw errors, and priorities shift weekly.
If you’re ready to bring structured, data-driven workflow management to your web projects — or if you need a team that already operates this way — Lueur Externe can help. With over 20 years of experience delivering web projects across e-commerce (Prestashop), WordPress, and custom AWS architectures, we bring both the technical expertise and the process discipline to ship your project predictably.
Get in touch with our team to discuss how we can optimize your web development workflow.