Little's Law applied to Quarterly ART delivery

The following is my opinion and does not reflect that of anyone else. 

All of the metrics that Daniel Vacanti recommends is based upon what has already been done.  Using those numbers can help you forecast what COULD be done, not WHAT will be done. I would also caution the use of them on multiple teams.  I have found that it is best to calculate on a single team because the "unknowns" are more consistent at that level than at a higher level. 

I have also had much better luck when applying the metrics to individual work items than to epics. Epics can change so much over time and may never complete. Individual work items will have a shorter life span if they are being crafted correctly. 

You can still apply metrics created at the lowest level item to larger plans.  For example, if you use Little's Law to calculate that one team's cycle time on 200 items is 2 quarters and another team's cycle time on 400 items is 2 quarters, you could identify work for both teams that could potentially be completed in 2 quarters.  That is going to be more useful to the individual teams. 

And if we wanted to increase throughput, according to Little's Law we should increase WIP, but that sounds counterintuitive:

Not completely accurate.  Your statement is targeting cycle time, not throughput.  Throughput does not have a direct link to WIP.  Managing WIP can help improve throughput but there are other ways to do that as well.  For example, the number of items completed can be increased if the items are better structured or better preparation is done before starting the work. 

I suggest that you stop focusing so much on a single aspect of Mr. Vacanti's work and take the body of that work in it's entirety. Each piece of the work feeds and supports other pieces. Each part provides information on specific data.  But the whole of the data is needed to truly understand the situation.

The group of Scrum Masters in the ART (I am of one of them) has put effort 2 quarters ago to get some metrics on the ART quarterly delivery to try and increase our predictability.

Little's Law can be helpful for understanding time to market. It seems you have "Sprints" per delivery, rather than deliveries per Sprint, and the leap-of-faith taken is at least 3 months before an empirical outcome is obtained. If so, that's the biggest obstacle to establishing predictability.

How are you measuring current and unrealized product value, and the ability to innovate? 

It seems you have "Sprints" per delivery, rather than deliveries per Sprint, and the leap-of-faith taken is at least 3 months before an empirical outcome is obtained. If so, that's the biggest obstacle to establishing predictability.

Could you explain further please Ian? I don't understand what that means nor what the basis of this statement is.

For example, the number of items completed can be increased if the items are better structured or better preparation is done before starting the work.

And what I'm thinking from this in the context of Epics is that a lot of work needs to be done to prepare them, refine them, get all the teams involved to share ideas and concerns, prepare a solution architecture.. Which I expect will reduce our agility. So one more reason not to apply these concepts at Epic level?

I suggest that you stop focusing so much on a single aspect of Mr. Vacanti's work and take the body of that work in it's entirety. Each piece of the work feeds and supports other pieces. Each part provides information on specific data.  But the whole of the data is needed to truly understand the situation.

Thanks for the tip Daniel. I'm thinking about understanding properly these three main concepts before moving on, hence my decision to try and apply it (also for my own sake of learning) but I'll take your tip and continue reading, hopefully things will make more sense soon.

According to Little’s Law, to increase throughput, you should focus on reducing cycle time, not increasing WIP. More WIP typically leads to more multitasking and longer cycle times, which is counterproductive. Reducing cycle time can allow for faster delivery of work, thus improving throughput. Measure the trends over time and look for decreasing cycle time. As the saying goes, stop starting and start finishing!

My opinion: you should only count the Epics that have been started within the quarter. Epics that are planned but not yet started should not be included in WIP.

Try lowering WIP to cause a little pain, which might be a catalyst for people see the need to remove dependencies and things that block the flow of work.

In the User Story model, Epics were created to be "containers".  They represent a large body of related work that can be broken down into smaller deliverable units.  They weren't expected to represent the work that is needed. That is what User Stories are for.  Epics don't show immediate value, they show long term goals.  Remember that in Scrum, you want to deliver at least one usable increment of value to the stakeholders in each Sprint.  That is how you gain your feedback that is crucial to adjusting your future work.  If you are not providing that value delivery on a consistent basis, you are not getting all of the benefits of the framework. 

In your original post, I got the impression that your organization is using SAFe.  SAFe uses it's own version of Scrum. The methods and goals of the SAFe methodology are not the same as the Scrum Framework. Some practices that make the Scrum framework useful do not always work in SAFe. Such as @Ian's statement. 

It seems you have "Sprints" per delivery, rather than deliveries per Sprint,...

My interpretation of that statement is that you are not planning to delivery anything during a Sprint.  You seem to be planning multiple Sprints in order to deliver something. That is something I've encountered with many SAFe implementations.  There is nothing wrong with that if it fits your business model and the stakeholders are aligned with it. And for some products, it is the ideal way to work.  But in those models, the value is determined in much different ways and the need for quick feedback/guidance from the stakeholders is not as important. SAFe fits the definition of Agile (capital A, noun) but it isn't necessarily agile (lowercase a, adjective). 

It seems you have "Sprints" per delivery, rather than deliveries per Sprint,...

Similar to @Danial, you are not delivering every sprint, but aim to deliver every 6 weeks. The risk @Ian points out as I understand is that you have a potential longer disconnect from your stakeholders, before they see the final product. (Not wrong, but something to consider.)

I see Little’s Law as more relevant at the task or story level, rather than at the Epic level — although limiting the number of Epics in progress can provide clarity and help with planning and coordination.

My understanding is that WIP limits and Little’s Law are about managing the actual work in progress — limiting how many tasks are in flight at once to reduce context switching and improve flow. Even if you have many Epics open, that alone doesn't tell you much about what's really happening within a sprint or iteration, where the team may be juggling too many user stories or tasks simultaneously.

So regardless of how many Epics are active over a six-week period, it’s important to limit WIP at the task level, such as on your Kanban board. 

As others have mentioned, Littles Law is not a forecasting or planning tool. It is a formula that demonstrates the interplay of Avg. WIP, Avg. Cycle time and Avg. Throughput. Cycle time and Throughput are lagging measures that are measured after the fact. Key takeaway from Little's Law is for a given process, in general, the more things that you work on (WIP) at any given time (on average) the longer it is going to take for each of those things to finish (on average).

Little’s Law is about examining what has happened in the past. It is not about making deterministic forecasts about the future.

~ Actionable Agile Metrics for Predictability_An Introduction (by Daniel S. Vacanti) (Kindle Location 2175). Kindle Edition.  

There are also a set of assumptions associated to Little's Law that must be met for the formula to work out. These assumptions basically boil down to having a stable system. https://www.55degrees.se/post/littles-law-assumptions 

This is something we cover in the Applying Professional Kanban class so students know to avoid the trap of seeing the formula and trying to use it for forecasting. There are better tools for this (cycle time scatterplot for single item forecasts, Monte Carlo for multi-item forecasts are a few to explore).