Measuring Progress in Your First Three Months of Agile

Soon after a team starts working in an agile way, someone asks, "Is it working?" It is a fair question, and numbers can help answer it. But the first three months are a learning period, and early data is noisy. Measure the wrong thing, or lean on it too hard, and you can do more harm than good.

This guide explains the basic measures beginners meet, velocity, throughput and cycle time, and offers a simple month-by-month plan. It deliberately offers no industry benchmarks. Your own history is the only baseline that means much.

Start with what agile treats as progress

The Agile Manifesto's principles state: "Working software is the primary measure of progress." Outside software, read that as working results: a finished campaign, a resolved request, a product people can use.

That principle is a useful check on every metric below. If your numbers improve but nothing usable reaches the people you serve, you are not making progress.

Velocity basics

Velocity is the total size of the work a Scrum team finishes in a sprint, usually measured in story points or another relative estimate. Many teams use it to help forecast how much they can take on in Sprint Planning.

Note two things. First, velocity is a common practice, not a rule of Scrum; the word does not appear in the Scrum Guide (November 2020). The guide says only that the more the Developers know about "their past performance, their upcoming capacity, and their Definition of Done," the more confident their forecasts. Second, velocity depends entirely on how a team estimates, so it cannot be compared across teams.

Ron Jeffries, who has written that he "may have invented story points," said in a 2019 article that "using them to predict 'when we'll be done' is at best a weak idea." Discussing two teams that size similar work differently, he wrote that it is "certainly not a useful way to compare teams," and that comparing teams is "an irresistible temptation, for many managers." Treat velocity as a rough planning aid for one team, never a score.

Throughput and cycle time basics

The Kanban Guide (May 2025) defines four flow measures that work with any approach, including Scrum:

• WIP: "The number of work items started but not finished."
• Throughput: "The number of work items finished per unit of time."
• Work item age: "The elapsed time between when a work item started and the current date."
• Cycle time: "The elapsed time between when a work item started and when a work item finished."

These need no estimating at all. You only need two dates per item: when it started and when it finished. That makes them a good fit for beginners.

A month-by-month plan

Month one: build the habit of recording data.

• Agree on exactly when an item counts as started and finished.
• Record both dates for every item.
• Count finished items each week or sprint.
• Do not set targets. You are establishing a baseline.

Month two: look at ranges, not averages.

• List the cycle times of finished items from shortest to longest. Note the spread.
• Check work item age every few days. An item older than most finished items is a signal to swarm on it or unblock it.
• If you use sprints, note what was planned versus finished, without blame.

Month three: begin cautious forecasting.

• Use your own history to state ranges. For example, imagine a team whose finished items mostly took between two and nine days; it can say most items finish within about nine days, while some take longer.
• Consider a first service level expectation. The Kanban Guide describes it as "a period of elapsed time and a probability associated with that period," with the example "85% of work items will be finished in eight days or less." Base yours on your data, not that example.

Charts worth knowing

The Scrum Guide notes that "Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows." A burn-down shows remaining work falling over time. A burn-up shows completed work rising toward a total, which makes scope changes visible. A cumulative flow diagram shows how many items sit in each stage over time; a band that keeps widening suggests a bottleneck.

The guide adds an important caution: "While proven useful, these do not replace the importance of empiricism." Charts start conversations. The Sprint Review and real feedback from users finish them.

Cautions that keep numbers honest

• Do not turn measures into targets. DORA, the research program behind widely used software delivery metrics, warns against Goodhart's law: when metrics become rigid targets, people may game the data instead of improving.
• Do not compare teams. DORA advises using metrics to track a team's own improvement rather than to rank teams, and the velocity caution above applies to every measure here.
• Keep reporting light. The GOV.UK Service Manual warns that "Too many reporting requirements become counterproductive as the team has less time to spend on delivery work."
• Expect early instability. A team learning new habits will see its numbers swing. Look for trends over several weeks, not single data points.
• Ignore outside benchmarks for now. Numbers from other organizations reflect different work, definitions and contexts.

Look beyond output

Flow measures tell you how work moves, not whether it was worth doing. Pair them with outcome signals: are customers using what you delivered? Are defects or rework going down? Do people on the team feel the new way of working is sustainable?

Software teams may later look at DORA's delivery metrics, such as change lead time and deployment frequency. For the first three months, a few honest flow measures and regular conversations about results are plenty.

Key takeaways

• Working results are the primary measure of progress; metrics support that, not replace it.
• Velocity is a team-specific planning aid, not a Scrum rule and never a score.
• Throughput, cycle time, WIP and work item age need only start and finish dates.
• Build a baseline in month one, study ranges in month two and forecast cautiously in month three.
• Avoid targets, team comparisons, heavy reporting and outside benchmarks.

Sources

• Agile Manifesto authors, Principles behind the Agile Manifesto (2001)
• Ken Schwaber and Jeff Sutherland, The Scrum Guide (November 2020)
• John Coleman and Daniel Vacanti, The Kanban Guide (May 2025)
• Ron Jeffries, Story Points Revisited (May 23, 2019)
• DORA, DORA's software delivery performance metrics (January 5, 2026)
• GOV.UK Service Manual, Measuring and reporting progress