Based on my previous post where I explained how you can apply Little’s Law for Release Planning this post describes how to add a necessary buffer to consider that project delivery rates follow a fairly predictable S-Curve and that Little’s law can just be applied to the middle section of this curve (if at all).
The following description is based on the book Scrumban [R]Evolution – Getting the most out of Agile, Scrum and Lean, Kanban by Ajay Reddy (I highly recommend reading this book to get a wide range overview about Scrumban!)
As a short recap from the previous post lets shortly have a look on the basic formulas explained:
Now lets consider an example S-Curve for project delivery rates:
It shows that work flows more slowly during the early stages of new projects as understandings are refined and basic infrastructure set up takes place.
It also flows more slowly toward the end of project cycles because of more testing overhead, bug fixes and regression effects (although we try to minimize this effect by test driven approaches, zero bug policies and using agile approaches with iterative and incremental deliveries).
The described formulas can only be applied to the middle portion of the S-Curve for most projects (in the example around 60% of the projects time).
In addition project duration is influenced by expansion of work (as we learn more about the true customer requirements during the project and incremental delivery) and failure demand (like for instance ensuring high quality by removing technical debt).
We need a way to include the mentioned project influences (40% of the S-Curve, expansion of work and failure demand). This can be done by calculating a project buffer like described in Project Planning Using Little’s Law by dimitar.bakardzhiev.
All variables remain best estimates based on historical observation.
The S-Curve coefficient is expressed as percentage and accounts for the uncertainty associated with the slower first and third legs of the S-Curve. Values vary depending on the system but are usually between 25-50%.
The average failure demand, expressed as percentage, accounts for the typical rate of failures (defects, rework, technical debt and others) the system experiences across development efforts.
The average dark matter, expressed as percentage, accounts for the typical rate of work expansion (e.g through knowledge discovery). It can range from 20% to as much as 100% for novice teams.
Lets assume a failure demand of 20% of your time (measured during your project) and your expansion of work is around 80%. In addition we assume an S-Curve coefficent of 40% (0,4).
Our average lead time is 0,9 weeks per story and average WIP is 24 (meaning the average throughput is 26 stories per week)
How to use the buffer
Calculating the percentage of your project completed in addition to the buffer consumption enables tracking your buffer consumption over time.
Lets assume we have after 14 weeks in a project you have delivered 85 out of 675 stories.
With an average lead time of 0.9 weeks per item and WIP of 24 (see values from previous post) this results in:
Now we can calculate the percentage of buffer consumed after 14 weeks:
Assuming a buffer of 21 weeks we calculate the buffer consumption:
Using the percentage of project completed and the calculated buffer consumption you can plot this information over time and visualize your buffer usage.
The average Arrival Rate (Lambda) should equal the average Departure Rate (TH) = we will only start new work at about the same rate that we finish old work
Needs a more late binding (commitment) approach.
Monitor policies around the order in which we pull items through the system – so that work items do not sit and age unnecessarily
all work started will be completed and exit the system
WIP should be roughly the same in the chosen interval
average WIP is neither increasing nor decreasing
- CT,WIP,TH are measured using consistent units
Please share your opinions – I would like to learn more deeply what to consider and if it makes sense at all? I’ll keep you updated with more results of my journey.
Scrumban [R]Evolution – Getting the most out of Agile, Scrum and Lean, Kanban by Ajay Reddy
Whats wrong with Little’s Law predictability
Actionable Agile Metrics for predictability
Release burndown chart
Little’s Law for Release Planning