In order to undertand Scrumban I researched and found this book: Scrumban: And Other Essays on Kanban Systems for Lean Software Developmentby Corey Ladas.

In this book I encountered the Theory of Constraints (ToC) and Drum Buffer Rope (DBR) concepts. Here is a corresponding excerpt from the book:

Imagine we have team of three people, each working as generalists in an agile-style process. They are all qualified and competent workers, and correctly execute the process that they intend to follow. They break their work up into customer-valued features that each take a few days to complete through integration. One developer is a true generalist. It takes her a couple of days to produce a testable functional specification and high-level design. It takes her a couple of days to produce a detailed design and working code. And it takes her a couple of days to verify and validate everything, from code correctness to functional acceptance. Another developer is basically competent at all of these things, but he is a more stereotypically geeky programmer who can crank out high-quality code for most product features in a day, on average. It takes him a bit longer than the others to do the customer-facing part, usually about 4 days for analysis and high-level design. He’s also a bit slower with the validation, because again, if it ain’t writing code, he’s just not that excited about it. And for all the time he spends on specs, they are still mediocre, which results in rework in spite of his good coding skills. The third developer, by contrast, has a sharp eye for design and is very friendly and sympathetic to the business and the customers. He knows the business so well that most of his specs only take a day to write. He’s a competent coder, but a bit old-school in his style and it takes him a bit longer with the current technology. Plus, his heart isn’t quite in it the way it used to be. It takes him three days to develop good code that everybody will feel comfortable with. On the other hand, since his specs are so clean and thorough, and he has a good rapport with the business, the testing usually goes very smoothly in about two days, also (tied for) the best on the team. The team, on average, produces features with a cycle time of 6.67 days per feature. Overall, each team member produces at a similar rate. 2d + 2d + 2d = 6d 4d + 1d + 3d = 8d 1d + 3d + 2d = 6d 20 days / 3 features = 6.67 days/feature It is a one-piece flow (per developer), and everybody is always busy with his or her feature. Nobody ever has to wait to start a new feature. Other than the personal slack built into the task times, capacity utilization is high. But imagine if this team of generalists were allowed to focus only on the skills that they were best at: 1d + 1d + 2d = 4d 1d + 1d + 2d = 4d 1d + 1d + 2d = 4d 12 days / 3 features = 4 days/feature Same people, same features, 40% improvement in productivity... ...if only it were that simple, because there is also a cost here. If they organize themselves as a pipeline, then that pipeline becomes subject to the Theory of Constraints. If they apply Drum-Buffer-Rope, then the testing task sets the pace at 2 days.

That means the total cycle time per feature is: 2d + 2d + 2d = 6d

Please explain why 2d + 2d + 2d = 6d? If you use DBR, I believe it should still take 1d + 1d + 2d = 4d, i.e. we place a buffer in front of the bottleneck to make sure the bottleneck constantly works. What am I missing?

  • The point of Drum-Buffer-Rope here is to identify the "limiting station." It's arguable about whether that applies to your quoted text as originally posted, but the point is most likely that optimizing each "station" yields these values using DBR, but whether that's either true or useful is undefined within the quote.
    – Todd A. Jacobs
    Commented Apr 2 at 20:26
  • In addition to containing insufficient context, your quote seems like it's mashing paragraphs together. This makes it hard to read. Can you please restructure the quote without changing the original question? If you find that you have a new, related question based on additional context you can open a related question and link back to this one.
    – Todd A. Jacobs
    Commented Apr 3 at 17:57

1 Answer 1


You appear to be quoting some text out of context, which is likely why you're confused. I haven't read the book so I can't speak to specifics, but the quoted piece says the average cycle time for this team is 6.67 days regardless of who is doing the work. Personally, I would never round down in such a situation, but the author did.

Whatever answer you're looking for is doubtless later in the chapter or section, making this an exercise in hermaneutics based solely on the text quoted. Even so, the author says that slack is already built into the team's current process, but that the results would be different if the work were organized as a pipeline instead of as a per-person end-to-end task. The high variability of testing time would impact scheduling according to some point the author wishes to make, but the correlation of that variable with a planning principle is not actually made within your quote.

Setting that aside, the basic point is that either sufficient slack is already built into the forecast of future cycle times or it must be explicitly added in some way. Cycle time itself is generally an empirical value derived from "yesterday's weather," but forecasting cycle time onto specific future work items may require a fudge factor of some kind to account for variances in productivity or batch/queue/item sizes. That appears to be the point the author is driving towards, but you'd have to read the whole section in context in order to answer your own question.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.