A recent delivery rate helps with the part of a project that resembles work already finished. It can also challenge a date that assumes the team will suddenly work faster. Give it less weight when the work left needs different people, tests or approval.
Worked example
Imagine a web project. In four successive fortnights, a content team got 8, 10, 7 and 9 standard pages accepted. Eight more pages of the same kind remain. The team has the same capacity, and a page is still counted only when it passes the same acceptance check.
That’s an average of 8.5 pages a fortnight. If the next eight follow the fastest or slowest of those four periods, they take about 1.6 to 2.3 weeks. The figures give the similar pages a starting estimate. They don’t establish a probability or guarantee that either rate will recur.
There are three unlike items too: a booking integration, a system test and an outside approval. Counting all eleven as pages gives about 2.6 weeks at the average page rate. Against a four-week target, the calculation looks safe. It has silently treated three different pieces of work as standard pages.
Suppose the developer starts the integration now and estimates three weeks. The system test needs the integration and takes one week. Approval takes another week after the test passes, assuming the reviewer can start then. The content team works on its pages in parallel. On those assumptions, integration, test and approval take five weeks. Even a repeat of the slowest observed page pace would finish the eight pages before the integration. Check whether the pages are needed for the test, but they don’t shorten the five-week sequence in this example.
The US Government Accountability Office’s schedule guide calls the longest sequence of linked activities the critical path and says it determines the earliest completion date. Its guidance for government programmes also includes reviews and acceptance work in the schedule, since a later phase may have to wait for them. The web project is an illustration of that scheduling logic, not a government programme.
The four-week target now needs a decision. Check the developer’s estimate, the test’s entry conditions and the reviewer’s availability. If the target must stay, ask which step can actually change, who has authority to change it and what that would mean for acceptance. All these durations are invented for the example. Five weeks is the earliest finish under the stated assumptions, not a commitment. A failed test or a later review slot pushes it out.
The current Kanban Guide calls the count of items finished per unit of time throughput and requires a defined finish point. That gives the page record a clear meaning. The judgement about using it comes next: are the remaining pages still similar, is the same team available, and have the finish conditions changed? A new template or a lost designer would make the old rate less useful.
The GAO guide also says schedule updates should use actual progress, current links between activities and a fresh estimate of what remains. At the next review, check the pages accepted, whether the integration is ready for test, and whether the reviewer has confirmed a slot. Update the estimate from those facts before anyone repeats the finish date.