Blog

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.

Technically, one person can hold both the Scrum Master and Product Owner accountabilities. The Scrum Guide doesn't forbid it. But each role is genuinely a full-time job, the two pull in different directions, and when you combine them you tend to get a concentration of power that quietly kills healthy conflict inside the team.

What is a product, really? If you're a Scrum product owner who's supposed to be on the hook for maximizing value, you'd better be clear on what you actually own. This piece tackles a confusion that runs deep in product development: the conflation of product, platform, project, and service. Drawing on Bas Vodde's idea that "a product does not have scope" and Craig Larman's framing that a product is something an external customer recognizes and pays for, it offers definitions from the Kanplexity guide for product, platform, and service — and explains why the distinction matters. Why is your CRM not a product? When does a platform become a product? And why does it all come back to one core question: are you worrying about the short term or the long term?

Throughput sounds simple — the number of items delivered to the finish point of your workflow in a given time period — but there's more nuance to it than meets the eye. This piece breaks down what throughput actually measures, why it's tied to valuable work items (not sub-tasks or noise), and how to avoid the apples-and-oranges trap that pollutes so many teams' numbers. It also covers how to handle multiple finish points, why work item types matter more in non-software contexts, and the bigger question lurking behind every throughput conversation: are you delivering real value, or just turning Kanban into another velocity game? Because the goal isn't just shipping more outputs — it's delivering fewer outputs that produce more outcomes.

What separates a scrum master from an agile leader? And while we're at it — what's the difference between a scrum master and an agile coach? (Answer: about $200 a day.) Beyond the punchline, there's a meaningful conversation to be had about the overlapping roles that shape agile organizations. This piece breaks down what scrum masters actually do, what leaders add to the mix, and why the best leaders often make excellent scrum masters — provided they leave their controlling-manager instincts at the door. From walking the gemba to cultivating environments where agility can grow, here's a practical look at where these roles meet, where they diverge, and why the overlap matters more than the distinction.

Scrum Masters and agile leaders do a lot of the same work: observing, coaching, removing impediments, and cultivating the environment where agility can actually grow. The main differences are about reach — leaders walk the Gemba of value creation and consumption, connect funding to learning, and use their power to clear the obstacles Scrum Masters can't. Done right, the line between the two starts to blur — and that's a good thing.

What exactly is cycle time in Kanban — and why does it matter? In the context of knowledge work, cycle time measures how long a work item takes to travel from a starting point to a finishing point in your workflow. But there's more nuance than meets the eye: should you measure work days or elapsed time? How do you handle holidays, weekends, and that one teammate on vacation? And why does an item started and finished on the same day have a cycle time of one, not zero? This piece walks through the practical definition, explains why elapsed calendar time keeps standards from eroding, and shows how cycle time scatter plots can help you build a service level expectation — turning historical data into a practical tool for rightsizing future work.

You might assume the product owner writes acceptance criteria. They shouldn't — and when they do, a predictable dysfunction creeps in. Here's why the people doing the work should own what "done" looks like, and what the product owner should be doing instead.