I’ve seen what happens when a team gives one anyway. One team estimated four weeks for a new feature. The code underneath was old, and building on it kept uncovering problems. The feature shipped four months later, and three months after that, customers were still reporting bugs and the team was still doing rework.

Psychologists have a name for part of this. Kahneman and Tversky called it the planning fallacy in 1979: people underestimate how long their own work will take, even after watching past work run late.

A weather forecast for your backlog

So I built Chance of done, a weather forecast for your backlog. You tell it how many items are left. It replays your team’s past weeks of finished items in random order, 5,000 times, and counts how many of those futures are done by each coming week. There are no estimates and no story points. Replaying past throughput like this is a common practice in lean and agile teams.

You get a strip of weeks, each with its chance of done, and two dates. The 50% date is a coin toss. Plan on the 85% date.

When a stakeholder wants one date, I bring up the weather. In an environment as complex as a weather system, we need forecasts and confidence ratings to navigate. An 85% chance of rain is a strong likelihood, but it isn’t a guarantee.

My teams also make a wisdom-of-the-crowd estimate: everyone guesses in weeks of ideal engineering effort, and we take the median. It’s getting more accurate with time and consistency. What I like most is how efficient it is: no heavy debate, no planning poker over story points. Poker has its uses for surfacing valuable information, but its value diminishes. Sizing individual stories is a whole other ball of wax.

What makes a throughput forecast work is small stories. We aim for one to two days and split them when they get too large. Over months, I’ve seen the pattern again and again: a team’s ability to slice stories and its forecast accuracy improve together. You can take that to the bank.

Storms and mudslides

Your history only holds the weeks you’ve had. So the tool has a storm season control, which drops in rough stretches of one to four weeks with nothing done. Turn it up and both dates move. The 85% date moves further.

On my teams, storms are high-severity CVEs, which seem to be happening more often. A record 48,185 CVEs were published in 2025, up 21% from 2024. Then there are supply chain attacks, like the compromised tj-actions GitHub Action in March 2025, and GitHub Actions crumbling under pressure, which GitHub’s own availability reports document. External customer factors, dependencies, you name it. Some days are better than others.

AI agents are changing the weather too. We ran a test with a few engineers, capturing what they thought each story would take and how long it actually took with our AI harness. There were still more variables than we wanted, but the general consensus was a sense of acceleration. Two-day stories got done in half a day, and one-day stories in a quarter of a day. And then there were places we got stuck. Trending fast overall, but mudslides still happen.

That’s where the look back control earns its place. If your team’s pace just changed, replaying every past week forecasts a team that no longer exists. Shorten the look back until the new pace settles.

Weeds after the rain

The control that surprised me most was items left to do. Slide it past 100 and watch the dates run away. With a backlog that big, nothing will ever get done within reason.

Weeds grow fast after a rainy stretch, and backlogs do too. A backlog that big is a sign to weed. On my teams, stories drop off the count when YAGNI tells us we won’t need them, and new ones get added. “Some day, one day” items left sitting in a backlog become work nobody cares for. And for work already started, work item age is the metric to watch. It tracks how long an item has been in progress, so you see stale work before it piles up.

If you lead the team

If a leader still asks for story points, I’d engage a bit deeper to find the real concern hiding behind predictability. Are throughput and dates more important to them than points? If they’re senior, do they know story points don’t translate well from one team to another, and that seniority skews the numbers? And remember Goodhart’s law: when a measure becomes a target, it ceases to be a good measure.

Forecasting has limits too. That’s a story for another time, but borrowing from Dave Snowden’s Cynefin framework, it starts with one question: which domain are you in?

Try the forecast with your own team’s weekly counts. They stay in your browser. Refresh it every week, trust the near weeks more than the far ones, and say the chance out loud.

I’d like to hear what your forecast says, and what storms look like on your teams.

Nobody wanted it this way. There’s always more to do than there’s capacity for, and the work depends on other work. Engineers want to make product happy. Production issues land in the middle of everything else, and we keep opening emergency lanes for them. Before long, we’re working on everything and finishing very little. Too many spinning plates.

“Stop starting, start finishing” is an old line from the Kanban community. It sounds obvious when you say it out loud, and it’s surprisingly hard to feel when you’re the one spinning the plates. So I built something you can watch.

The race

Stop starting, start finishing puts two teams of three side by side on the same backlog, item for item. One team finishes what it has before it picks up anything new. The other keeps starting, up to a limit you set with a slider.

Let it run for a bit before you touch anything. Then move the slider and race again. Try a few limits and see where the busy team starts to fall behind.

I won’t tell you the score. It changes a little every race, and you’ll get more out of watching it than reading about it. Two things to keep an eye on while it runs:

• The busy team works as hard as the other one. Each person spreads their day across more items, and every switch between them costs a bit of the day.

• The “days each took” boxes matter more than the count of items done. That’s the wait your customers feel.

Why the waiting matters most

The second point is the one I’d sit with. With too much going at once, each item spends more of its life waiting, half-done, while people attend to everything else.

There’s even a law for this. Little’s law ties together how much work is in progress, how fast work gets finished, and how long each item takes. Start more without finishing faster, and everything takes longer. The race shows it in the “days each took” boxes.

For your customers, a feature that’s 80% done is worth the same as one nobody started. And while it sits there, you’re not learning anything from it either.

The model is simple on purpose. No meetings, no blockers, no bugs coming back, no one out sick. Real teams have all of those, and my guess is each one makes the gap bigger.

What AI agents change

The model also leaves out something that’s changing how my team works right now. It’s still evolving, so the race doesn’t capture it yet, but the same principle applies.

I’ve been a big proponent of mob programming, partly because it keeps fewer things in flight. When our mobs grew beyond four people, though, things got confusing and slow. So my team settled on three or four people per mob, which also set our work in progress: one item per mob.

AI agents are another fundamental shift. They make it easy to start more work. Four people watching an agent implement a spec isn’t much of a spectator sport, and one engineer with an AI agent isn’t really a pair either. Experienced humans are still critical, especially when the AI’s output drifts ever so slightly. We’re adding automated checks and automating more of the routine work where we can, but we can’t put AI on autopilot. Not yet.

Our new sweet spot is two or three people, sometimes just two, working with AI agents. So far, it’s working well. Even here, discipline matters, because AI amplifies what’s already there, good engineering practices and bad ones alike. Work in progress still matters too. Avoid spinning plates, even now that they come with booster rockets. Stop starting, start finishing is more possible now than ever before. The discipline still needs nurturing.

If you lead the team

Look back at the list at the top. Most of that pressure comes from outside the team, and leaders are part of it. If your first question in a status meeting is “what is everyone working on?”, people learn that being busy is what you want to see. Try asking “what’s closest to done, and what’s in its way?” instead.

It also helps to be the person who says “not yet” to new work, so the team doesn’t have to. A team can only keep a limit if the people asking for things respect it.

If you’d like to try this with your own team, the race makes a nice opener for a retro. Put it up, let it run, and see what people notice. Then count what your team has in progress right now, reviews and that side project included, and compare it with the number of people. If the first number is bigger, try finishing before starting for a couple of weeks. When someone gets blocked, they help finish something already in flight instead of picking up something new.

I’d like to hear what you see, in the race or on your own team.

Subscribe now

You’ve sat through the retro where everyone agrees the team has a communication problem. Someone proposes a new channel, someone else a weekly sync. A month later the team has both, and the same problem.

The problem lives in the conditions around the people, and those conditions keep producing it until someone changes them. Human Systems Dynamics has a model for those conditions called CDE. I learned it in 2018 and have used it with teams ever since.

Three conditions

The container holds a group together long enough for a pattern to form. A purpose, a boundary, a shared way of working, a deadline, even a meeting agenda can all be containers.

Differences are the distinctions that matter to the people inside: skills, views, experience, the staff engineer and the new hire.

Exchanges move information and work between people: pairing, tickets, demos, code review, the conversation by the coffee machine.

Each condition can be too tight or too loose. Tight means constrained and rigid; loose means open and unbounded. Give a meeting too much time and it drifts into topics nobody cares about; you tighten it by sharpening the purpose or inviting fewer people. Give it too little and it can’t hold the disagreement it needs; you give it more room.

The model also explains why your fixes surprise you: the three conditions pull on each other. Shrink the container and the differences inside it start to matter more, and the exchanges speed up. You can guess the direction of a change, but you can’t predict or control where it lands.

Three shapes you may know

Three conditions, each too tight or too loose, plus a team in balance, make seven shapes. Here are three you may recognize.

Exchanges too tight. A platform team and three product teams talk through tickets and nothing else, and each one guards its own roadmap. Integration bugs show up in production, and every postmortem blames the handoff. Ask someone on the team and you’ll hear “I don’t know who to ask, so I guess.” Zoom out and the organization runs on blame: problems land between teams, and each points at the other. In software it looks like Conway’s Law, with the architecture copying the broken communication.

Exchanges too tight, from the team up to the community around it.

Container too loose. A team takes on whatever the business asks for this quarter: a mobile app, a data pipeline, a partner integration. Nobody can say what the team is for. People start everything and finish little, and the teams around it start fighting over who owns what. We call that a feature factory.

Container too loose: everything gets started, little gets finished.

Differences too tight. A group of long-tenured engineers agree on everything. Their estimates match, code review is a formality, and the one person who questioned the architecture stopped speaking up in retros. Bad news travels up slowly, and the team calls it alignment. The model calls it groupthink.

Differences too tight: agreement comes fast because nobody dissents.

The tool

A few years ago I started mapping these configurations for software teams in Airtable, with the idea that you could zoom out from a team to the organization around it. It’s now a page you can try: What shape is your team in?

A balanced team. Change one answer and watch the shape bend.

You answer three questions: is the container, are the differences, are the exchanges too tight, about right or too loose? A triangle bends into your team’s shape. A ladder shows the same pattern at four levels, from how one person feels at work up to how the community around the team responds. Then you get the agile pattern it looks like, a practice that shifts it, and a next wise action.

The tool lets you move one condition at a time. If more than one feels off, pick the one that feels most off. The conditions are entangled, so when you shift one, the other two move with it.

Using it with your team

Take the three questions to your next retro. Ask each person to answer the three questions on their own, then compare. The disagreements tell you as much as the answers. If half the team says the container is too loose and the other half says too tight, you’ve found a difference that matters.

Then pick one condition and make one small move. Narrow the container by saying no to one request. Open an exchange across a gap with a shared demo. Bring in a difference by inviting a customer to the sprint review. Watch what changes, and choose your next step from there.

Which shape is your team in right now? Reply and tell me. I’d like to hear what you found.

I write about teams, change and complexity at agile-7.com, where you’ll also find stories from teams I’ve worked with.