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:

$\mathrm{Average WIP}\phantom{\rule{0.2em}{0ex}}\text{(The amount of developers,resources,… needed)}\phantom{\rule{0.2em}{0ex}}=\phantom{\rule{0.2em}{0ex}}\phantom{\rule{0ex}{0ex}}\mathrm{Average Lead Time}\phantom{\rule{0.2em}{0ex}}\left(\frac{\mathrm{number of user stories}}{\mathrm{Total project time}}\right)$

$\mathrm{\left(Project/Release\right) lead time \left(Duration\right)}\phantom{\rule{0.2em}{0ex}}=\phantom{\rule{0.2em}{0ex}}\left(\frac{\mathrm{number of user stories}}{\mathrm{Average Throughput}}\right)$

$\mathrm{Duration}\phantom{\rule{0.2em}{0ex}}\phantom{\rule{0.2em}{0ex}}=\phantom{\rule{0.2em}{0ex}}\mathrm{number of stories}\phantom{\rule{0.2em}{0ex}}\left(\frac{\mathrm{average lead time}}{\mathrm{average WIP}}\right)$

Now lets consider an example S-Curve for project delivery rates:

Source: Scrumban [R]Evolution – Getting the most out of Agile, Scrum and Lean, Kanban by Ajay Reddy

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.

$\mathrm{Project Buffer}\phantom{\rule{0.2em}{0ex}}\phantom{\rule{0.2em}{0ex}}=\phantom{\rule{0.2em}{0ex}}\mathrm{S-Curve coefficient}\phantom{\rule{0.2em}{0ex}}x\phantom{\rule{0ex}{0ex}}\left[\left(1+\mathrm{average failure demand}+\mathrm{average expansion of work}\right)x\phantom{\rule{0ex}{0ex}}\left(\frac{\mathrm{number of stories}}{\mathrm{average throughput}}\right)\right]$

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)

$\mathrm{Project Buffer}\phantom{\rule{0.2em}{0ex}}\phantom{\rule{0.2em}{0ex}}=\phantom{\rule{0.2em}{0ex}}0.4\phantom{\rule{0.2em}{0ex}}x\left[\left(1+0.2+0.8\right)x\left(\frac{675}{26}\right)\right]\approx 21weeks$

#### How to use the buffer

As items are delivered you can compare the consumption rate of the buffer against the rate of progress of the project as a whole.
Use the buffer consumption over a defined threshold as a warning signal for your project.

Calculating the percentage of your project completed in addition to the buffer consumption enables tracking your buffer consumption over time.

$\mathrm{Percentage of project completed}\phantom{\rule{0.2em}{0ex}}\phantom{\rule{0.2em}{0ex}}=\phantom{\rule{0.2em}{0ex}}\frac{\mathrm{number of stories delivered}}{\mathrm{number of total stories in your project}}$

Lets assume we have after 14 weeks in a project you have delivered 85 out of 675 stories.

$\mathrm{Percentage of project completed}\phantom{\rule{0.2em}{0ex}}\phantom{\rule{0.2em}{0ex}}=\phantom{\rule{0.2em}{0ex}}\frac{85}{675}\phantom{\rule{0.2em}{0ex}}\approx \phantom{\rule{0.2em}{0ex}}12,6%$

$\mathrm{Projected lead time}\phantom{\rule{0.2em}{0ex}}\phantom{\rule{0.2em}{0ex}}=\phantom{\rule{0.2em}{0ex}}\frac{\mathrm{average lead time}}{\mathrm{average WIP}}x\mathrm{number of stories completed}$

With an average lead time of 0.9 weeks per item and WIP of 24 (see values from previous post) this results in:

$\mathrm{Projected lead time}\phantom{\rule{0.2em}{0ex}}\phantom{\rule{0.2em}{0ex}}=\phantom{\rule{0.2em}{0ex}}\frac{0.9}{24}x85\phantom{\rule{0.2em}{0ex}}\approx \phantom{\rule{0.2em}{0ex}}3.2weeks$

Now we can calculate the percentage of buffer consumed after 14 weeks:

$\mathrm{Percentage of buffer consumed}\phantom{\rule{0.2em}{0ex}}\phantom{\rule{0.2em}{0ex}}=\phantom{\rule{0.2em}{0ex}}\frac{\left(\mathrm{actual lead time}–\mathrm{projected lead time}\right)}{\mathrm{project buffer}}$

Assuming a buffer of 21 weeks we calculate the buffer consumption:

$\mathrm{Percentage of buffer consumed}\phantom{\rule{0.2em}{0ex}}\phantom{\rule{0.2em}{0ex}}=\phantom{\rule{0.2em}{0ex}}\frac{\left(14–3.2\right)}{21}\phantom{\rule{0.2em}{0ex}}=\phantom{\rule{0.2em}{0ex}}51%$

Using the percentage of project completed and the calculated buffer consumption you can plot this information over time and visualize your buffer usage.

Source: Scrumban [R]Evolution – Getting the most out of Agile, Scrum and Lean, Kanban by Ajay Reddy

#### Disclaimer

While reading through various sources and considering a great comment by Gerrit Beine I’m still struggling if its right to apply Little’s Law in software projects or not at all. Having all the limitations in mind (please read e.g. my summary about Actionable Agile Metrics for predictability):

• 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

I still need to figure out whether it’s correct or not. For the moment I think it’s another indicator (e.g. in addition to the Release burndown chart) to foster discussions but should be used carefully.

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.