In my last posts, I wrote about modelling one business activity at a time and about replacing gatekeepers with clarity.

Now I want to address the part that usually triggers the most disbelief.

What happens after the EventModel is signed off?

In most organizations, this is where the “real” work supposedly begins. Stories are written. Backlogs are groomed. Estimates are debated. Dependencies are discovered. Meetings multiply. Coordination becomes a job in itself.

But if the modelling was done properly, delivery should not feel like a second discovery phase.

The decisive condition is simple, but demanding: do not stop until the EventModel is information complete.

Information complete means that the events are explicit, state transitions are clear, business rules are written down, edge cases are covered, actors are visible, and every slice belongs to one of a small number of defined building block types. State change. State view. Automation. Translation.

Nothing bespoke. Nothing mysterious.

Each slice has a known shape and a predictable level of complexity.

If you stop modelling too early, execution turns into interpretation. And interpretation inevitably leads to rework, coordination overhead, and surprises. But if the model is truly complete, execution becomes mechanical. Not trivial, but mechanical.

Each slice is autonomous. Boundaries are already clarified. There is no accidental coupling because interactions were made explicit. There are no hidden assumptions waiting to surface mid-sprint. The slices are the work.

This is the point where many familiar rituals start to look different.

Backlog grooming becomes redundant because the work items already exist. They are the slices. They are already small enough, already structured, already understood.

Status meetings become unnecessary because the EventModel itself is the dashboard. White slices are ready. Grey slices are in progress. Green slices are done. Red slices are blocked. With one glance, anyone can see where the hotspots are. There is nothing to narrate. Nothing to reframe. Transparency is built into the artifact.

What often surprises people is the estimation part.

In many companies practicing Scrum, work packages are not of similar complexity. Every story is treated as unique. Every ticket seems special. And so teams sit in estimation meetings, playing planning poker, debating whether something is a five or an eight. Developers tolerate it. Few enjoy it.

The underlying assumption is that each piece of work is fundamentally different and must be judged individually.

But that assumption is rarely questioned.

When modelling is shallow, stories are indeed unpredictable. They hide complexity. They mix concerns. They blur boundaries. So of course estimation becomes a negotiation.

However, when modelling is done properly and every slice conforms to one of a few well-defined building blocks, the variability drops dramatically. The slices are not identical, but they are structurally similar. Their complexity is bounded. What changes is not the type of problem, but the number and combination of slices.

This is the part many resist.

There is always someone who says, “That works for simple cases, but our domain is different.” Or, “In my special case, this does not apply. It’s much more complex.”

It sounds reasonable. It usually is not.

Nature offers a useful analogy. The most complex structures we know are built from a limited set of recurring atoms and molecules. Complexity does not require infinite building blocks. It requires combinations of a few consistent ones.

Software systems are not exempt from this logic.

If every story in your backlog feels bespoke, it is often a sign that modelling stopped too early. Not that the domain is uniquely complex.

When the EventModel is complete and signed off, delivery becomes steady rather than dramatic. No additional coordination layer is required. No “translation meetings” between roles are needed. No parallel shadow planning happens in spreadsheets. The work is ready to be self-served by the team.

That does not mean discipline disappears. Quite the opposite. It means the discipline moved upstream into modelling.

If modelling is thinking, then delivery becomes execution.

And when execution starts to feel almost boring in its predictability, that is not a failure of ambition. It is a sign that the thinking was done properly.

I often wonder how many organizations would recognize their own process if backlog grooming, poker games, and status theatre simply vanished because the work was already clear.

Originally published on LinkedIn (2026-02-24): https://www.linkedin.com/pulse/from-eventmodel-execution-why-delivery-should-feel-boring-schenker-x0vqe