Written by the AgileFever editorial team. Facts checked on November 6, 2026 against the official pages of the organizations named in this post. AgileFever sells training for some of the topics covered here, and we say so wherever it applies. Metric definitions are quoted from the Kanban Guide, version 2025.5. The worked example uses invented numbers, labelled as such.
Teams that move from Scrum to Kanban search for kanban velocity because they want the same number they used to report. The honest answer is that the number does not carry over. Kanban measures flow in counts and elapsed time, and that is better for forecasting than points. This post defines each term, computes throughput and cycle time from a small dataset, and shows how to switch a team over.
Kanban velocity: what the term means and where it comes from
Velocity is a common practice among Scrum teams that estimate in story points: add up the points of the stories finished in a sprint, and you have the sprint’s velocity. The Scrum Guide (2020 edition) does not use the word velocity or the phrase story points, so this is a team practice and not a defined Scrum rule. The Kanban Guide does not use either term. Searching for kanban velocity therefore finds blog posts that borrow the word, not a definition.
What the Kanban Guide from Kanban University (version 2025.5, updated May 1, 2025) does define is a set of flow metrics. It says throughput is “the number of work items finished per unit of time” and that its measurement is the exact count of work items. No estimate, point or size enters the calculation. That is the main difference from velocity.
Velocity, throughput, cycle time, lead time, WIP and work item age
Use this table as the glossary for your team. The last column shows which terms the Guide defines.
| Term | Meaning | Unit | In the Kanban Guide? |
|---|---|---|---|
| Velocity | Story points finished per sprint, a Scrum team practice | Points per sprint | No. Not defined, and the Scrum Guide does not define it either. |
| Throughput | The number of work items finished per unit of time | Items per day or week | Yes. Exact count of items. |
| Cycle time | Elapsed time between when a work item started and when it finished | Days (calendar) | Yes. The Guide notes it can be called flow time. |
| Lead time | Commonly: elapsed time from a customer request to delivery, so it includes waiting before the work starts | Days (calendar) | No. A common term; define where it starts in your policies. |
| Work in progress (WIP) | The number of work items started but not finished | Items | Yes. |
| Work item age | Elapsed time between when a work item started and the current date | Days, for unfinished items | Yes. |
The Guide also says these metrics can go by other names. Cycle time, for example, is sometimes called flow time. For the full detail on each, read our posts on Kanban cycle time, flow time and lead time.
The three measures connect through Little’s Law: average WIP equals average throughput multiplied by average cycle time. If the team keeps 6 items in progress and finishes 3 a week, the average item takes about 2 weeks. Lower the WIP and cycle time falls, with no change in the points.
Worked example: computing throughput and cycle time
Take a small support team over three weeks. These numbers are illustrative. Each row below lists the cycle time, in days, of every item that finished that week.
| Week | Items finished (throughput) | Cycle time of each item (days) | Sum of days |
|---|---|---|---|
| Week 1 | 5 | 3, 5, 2, 8, 4 | 22 |
| Week 2 | 7 | 2, 4, 6, 3, 12, 5, 3 | 35 |
| Week 3 | 4 | 7, 3, 9, 4 | 23 |
| Total | 16 | 80 |
Illustrative data created for this post.
Throughput is the count: 5, 7 and 4 items, an average of 16 / 3 = 5.33 per week. Cycle time is the elapsed time per item. The 16 values sorted are 2, 2, 3, 3, 3, 3, 4, 4, 4, 5, 5, 6, 7, 8, 9, 12. The average is 80 / 16 = 5.0 days and the median is 4 days. The 85th percentile is 7.75 days, which we round up to 8: 85% of items in this sample finished within 8 days.
Notice what the average alone hides. One item took 12 days, more than twice the average. That is why Kanban teams quote a percentile, and why the Guide asks for a service level expectation: a forecast of how long an item should take, with a period and a probability. For this team a fair statement is “85% of items finish within 8 days.”
Now extend the view to 12 weeks. The chart shows the weekly counts, the average and the level the team reached in 85% of weeks. The low-side line is the right one for planning: you want to know the throughput you can almost always count on, not the best week.
Items finished each week. The red line is the 12-week average (5.83). The green line is the level the team met or beat in 85% of weeks (4.65).
Example data created for this post, not from any company. Y-axis: work items finished per week.
Over the 12 weeks the team finished 70 items: 5, 7, 4, 6, 8, 5, 6, 3, 7, 6, 5 and 8. The average is 70 / 12 = 5.83 per week. Sorted, the weekly counts are 3, 4, 5, 5, 5, 6, 6, 6, 7, 7, 8, 8, and the 15th percentile is 4.65 (Excel’s PERCENTILE.INC). Read it as: in 85% of weeks, the team finished at least 4.65 items, so plan on 4 per week with confidence and 5 to 6 as the typical pace.
Why story-point velocity misleads in a flow system
Kanban velocity, if you build it, inherits the problems of points and adds new ones, because a Kanban team pulls items continuously and has no sprint boundary to total over.
| Problem | What happens | What throughput does instead |
|---|---|---|
| Points are estimates | A story that took 2 days can be 8 points or 3 points depending on who estimated it. | Counts one item as one item. No estimate to argue about. |
| Points drift | Teams re-estimate upward when asked to raise velocity. The number rises and delivery does not. | A count cannot be inflated without finishing more items. |
| No sprint boundary | Without a fixed period, you must pick an arbitrary window to total points. | Items per week works for any period, and rolls forward every week. |
| Hides waiting time | Points say nothing about how long an item sat blocked or queued. | Pair throughput with cycle time and work item age to see the waiting. |
| Not comparable | Team A’s 40 points and Team B’s 25 points mean nothing side by side. | Counts are comparable when item sizes are broadly similar. Still avoid ranking teams. |
A short illustration with invented numbers. Sprint A: the team finishes 3 large stories worth 26 points. Sprint B: the team finishes 8 small stories worth 24 points. Velocity says the two sprints were nearly the same. Throughput says 3 against 8, and that gap is what customers experience and what your forecast needs. Points flattened a real change in how work flows.
How to move from velocity to throughput forecasting
Take finished work from your tracker and count items per week, ignoring the points. If sprint data is all you have, count the stories finished in each sprint.
For each finished item, note the date it started and the date it finished. That gives you cycle time without any estimate.
Replace the velocity line in the sprint review or weekly review with items finished per week and the 85th percentile cycle time.
Divide remaining items by weekly throughput at two levels: the average and the 85% level. Quote both as a range, never a single date.
Review the oldest unfinished items every day. Set a WIP limit so age and cycle time stop growing.
Keep points only if they help the team talk about a story. Do not feed them into the forecast.
Use a rolling window of 4 to 6 weeks of throughput. Shorter windows swing too much with one bad week, and longer ones lag behind real change in the team. For the example team, the last 6 weeks average 5.83 and the last 4 average 6.5. Both fall inside the 12-week range, so the forecast is stable.
Now forecast a backlog of 30 items. At the average of 5.83 per week it takes 30 / 5.83 = 5.1 weeks. At the 85% level of 4.65 per week it takes 30 / 4.65 = 6.5 weeks, which we round up to 7. Tell the stakeholder: “About 5 weeks is typical, and we are 85% confident of finishing within 7.” This is a range with a stated probability, and it is far easier to defend than a velocity-based date. Remember that it assumes the team keeps its WIP limit and the arrival of new work stays similar.
Spreadsheet formulas for Kanban throughput and cycle time
You need three columns: item, start date and finish date. Put dates in Excel or Google Sheets date format. The formulas below assume items in rows 2 to 17, start dates in B and finish dates in C, week starting dates in F2 to F13 and weekly counts in G2 to G13.
| What you want | Formula | Notes |
|---|---|---|
| Cycle time per item | =C2-B2 |
Calendar days between start and finish. Some teams add 1 to count the start day. Choose one rule and write it in your policies. |
| Throughput for the week | =COUNTIFS($C$2:$C$17,">="&F2,$C$2:$C$17,"<"&F2+7) |
Counts items whose finish date falls in the week starting at F2. |
| Average weekly throughput | =AVERAGE(G2:G13) |
Use the rolling 4 to 6 weeks for forecasts. |
| Rolling 6-week average | =AVERAGE(G8:G13) |
Move the range down one row each week. |
| Throughput you meet in 85% of weeks | =PERCENTILE.INC(G2:G13,0.15) |
The 15th percentile: 85% of weeks were at or above it. |
| 85th percentile cycle time | =PERCENTILE.INC(D2:D17,0.85) |
Column D holds the cycle times. This is the number for your service level expectation. |
| Work item age (unfinished) | =IF(C2="",TODAY()-B2,"") |
Shows age only for items without a finish date. |
| Weeks to finish N items | =N/G_average |
Run it with the average and again with the 85% figure. |
For the board that feeds these columns, copy the structure from our Kanban board template and see Kanban board examples for how teams in different functions lay out their workflow. Our post on Kanban metrics and how to track them covers charts such as the cumulative flow diagram, and Kanban principles vs practices explains how measurement fits with the rest of the method.
Mistakes teams make when they measure Kanban velocity
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| Converting throughput into points to get a kanban velocity | Reintroduces estimates and the arguments over them. | Keep the count. Report items per week. |
| Quoting one average cycle time | Hides slow items. One 12-day item sits behind a 5-day average. | Quote the 85th percentile and show the spread. |
| Forecasting from one good week | The best week is not the typical week. | Use a rolling 4 to 6 weeks and a range. |
| Setting a throughput target | People split items or close them early to hit the number. | Use throughput to forecast and to ask questions, not to rate people. |
| Comparing teams by throughput | Item sizes and work types differ. | Compare each team with its own history. |
| Ignoring work item age | Finished work shows only the past. Old items on the board are the risk now. | Check the oldest items daily. |
| Mixing very different work types in one count | Support tickets and large features distort the average. | Measure each work item type separately, or slice features. |
Learn flow metrics with Kanban University courses
AgileFever delivers Kanban University courses. The practitioner course is Team Kanban Practitioner (TKP), an 8-hour class for team members that covers board design and daily practice. As listed on November 6, 2026, TKP is $550 (regular price $600) or Rs 14,000 (regular Rs 14,999), and buyers in India pay 18% GST at checkout on top of the rupee price. Batches listed that day include November 7 to 8, November 20 and November 26 to 27, 2026. See the Team Kanban Practitioner course page.
For leads and managers who improve flow across a service, Kanban Systems Improvement (KSI) is a 16-hour course. It is listed at $1,100 or Rs 27,000 (before GST) with batches on November 16 to 18, November 21 to 22 and December 14 to 16, 2026, as listed on November 6, 2026. Details are on the Kanban Systems Improvement page. Prices and dates change, so confirm them on the course pages.
Additional discounts are available. Contact us to know more.
Questions people ask
Is there velocity in Kanban?
Not as a defined metric. The Kanban Guide defines work in progress, throughput, work item age and cycle time, and it does not mention velocity. Velocity is a Scrum team practice based on story points. Kanban teams track throughput, the count of items finished per period, and forecast with it.
What is the Kanban equivalent of velocity?
Throughput is the closest equivalent: the number of work items finished per unit of time, such as per week. It is a plain count, so it needs no story points. Pair it with cycle time to say how long items take, and use ranges to forecast.
How do you measure Kanban team performance?
Track throughput, cycle time, work item age and WIP. Report the 85th percentile of cycle time, not only the average, and review the oldest unfinished items daily. Compare a team with its own history. Do not use these numbers to rank people or teams.
What is the difference between throughput and velocity?
Throughput counts finished work items per period, such as 6 items a week. Velocity adds up the story points of finished stories per sprint, such as 30 points. Throughput needs no estimates and works without sprints, which is why it suits a continuous flow.
How many weeks of data do I need to forecast with throughput?
Use a rolling window of 4 to 6 weeks as a starting point. Fewer weeks swing too much with one unusual week, and many more weeks react slowly to real change. Quote a range, such as the average and the level met in 85% of weeks.
What is the difference between lead time and cycle time?
Per the Kanban Guide, cycle time runs from when an item started to when it finished. Lead time is commonly measured from the customer’s request, so it also includes the wait before work starts. Write down where each clock starts in your team policies.
Can I use story points in Kanban?
You can, if they help the team discuss a story, but do not use them to forecast. Forecast from counted items and cycle time. If you keep points, never convert throughput into points to report a kanban velocity number.
