Lighthouse - Advanced Features
What distinguishes Lighthouse from any other Forecasting Tool
In this post, we will give you an overview of Lighthouse's advanced features so you know what sets it apart from other forecasting tools.
Note that this is the state as of February 2025. The most up-to-date way Lighthouse is forecasting can always be found in the docs themselves, as this post may be outdated.
Lighthouse is the flagship product of Let People Work. It allows you to forecast completion dates with confidence and supports a wide range of scenarios, including projects with multiple teams and handling features that are not broken down yet.
It’s free to use, is open-source, and doesn’t need any cloud connection.
Join our Slack Community to learn from other users and become part of the development.
If you look for the basic features, you can find it in this post:
In this post, we’ll share some advanced (but awesome) features of Lighthouse that make your life better, and your forecast more realistic, and hopefully help you drive meaningful change in your organization:
Default Feature Sizes
Unparented Work Items
Feature WIP
Active Feature Visualization
Default Feature Size
Lighthouse Project Forecasting is based on the child items of your Features (for example your Epics or Feature work item types). However, not every Feature will be broken down already. This is great because it might not be worth the effort. However, when we run a forecast, we need to know the approximate size. Lighthouse offers functionality to define a Default Feature Size that is applied to features that don’t have any child items yet.
The default feature size can be defined either as a fixed number, using historical data, or using an estimate.
Lighthouse will determine the size in this order:
Number of Child Items read from your Work Tracking System
Estimation of Size per Feature
Default/Historical Feature Size
If no child items are defined, it will fall back to the estimation. If no field is defined, or the field is defined but no estimate is found for a feature, it will fall back to the default or historical value (depending on your configuration).
Default Number of Items
The easiest way is to define a default number of Items, for example, 15 items. You can base this number on your historical data or just go with your gut. The value is fixed and will be applied to all Features that qualify for using the default value.
Historical Feature Size
Instead of a default size, you can also choose to let Lighthouse calculate your historical feature size. If you do so, you have to define a percentile and a query.
As an example, if you chose the 85th percentile, it means that it uses the size that 85% of your Features had. If you go for 50, it uses the size that at least 50% of your features had. This is more flexible than using a fixed number, as Lighthouse will recalculate this value for you when updating. So over time, the system learns and the values will automatically adjust.
Estimated Size
On top of the default size, which will be similar for every Feature, you can also specify a field that would include an estimate. This allows you to use the default size for features you have not looked at at all while providing more details for some things that you may have started to refine, but have no child items yet. Simply specify the name of the field that contains your estimate, and Lighthouse will extract the data from your work tracking system.
State Override
Sometimes we may have child items already, but we are still in the process of refining them. So instead of using the 3 child items that are already there, we may still want to use the estimate (which may say 12 for a feature) for some time. In order to achieve this, you can define which states should ignore the actual child items. For those states, the real number will always be ignored, and the estimate or default size will be used.
Visual Indication
You will get a visual indication for every item that is using the default/estimated size. That helps you identify where you have pending work to refine the features. This way Lighthouse allows you to create realistic forecasts early on, while also making sure you are not forgetting about the fact that some features still need to be refined (which may change your forecasts).
Unparented Work Items
Sometimes (or shall we say “in the real world”) there is work that does not belong to a specific Feature. Still, it needs to get done. These may be small improvements that were planned (or promised) or some bug fixes.
You could of course add some container feature (or even multiple) with the sole purpose of adding everything in this bucket. However, if you use a dedicated workflow for features (which we highly encourage), and your feature should be scoped and provide value, that is often at odds with such “containers”.
What Lighthouse offers instead is to collect all work items that are not having a featured parent into a “virtual” unparented feature that is also taken into the forecast. All you need to do for this is to create a query that searches for the work items in the individual team backlogs and Lighthouse will group all of them together and show them as “Unparented Items” for your projects.
The query will only include items that are not already part of this project (under a ‘regular feature’). If we look at the screenshot above, it means that Lighthouse will go through the Backlogs of all the four involved teams, check every item that has the label My Release, and will add it to the virtual unparented feature if it’s not part of a “regular” Feature.
If you have multiple teams, all unparented work will be added to this Feature. Also, the unparented Feature will be at the bottom of the priority, so it is always assumed that it will be done last.
Feature WIP
If your team is working on multiple Features at the same time, Lighthouse allows you to define this number, as this will impact your forecasts for projects, and will lead to different predicted delivery times.
Working on one Feature at a time does not mean only having one item in progress. It means that all items that are in progress belong to the same feature.
As an example, if you work on a single feature at a time, this feature will be done as fast as possible. If you work on two features, the first feature will finish later (as at least some of the teams effort goes to the second feature). In an ideal world, you have a Feature WIP of one. Your reality might look different, and that’s ok. Just know that ideally you should strive to be as close as possible to a Feature WIP of one.
Automatically Adjust Feature WIP
Probably you don’t want to go and count your Feature WIP and adjust the Lighthouse settings every few days. So instead, Lighthouse allows you to automatically adjust the Feature WIP with every refresh to the number of Features that are right now being worked on by this team.
Enable this setting if you want to increase transparency. A higher Feature WIP will lead to late delivery of many features. Not everyone will like this. It may be a good way to show why we should use focus (and Lighthouse might give you the underlying data for that). Keep fighting the good fight!
Visualize The Impact of Feature WIP
Your Feature WIP might not always be the same (again, the real world is messy). You can set your Feature WIP to anything you like, there does not need to be a correlation to what is actually happening (although obviously it would be good if the number reflects reality…). Lighthouse allows you to easily adjust the Feature WIP to visualize the impact. Once adjusted, it will automatically reforecast the completion dates and likelihoods for each milestone:
You should strive for a Feature WIP that is as low as possible, ideally 1 or 2. However, if your reality looks different, it makes more sense to set Lighthouse up accordingly, as otherwise the forecasts will be off. You may use Lighthouse to make it transparent what a change in Feature WIP can mean in terms of Feature delivery, which could be a good conversation starter to make a change.
If a team is configured to Automatically Adjust Feature WIP, you can still change the settings manually. However, they will be overridden the next time the Team Data will be updated.
Active Feature Visualization
For both Teams and Projects, Lighthouse will visually indicate what Features are actively being worked on.
This is a great indicator to see if we are focusing on the most important items (as Lighthouse is based on the order in your Work Tracking System).
Actively being worked on means that right now there is one child item of a Feature that is In Progress. If you have 2 items already done, but right now no other child item is in progress, it will not appear as actively being worked on.
On a team level, you can see how many Features are actively being worked on, and if they are “at the top” of the list (if not, this may be a good conversation starter).
For projects you get the same view, but with all the involved teams. In the following screenshot you can see that we currently work on the second feature, while the first one is not even refined yet (indicated by the use of the Default Size).
Getting Started
Now that you know about what sets Lighthouse apart, you may wonder how you can start to use it. Our documentation at https://docs.lighthouse.letpeople.work is the best place to get started. Do you need support? Join our Slack Channel and get help from us and other users who already use the tool. Or reach out to us to discuss what options we offer to businesses that need tailored support.