Blog

Most conversations about value stop at the organization — revenue protected, costs reduced, market share grown. But societal value is a legitimate dimension too, and the UN's 17 Sustainable Development Goals offer a practical way to bring it into how you order your backlog. The catch: only the authentic version counts, because greenwashing wastes the energy you could have spent delivering something genuinely better.

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.

When there's more unknown than known, committing to a Gantt chart that has everything wrapped up by Christmas isn't planning — it's theatre. But "we don't know when we'll be done" rarely lands well with stakeholders, and if you leave a vacuum, they'll fill it with a date they invented themselves. Monte Carlo probabilistic forecasting offers a middle path: still honest about uncertainty, but structured enough to give stakeholders something they can actually work with.

A long queue for pizza at a rainy English festival turned into an unexpected lesson in flow. The team at the stall was deliberately slow at taking orders, perfectly coordinated through each step, and careful never to take on more work than their slowest stage could handle. That's a lesson most knowledge work teams haven't quite learned yet — and it's why so many of them feel constantly overloaded.

How do you measure value on a major IT infrastructure project? Start by admitting that "value" itself is a loaded word — organizational, market, societal, risk-reduction, and learning value are all different things, and most teams conflate them. And then accept the harder truth: until something is actually released and in someone's hands, there's nothing real to measure, and proxy metrics like story points will quietly take over to fill the vacuum.

When a Definition of Done stretches to 30 items, most people stop reading it, stop respecting it, and stop improving it. The usual instinct is to make it shorter by cutting items — but the real problem usually isn't the list at all. It's trust, and until you address that, adding or removing items won't change much.

The buck stops with the product owner when it comes to stakeholders — customers, end-users, compliance, suppliers, and the wider organization all fall under that remit. But that doesn't mean the product owner should be doing it alone. Developers should be connecting directly with customers, the scrum master should be negotiating with other teams and shaping how compliance gets demonstrated, and the whole team should be having honest conversations about who owns what.

Developers finish their code early in the sprint, hand it off to testers, and start looking around for the next thing to do. If that sounds familiar, the question isn't really what developers should do with their spare time — it's why work is being handed off at all. Here's what collaboration looks like when a team is actually working toward Done together.