See, if you had the job of automating some business process a few decades ago, you would walk around the office and watch people doing their jobs. You would learn employee A would call some customer, fill an order on paper, then leave it at the desk of another employee from another department. The this other employee would type some other paper, staple it together and dispatch to yet another department, and so on so forth…
If you think in terms of “employees” exchanging “documents”, this naturally leads to capturing the process with a model of a timeline of events. The words Create/Update/Delete simply don’t exist in business vocabulary; nothing in business is “mutate-in-place”; naturally, modeling a process around these notions is a conceptual mistake - it just happens that for a long time now technologists have enforced their tools models (relational databases, OO/ORM, CRUD APIs) onto business process instead of the other way around.
How does it help with scrum, points, project estimation and so on? Well, I guess instead of the usual throwing your hands in the air saying “Nobody knows the requirements! Let’s ship some CRUD based on a mockup and iterate!”, the Event modeling approach at least tries to gather actual requirements earlier in a format stakeholders can understand/contribute.
"Agile"/Scrum/SAFe is everything that is wrong with our industry.
Don't let me start with storypoints, or SW time estimations in general. Shape Up method use "appetite" instead - a fixed length variable scope time budgets with circuit breakers.
Most modern SDLCs are mini-waterfalls with SDUF (Some Design Up Front).
Example: informal mini-waterfall at FAANG, Shape Up method, Event Modeling, EventStorming.
The uniquence of the EventModeling is that it uses a single paradigm - visual canvas/board, for almost everything: requirements gathering, UI/UX, Software Design, documentation, and Project Management.
For the initial discovery/ideation I would use Big Picture EventStorming as it's a much simpler notation understandble to non-technical people (if you know what is a sticky note - you can participate;)
IMO EventModeling is more comparable to Software Design EventStorming but with Project Management, full documentation, SDLC, etc.
The author makes some pretty large claims (it's the end of: scrum, storypoint-estimations , project management and whatnot) and it does sound promising, but I can't help but be sceptical.