1 Overview
Cycle time is the elapsed time from when work starts to when it finishes. Story points are a relative estimate of effort, complexity, and uncertainty. Both appear on agile teams, but they answer different questions. Story points help a team forecast how much work it can take on in a fixed period. Cycle time tells you how long a single item actually took to move through the system. One is a planning input; the other is an outcome measure.
The trouble is that story points are easy to compare badly. A five in one team is not a five in another, and even within a team the meaning of a point can drift as people learn. Cycle time is grounded in the calendar. It does not care how hard something felt. It records when work began and when it was done. That makes it harder to game and easier to discuss with people outside the team.
This article compares Agile, Scrum, and Kanban through the lens of metrics, especially cycle time and story points. It does not argue that one method is best. It argues that if you want to understand delivery, cycle time will usually tell you more than story points ever will.
2 The problem this method was built to solve
Agile, Scrum, and Kanban all emerged to address a common failure: work that takes too long to reach customers, with too little feedback along the way. Traditional project planning often assumed that requirements could be fixed early and that progress could be measured by percent complete. In software, that assumption breaks down. Requirements change, estimates are uncertain, and a task that is ninety percent done can remain stuck for weeks.
Scrum responded with short, fixed iterations and a cross-functional team that commits to a sprint goal. Kanban responded by making the flow of work visible and limiting how much work is in progress at once. Agile is the umbrella set of values and principles that both approaches serve. Each method tries to shorten the time between deciding to do something and learning whether it worked.
The metric problem sits underneath all of this. If you measure progress by story points completed, you can look busy while items sit unfinished. If you measure cycle time, you see the real delay. The methods were built to improve flow, but the wrong metric can hide whether flow is actually improving.
3 How one cycle runs, from ready to done
In Scrum, a cycle begins with a sprint planning session. The team selects items from the product backlog, clarifies them, and forecasts what it can finish in the sprint. Work moves into a sprint backlog. Each day the team meets briefly to coordinate. At the end of the sprint, the team reviews a potentially shippable increment with stakeholders and then reflects on its process in a retrospective. Cycle time in Scrum is often measured from when an item enters the sprint to when it meets the definition of done.
In Kanban, there is no required sprint boundary. Work items are pulled across a board that reflects the team's workflow. Each column has a work-in-progress limit, so people start new work only when capacity frees up. Cycle time is measured from the moment an item enters the active workflow until it reaches the done column. Because the board is continuous, cycle time can be tracked item by item and reviewed at any time.
Both methods depend on a clear definition of done. If done means coded but not tested, cycle time looks short and quality suffers. If done means deployed and verified, cycle time is longer but more honest. The metric is only as good as the boundary you draw around it.
4 Roles and how they divide the work
Scrum defines three accountabilities. The Product Owner owns the product backlog and maximizes value. The Scrum Master helps the team apply Scrum and removes impediments. The Developers do the work of creating the increment. These roles divide responsibility for what to build, how to work, and how to do the work. Story points are typically estimated by the Developers, while the Product Owner uses them to inform ordering and forecasting.
Kanban does not prescribe roles. A team may keep its existing job titles and simply adopt a board with explicit policies and work-in-progress limits. Some teams designate a service manager or flow manager to watch cycle time, blocked items, and queue sizes. Others rotate that responsibility. Because Kanban has no required ceremonies, the discipline comes from the policies the team writes and follows.
Agile as a set of principles does not assign roles either. It expects self-organizing teams and close collaboration with customers. In practice, most teams blend roles from Scrum, Kanban, and their organization's structure. The key question for metrics is who owns the definition of done and who reviews cycle time. If no one owns it, the number becomes trivia rather than a tool for improvement.
5 Artifacts worth keeping
Scrum's artifacts are the product backlog, the sprint backlog, and the increment. The product backlog is an ordered list of everything that might be built. The sprint backlog is the subset selected for the current sprint, along with a plan for delivering it. The increment is the sum of completed work that meets the definition of done. Story points often live on backlog items as a relative size estimate.
Kanban's central artifact is the board itself, supported by explicit policies. The board shows workflow stages, work items, and work-in-progress limits. Policies describe when an item can move, what done means at each stage, and how to handle blocked work. Cycle time is derived from the board by recording when items enter and leave each stage. Some teams also keep a cumulative flow diagram to see how work accumulates.
Both methods benefit from a clear definition of done and a visible workflow. Story points are useful for planning but are not a delivery measure. Cycle time is a delivery measure but does not tell you whether the work was valuable. The strongest artifact set includes both: a backlog for deciding what to do, and a flow record for seeing how long it takes. Keep the artifacts that answer questions you actually ask.
6 Where this method breaks down
Story points break down when they are treated as a universal currency. Because they are relative and team-specific, comparing velocity across teams is misleading. Points can also inflate over time if a team unconsciously redefines what a point means. When points become a target, people may split work to look productive or avoid difficult items. The metric then measures estimation behavior rather than delivery.
Cycle time breaks down when the definition of done changes without notice, when items are unusually large, or when the workflow has hidden queues. A single outlier can distort an average, so teams should look at distributions rather than a single number. Cycle time also says nothing about value. A team can have excellent cycle time while building the wrong thing. It is a flow metric, not a product metric.
Scrum can break down when sprints become mini-waterfalls, with all testing at the end and no real feedback until the review. Kanban can break down when work-in-progress limits are ignored and the board becomes a wish list. Agile can break down when it is reduced to ceremonies without the underlying principles. No method protects you from measuring the wrong thing. Cycle time is more honest than story points, but it still needs context.
7 Frequently asked questions
Is cycle time always better than story points? No. They answer different questions. Story points help a team forecast how much work fits in a fixed period. Cycle time shows how long work actually takes. Use points for planning and cycle time for improvement. If you must choose one to judge delivery, cycle time is usually more concrete and harder to manipulate.
Can a team use both Scrum and Kanban? Yes. Many teams run Scrum sprints while using a Kanban board to visualize flow and limit work in progress. The combination can work well, but be clear about which metric drives decisions. If you plan with points and measure with cycle time, you may find that your forecasts and your actual flow tell different stories.
How do you start measuring cycle time? Pick a clear start point and end point, such as from when an item enters active development to when it meets the definition of done. Record the dates on the board. After a few weeks, look at the distribution, not just the average. Discuss outliers in your retrospective or flow review. The goal is not a perfect number but a shared understanding of where work waits.
Does cycle time replace velocity? It can, for teams that prefer flow-based planning. Instead of estimating points, you can forecast by counting how many items typically finish in a given period. That approach works best when items are reasonably similar in size. If sizes vary widely, you may still need some form of estimation or you may need to split work smaller.