I’ve had management set arbitrary deadlines to try to change our mindset. With AI we recently tried this as we thought we could find the limits of where AI could help us. The problem I see with some teams employees will do everything to hit deadlines including working 20+ hours of work extra.
Right, this makes a lot of sense. The culture part is very important, and setting the right expectations, so people don't feel they need to work overtime, instead do what's possible in the time they are working. I'd say it's a big difference the way you do this in US companies vs EU companies (for example), as the mentality of people is quite different.
It’s great that you’re bringing up this risk. People generally want to do a good job -that’s why, as you said, they end up pulling 20+ hours of overtime and burning out. That’s why it’s crucial to take a different approach, ensuring there are absolutely no consequences for missing aggressive estimates, neither formal nor informal. I'd also recommend starting with a less aggressive buffer at the beginning, maybe 25% instead of 50% to start with. Good luck!
Interesting case study, but I’m not sure I fully agree with this part:
> “By traditional velocity/throughput metrics, this was a completely normal first week.”
If this is a long-living team working in a familiar product/domain, I would normally expect relatively stable velocity patterns. In this example, Week 1 velocity was roughly 2x lower than the following weeks (11 SP vs. ~18–21 SP later), which already looks like a noticeable slowdown compared to the team’s historical velocity (assuming they typically deliver ~20 SP per sprint).
Also, if the team initially committed to a normal amount of work but closed only ~50% of it, then the do/say ratio would already drop significantly compared to a typical 70–90% range. In many teams, that alone would trigger a retro discussion around blockers, unclear requirements, or execution friction.
That said, I do think the buffer consumption tracking is an interesting approach. We’ve used similar mechanisms a few times on projects where delays had significant financial impact.
Thanks for the thoughtful pushback, you're raising a fair point.
You're right that in theory, a 2x velocity drop in Week 1 should be noticeable. But here's the thing: in practice, the only reference point you have without the buffer is approximate velocity. You see 11 SP delivered and you compare it to... what exactly? A rough historical average? Most teams don't have a precise enough baseline to confidently say "this is a problem" after just one week. First weeks are noisy, onboarding to a new epic, context switching, ramping up. It's easy to rationalize.
The buffer makes this comparison much sharper. Instead of comparing delivered SP to a vague velocity range, you're comparing actual cycle times against the median completion time for each story point value. That's a much more sensitive signal. In day-to-day work, nobody remembers how long a 3 SP task typically takes - we remember whether it felt hard or easy, not whether it took 3 days or 5. The buffer tracking does that remembering for you, at the individual task level, and aggregates it automatically.
But you're absolutely right, you can draw meaningful conclusions without this methodology too. I just find it's harder to catch things early, and easier for signals to slip through. The buffer gives you a structured framework for something that otherwise relies on gut feel and experience.
Thank you for sharing the methodology. I am wondering how to adjust it for the teams that are redesigning their workflow and no longer create tasks that can be tracked or do it lightly, as they adopt more AI coding.
How do you communicate about scope/requirements? Anyway, if you have nothing, you can ask the team for estimates and then cut them off by 25%-50%, and track only buffer. That's fine. Then your fever chart is based on what you can accept/tolerate. Let's say the yellow area is where your project progress - buffer consumption is <-15;15> (in percentage points), and your red is below -6 percentage points. Let me know, Dana if it makes sense to you
As an expert Scrum Master, my reaction to this article on the Critical Chain methodology is mixed. While I deeply appreciate the practical problem-solving and the focus on flow and team psychology, the core prescription—cutting all estimates in half—is fundamentally at odds with Scrum’s values and empirically proven best practices. It’s an elegant solution, but to the wrong problem.
Here’s my breakdown from an agile and Scrum perspective.
What I Appreciate (The Good)
The author, Karol, is a thoughtful practitioner, and several aspects of his approach are genuinely clever and align with an agile mindset, even if the framework isn't.
· Focus on Flow and Constraints: The core idea of identifying the critical chain and using a project buffer is conceptually similar to a Kanban system’s focus on flow and limiting work in progress (WIP). The "red alert" in Week 1 is a fantastic example of catching a blocker (unclear requirements) early, which is pure agile.
· Psychological Safety is Key: The non-negotiable rule of "no penalties" for missing aggressive estimates is 100% correct and crucial for any team's success. Creating an environment where it's safe to fail is a foundation of Scrum’s value of Courage.
· Shifting from Individual to Team Accountability: The practice of tracking the buffer instead of individual task overruns is excellent. It fosters collective ownership and moves away from the toxic "who's behind?" interrogation. This perfectly mirrors a Scrum team’s shared commitment to the Sprint Goal.
· Empirical Data (Used Creatively): Using historical median cycle time is a good, data-driven starting point. He’s looking at real work, not wishful thinking. His point about not building complex math on an uncertain baseline is, ironically, a fantastic argument for relative estimation and against his own time-based conversion.
The Fundamental Flaws (The Risky)
Despite the smart tactics, the method’s foundation is built on two anti-agile principles: mistrust of the team and a time-based, predictive planning model.
It Violates the Core Principle of Self-ManagementA Scrum team collectively owns their Sprint Backlog and creates a forecast, or plan, based on their capacity and historical velocity. A manager secretly cutting their estimates by 50% is a direct assault on that self-management. It says, "I don't trust your professional judgment; I know your job better than you do." This erodes the Respect and Openness that Scrum demands.
It Misdiagnoses the Problem of Parkinson’s LawParkinson’s Law ("work expands to fill the time") is a symptom of a system with low urgency and unclear short-term goals, not an immutable law. Scrum addresses this directly, not by shortening a deadline in a spreadsheet.
· The Sprint Timebox: The Sprint itself is a natural Parkinson’s Law killer. The team commits to a Sprint Goal for a fixed short period (e.g., two weeks). This creates immediate, palpable urgency.
· Sprint Backlog & Daily Scrum: Every day, the team inspects progress toward the Sprint Goal. If someone finishes early, they don't "polish things that don’t need polishing"—they pull the next highest-priority item from the Sprint Backlog. The time saved is instantly and transparently reinvested.
The "Estimate Conversion" is a Dangerous AbstractionConverting story points to time using a median is a cardinal sin in Scrum. Story points are a relative, unitless measure of complexity, effort, and uncertainty. They are specifically designed to avoid the illusion of time precision. A median of 3 days for a 5-point story erases critical context: Was that a simple 5-pointer or a risky one? By slicing this unreliable number in half, you’re not creating an "aggressive but achievable" target; you’re creating a random guess and then calling it a plan. The buffer becomes a pseudo-scientific way to manage the resulting chaos, which you created.
The Scrum Master’s Expert Advice
Instead of secretly managing a buffer spreadsheet, a Scrum Master would facilitate a transparent, team-empowered solution. Here’s how to achieve the same goals—early project completion without stress—using actual Scrum:
Replace the "Critical Chain" with a Laser Focus on the Sprint GoalThe author’s red alert in Week 1 was triggered because the method highlighted a rate of progress problem. A great Scrum team sees this even faster. In the Daily Scrum, the question isn't "Are you on track to finish your task?" but "Is there anything blocking our path to the Sprint Goal?" Unclear requirements blocking two senior engineers would have been the screaming, central topic of conversation on Day 1 or 2, not discovered in a weekly review.
Use the Sprint Retrospective to Inspect and Adapt FlowIf the team feels they aren’t working with enough intensity, that’s a process problem they can solve. In a Retrospective, a Scrum Master can guide the conversation:
"Team, I've noticed our cycle times have a lot of variance, and some tasks sit idle for a while. How can we improve our flow? Would it help to swarm on a key item? Should we define our 'Definition of Done' more clearly to reduce polishing? What’s our working agreement for pulling in new work once our task is complete?"
This creates team-owned rules for urgency, not management-imposed half-deadlines.
Forecast with Data, Not Manufactured StressThe desire for a project end-date is real. Scrum uses empirical data transparently. A burndown chart for the release, complemented by a Monte Carlo simulation based on the team’s historical throughput (e.g., "How many story points do we finish per Sprint?"), provides a probabilistic forecast. The conversation changes from "We must hit this artificial date I’ve set" to "Based on our data, we have an 85% chance of finishing this scope in 4 Sprints. If we want higher confidence, we need to negotiate scope." This is honest, respects the team, and manages stakeholders far more professionally than a red/yellow/green buffer gauge.
In conclusion: The article describes a well-intentioned, sophisticated way to manage a team’s commitment as if it were a project management problem. Scrum’s philosophy is to make visible the dysfunction (Parkinson’s Law) and empower the team to solve it through transparency, inspection, and adaptation. The "captured time savings" he celebrates are just the team working at a sustainable, focused pace, which is the baseline expectation in a healthy Scrum team. The method gets results despite its flawed premise because it introduces focus and a feedback loop, but a skilled Scrum Master achieves the same results by building a system of trust and empowerment, not by gaming one.
Thank you for such a thorough response. You've raised a lot of points here. To keep this from becoming an essay of its own, let me address the main ones.
1. First, this isn't done secretly. I present the methodology to the team transparently, explain how it works, and walk them through the rules - including the "no penalties" principle. They know exactly what's happening and why. So the "assault on self-management" framing doesn't apply here.
2. On Parkinson's Law being a symptom of low urgency - I respectfully disagree. It affects everyone, including highly motivated teams. A sprint timebox limits it at the sprint level, but within individual tasks, it still operates. If someone has 5 days for a task inside a two-week sprint, Parkinson's Law applies to those 5 days.
3. On the story point to time conversion being a "cardinal sin" - in theory, story points measure complexity, not time. In practice, every team knows that their 5-point tasks take roughly X days. I'm simply formalizing what everyone already knows but pretends they don't - and I'm doing it with empirical data (medians from historical completions), not guesswork.
4. On the Daily Scrum catching blockers faster - in theory, yes. In practice, unclear requirements rarely surface as blockers in standup. Developers say "working on task X, no blockers" - because ambiguity doesn't feel like a blocker, it feels like normal work. The buffer metric catches this because it measures outcomes (actual cycle time vs. expected), not self-reported status.
I fully agree that a mature Scrum team with a skilled Scrum Master can achieve similar results through transparency and empowerment. But that's a high bar that not every team meets every sprint. Critical Chain gives you a structured fallback - a measurable feedback loop that works even when the human dynamics aren't perfect.
Appreciate the discussion - these are exactly the kind of conversations that push practitioners to sharpen their thinking.
Thank you, Gregor, for hosting me ⚡️
Thank you for sharing your insights on this important topic Karol!
Way, very, cool. I’m sure this could use ADO as well as Jira
Glad the article resonated! And yes, any project management software works, just the automation/set up would look a bit different.
Yeah, I didn't want to focus on a specific tool, you can have it basically everywhere
I’ve had management set arbitrary deadlines to try to change our mindset. With AI we recently tried this as we thought we could find the limits of where AI could help us. The problem I see with some teams employees will do everything to hit deadlines including working 20+ hours of work extra.
Right, this makes a lot of sense. The culture part is very important, and setting the right expectations, so people don't feel they need to work overtime, instead do what's possible in the time they are working. I'd say it's a big difference the way you do this in US companies vs EU companies (for example), as the mentality of people is quite different.
It’s great that you’re bringing up this risk. People generally want to do a good job -that’s why, as you said, they end up pulling 20+ hours of overtime and burning out. That’s why it’s crucial to take a different approach, ensuring there are absolutely no consequences for missing aggressive estimates, neither formal nor informal. I'd also recommend starting with a less aggressive buffer at the beginning, maybe 25% instead of 50% to start with. Good luck!
Great collab to see! And really interesting approach!
Thank you, Alex!
Interesting case study, but I’m not sure I fully agree with this part:
> “By traditional velocity/throughput metrics, this was a completely normal first week.”
If this is a long-living team working in a familiar product/domain, I would normally expect relatively stable velocity patterns. In this example, Week 1 velocity was roughly 2x lower than the following weeks (11 SP vs. ~18–21 SP later), which already looks like a noticeable slowdown compared to the team’s historical velocity (assuming they typically deliver ~20 SP per sprint).
Also, if the team initially committed to a normal amount of work but closed only ~50% of it, then the do/say ratio would already drop significantly compared to a typical 70–90% range. In many teams, that alone would trigger a retro discussion around blockers, unclear requirements, or execution friction.
That said, I do think the buffer consumption tracking is an interesting approach. We’ve used similar mechanisms a few times on projects where delays had significant financial impact.
Thanks for the thoughtful pushback, you're raising a fair point.
You're right that in theory, a 2x velocity drop in Week 1 should be noticeable. But here's the thing: in practice, the only reference point you have without the buffer is approximate velocity. You see 11 SP delivered and you compare it to... what exactly? A rough historical average? Most teams don't have a precise enough baseline to confidently say "this is a problem" after just one week. First weeks are noisy, onboarding to a new epic, context switching, ramping up. It's easy to rationalize.
The buffer makes this comparison much sharper. Instead of comparing delivered SP to a vague velocity range, you're comparing actual cycle times against the median completion time for each story point value. That's a much more sensitive signal. In day-to-day work, nobody remembers how long a 3 SP task typically takes - we remember whether it felt hard or easy, not whether it took 3 days or 5. The buffer tracking does that remembering for you, at the individual task level, and aggregates it automatically.
But you're absolutely right, you can draw meaningful conclusions without this methodology too. I just find it's harder to catch things early, and easier for signals to slip through. The buffer gives you a structured framework for something that otherwise relies on gut feel and experience.
Thank you for sharing the methodology. I am wondering how to adjust it for the teams that are redesigning their workflow and no longer create tasks that can be tracked or do it lightly, as they adopt more AI coding.
How do you communicate about scope/requirements? Anyway, if you have nothing, you can ask the team for estimates and then cut them off by 25%-50%, and track only buffer. That's fine. Then your fever chart is based on what you can accept/tolerate. Let's say the yellow area is where your project progress - buffer consumption is <-15;15> (in percentage points), and your red is below -6 percentage points. Let me know, Dana if it makes sense to you
As an expert Scrum Master, my reaction to this article on the Critical Chain methodology is mixed. While I deeply appreciate the practical problem-solving and the focus on flow and team psychology, the core prescription—cutting all estimates in half—is fundamentally at odds with Scrum’s values and empirically proven best practices. It’s an elegant solution, but to the wrong problem.
Here’s my breakdown from an agile and Scrum perspective.
What I Appreciate (The Good)
The author, Karol, is a thoughtful practitioner, and several aspects of his approach are genuinely clever and align with an agile mindset, even if the framework isn't.
· Focus on Flow and Constraints: The core idea of identifying the critical chain and using a project buffer is conceptually similar to a Kanban system’s focus on flow and limiting work in progress (WIP). The "red alert" in Week 1 is a fantastic example of catching a blocker (unclear requirements) early, which is pure agile.
· Psychological Safety is Key: The non-negotiable rule of "no penalties" for missing aggressive estimates is 100% correct and crucial for any team's success. Creating an environment where it's safe to fail is a foundation of Scrum’s value of Courage.
· Shifting from Individual to Team Accountability: The practice of tracking the buffer instead of individual task overruns is excellent. It fosters collective ownership and moves away from the toxic "who's behind?" interrogation. This perfectly mirrors a Scrum team’s shared commitment to the Sprint Goal.
· Empirical Data (Used Creatively): Using historical median cycle time is a good, data-driven starting point. He’s looking at real work, not wishful thinking. His point about not building complex math on an uncertain baseline is, ironically, a fantastic argument for relative estimation and against his own time-based conversion.
The Fundamental Flaws (The Risky)
Despite the smart tactics, the method’s foundation is built on two anti-agile principles: mistrust of the team and a time-based, predictive planning model.
It Violates the Core Principle of Self-ManagementA Scrum team collectively owns their Sprint Backlog and creates a forecast, or plan, based on their capacity and historical velocity. A manager secretly cutting their estimates by 50% is a direct assault on that self-management. It says, "I don't trust your professional judgment; I know your job better than you do." This erodes the Respect and Openness that Scrum demands.
It Misdiagnoses the Problem of Parkinson’s LawParkinson’s Law ("work expands to fill the time") is a symptom of a system with low urgency and unclear short-term goals, not an immutable law. Scrum addresses this directly, not by shortening a deadline in a spreadsheet.
· The Sprint Timebox: The Sprint itself is a natural Parkinson’s Law killer. The team commits to a Sprint Goal for a fixed short period (e.g., two weeks). This creates immediate, palpable urgency.
· Sprint Backlog & Daily Scrum: Every day, the team inspects progress toward the Sprint Goal. If someone finishes early, they don't "polish things that don’t need polishing"—they pull the next highest-priority item from the Sprint Backlog. The time saved is instantly and transparently reinvested.
The "Estimate Conversion" is a Dangerous AbstractionConverting story points to time using a median is a cardinal sin in Scrum. Story points are a relative, unitless measure of complexity, effort, and uncertainty. They are specifically designed to avoid the illusion of time precision. A median of 3 days for a 5-point story erases critical context: Was that a simple 5-pointer or a risky one? By slicing this unreliable number in half, you’re not creating an "aggressive but achievable" target; you’re creating a random guess and then calling it a plan. The buffer becomes a pseudo-scientific way to manage the resulting chaos, which you created.
The Scrum Master’s Expert Advice
Instead of secretly managing a buffer spreadsheet, a Scrum Master would facilitate a transparent, team-empowered solution. Here’s how to achieve the same goals—early project completion without stress—using actual Scrum:
Replace the "Critical Chain" with a Laser Focus on the Sprint GoalThe author’s red alert in Week 1 was triggered because the method highlighted a rate of progress problem. A great Scrum team sees this even faster. In the Daily Scrum, the question isn't "Are you on track to finish your task?" but "Is there anything blocking our path to the Sprint Goal?" Unclear requirements blocking two senior engineers would have been the screaming, central topic of conversation on Day 1 or 2, not discovered in a weekly review.
Use the Sprint Retrospective to Inspect and Adapt FlowIf the team feels they aren’t working with enough intensity, that’s a process problem they can solve. In a Retrospective, a Scrum Master can guide the conversation:
"Team, I've noticed our cycle times have a lot of variance, and some tasks sit idle for a while. How can we improve our flow? Would it help to swarm on a key item? Should we define our 'Definition of Done' more clearly to reduce polishing? What’s our working agreement for pulling in new work once our task is complete?"
This creates team-owned rules for urgency, not management-imposed half-deadlines.
Forecast with Data, Not Manufactured StressThe desire for a project end-date is real. Scrum uses empirical data transparently. A burndown chart for the release, complemented by a Monte Carlo simulation based on the team’s historical throughput (e.g., "How many story points do we finish per Sprint?"), provides a probabilistic forecast. The conversation changes from "We must hit this artificial date I’ve set" to "Based on our data, we have an 85% chance of finishing this scope in 4 Sprints. If we want higher confidence, we need to negotiate scope." This is honest, respects the team, and manages stakeholders far more professionally than a red/yellow/green buffer gauge.
In conclusion: The article describes a well-intentioned, sophisticated way to manage a team’s commitment as if it were a project management problem. Scrum’s philosophy is to make visible the dysfunction (Parkinson’s Law) and empower the team to solve it through transparency, inspection, and adaptation. The "captured time savings" he celebrates are just the team working at a sustainable, focused pace, which is the baseline expectation in a healthy Scrum team. The method gets results despite its flawed premise because it introduces focus and a feedback loop, but a skilled Scrum Master achieves the same results by building a system of trust and empowerment, not by gaming one.
Thank you for such a thorough response. You've raised a lot of points here. To keep this from becoming an essay of its own, let me address the main ones.
1. First, this isn't done secretly. I present the methodology to the team transparently, explain how it works, and walk them through the rules - including the "no penalties" principle. They know exactly what's happening and why. So the "assault on self-management" framing doesn't apply here.
2. On Parkinson's Law being a symptom of low urgency - I respectfully disagree. It affects everyone, including highly motivated teams. A sprint timebox limits it at the sprint level, but within individual tasks, it still operates. If someone has 5 days for a task inside a two-week sprint, Parkinson's Law applies to those 5 days.
3. On the story point to time conversion being a "cardinal sin" - in theory, story points measure complexity, not time. In practice, every team knows that their 5-point tasks take roughly X days. I'm simply formalizing what everyone already knows but pretends they don't - and I'm doing it with empirical data (medians from historical completions), not guesswork.
4. On the Daily Scrum catching blockers faster - in theory, yes. In practice, unclear requirements rarely surface as blockers in standup. Developers say "working on task X, no blockers" - because ambiguity doesn't feel like a blocker, it feels like normal work. The buffer metric catches this because it measures outcomes (actual cycle time vs. expected), not self-reported status.
I fully agree that a mature Scrum team with a skilled Scrum Master can achieve similar results through transparency and empowerment. But that's a high bar that not every team meets every sprint. Critical Chain gives you a structured fallback - a measurable feedback loop that works even when the human dynamics aren't perfect.
Appreciate the discussion - these are exactly the kind of conversations that push practitioners to sharpen their thinking.