Progress Monitoring - Measurement That Matters

Short answer: Progress tracking for software teams means measuring what forecasts delivery, not what feels productive. Three metrics earn their keep: cycle time per story, cumulative flow per board column, and accepted-stories velocity on a rolling 3-iteration average. Everything else — hours logged, tasks closed, percent complete, points committed — is vanity or theatre. Start measuring, pick three metrics, hold them for six iterations, and only then decide whether to add another. Most teams track too many metrics and act on none.

Progress tracking involves measuring the movement of a project with sufficient depth of honest to allow you to bet money on the next milestone. They are not status updates. It is not the case where a Gantt chart turns green on the dashboard because someone updated a field. It is a small set of figures which forecasts delivery and surfaces as soon as anything goes off track.

That’s all there is. It's unnecessary to read more. You can also continue reading to learn about why most teams measure the wrong things, which three metrics are worth the ceremony, and the two or three you should stop measuring today.

This resource is designed for engineers and team leads (and PMs) who have been handed a dashboard full of charts with the instruction to “track progress”, without a working definition of progress. In this post, we will examine what progress tracking means in a software context, the three metrics that deserve attention, the vanity metrics to not bother measuring, what a tracking cadence can look like that doesn’t eat your week, and the only honest answer to ‘when are we going to be done’.

The references made here arise from twenty years of running delivery for app teams and XP-flavoured agile practice that underlies LiteTracker. All of it is practical. A lot of it has already been done, usually badly first, which is how you will see which metric is lying to you.

Progress tracking, plainly defined

Continuously comparing what a team has shipped against what it expected to ship is progress tracking. The cadence for this comparison must be tight enough to detect a drift before it eats a release.

The three mistakes it was made to catch.

• Silent slippage. The team feels busy, the burn-down looks fine, and the release date quietly moves two weeks every month.
• Scope creep without a conversation. New work gets added to the iteration and nobody can point at the decision that let it in.
• Dead work in flight. Stories sit in review for a week, a card is "nearly done" for three iterations, cycle time balloons, nobody notices because the kanban board still looks like it's moving.

The three share a common design: the illusion of momentum that doesn’t yield shipped user value. The discipline that forces the feel to match the facts is Progress Tracking. The Project Management Institute frames the same loop as “monitoring and controlling” in the PMBOK; for conventional projects it uses Schedule Performance Index (SPI) and Cost Performance Index (CPI). For a software project, those indices are generally theatre: they record estimated value delivered against estimated time elapsed. We will use something more honest.

Every progress-tracking signal should answer one question: has the time between a story entering development and a user being able to use it changed, in a way we can forecast?

• If a metric fails to assist with that, discard it. We will revisit this point frequently.

The metrics that forecast delivery

Three metrics earn their pay. All of the metrics measure the actual flow of user value and not activity.

Rolling three-iteration average of accepted-stories velocity. The number of story points accepted by the PM in an iteration, averaged over the last three iterations. The terms we use deliberately to settle the meaning precisely are: accepted (meaning not finished-by-engineering) and rolling (meaning not last-iteration-only). A human has reviewed and approved of it. To roll your forecast means that one bad iteration will not take it down, and one lucky iteration will not puff it up. The point is forecasting, not scoreboarding — velocity is not the goal, it's the signal. LiteTracker is built around the assumption that velocity is only ever calculated on accepted stories, which is what G2 reviewers called best velocity tracking of any tool.

The cycle time per story is the elapsed time from a story entering the “in progress” state to the same story entering the “done” state. Not time spent coding but rather total elapsed time. The most informative flow metric is cycle time. This is because it takes into account time spent in code review, PR queue and QA bandwidth. If your output isn’t changing (and your velocity is steady), your WIP is growing. In our write-up on lead time and cycle time, there’s a more extended rationale behind this.

A flow of values for each column in the kanban, per day (x-axis). The sum of values is “throughput”. Pay attention to the following scenarios: the Done band gradually widening (good sign), Review band enriching while In Progress drains (review bottleneck), or every channel growing except Done (WIP explosion, stop pulling, start finishing).

All three of them measure flow of accepted value and not activity. When comparing a team that logs 400 hours and ships three accepted stories with another that logs 100 hours and ships five, the first team is slower. The metrics will reveal that. Not hours-logged.

The velocity of accepted stories multiplied by three iterations provides us with a defensible delivery window for the backlog, provided we do not reshuffle the backlog. If your backlog contains 60 points worth of work and your rolling velocity is 20, you are three iterations from done, plus or minus one. Say the phrase, “give or take one,” out loud. The actual reason the metric exists.

Using this method to manage sprints gives teams the opportunity to deliver up to 70% more value by sprint 8. The engineers aren't working any faster; rather, the planning process no longer asks the backlog questions that this data can answer.

The vanity metrics to stop tracking

Multiple teams tend to closely monitor at least four distinct metrics. Don’t focus on the massive deployments they distract from the three that work.

Hours tracked. Assesses effort, not output. Logging 400 hours and shipping two accepted stories makes a team slower than a team that logs 100 hours and ships four. When managers optimize for hours logged, they promote presenteeism and padded estimates. Use cycle time instead, which is the honest version of this metric.

All tickets in Jira have been resolved, and all subtasks have been checked. It's accounting for engineering work, not user value. A component feature or the same functionality delivered by two stories with varying subtasks i.e. one story comprising of fifteen subtasks and another story comprising of three subtasks, production will result in different “tasks closed” counts. If you would like to track accounting, do that in another tool.

Points committed. The number of story points planned at the beginning of an iteration. This is a scheme, not advancement. When a team reports on points committed instead of points accepted, they can appear productive by committing more points each iteration, no matter what ships. Report deemed final.

Percentage accomplished the orthodox phrase. The story is not 80% done. 80% done doesn’t exist. A story always has a binary answer; it gets accepted or it doesn’t. That 80% number is a gut feeling. If a story has been nearly “done” for two iterations, it is time to split the story, not report it. According to LiteTracker principles, the only statuses are "shipped and accepted" or "not." There is no in-between.

Yet another unit of measurement you dislike. If you need explanation start any earlier.

All five of them fail in the same manner- they measure not the user’s progress but the team’s activity. Even when the team is very busy, the customer can still be waiting on a thing for six weeks. Choose metrics that clearly show that differentiation.

A progress-tracking cadence that doesn't eat the week

This is the order that actually benefits a software team consisting of three to twelve people. Each slot has a certain job and a time budget - ignore the budgets at your peril.

Things to consider about this cadence.

The purpose of the daily standup is to discuss blockers and not give status updates. In other words, let your status be known through the board. When you read out "I worked on X", you are wasting four other people's time. Standup is the place for surfacing blocked cards and deciding in-room who clears them. The useful bit is that it (the Scrum Guide) describes the daily scrum as a planning event (not a reporting event).

The iteration review is solely for accepting or rejecting iterations, and nothing else. During an iteration review, absorbed-stories velocity is computed. Ideally, keep demos out of it, or put them before, so the acceptance meeting doesn’t turn into a design critique.

The retro’s role is identifying cycle-time killers, not creating a complaint listing. The slowest story in each iteration – what was the primary factor and what will change going forward?* One solution. That concludes the retro.

The flow review that you do once a month is where forecasting lives. You don’t forecast on a weekly basis. The data sample is too small and the chart will whiplash. Predict on a monthly basis, indicate the error bars, and allow the team to proceed with their work.

The honest answer to "when will it be done"

In software project management, the most frequently asked question is also the most poorly answered. The insincere version is "end-of-Q2", given without an error bar. The authentic version includes three components.

1. State the velocity. "Our rolling three-iteration accepted-stories velocity is 22 points per iteration."
2. State the remaining scope. "The remaining backlog in this release is 88 points, assuming no new work."
3. State the window. "That gives us four iterations, plus or minus one — so eight to ten weeks from today, assuming scope stays fixed."

Everyone wants to drop the clause “assuming scope stays fixed”. Store it. We find that scope changes are the biggest reason for missed dates. 50% of all missed dates result because somebody made a scope change, and nobody updated the forecast. The forecast relies on specific inputs. Leave the inputs.

The requester asks for a definitive date, not a range; a commitment, not an estimate. This is a different request. The date is a business decision (how much do we spend to hit this date), not a math problem. Word it as such. In order to guarantee completion on 2026-01-15, we either need to freeze scope now, or add a second parallel squad on this work.Those are the actual levers. Pretending otherwise erodes trust between PMs and engineering teams.

When progress tracking breaks down — three signs

Three ways a practice for tracking progress slowly stops working

The team is may be trying to game the story points metric. Stories are getting smaller for no reason. Bugs are getting points with no fuss. “Chores” are being redefined as features. When your velocity number is increasing but the number of accepted stories is flat, the team has zeroed in on the number. Change the headline to ‘Accepted Stories Count’ and make velocity a planning tool only.

The bottleneck in our review process is becoming very evident. The cumulative flow shows the Review band getting fatter every week. Due to a backlog of pull requests, nothing is getting shipped. Limit the review work in progress to two. Assign new review work to whoever has the fewest open pull requests (PRs). Don’t allow authors to ping whoever.

Predicting Based on Last-Iteration Velocity

In the previous iteration, the team, by pure luck, managed to ship 28 points. Now, somebody is forecasting the remaining iterations of the roadmap based on that number. The 14th shipment in the following iteration has been prepared. This is precisely the purpose of the Rolling-3 churn. Reporting single-iteration velocity delivers a noise forecast to stakeholders.

All three of the above have a common root cause, namely treating progress tracking as a reporting activity rather than as a feedback loop. The metrics are primarily designed to be used by the product team on the coalface, and not be used to scorecard them by a manager two layers up. See more at the ground rules that keep this discipline honest.

When NOT to track progress — the small-team case

The benefits of tracking progress disappear under a certain level. Skip the cumulative-flow charts, velocity boards, or any of these things if.

• You're a team of two or three on one product. You can hold the state of every story in your head. Writing it down is slower than talking about it. A sticky-note wall and a daily "what's blocking you?" is the entire practice.
• You're pre-product-market-fit. The question isn't "how fast are we shipping?" — it's "are we shipping the right thing?" Measure learning, not throughput, until the product line stabilises. (The MVP project management write-up covers that lens.)
• The project is one two-week push. For a time-boxed spike, cycle time and velocity are statistical noise. Just ship it and retro at the end.

The rule we give to our own prospects is that if you have fewer than three engineers or you’re not doing iterations just yet, don’t set up this ceremony for progress tracking. You will expend cognitive overhead and not receive anything in return. If you have a tiny team, the best progress tracking is asking out loud, every Friday, “Did we ship something a user cares about this week?” That’s the whole game.

Frequently asked

What is progress tracking in a software project?

When we measure whether the team is indeed shipping against their plan and shipping bound user value that was accepted, with a cadence tight enough that drift shows up before it eats a release. In practice, we track three metrics: accepted-stories velocity, cycle time per story, and cumulative flow per column. They are reviewed weekly inside the team and monthly for forecasting.

What are the best metrics for tracking project progress?

The speed of accepted stories on a rolling average over three iterations (not on the last iteration and not on points that were committed), cycle time per story (elapsed, not just coding), and cumulative flow per column of the kanban board. All three track measured flow of accepted value, not team activity.

Why is "percent complete" a bad progress metric for software?

Due to the lack of significant partial state in software stories. A story is either accepted or not accepted. The feeling of "80% done" is a story. If a story feels “80% done” for two iterations, it is usually a split-the-story moment not a reporting moment. Track only accepted.

How often should a team review progress-tracking metrics?

Get daily blocker-level signals via standup, cycle time and WIP mid-iteration, accepted-stories velocity at every iteration review, full rolling trends monthly. The weekly velocity report experiences fluctuation due to an inadequate sample size.

Should we track hours logged?

No. Time on task is effort, not output. It is slower to ship two stories for 400 hours than to ship four for 100 hours. If a time-based signal is needed, cycle time should be used, as it includes every delay, which the user actually feels.

What's the difference between a progress-tracking metric and a vanity metric?

A system that tracks progress helps predict when something would reach a user. The team is busy, but no change in forecast, is a vanity metric. These are historical facts. This is not to be confused with the task closed, points committed, and lines of code values, which are the latter.

Do small teams need progress tracking?

Not officially. Two or three people working on the same product can hold the state in their heads. The entire exercise reduces to "what shall we have shipped by the end of the week?", voiced aloud. Once the team crosses four engineers and iterations are set up. Metric to be optionally set up.

How do I forecast a release date from these metrics?

Take the remaining backlog points (after estimating iter 1), divide by the rolling 3-iteration accepted-stories velocity, and state the result as a window (not a date). Append “assuming scope stays fixed” to the forecast. If stakeholders require a fixed date, it is a scope or staffing conversation, not a forecasting one.

Still stuck

When metrics are honest, the cadence is tight, and the team forecasts off accepted stories rather than committed points, we’re already capturing most of the value of tracking progress. Tooling is the final 10%.

LiteTracker is the tool for you if all you want to do is velocity-based forecasting, accepted-stories-only, rolling-3-iteration average and you want a tool that only lets you work that way. No per-user restrictions on the free tier. If a Kanban board on the wall and a Friday 'what shipped?' standup work better for you, use these instead. We prefer you not compensate us for any friction you lack.

Whichever way: pick three metrics, hold for six iterations, and ignore the rest.