Low WIP, Small Features, High Freedom
How we use Flow Metrics to ship and learn fast
In early February, we released a new version of Lighthouse with the “MCS Backtesting” feature. We did not anticipate this feature to be noticed much; in fact, we only did it because we built it as part of a workshop to demo how we implement features (but that’s for another blog post). However, after we released it, we got a spike in users, and with that, a lot of feedback.
Using this event as an example, we’d like to share in this post how we use Flow Metrics for this part of our Product Management for Lighthouse. We realized that our way of working allows us not only to try out risk-free experiments, but also to react quickly to new developments like a sudden inflow of feedback from new users.
About Value
When we formulate new Features, we try to focus on what problem this will solve. Then we add one or multiple work items below that, which are more concrete steps to achieve this functionality that should solve the problem. Every Feature is assumed to be releasable on its own and to add value for our customers and users. We hope that those Features bring value; however, we can only know this once we have released them and they are in our users’ hands.
Flow is the movement of potential value through a system
- The Kanban Guide
Thus, we need to slice a feature as thin as we can. There is no point in spending multiple weeks on something, only to find out it was not what anyone needed. No feature adds value until proven otherwise.
The MCS Backtesting feature was no different; we had no idea if people would care about this. But it was small enough that finding out was worth the risk.
Impact, Confidence, and Ease
When we look at a new feature, we evaluate it through three lenses: Impact, Confidence, and Ease. Rather than debating endlessly or going with the loudest voice in the room, this gives us a structured way to prioritize.
If you want to dive deeper into this approach, Itamar Gilad's writing on ICE scores is a great starting point
The good thing about slicing our features into small pieces is that we usually do not have to spend much time arguing about the impact and the confidence, because they are rather easy to implement.
We can take risks with features we are very unsure about, because they are all easy to implement. Sometimes things will not resonate with the user base as we’d hoped. Sometimes we do something and are highly surprised by the success. If it weren’t for the high “Ease” score, we most likely would never have worked on it. And in turn, we’d never have learned that they are valuable.
MCS Backtesting scored low on Confidence, we genuinely weren't sure anyone would notice it. But the Ease was high, so we shipped it anyway. That's exactly the kind of bet this approach allows you to make.
So what makes a Feature easy for us? Size matters!
Feature Size
It’s rather simple; a small feature is an easy feature. We measure the size of our feature by its work item count. No estimate, no effort, simply the count of work items for a Feature. Below you can see how our features are sized:
You can see that:
50% of our Features contain 5 or fewer Child Items
85% of our Features contain 7 or fewer Child Items
Only one Feature is much larger, with 16 Child Items
This is a testament of our effort to aggressively slice our Features to the smallest possible thing that still delivers value. As we mentioned above, this is important because we want to get feedback as fast as possible. We can always do more, but we often shouldn’t. Having such small Features allows us to start and finish our Features, including releasing them, in most cases within a week.
We can always do more, but we often shouldn’t
If we look at the Cycle Time of our Features, we can see that 85% of all our Epics are closed within 10 days after we started. 70% are done within 7 days of starting. This means if we start today, we have the Feature not only done, but also tested, documented, and released within a week.
MCS Backtesting was one of those sub-5-item features, that we started and shipped within two days.
The Power of Moving Quickly and Easily
Being able to release Features quickly is one thing. However, we want to gather feedback and adjust our approach based on this. For this, we must ensure that we can react quickly and easily as soon as we get this feedback, which can happen at any point in time.
In our “MCS Backtesting” example, we were surprised by the number of new users this feature has brought into Lighthouse. And with those new users, we got:
Questions about how certain things work - which were signals for us that the UX can be improved for easier onboarding
Feedback on existing functionality
Bug Reports, as our tool was used in new environments
We can’t afford the luxury of having a high WIP
In many organizations, their WIP is abundant. We’re just a two-person company. We can’t afford the luxury of having a high WIP. We release a new version with new features roughly every week. We must be able to react to things we learn.
And we do this simply by:
Aggressively controlling WIP
Reduce Cycle Time to the minimum
To many people’s surprise, our WIP at the end of a day is often…zero (nada, niente, 0):
As you can see from the above chart, in the last 30 days, there were only three days where something rolled over to a new day. If we start something, the goal is always to finish it on the same day. Because who knows what tomorrow will bring - maybe someone discovered a bug that needs fixing urgently, or we get some feedback we can address right away. Having things in progress will block us from reacting to those things.
When the MCS Backtesting feedback started rolling in, we were ready to act on it. Not because we planned for it (we obviously didn’t), but because we had nothing else blocking the pipeline.
The result of this is a low Cycle Time. From the 57 Stories we closed in this period, only three took longer than a single day (they were closed in two days). So we practically closed everything within the day we started:
This is not happening by accident, but it also drives our decision-making. We also make Stories as small as possible, and we try whenever possible not start something where we know we can’t close it on the same day.
It’s important to mention that proper engineering practices are the fundamental building block: Practicing proper Continuous Integration and Continuous Delivery (see https://minimumcd.org/ for details), keeping the code clean, and having automated tests for most parts of the application will allow you to develop at speed.
By reducing our Cycle Time and aggressively controlling WIP (see below), combined with the thin feature slices, the “Ease” of most of our features is high. Running an experiment is easy and fast. The cost of failure is low. The ability to pivot is high.
Low WIP = Total freedom to pivot. Or how someone once put it: Agile as fuck!
Conclusion
The MCS Backtesting feature is a perfect example of all of this coming together. We built it as a workshop demo, kept it small, shipped it in a week, and woke up to a wave of new users and feedback we hadn't anticipated. Because our WIP was low and our pipeline was clear, we could respond to that feedback almost immediately. No half-finished work blocking the way.
That's the real power of Flow Metrics in product management. It's not just about going fast; it's about staying free to respond to what you learn. Low WIP, short cycle times, and thin feature slices don't just reduce waste. They give you the ability to be genuinely surprised by your users, and actually do something about it.
If you're curious how this could work for your team, check out Lighthouse, our Services, or reach out if you'd like to explore consulting or a workshop.
It looks like a utopia to me. Even though it’s a two-person product, that WIP progress chart and a cycle time of 1 day at the 95th percentile feels like a dream :) Yes, TDD and CI/CD provide the backbone, but how can you be so aggressive with your WIP? Agile is not dead! It just takes huge courage to do the right thing in the right way.