This week, we’re joined by Jakob Buis, a freelance engineering manager who has been a developer, a team lead, and an engineering manager. These days he works with companies whose software teams have got stuck, or that need to get through their next stage of growth, and he tries to make them “a nicer place to work through getting better results.” Over the years he has collected a set of practices from the best teams he has worked on. They aren’t Scrum theory. They’re the things he has seen work: measure whether customers actually use what you ship, release working software every sprint, and replace estimation with forecasting based on your team’s real data.
The Number That Looked Like a Mistake
The first time Jakob opened the dashboard at one client, a number jumped out at him. The team had four engineers and almost 997,000 days of backlog age in total, close to a million days of good ideas waiting to be built. When he showed it to the company’s product engineer, the reaction was immediate:
Are we that slow?
“No, you’re just collecting a lot of stuff.” Jakob told him.
That distinction matters. A slow team needs help going faster. A team that is just collecting ideas needs to step back and ask a harder question: is what we’re building worth building at all? For Jakob, that question is where improvement starts, because no amount of delivery speed can make up for work that should never have been done.
What Changes When “Done” Means Someone Is Using It
Jakob often quotes Peter Drucker: there is nothing so useless as doing efficiently what should not have been done at all. One of the best teams he ever worked on took that idea literally. Code that was written, tested, and running in production wasn’t counted as done. “It’s done for us,” Jakob says, “but it is done once the actual customer is using it.” A feature nobody opens has delivered no value, however efficiently it was built.
Measuring that doesn’t need a heavy analytics stack. When his team shipped a feature, they added a small, temporary tracking table and recorded one thing: whether a user clicked into it. Zero clicks meant the feature couldn’t have delivered value. One or two clicks meant it caught someone’s interest but didn’t keep it, which makes that person the user to call. Regular daily use pointed to a power user, and forty clicks in an hour usually meant something had crashed. After a couple of weeks, the table was removed.
He pairs this with an idea from Flow Metrics for Scrum Teams by Will Seele and Daniel Vacanti: extend the board to cover the feature’s whole life. The backlog becomes Options, a list of things the team might do. After Discovery and Building comes a column most boards leave out: Validating. “Because you make it visual, you make it easier for people to start thinking about this,” Jakob says. “How will we know that this is actually valuable?” Sometimes the answer is a tracking table. Sometimes it is simply the product owner calling the requester a week after release to ask whether they used the feature.
Why Working Software Beats a Good Demo
The second practice is being able to release working, tested software every sprint. Jakob learned ‘why’ the hard way. His team once built a feature exactly as an internal customer had described it, and only when the customer used it did he realise the concept was wrong. “No one made a mistake there,” Jakob says. What saved the team was that they had built a prototype in a week instead of spending two months before showing anyone.
The Cynefin framework explains why this keeps happening. Most software development is complex work, where cause and effect only become clear once the work is done. The only protection is to make the pieces smaller and put them in front of real users sooner. That is also why a sprint review shouldn’t be a demo. Jakob remembers a team that got excellent feedback on an interactive UX mock-up, then found in the next sprint that the design couldn’t be built as shown. “We demoed the UX. We didn’t demo the working product.”
The same logic applies to the feedback loop itself. On one team Jakob led, users took about a week to reply, so the team kept switching between features while it waited. Cutting that wait to a day, or an hour, protects focus as much as it speeds up learning. “To me, that’s what agility is all about,” he says: the ability of a business to change direction based on what it learns from the market.
From Estimates to Forecasts
The third practice is where Nave comes in. “I hate estimation, personally,” Jakob says. “I’ve never seen a team that does it right, including all the teams I’ve been on.” Optimists, pessimists, the flaw of averages, the tendency to give the same work a higher estimate the second time: the biases pile up faster than any team can remove them.
“There are some ways to make estimation better,” he says. “But ultimately, and this is where Nave comes in, because this is what I essentially learned from Nave and did for the first time with Nave, I am a huge fan of Monte Carlo.” The method takes the team’s actual daily throughput and simulates the weeks ahead thousands of times. The result is a range of outcomes with a probability attached to each. Turn the question around and it gives you a delivery date. “There was no three-hour meeting,” he says. “This turns what is essentially a guess into a data-driven conversation.”
Forecasting also changes how teams answer the manager who wants 100% certainty. The correct answer, Jakob points out, is that you can only be 100% sure of delivering zero or more items. The practical answer is to commit well below the forecast: if you’re 95% sure you can finish 12 items, commit to three or four. That makes the point without a fight: being absolutely sure and being almost sure are very different things.
What This Takes and What It Makes Possible
None of this makes ideas better, and Jakob is clear about that. “The quality of that idea depends on how smart you are, how much you know about the business, how much you know about your customers,” he says. “All of the methods we have are only going to help you find out faster if your idea is any good.” A backlog of almost a million days isn’t a sign of a slow team. It’s a queue of untested ideas. Validating what ships, releasing working software, and forecasting from real data are how a team finds out which of those ideas deserve its time.
It takes discipline: a Validating column that someone actually works, sprint reviews built around software people can use, and a willingness to let data replace gut feeling. What it makes possible is a team that learns faster, promises more honestly, and spends its time on work that matters.
If you’d like to connect with Jakob, follow him on LinkedIn or visit jakobbuis.nl.
Explore more from Nave: Monte Carlo Simulation Explained | Identifying Bottlenecks with Kanban Metrics | Managing Blocked Work
I wish you a productive day, and I’ll see you next week, same time and place, for more managerial insights. Bye for now.
