Managing Projects with Kanban Project Management
This skill teaches you how to plan, execute, and deliver entire projects using Kanban's pull-based system, replacing fixed sprint cycles with continuous flow, explicit policies, and data-driven forecasting.
Start by mapping your project's workflow into columns on a Kanban board, then decompose deliverables into cards sized to flow in 1-3 days. Set WIP limits per column, define explicit pull policies so team members pull work when capacity opens, and track cycle time and throughput to forecast completion. Replace sprint planning with continuous replenishment meetings where you pull the next highest-priority item into the system as capacity frees up.
Outcome: You can take a project from intake to delivery using pull-based scheduling, with predictable flow metrics, clear priority signals, and the ability to forecast delivery dates without fixed iteration commitments.
Prerequisites
- Basic understanding of Kanban boards and column-based workflows
- Familiarity with the concept of work-in-progress limits
- A defined project with known deliverables or a backlog of work items
- Access to a physical or digital Kanban board tool
Overview
Kanban project management replaces the fixed-iteration planning cycle with a continuous pull-based system where work enters the board when capacity exists and exits when it meets the definition of done. Instead of committing to a batch of work every two weeks, the team maintains a prioritized backlog and pulls the next most important item whenever a slot opens. This approach removes the artificial pressure of sprint boundaries, reduces context switching, and lets teams respond to changing priorities without waiting for the next planning ceremony. The concrete artifact you produce is a living Kanban board with explicit columns, WIP limits, pull policies, and a replenishment cadence that together form a lightweight but complete project management system.
The skill sits at the center of the Kanban method. Where sibling skills like designing boards and setting WIP limits address individual components, this skill is the integration layer. It connects board design, flow metrics, pull policies, and cadences into a coherent project lifecycle. You are orchestrating the system, not just configuring one part of it. A well-managed Kanban project looks deceptively simple from the outside: cards move left to right at a steady pace, blockers surface fast, and delivery dates become predictable within a range rather than a guess.
Success looks like this: your team can answer "when will this project be done?" with a probabilistic forecast grounded in throughput data rather than a gut estimate. Stakeholders can see progress without asking for a status update because the board is the status update. New priorities slot into the system without blowing up existing commitments because pull-based scheduling absorbs variability instead of fighting it. You stop spending time on sprint planning, sprint review prep, and velocity debates, and redirect that time into the work itself.
This skill is most valuable for teams that ship continuously, have unpredictable inflows of work (support escalations, ad-hoc requests, regulatory changes), or find that sprint boundaries create waste. It also works well for cross-functional projects where different disciplines (design, engineering, QA, marketing) have different throughput rates and forcing them into a shared sprint cadence creates idle time or rushed handoffs.
How It Works
The mental model behind kanban project management is the factory floor, not the calendar. In sprint-based systems, time is the organizing principle: you fill a fixed time container with as much work as you think will fit. In Kanban, capacity is the organizing principle: you limit how much work can exist in each stage simultaneously, and new work enters only when old work exits. This distinction changes everything about how you plan, prioritize, and forecast.
The system works because of Little's Law, a queueing theory principle that states: average cycle time equals work in progress divided by throughput. If your team has a throughput of 5 items per week and you maintain 10 items in progress, your average cycle time is 2 weeks. The only levers you have are WIP and throughput. Reducing WIP is the fastest way to reduce cycle time because it requires no new skills or resources, just discipline. This is why WIP limits are not optional in Kanban project management. Without them, you have a task board, not a Kanban system.
Pull-based scheduling means no one assigns work. Instead, each person looks at the board, checks whether they have capacity (is their current WIP below the limit?), and if so, pulls the top item from the previous column. This requires two things: a clearly prioritized input queue so the team knows what to pull next, and explicit pull policies so there is no ambiguity about what "ready to pull" means. For example, a pull policy for the "Development" column might state: "Pull only items that have an approved design mockup, acceptance criteria written, and no unresolved open questions." Without these policies, people pull whatever is easiest or most interesting, not what is most important.
Forecasting in Kanban is probabilistic, not deterministic. Instead of saying "we will deliver feature X on March 15," you say "based on our throughput over the last 8 weeks, there is an 85% chance we will deliver feature X by March 15 and a 50% chance we will deliver it by March 8." You build this forecast using throughput data (how many items you complete per week) and Monte Carlo simulation or simple percentile-based estimation. This approach is more honest and more accurate than velocity-based sprint forecasting because it accounts for variability rather than hiding it behind an average.
The assumptions that break this model are worth understanding. First, if your work items vary wildly in size (one card takes 2 hours, another takes 3 weeks), your throughput data becomes meaningless for forecasting. You need to decompose work into roughly similar-sized pieces, typically items that take 1-3 days to complete. Second, if your team composition changes frequently (people joining, leaving, or being pulled to other projects), historical throughput stops predicting future throughput. Third, if external dependencies block cards for long periods, your cycle time data will be skewed by wait time rather than work time. Tracking blocked time separately from active time lets you diagnose this.
Step-by-Step
Step 1: Define the project scope and decompose deliverables
Before touching a board, write down the project's goal in one sentence and list every deliverable needed to reach it. Break each deliverable into work items that can be completed in 1-3 days by a single person or pair. Use a simple rule: if you cannot describe the done state of an item in one sentence, it is too big and needs splitting. Each work item becomes a card.
Write a clear title, a one-sentence description of what "done" looks like, and tag it with its parent deliverable. Aim for 15-50 cards for a typical project. If you have fewer than 10, your items may be too large to flow predictably. If you have more than 100, consider whether you are really managing one project or several.
Tip: A quick decomposition heuristic: if an item requires more than one handoff between people, it is probably two items. Split at the handoff point.
Step 2: Map your workflow into board columns
Identify every distinct stage a work item passes through from start to finish. Common stages include Backlog, Ready, In Progress, In Review, and Done, but your real workflow may differ. The key is to model what actually happens, not what you wish happened. If work routinely sits waiting for QA, that wait state deserves its own column ("Awaiting QA") separate from "In QA" so you can see where items stall.
Keep the board to 4-7 columns. Fewer than 4 hides bottlenecks. More than 7 adds overhead without insight. Each column should represent a clear change in who is working on the item or what type of work is happening.
Tip: Add a "Blocked" swim lane or tag rather than a column. Blocked items should stay in their current column (making the bottleneck visible) rather than moving to a separate blocked column where they become invisible.
Step 3: Set initial WIP limits for each active column
Assign a maximum number of cards allowed in each column simultaneously. For your first attempt, use the formula: WIP limit = number of people working in that stage, plus one buffer item. So if 3 developers work in the "In Progress" column, set the limit to 4. This gives one person room to pull new work while others finish, without letting the column become a parking lot.
Do not set WIP limits on Backlog or Done columns. WIP limits are for active work stages only. Write the limit visibly on the board header. When a column hits its limit, no one may pull new work into it until an existing item moves forward.
This is the constraint that creates flow, and it will feel uncomfortable at first.
Tip: Start slightly tighter than comfortable. If the team constantly hits the limit and it causes real pain, raise it by one. If the limit never constrains anyone, it is too high and you should lower it. Revisit limits every two weeks for the first month.
Step 4: Write explicit pull policies for each column transition
For every boundary between columns, write a short checklist that defines when an item is eligible to be pulled into the next stage. For example, the transition from "Ready" to "In Progress" might require: acceptance criteria documented, no open questions flagged, design assets linked. The transition from "In Progress" to "In Review" might require: code committed to feature branch, unit tests passing, self-review checklist completed. Post these policies on the board or in the board tool's column description.
Pull policies prevent two costly problems: items entering a stage before they are truly ready (causing rework), and ambiguity about what "done" means at each stage (causing disputes). Review and refine these policies in your first retrospective.
Tip: Phrase policies as concrete checkboxes, not vague standards. "Has acceptance criteria" is checkable. "Is well-defined" is not.
Step 5: Prioritize the backlog with a single ordered list
Arrange every card in the Backlog column into a strict priority order, top to bottom. There should be no ties. When a team member has capacity, they pull the top card from the backlog, period. This eliminates priority debates during the workday and ensures the team always works on the most important thing available.
Use whatever prioritization method fits your project: cost of delay, stakeholder input, dependency order, or risk reduction. The method matters less than the outcome: a single, unambiguous sequence. Re-prioritize the backlog at your replenishment meeting (see Step 7), not on the fly. Frequent mid-day priority changes signal that you need better upfront prioritization, not a more flexible system.
Tip: If stakeholders cannot agree on a single priority order, ask them to stack-rank by cost of delay: "Which of these two items costs us more for every week it is not done?" This reframes priority from subjective importance to economic impact.
Step 6: Start pulling work and track cycle time from day one
With the board set up, the team begins pulling work. " The difference is the card's cycle time. Track this in your board tool or a simple spreadsheet. After one week, you will have initial cycle time data.
After two weeks, you will have enough throughput data (cards completed per week) to start simple forecasting. Do not skip this measurement step. Without cycle time and throughput data, you have no basis for forecasting, no way to detect deteriorating flow, and no evidence for whether process changes are helping or hurting.
Tip: Most digital Kanban tools track cycle time automatically. If using a physical board, keep a simple log: card name, start date, end date. Even this minimal data becomes powerful after 3-4 weeks.
Step 7: Establish a replenishment cadence
Schedule a regular meeting (typically twice per week for teams with throughput of 5+ items per week, or once per week for slower-flowing teams) where the team reviews the backlog, re-prioritizes if needed, and ensures enough ready items exist for the next few days of pulls. This meeting replaces sprint planning. It should take 15-30 minutes. The agenda is simple: review the top 5-10 backlog items, confirm they meet pull policies for the first active column, remove any that are no longer relevant, and add any new items that have arrived since the last meeting.
This cadence ensures the team never runs out of clearly prioritized, ready-to-pull work without requiring a heavyweight planning ceremony.
Tip: Time-box replenishment ruthlessly. If debates about priority take longer than 5 minutes on a single item, table it and schedule a separate discussion with the relevant stakeholders. The meeting's job is to keep the pipeline fed, not to resolve product strategy.
Step 8: Use throughput data to forecast delivery
After two or more weeks of operation, calculate your weekly throughput: total cards completed divided by number of weeks. Use this to forecast remaining work. If you have 30 cards remaining and your throughput is 8 cards per week, a simple forecast gives roughly 4 weeks to completion. For more accuracy, use percentile-based forecasting: sort your weekly throughput numbers, take the 50th percentile for a "likely" date and the 85th percentile for a "high confidence" date.
Share these forecasts with stakeholders. Update them weekly as throughput data accumulates. Forecasts become more accurate over time as your data set grows, which is the opposite of sprint-based estimation where accuracy degrades as the project evolves.
Tip: If stakeholders push for a single date, give them the 85th percentile and explain: "We are 85% confident we will finish by this date, and 50% confident we will finish a week earlier." This frames the conversation around risk tolerance rather than false precision.
Step 9: Run retrospectives focused on flow, not feelings
Every two weeks (or after a project milestone), hold a retrospective focused on flow data. Review: average cycle time this period versus last period, throughput trend, number of blocked items, and which columns had the most congestion. Identify one concrete process change to try in the next two weeks. Common changes include adjusting a WIP limit, adding or removing a column, tightening a pull policy, or changing the replenishment cadence.
" Instead, target specific flow problems: "Cards are waiting an average of 2 days in the Review column. " Test the change for two weeks, then evaluate with data.
Tip: Bring a cycle time scatter plot or histogram to the retrospective. Outliers (cards that took dramatically longer than average) are the most useful discussion starters because they reveal systemic blockers.
Examples
Example: SaaS Feature Launch for a Small Team (4 people)
A product team of 4 (1 designer, 2 developers, 1 QA) needs to ship a new billing dashboard within 6 weeks. The project has 8 major features, and the team has never used Kanban for project management before. They have been using ad-hoc task lists and weekly status meetings.
The team decomposes the 8 features into 38 work items, each sized to 1-3 days. They set up a board with 5 columns: Backlog, Ready, In Development (WIP limit: 3), In Review (WIP limit: 2), Done. Pull policies require that items in "Ready" have acceptance criteria and linked design mockups. The designer works ahead, feeding the Ready column so developers never starve.
In week 1, the team completes 6 items, establishing a baseline throughput. By week 2, throughput stabilizes at 7 items per week. 5 weeks, giving them a comfortable buffer. In week 3, they notice the Review column is consistently full, blocking developers from pulling new work.
The retrospective identifies that the QA engineer is also handling support tickets. They adjust by having developers do peer code review first, then QA does acceptance testing, splitting Review into two sub-columns. Throughput increases to 9 items per week. They deliver the billing dashboard in week 5, one week ahead of the 85th percentile forecast.
Example: Marketing Campaign Project for a Cross-Functional Team (8 people)
A marketing team of 8 (2 copywriters, 2 designers, 1 video producer, 1 social media manager, 1 email marketer, 1 project lead) is running a product launch campaign with 60+ deliverables across email, social, blog, video, and paid channels. The campaign spans 4 weeks from kickoff to launch day. Different team members work at very different speeds and have competing priorities from other projects.
The project lead decomposes the campaign into 64 cards grouped by channel using swim lanes (Email, Social, Blog, Video, Paid). The board has 6 columns: Backlog, Briefed, In Production (WIP limit: 10 across all lanes), In Approval (WIP limit: 4), Scheduled, Published. Pull policies for "In Production" require a completed creative brief with messaging, target audience, dimensions, and deadline. The team runs a 20-minute replenishment meeting every Monday and Thursday.
In week 1, throughput is 12 items, but 5 are stuck in Approval because the VP of Marketing is the bottleneck. The team changes the pull policy to allow the project lead to approve standard assets, escalating only brand-new messaging to the VP. Approval throughput doubles. By week 3, 50 of 64 items are in Scheduled or Published.
The remaining 14 items are all video content, which has a longer production cycle. The team identifies this bottleneck early because the Video swim lane's cycle time (6 days average) is triple the other lanes (2 days average). They bring in a freelance editor to increase video throughput. All 64 deliverables are published by launch day.
Example: B2B Enterprise Software Delivery (12-person engineering team)
A 12-person engineering team building enterprise compliance software needs to deliver a major release with 15 epics worth of work over a quarter. They previously used 2-week sprints but found that sprint boundaries caused thrashing: work items rarely fit neatly into sprints, and carryover averaged 30%. Stakeholders want monthly progress reports and a reliable ship date.
The team decomposes the 15 epics into 112 work items, each targeted at 1-2 days of work. They design a board with columns: Backlog, Refined, In Development (WIP limit: 8), Code Review (WIP limit: 4), In QA (WIP limit: 4), Staging, Released. Pull policies between Refined and In Development require that the item has a technical design decision documented, test scenarios listed, and no external dependencies unresolved. The team runs daily standup focused on blocked items and WIP limit violations, plus a weekly replenishment meeting on Mondays.
After 3 weeks, the team has throughput data: 22 items per week average. With 90 items remaining, the 50th percentile forecast is 4 weeks and the 85th percentile is 5 weeks. They share this with stakeholders in a one-line Slack update. In week 5, a new regulatory requirement adds 18 unplanned items.
Instead of panic, the team adds the items to the backlog, re-prioritizes with the product owner at the next replenishment meeting, and updates the forecast: 85th percentile pushes from week 9 to week 11. Stakeholders accept this because the forecast is grounded in data, not opinion. The team delivers in week 10, within the forecast range.
Example: Startup MVP Build (2-person founding team)
Two co-founders are building an MVP for a scheduling app. One handles front-end development and design, the other handles back-end and infrastructure. They have 8 weeks to build a demo for investor meetings. Neither has formal project management experience, and they are working remotely.
They list every feature needed for the demo and decompose them into 45 cards. The board is minimal: Backlog, Up Next (WIP limit: 2 per person), Doing (WIP limit: 1 per person), Needs Testing, Done. The strict WIP limit of 1 per person in Doing forces each founder to finish their current work before starting something new, preventing the common startup trap of having 10 things half-done. They use a shared Trello board and a 10-minute daily sync over video.
By week 2, throughput is 5-6 items per week (about 3 per person). With 35 items remaining, the forecast is 6-7 weeks, fitting their 8-week window. In week 4, the back-end founder gets stuck on payment integration, which blocks 4 downstream cards. The card has been in Doing for 3 days, violating their informal norm of 1-2 days per card.
They decide to descope payment to a simulated flow for the demo and add real payment integration as a post-funding item. This decision surfaces naturally because the blocked card is visually obvious on a board with WIP limits of 1. They deliver the MVP demo in week 7.
Best Practices
Decompose work items to a consistent size of 1-3 days before they enter the board. Inconsistent sizing destroys the predictive value of throughput data. If some cards take 2 hours and others take 2 weeks, your weekly throughput number is meaningless for forecasting. When you see a card lingering for more than 3 days, it is a signal to split, not a reason to wait.
Make the board the single source of truth for project status. Every conversation about what is happening, what is blocked, and what is coming next should reference the board. If stakeholders learn to check the board before asking for updates, you reclaim hours of status reporting time every week. If the board is out of date, people stop trusting it and revert to email and chat, which defeats the purpose.
Enforce WIP limits even when it feels unproductive. The instinct when hitting a WIP limit is to raise it or make an exception. Resist this. When a column is full, the correct response is to help move existing items forward, not to start new ones.
The discomfort is the system working. If a developer finishes their work but the Review column is at its limit, they should review someone else's work, pair on a stuck item, or address technical debt, not pull a new card.
Separate blocked time from active work time in your metrics. A card that sits blocked waiting for a third-party API key for 5 days has a 6-day cycle time but only 1 day of actual work time. If you do not distinguish these, you will misdiagnose flow problems as skill problems when they are actually dependency problems. Tag blocked cards with the reason and duration so retrospectives can target the right root cause.
Limit the number of priority classes to three: expedite, standard, and low. Expedite items bypass WIP limits and flow through the system as fast as possible, but there should never be more than one expedite item on the board at a time. If everything is urgent, nothing is urgent, and the system collapses. Standard items follow normal flow.
Low-priority items are pulled only when no standard items are available.
Update forecasts weekly and share them proactively. Do not wait for stakeholders to ask "when will this be done?" Send a one-line update: "30 items remaining, current throughput 7/week, 85% confidence date is April 12." This builds trust in the system and replaces the anxiety-driven status meetings that consume disproportionate time in traditional project management.
Review and refine pull policies monthly. Policies that were appropriate at project start may become stale as the team's maturity grows or as the nature of the remaining work changes. A pull policy that requires a design mockup makes sense during the feature-building phase but may be unnecessary during a bug-fixing phase. Keep policies tight enough to prevent rework but loose enough to avoid bureaucratic overhead.
Common Mistakes
Using a Kanban board without setting or enforcing WIP limits
Correction
A board without WIP limits is a task tracker, not a Kanban system. Without limits, work piles up in active columns, context switching increases, and cycle times balloon. The team feels busy but throughput stalls. You can catch this by checking whether any column regularly has more items than people working in it.
Set initial limits at team-size-plus-one per column and enforce them from day one. See setting WIP limits for detailed guidance.
Skipping work item decomposition and putting large, multi-week items on the board
Correction
Large items mask progress and destroy forecast accuracy. A card sitting in "In Progress" for 10 days gives the team no signal about whether it is 20% done or 90% done. This happens because teams carry over the habit of writing user stories sized for sprints rather than for flow. Watch for any card that has not moved columns in 3+ days.
Split it into smaller pieces that can complete in 1-3 days each. The splitting itself often reveals hidden complexity or dependencies that would have caused a late surprise.
Treating the Kanban board as a private team tool and not sharing it with stakeholders
Correction
When the board is not visible to stakeholders, they resort to asking for status updates via email, chat, and meetings. This creates reporting overhead that negates the efficiency gains of the system. It also means stakeholders never develop trust in the process and continue to push for sprint-like commitments. Share the board link, walk stakeholders through how to read it once, and point them to it every time they ask for status.
Within two weeks, most stakeholders will self-serve.
Constantly re-prioritizing the backlog mid-day based on whoever shouts loudest
Correction
Frequent priority changes cause cards to be started and abandoned, inflating WIP and cycle time. This happens when there is no defined replenishment cadence or when the team has not established who has authority to set priority. The symptom is cards with multiple start and stop dates, or a backlog that changes order daily. Fix this by establishing a fixed replenishment meeting and a single priority owner.
Between meetings, the priority order is frozen unless a genuine expedite-class emergency arises.
Ignoring flow metrics and running the project by gut feel
Correction
Without cycle time and throughput data, you cannot forecast, you cannot detect flow degradation until it is severe, and your retrospectives devolve into opinion-based debates. This happens because teams see measurement as overhead rather than as the foundation of continuous improvement. Start tracking on day one, even if just in a spreadsheet. After three weeks of data, you can forecast.
After six weeks, you can identify trends. The investment is five minutes per day of logging; the return is reliable delivery forecasting.
Adding too many columns to the board in an attempt to model every sub-step
Correction
Boards with 10+ columns create cognitive overhead, make it hard to spot bottlenecks at a glance, and slow down daily standups because there is too much surface area to review. This happens when teams try to model their ideal process rather than their actual process. Start with 4-5 columns that represent genuinely different work states. If you suspect a bottleneck inside a column, split it into two columns temporarily to confirm.
If the data shows no bottleneck, merge them back.
Other Skills in This Method
Running Kanban Cadences and Feedback Loops
How to facilitate the seven Kanban cadences — including standups, replenishment meetings, delivery planning, and service delivery reviews — to enable continuous improvement.
Setting and Enforcing Work-in-Progress Limits
How to determine optimal WIP limits for each workflow stage to reduce bottlenecks, improve flow, and prevent team overload.
Designing Effective Kanban Boards
How to structure columns, swimlanes, and card layouts on a Kanban board to accurately visualize your team's workflow from intake to completion.
Measuring Kanban Flow Metrics
How to track and interpret lead time, cycle time, throughput, and cumulative flow diagrams to continuously improve delivery performance.
Creating Explicit Pull Policies and Workflow Rules
How to define clear entry and exit criteria for each Kanban column so the team knows exactly when and how to pull work forward through the system.
Comparing Kanban and Scrum for Your Team
How to assess the differences between Kanban's continuous flow and Scrum's sprint-based approach to choose or combine the right method for your context.
Choosing the Right Kanban Tools and Software
How to evaluate and select digital Kanban tools like Trello, Jira, and Asana based on team size, workflow complexity, and integration needs.
Related Skills from Other Methods
Frequently Asked Questions
How do I handle deadlines in kanban project management if there are no sprints?
Deadlines are handled through forecasting rather than commitment. Use your throughput data to calculate a probabilistic delivery date: count remaining items, divide by your average weekly throughput, and present the 50th and 85th percentile dates. If the forecast shows you will miss the deadline, you have three options: reduce scope, increase throughput (add people or remove impediments), or negotiate the deadline. The key difference from sprints is that you get this signal continuously, not just at sprint boundaries, so you catch problems earlier.
How long should it take to set up kanban project management for a new project?
Initial setup takes 2-4 hours: about 1 hour to decompose deliverables into cards, 30 minutes to design the board columns, 30 minutes to set WIP limits and write pull policies, and 30-60 minutes to prioritize the backlog. The system becomes useful on day one, but the real payoff starts at week 2-3 when you have enough throughput data to forecast. Do not over-engineer the setup. Start simple and refine based on retrospective insights.
Should I manage projects with Kanban before or after establishing flow metrics?
Start the project and begin measuring simultaneously. You do not need historical data to set up a Kanban board and start pulling work. Metrics accumulate naturally as work flows through the system. Waiting until you have "enough data" before starting is a common procrastination trap. After 2 weeks of operation, you will have enough cycle time and throughput data for basic forecasting. After 4-6 weeks, your forecasts will be reliable. See [measuring flow metrics](/skills/measuring-kanban-flow-metrics) for detailed guidance on what to track.
How do I manage dependencies between cards on a Kanban board?
Make dependencies explicit on the cards themselves. Tag dependent cards with the ID of the card they depend on, and add a pull policy that prevents pulling a dependent card until its prerequisite is Done. Visually, use colored tags or link indicators so dependencies are visible at a glance. During the daily standup, call out any dependency chains that are at risk. If you have many interdependent cards, consider grouping them in a swim lane so the team can focus on completing the chain end-to-end before starting unrelated work.
Why does my Kanban board keep turning into a giant to-do list with no flow?
This happens for two reasons. First, you probably do not have WIP limits set or enforced. Without limits, people keep pulling new work without finishing existing work, and the board fills up with half-done items. Second, your work items may be too large. If cards sit in a column for a week, the board looks static and feels like a list rather than a flow system. Fix both: set strict WIP limits (smaller than you think you need) and decompose items to 1-3 days. Flow should be visible daily.
How do I manage a Kanban project when team members split time across multiple projects?
Reduce their WIP limit proportionally. If someone spends 50% of their time on your project, their personal WIP limit should be 1, not 2. This prevents them from pulling more work than they can realistically finish. Also adjust your throughput expectations. A team of 4 people who each spend 50% of their time on your project has an effective team size of 2 for forecasting purposes. Be honest about this in your capacity planning rather than pretending you have a full team and being surprised when throughput is half of what you projected.
Can I use Kanban project management alongside Scrum or other frameworks?
Yes, many teams use a hybrid approach, sometimes called Scrumban. You keep sprint boundaries for planning and review ceremonies but add WIP limits and pull-based work selection within the sprint. Over time, many teams find the sprint boundaries add less value as the Kanban practices mature, and they gradually shift to pure flow. See [comparing Kanban and Scrum](/skills/comparing-kanban-and-scrum) for a detailed breakdown of when each approach fits and how to transition between them.