Recent delivery can help you estimate the part of a project that resembles tasks already finished, provided the team’s capacity and acceptance conditions still match. It can also expose a finish date that assumes everyone will suddenly work faster. The difficulty comes when the tasks left include different people, tests or approvals, and you try to estimate them using the same rate.
Worked example
Imagine a web project where a content team got 8, 10, 7 and 9 standard pages accepted in four successive fortnights. Eight more pages of the same kind remain, the team has the same capacity, and each page still has to pass the same acceptance check before it counts as finished.
The team averaged 8.5 pages a fortnight. Applying the fastest and slowest observed rates to the next eight pages gives about 1.6 to 2.3 weeks, which provides a starting estimate for those pages. Four observations don’t establish how likely either result is, or guarantee that the next fortnight will fall between them.
The project also needs a booking integration, a system test and an outside approval. If you count those alongside the eight pages, you have eleven items left. Divide eleven by the average page rate and you get about 2.6 weeks, apparently leaving room within a four-week target. The arithmetic works, but it treats an integration, a test and an approval as though each takes the same effort and follows the same process as a standard page.
Suppose the developer can start the integration now and estimates three weeks to complete it. The system test takes another week and can only begin once the integration is ready. Approval then takes a week after the test passes, assuming the reviewer can start straight away. Those linked steps take five weeks, while the content team produces its pages in parallel.
Even at the slowest observed page rate, the eight pages would finish before the integration. You’d still need to check whether they’re required for testing, but finishing them sooner wouldn’t shorten the five-week sequence in this example.
The US Government Accountability Office’s schedule guide describes the longest-duration sequence of linked activities as the critical path, which determines the earliest completion date. Its guidance for government programmes includes reviews and acceptance tasks in the schedule because later activities may have to wait for them. The invented web project uses that scheduling logic to show why counting everything as a page gives the wrong answer.
The four-week target now needs a decision. Check the developer’s estimate, what must be ready before testing can begin, and whether the reviewer is available when needed. If the target has to stay, establish which step could change, who can authorise that change and what it would mean for acceptance.
All the durations here are assumptions for the example. Five weeks is the earliest finish they support, and a failed test or a later review slot would extend it.
The Kanban Guide calls the number of items finished per unit of time throughput and requires a defined finish point. In this example, counting accepted pages gives the record a consistent meaning. You can then judge whether it applies to the remaining pages by checking that they’re still comparable, the same team is available and the acceptance conditions haven’t changed. A new template or the loss of a designer would give you reason to reconsider the estimate.
The GAO guide also says schedule updates should reflect actual progress, the links between activities and revised estimates of what remains. At the next review, check how many pages have been accepted, whether the integration is ready for testing and whether the reviewer has confirmed a slot. Use those findings to update the forecast before repeating the finish date.