Blog

It is essentially re-wording an assumption or set of assumptions in a way that is put more like a question, or something that needs to be tested, eg. we believe this particular set of assumptions to be true, and we will know if we are right if X happens.

I think the key difference really would be: the leader leads the way in terms of direction and then creates the space where that might happen. A leader is understanding that it is not just about delivery, that two-thirds of things are rarely or never used and so maybe we should be trying to have a heat-seeking missile to find the value in the market and maybe use cheap experiments so we do not lose our short and massive bets.

Two-week sprints have quietly become the industry default, and a lot of teams never question it. But the length of your sprint shouldn't be driven by what's most popular — it should be driven by how long it actually takes your team to deliver a Done increment. Anything shorter invites shortcuts and technical debt; anything much longer points to a product backlog problem that a new sprint length won't solve.

Work item types are optional in Kanban — but used well, they can transform how teams read their boards and respond to aging work. This piece walks through a practical example: imagine a red item that's four days old on a board with an 85th percentile SLE of eight days or less. At first glance, it looks fine. But what if red items typically take three days or less? Suddenly, that card is in real trouble. By assigning a Service Level Expectation to each work item type — and showing it visibly on the board — you stop treating apples, oranges, and grapes as if they were all the same fruit. Plus a tip on showing both the 85th and 95th percentiles when there's a big gap between them, why bringing analytics to the board is half the battle, and how to use SLEs without bashing people over the head with metrics.

The Kanban Guide strips Kanban down to its minimal essentials and makes a lot of things optional — including the backlog itself. So where does a funnel fit in? This short piece explains how a funnel works as an optional container in your workflow: a kind of backlog for the backlog, useful when you're working with a roadmap or a now/next/later structure. It's a holding space for ideas that haven't been properly considered yet — submissions that may or may not earn a place in the backlog. Plus a quick reminder that, unlike Scrum, a Kanban backlog isn't necessarily ordered.

The definition of workflow is arguably the most important section in the Kanban Guide — and if you don't get it right, much of what follows simply doesn't work. So what should actually go into it? This piece walks through the essentials: defining the kinds of work items that flow through your system, identifying at least one "STARTED" and one "FINISHED" point, and applying the four key measures — work in progress, throughput, work item age, and cycle time — to each. It also covers the explicit policies that keep a Kanban system honest (replenishment, prioritization, pull, blocked items, exit criteria), the role of service level expectations and rightsizing, and why having more than one definition of workflow on a single board isn't just allowed — it's often exactly what your team needs.

Release planning is built on a promise most teams can't actually keep: that we know what we'll deliver and when. In reality, we're working with so much uncertainty that the most honest answer is "we don't know" — but stakeholders rarely accept that, so we need a better way to share a forecast without pretending it's a commitment. Monte Carlo probabilistic forecasting offers exactly that, provided you avoid burn-up charts, 50/50 dates, and the plumbing problems that quietly wreck your data.

Cycle time tells you how long a work item takes from start to finish — but cycle time percentiles are where things get interesting. Plot your cycle times on a scatter plot, lift a ruler up the page, and you can see where 50%, 70%, 85%, or 95% of your work items land. That's the foundation of a service level expectation (SLE): a probability-based forecast like "85% of items get done in 12 days or less." But which percentile should you actually use? This piece explains why the 50th is no better than a coin flip, why you should be cautious with the 90th and 95th, and why showing two SLEs on your board can keep you from misleading stakeholders. It also covers when it makes sense to have multiple SLEs for different work item types — a habit that's especially useful outside software.

Product owners, product managers, and product leaders aren't the same thing — but the overlap is real enough that teams constantly confuse them. The tension gets sharper when Scrum and product management meet, because Scrum doesn't recognize sub-roles within a team. Here's a practical way to map the responsibilities across all three, and where each one actually adds value.