This page will give you an overview of Monte Carlo Simulations (MCS) and how they are applied in Lighthouse.
While you don’t have to understand the details of what’s going on to use Lighthouse, we recommend eventually going through it. There are things that help predictability in general that become more clear when you understand how MCS works, while Lighthouse is based on certain assumptions that will impact the results.
- Monte Carlo Simulations Explained
- About Predictability
- How Lighthouse Forecasts
- Conclusion
- Further Resources
Monte Carlo Simulations Explained
A forecast using Monte Carlo Simulation will simulate a period using a historical Throughput. You can use it to forecast how many items you can manage to close in a specific amount of time, or how long it will take to get x items done.
Monte Carlo Simulations assume that your future will look like your past. This is great because in your past you most likely had sick-days, holidays, people leaving the team, people joining the team, etc., so you don’t need to do special ‘Capacity Planning’ or anything of those sorts.
Note that this also means that if your future will not be very similar to your past, MCS is maybe not the right approach (but after a couple of weeks you will have the new data to get started with).
Be aware that this is not magic, and you assume that “your future looks like your past”. Meaning that it highly depends on the input in the form of Throughput we feed it with.
Blackout Periods and Forecasting: If you have configured Blackout Periods (e.g. public holidays or company off-days), Lighthouse will automatically skip those days when running a Monte Carlo Simulation. Concretely, each simulated day that lands on a blackout date is not counted as a working day — the simulation simply advances to the next non-blackout day. This means the forecast naturally accounts for known non-working periods without you having to adjust throughput data or add manual buffers.
We recommend that you dive deeper into MCS by reading our blog post An Introduction and Step-by-Step Guide to Monte Carlo Simulations and follow along the exercise in a spreadsheet.
About Predictability
Now that you know How MCS Works, and before we dive into the details of Lighthouse, let’s briefly explore Predictability in the context of MCS.
You are more predictable the closer your forecasts are together. Meaning if there is only a small gap between your percentiles (for example 50/70/85/95%), you would be more predictable.
Let’s look at an example with two teams for this and forecast how many items we can get done in the next 14 days.
==== Forecast Team A ====
*How many Items can be done in 14 days?*
95% Chance: 3 items or more
85% Chance: 5 items or more
70% Chance: 12 items or more
50% Chance: 27 items or more
==== Forecast Team B ====
*How many Items can be done in 14 days?*
95% Chance: 9 items or more
85% Chance: 12 items or more
70% Chance: 14 items or more
50% Chance: 19 items or more
According to our definition, Team B is more predictable. Team A might have a higher upside, but the chance of that happening not that high. The 70% chance is very similar for both teams, but if you want a higher probability, it drops very low with Team A. If you need to get 9 items done in 14 days, you would trust Team B more to get the job done as they are more predictable.
Predictability does not equal speed. If you get one item done consistently every week, you are very predictable. You might also be slow, but those are two different things. We recommend first focusing on predictability, and once you are happy with it, focus on what you can do improve speed.
Improving Predictability
If you want to improve predictability, you should focus on Flow. Flow Metrics are a great indicator and starting point to do so. Keep your Work Item Age low, act on things that start to get older, and the rest will fall in place.
We recommend reading our blog post Using Flow Metrics to get an introduction into Flow Metrics.
How Lighthouse Forecasts
Now that we’ve covered the basics, let’s look at how Lighthouse is forecasting. We’ll use an example to explain the interesting parts. We’ll use some scenarios to explain how Lighthouse is running the forecast, starting from the most simple example to more complicated ones.
We’ll look into how Lighthouse is running When forecasts for portfolios. The How Many and When on Team level are the basic operations that are also covered in the above mentioned blog post.
Teams, Features, and Portfolios
Forecasts will always be made for specific Teams. The forecast will calculate When a certain number of Work Items will be done. Those Work Items are automatically fetched based on the Team Backlog (see Team Work Item Query) and that belong to a specific Feature of a Portfolio (based on the Portfolio Work Item Query).
%%{init: {'theme': 'neutral'}}%%
flowchart LR
T1[Team ] -->|Works on| W1(Work Item)
W1 --> |Belongs to| F1(Feature)
F1 --> |Is part of| P1(Portfolio)
Lighthouse is only aware about Work Items if they are linked to a portfolio. If your team is working on 5 Features, but only 3 of them are linked to Portfolios in Lighthouse, the other 2 Features and all the work items that belong to them will be ignored, and the forecast assumes you will only work on the 3 Features that are known. It is therefore important to make sure you have all the Features that are relevant to you covered within a Lighthouse Portfolio.
%%{init: {'theme': 'neutral'}}%%
flowchart LR
T1[Team] --> W1(Work Item 1)
T1 --> W2(Work Item 2)
T1 --> W3(Work Item 3)
T1 --> W4(Work Item 4)
T1 --> W5(Work Item 5)
W1 --> F1(Feature 1)
W2 --> F3
W3 --> F2(Feature 2)
W4 --> F3(Feature 3)
W5 --> F3
F1 --> P1(Portfolio 1)
F2 --> P1
F3 --> P2(Portfolio 2)
If Portfolio 2 is not defined in Lighthouse, Work Item 2, 4, and 5 will also not be known to Lighthouse.
Why the Backlog Order Matters
When Lighthouse is forecasting, it will always take all the Features of all Portfolios into account. If you set up a new Portfolio, you want to know when this will be done taking into account all the other things that are going on. You can’t make a forecast for a Portfolio in isolation, but you will always look at the full known backlog.
That means, if you really want to ignore everything else, just remove all other Portfolios. That’s not recommended though.
Because Lighthouse works this way, this is also the reason why the order is so important. In the above image, you can see that Feature 1 is ordered above Feature 2, which itself is above Feature 3. That means that Lighthouse assume we first focus all our efforts on Feature 1 (assuming a Feature WIP of 1), then on Feature 2, and only then on Feature 3. If you forecast Portfolio 2, the forecast will take into account that Feature 1 and Feature 2 must be done before that.
The Feature View in the Teams Detail Page will show you all Features the team is contributing towards in their order. If you want the full picture instead of one team’s slice, the Features page lists every Feature across all Portfolios in exactly the order described here.
Who decides that order
By default your work tracking system does, through the rank your Features already carry there. Lighthouse re-reads it on every refresh, which means a rank changed in Azure DevOps, Jira, or Linear moves your forecasted dates without anyone on your team deciding it — and on a connector with no meaningful rank, such as ServiceNow, there was never an order worth reading.
You can hand that decision to Lighthouse instead, with Feature Order under System Settings. Nothing moves when you turn it on; from then on refreshes no longer re-sequence the forecast.
Every Feature list then offers Move to Top, Move Up, Move Down and Move to Bottom, and a move re-forecasts straight away rather than waiting for the next refresh — so you can try an order and read the dates it produces. See Moving a Feature.
The Impact of Feature WIP
By default, Lighthouse will assume that your Teams will work on one Feature at a time (Feature WIP = 1). In other words, this means that the forecast will check how many items can be done, and assume all those items will contribute to the first feature. So the Features will be done in sequence:
%%{init: {'theme': 'neutral'}}%%
flowchart LR
F1(Feature 1) --> F2(Feature 2)
F2 --> F3(Feature 3)
If we increase the Feature WIP to 2, we will assume that the work that is completed is distributed to two Features (as long as we have 2):
%%{init: {'theme': 'neutral'}}%%
flowchart LR
F1(Feature 1) --> F3(Feature 3)
F2(Feature 2) --> F3
The same pattern can be applied with an even higher Feature WIP (as an example 3):
%%{init: {'theme': 'neutral'}}%%
flowchart LR
F1(Feature 1) --> F4(Feature 4)
F2(Feature 2) --> F4
F3(Feature 3) --> F4
In simple terms this means, the higher the Feature WIP, the more focus goes away from the highest priority item (Feature 1) and the earlier we start on less important things (Feature 2 and following). So instead of getting the most important thing early, we get everything later. This is contradicting with our ambition to continuously deliver value in small batches.
We highly recommend to keeping your Feature WIP as low as possible. Lighthouse can help you make the effects of a high Feature WIP transparent. It also is able to automatically adjust the Feature WIP based on your work in progress. See the Team Settings for more details.
Example Scenarios
So let’s go through some scenarios to look at what happens when Lighthouse forecasts.
For simplicity, we’ll talk only about Teams and Features. As you learned above, this is tied to Portfolios. However, when it comes to forecasting we just care about the Features in Order, independent of which Portfolios they are in. To simplify this a bit, we’ll skip the Portfolios in the examples.
1 Team - 1 Feature
The most basic case is if we have a single team, working on a single Feature. This equals a simple When forecast. We take the remaining Work Items for this Feature (all items that belong to this Feature that are Not Done).
Then we calculate how long it will take to complete all those items.
Feature WIP does not matter in this situation, as we’ll only have one Feature available. Thus all the work goes into that Feature.
1 Team - 2 Features
If we have a single team, but 2 features, it starts to get more interesting. Lighthouse will first get all remaining work items for each Feature.
Then it will simulate a single day, and reduce the remaining work of from the Features till there is nothing left. Once both Features have no remaining items left, the simulation is done. For each feature, we’ll count the simulated number of days it took.
For Feature 2 we will not start with the 1st day, but the count will resume from where it was when we finished Feature 1.
This is done 10’000 times and the results are stored (how long did it take till the Features were done).
If the Feature WIP is 1, all simulated Throughput goes into the first Feature, until it’s done. From then on, all simulated Throughput goes towards the second one.
If you have 1 item left for a Feature, and you simulate 2 or more items to be done that day, the full Throughput will go to Feature 1. Let’s book this under context switching cost.
If we have a Feature WIP of 2, we simulate the Throughput each day. Then we randomly pick which Feature to assign this to.
| Simulated Throughput | Feature WIP | Behaviour |
|---|---|---|
| 1 | 1 | Item goes to Feature 1 |
| 1 | 2 | Randomly select if it goes to Feature 1 or Feature 2 |
| 2 | 1 | Both items go to Feature 1 |
| 2 | 2 | Items are randomly distributed between Feature 1 and Feature 2. It can be 2 items in either Feature, or an even split. |
| 3 | 1 | All items go to Feature 1 |
| 3 | 2 | Items are randomly distributed between Feature 1 and Feature 2. It can be 3 items in either Feature, or a 2/1 split in either combination. |
Before you ask, it’s not possible to somehow weight Features, for example saying we work 80% on Feature 1 and 20% on Feature 2. If you work on mulitple things, items will be randomly distributed.
2 Teams - 2 Features
If we have two teams working on two features independently, it’s the same case as in 1 Team - 1 Feature. We simply do it for both teams individually.
2 Teams - 1 Feature
A tricky case is if we have a feature that is being worked on by two teams. This means both teams have work to do for this feature. Lighthouse will run two forecasts, one for each team with the remaining work for the Feature (similar to 1 Team - 1 Feature). Then both forecasts will be stored for this Feature.
The Feature is only done once every team is done. So Lighthouse combines the two forecasts into one: it multiplies the teams’ probabilities together.
That does not mean that one team is slower, they might just have other work that is ordered higher up.
Why multiply? Think of each team finishing on time as a coin landing heads. One coin landing heads is not unlikely. Both coins landing heads at the same time is rarer. If two teams each have an 85% chance of being done by a date, the chance that both are done by that date is about 72%. So the date Lighthouse can honestly call “85% likely” is a bit later than either team’s own 85% date.
Two things worth knowing about this:
- Dates only ever move later, never earlier. Nobody’s forecast becomes more optimistic because of this.
- Features with a single team are completely unaffected, at every percentile. If only one team contributes, there is nothing to combine.
Dependencies are still horrible, so try to get rid of them. Lighthouse now tells you the truth about what they cost you instead of hiding it.
Doing it by hand
You can reproduce this yourself with a spreadsheet - it needs no simulation, just the two teams’ results. Say both teams have 3 items left and their When forecasts each came out like this, out of 10’000 trials:
| Finished on day | Team A | Team B |
|---|---|---|
| 1 | 5000 | 5000 |
| 2 | 2500 | 2500 |
| 3 | 2500 | 2500 |
Step 1 - turn each team into “chance of being done by this day”. Add the trials up as you go down the column, then divide by 10’000:
| By day | Team A | Team B |
|---|---|---|
| 1 | 5000 / 10’000 = 0.50 | 0.50 |
| 2 | 7500 / 10’000 = 0.75 | 0.75 |
| 3 | 10’000 / 10’000 = 1.00 | 1.00 |
Step 2 - multiply the two columns, row by row. This is the whole idea: both teams have to be done.
| By day | Team A × Team B | Both done by then |
|---|---|---|
| 1 | 0.50 × 0.50 | 0.25 |
| 2 | 0.75 × 0.75 | 0.5625 |
| 3 | 1.00 × 1.00 | 1.00 |
Step 3 - read your percentile off that last column. It is the first day where the chance reaches the number you care about.
- 50%: day 1 is only at 0.25, day 2 is at 0.5625 → day 2
- 85%: day 1 and day 2 are both below 0.85, day 3 reaches 1.00 → day 3
Each team on its own would have told you day 1 for the 50% mark. Together they say day 2. Neither team got slower - you are simply asking a harder question, namely whether both of them are finished.
If a team has already finished its share, its column is 1.00 everywhere, and multiplying by 1.00 changes nothing. That is why finished teams and single-team Features do not shift the result.
The multiplication treats the teams as independent of each other. If the same people work in both teams, or one team has to hand something over to the other before it can start, that assumption breaks - and reality will be worse than this maths suggests, not better. That is another good reason to get rid of dependencies.
When a Team Cannot Be Forecast
A forecast needs history. If one of the teams working on a Feature has no closed items in its history, Lighthouse has nothing to simulate for that team, and therefore no honest answer for the Feature as a whole.
In that case Lighthouse tells you so instead of guessing: the Feature shows Cannot forecast rather than dates or a likelihood, and names the team whose data is missing. The same goes for any Delivery that contains such a Feature - one Feature nobody can forecast makes the whole Delivery unforecastable.
This is different from the insufficient data warning, which means the forecast rests on very little history but still exists. “Cannot forecast” means there is no forecast at all.
The fix is in your data, not in Lighthouse: give that team some closed work items in its history, and the Feature starts forecasting again.
A Feature with no remaining work is not affected. It is done - that is a fact, not a forecast - and it still reads as 100%.
A Delivery With Several Features
A Delivery groups Features that have to be there together. So the question it answers is not “when is one of these done” but “when are all of them done” - the same step up you just saw from one team to two, one level higher.
The trap is that a Delivery is not simply its Features multiplied together. Two Features worked by the same team are not independent: that team can only do one thing at a time, so its Features queue up behind each other rather than racing in parallel. Multiplying them would charge that team twice for the same capacity.
So Lighthouse works with one row per team per Feature:
- Within a team, take that team’s worst row. A team is done with the Delivery when it has finished the last of its own share.
- Across teams, multiply, exactly as it does for a single Feature with two teams.
A Feature worked by two teams contributes one row to each team’s side, so it is counted once on each and never penalised twice.
An example. Two teams, two Features. Team A works on Checkout only, Team B works on both Checkout and Reporting. By your target date, their rows say:
| Row | Chance of being done by the date |
|---|---|
| Team A on Checkout | 0.90 |
| Team B on Checkout | 0.80 |
| Team B on Reporting | 0.95 |
Team A’s side is just its one row, 0.90. Team B’s side is its worst row, 0.80 - Reporting’s 0.95 does not help, because Team B still has Checkout to finish. Multiply the two sides:
0.90 × 0.80 = 0.72, so the Delivery reads 72%.
Now look at what the Feature rows themselves show. Checkout needs both teams, so it reads 0.90 × 0.80 = 0.72. Reporting needs only Team B, so it reads 0.95.
The Delivery’s 72% is equal to Checkout’s 72%, not below it. That is not a rounding artefact: Checkout is the Feature that governs this Delivery entirely, and Reporting has enough slack that it adds no further risk. A Delivery is never more likely than the Features it contains, but it can match the least likely one exactly.
The same combination drives the 70/85/95 dates under the Delivery. They come from the combined distribution, not from any single Feature’s, which is why they can sit later than every date you see on the Features themselves.
Across teams this multiplication assumes the teams are independent of each other, exactly as it does for a single Feature. Shared people, or one team waiting on a hand-off from another, break that assumption and make reality worse than the number suggests. Within a team, taking the worst row is the optimistic end of the range too: it assumes that team’s Features do not delay each other beyond the queueing already in its throughput. Both approximations lean the same way, so treat the Delivery number as a ceiling rather than a floor.
A Feature with no remaining work drops out of the calculation - it is done, and multiplying by a certainty changes nothing. A Delivery whose work is all finished simply reads 100%.
Dependencies
You cannot define a dependency in Lighthouse. There is no screen that says “this Feature has to wait for those two other Features”, and there never will be: Lighthouse reads your work tracking system, it does not become a second place to plan in.
What it does do is read the dependencies you already recorded there — Predecessor links in Azure DevOps, is blocked by issue links in Jira, Project relations in Linear — and show them on every Feature list, together with a warning on the ones nothing could be done about. See Dependencies for what that looks like.
Reading them is not the same as forecasting around them. The dates on this page come from throughput and the Feature WIP of each Team, and nothing in that simulation waits for another Feature to finish first. A Feature whose dependency is not done yet can still be forecast to finish next week. Treat the Dependencies column as something to act on yourself, not as something the forecast has already accounted for.
That is deliberate, and it is worth saying why. We don’t like dependencies. Wherever there are some, you should try to remove them as aggressively as you can — as long as there are many of them, a tool like Lighthouse will not help you very much, and neither will a forecast that pretends to model them precisely. Making them visible is the part that changes behaviour; modelling them is the part that makes the tool complicated and the number no more honest.
Please have a look at the work of Prateek Singh, who wrote among others, this very interesting blog post: Understanding the Impact of Dependencies
Conclusion
Congrats, you made it to the end of this page! We understand that this may have been the opposite of light reading. As mentioned in the beginning, you don’t need to know all of this when you start out with Lightouse. But as you go on, you may wonder why certain things they work how they do. And sometimes the answer can be found in the way Lighthouse works.
You may wonder why this is so complicated. It would be a lot easier if there were no dependencies between teams, teams would only focus on one feature at a time, and could deliver portfolios without other teams. Also it would be nice if we could keep a proper order in our backlog. We just try to help you cope with reality…don’t hate the player, hate the game. Or better yet, change how your organization plays the game.
Further Resources
See Resources for an extensive list of resources around this topic.