Agile CCPM

Pattern: A named solution to a recurring problem.

Ujigawa and Updegrove’s software-specific Critical Chain Project Management variant: keep CCPM’s commitment discipline while using relative size, velocity, and a scope buffer where absolute task estimates break down.

Also known as: “Agile” CCPM; Critical Chain for Software Development.

Agile CCPM is not Scrum with a project buffer bolted on. Ujigawa and Updegrove use “agile” in the small-a sense: adaptable, responsive, and credible to software teams that can’t honestly quote a duration for work they haven’t discovered yet. The pattern keeps the critical chain, the project buffer, buffer management, full kitting, and project staggering. It changes the estimation and execution controls so software teams can protect a delivery promise without pretending the work is as knowable as construction or engineering-to-order work.

Context

Critical Chain Project Management assumes the project network can be built with task durations that are aggressive but usable. That assumption holds in many project environments. A bridge design, plant shutdown, aircraft maintenance package, or construction job can usually name the major tasks, predecessor relationships, scarce resources, and approximate durations before execution starts.

Software often fails that test. Feature scope changes as the team learns. Defects appear far from the code that caused them. Customers revise priorities after seeing a working increment. Developers can estimate relative effort more reliably than calendar duration: this feature is about twice the size of that one, but nobody knows whether the path through it is three days or eight until work starts. Standard CCPM still has value in that environment, but its usual network-construction technique can look too much like the waterfall planning software teams have already rejected.

Ujigawa and Updegrove’s 2016 TOCICO paper names that gap. Their claim is narrow: CCPM doesn’t need to surrender its project-commitment logic to become usable in software. It needs a different way to size work, update remaining duration, and handle discovered scope.

Problem

Software teams often face a false choice. Agile methods protect adaptability, responsiveness, and team autonomy, but they can leave the larger organization without credible commitments on delivery, cost, scope, and quality. Standard CCPM protects the commitment, but the usual demand for absolute task-duration estimates can feel impossible when the work content is still being discovered.

When the organization forces standard CCPM onto that uncertainty, developers resist or comply superficially. When it abandons CCPM entirely, customer commitments drift back into local sprint promises, optimistic roadmaps, or portfolio rituals that don’t protect the system constraint. The problem is not that software teams dislike discipline. The problem is that the discipline has to match the kind of uncertainty the work actually contains.

Forces

• Software scope is discovered during execution. The team may know the product aim before it knows the detailed feature set, dependencies, and defect paths.

• Absolute time estimates are weak before work starts. The team may be able to compare sizes but not quote reliable task durations.

• Developers value autonomy for good reasons. A method that removes adaptability will be treated as a regression to waterfall, even if its project-control logic is sound.

• The organization still owes commitments. Customers, sales, finance, and support need credible dates and scope decisions; “we’ll inspect and adapt” is not enough by itself.

• Fixed sprints can become local milestones. If a time box is treated as sacred, work expands to the slot or stops at the slot even when flow would be better served by finishing the feature and moving on.

• Scope change needs a buffer of its own. A time buffer can absorb duration variation, but it can’t absorb every newly discovered feature without a scope policy.

Solution

Keep CCPM’s project commitment structure, but replace front-loaded absolute duration estimates with relative size, velocity-based buffer management, and an explicit scope buffer.

The work starts with a prioritized feature list. Features are sized by relative effort, often with story points or a modified Fibonacci scale. The team then sets an initial velocity, converts the selected feature set into a project duration, and places the project buffer against that duration. The critical-chain schedule can be simpler than a standard CCPM network because the important unit is the feature stream and any major integration or test phase that sets the pace.

During execution, the team updates the plan by actual velocity. If the current feature is in progress, the team still reports remaining duration for that active work. For the features not yet started, the remaining duration is recalculated from remaining story points divided by actual velocity. The fever-chart logic survives: project health is still read from progress against buffer consumption, but progress is tied to relative-size completion and observed velocity rather than only to original task-duration estimates.

Agile CCPM also adds a scope buffer. Ujigawa and Updegrove recommend treating the lowest-priority tail of the planned scope, often about the last 15 percent, as the negotiable portion. The team defends the high-priority scope hard and uses the scope buffer when the project buffer is being consumed too fast. That move is not scope indifference. It is a visible policy for deciding which lower-priority features can be deferred or replaced when discovered work would otherwise consume the delivery promise.

This makes Agile CCPM a CCPM variant, not a hybrid method. The critical chain still governs the project. The project buffer still protects the commitment. Buffer management still determines when to prepare or act. Project starts are still staggered in multi-project environments. Full kits and resource subordination still matter. What changes is the measurement basis for a class of work where relative size is more honest than early absolute duration.

How It Plays Out

A software product release. A team is asked to deliver a major upgrade by a market date. The product owner can list and rank the desired features, but the team can’t defend a day-by-day task network because several features depend on API behavior that will be discovered during implementation. Agile CCPM starts with the ranked feature list, sizes the features by story points, selects the release scope, and converts the initial point total into a duration using planned velocity.

The project buffer protects the release date. The lowest-priority part of the feature list becomes the scope buffer. As execution proceeds, actual velocity replaces planned velocity for the not-yet-started feature set. If the fever chart moves into yellow, the team prepares recovery moves: protect the integration phase, reduce interruptions to the constrained skill, or decide which scope-buffer features can move. If it moves into red, the scope decision is no longer theoretical.

Being Company Ltd. Ujigawa and Updegrove ground the method in Being Company’s software-development experience in Japan. Being had used standard CCPM from 2005, but due-date performance was still below the target the company expected. For a major software upgrade, the team could tell the project was much larger than prior work but could not build a reliable absolute-time estimate for every task. The company began using relative size, velocity, and Agile-style ideas while keeping CCPM’s buffer logic. The paper reports due-date performance rising from less than 30 percent to more than 90 percent by the end of 2011, and then staying near 100 percent in later years.

A Scrum team under portfolio pressure. A Scrum team can keep its sprint cadence for team learning while the portfolio uses Agile CCPM for the release commitment. The sprint is not the constraint. The critical chain is the release-level sequence of feature completion, integration, testing, and resource availability. If a sprint boundary interrupts a feature that should finish early, Agile CCPM says the time box is serving the wrong master. Finish the feature, update velocity, and read the buffer.

Do not confuse Agile CCPM with Scrum plus padding: Agile CCPM does not keep padded task estimates, add a project buffer, and call the result critical chain. It removes hidden task safety, protects the commitment with an aggregated buffer, and makes lower-priority scope explicitly negotiable. Without that discipline, the method has only borrowed CCPM vocabulary.

Consequences

Benefits:

• The organization gets a real commitment mechanism. Delivery promises are tied to a protected critical-chain plan rather than to sprint optimism or a conventional Gantt chart.

• Developers keep a credible form of adaptability. Relative sizing and velocity updates respect the uncertainty of software work without abandoning project control.

• Scope decisions become visible. The scope buffer names the lower-priority work that can move when discovered work threatens the date.

• Buffer management remains the control signal. The team still knows when to leave the project alone, prepare recovery, or act.

• CCPM becomes more acceptable in software. The method no longer requires early absolute estimates where the team has better evidence for relative size.

Liabilities:

• The method depends on honest relative sizing. Story points can become a local performance game if management treats them as individual productivity scores.

• Velocity readings can be noisy. A small team, changing feature mix, or unstable integration environment can make actual velocity jump enough to distort buffer status.

• Scope-buffer policy needs authority. Someone has to be able to defer, replace, or protect features when the buffer signal requires it.

• Fixed sprint culture can fight the method. If the organization treats sprint boundaries as immovable milestones, it recreates Parkinson’s Law and loses the flow advantage the variant was built to preserve.

• The variant does not replace broader software-flow management. ToC for Software and DevOps still handles recurring delivery flow, deployment constraints, and operations; Agile CCPM handles bounded project commitments.

Complements: Flow Metrics for Knowledge Work — Flow Metrics for Knowledge Work makes recurring software flow visible; Agile CCPM uses relative size and velocity for a bounded project commitment.

Complements: Throughput Economics for Software Organizations — Throughput Economics for Software Organizations supplies the decision frame for which features, scope trades, and capacity moves deserve the critical-chain protection Agile CCPM provides.

Complements: ToC for Software and DevOps — ToC for Software and DevOps covers the broader delivery-system flow problem; Agile CCPM covers the project-commitment problem inside software work.

Mitigates: Parkinson's Law in Projects — Agile CCPM rejects fixed time boxes when they invite work to expand to the calendar slot rather than finish when the feature is done.

Mitigates: Student Syndrome — Agile CCPM preserves CCPM's removal of hidden task safety, which reduces the local margin Student Syndrome consumes before work begins.

Refines: Critical Chain — Agile CCPM keeps the critical-chain idea but changes how software teams build and read the chain when absolute task-duration estimates are weak.

Uses: Fever Chart — Agile CCPM still reads project health through buffer consumption against progress, but progress is tied to relative size and velocity rather than only to absolute task durations.

Uses: Project Buffer — Agile CCPM keeps the project buffer as the commitment protection mechanism while adding velocity-based readings and a scope buffer for software uncertainty.

Sources

• Ujigawa and Updegrove, “Agile CCPM: Critical Chain for Software Development” (TOCICO White Paper Series, 2016). The primary source for the pattern’s relative-size estimation, velocity-based buffer management, scope buffer, and Being Company case.

• Cox, TOCICO Dictionary (2nd ed., 2012), entries “critical chain project management (CCPM),” “critical chain,” “project buffer,” “fever chart,” “buffer burn rate,” and “resource buffer.” The Dictionary supplies the certification-grade CCPM vocabulary this software-specific variant preserves.

• Goldratt, Critical Chain (1997). The originating treatment of CCPM: critical chain, project buffer, feeding buffers, resource buffers, remaining-duration reporting, and relay-runner work behavior.

• Cox and Schleier, Theory of Constraints Handbook (2010), Ch. 3 (Budd and Cerveny, “A Critical Chain Project Management Primer”). The standard CCPM implementation frame Agile CCPM modifies for software conditions.

• Kim, Behr, and Spafford, The Phoenix Project (2013). The software and DevOps bridge that makes TOC’s project and flow vocabulary legible to software teams.