During my career, I have been involved in a number of different projects. At the same time, I have noticed how the definition of requirements has changed over time. Up to 2010, the requirements were defined in the so called traditional way system. Based on the classic model, where all requirements were defined before writing a single line of code, let alone testing. In itself, of course, it seems logical that it should be defined and then implemented according to the specifications. In practice, very often the definitions tend to change and live as the project progresses, and the above method therefore does not work in practice.

About ten years ago, agile methods like Scrum started to be used on IT projects. It was promised to be a golden bullet to better meet the customer's wish and better quality software. The idea of defining only the things for the next sprint at a time, after which you look at the direction and, if necessary, correct the course, sounds ideal. The process also involved the product manager (PO) acting as a link between business and developers, enabling developers to better focus on developing the software itself.

My own experiences at Scrum are two-way. I have been involved in projects that have been successful and, on the other hand, I have been involved in projects, which leaves not much to tell posterity. In my opinion, in successful projects, Scrum has not necessarily been a sign or prerequisite for success, but that the team has not been isolated from the business. In fact, the fact that Scrum has been slavously followed and the PO has isolated the team has rather caused the project to fail more likely than succeed. This is because when all information flows through the PO, the implementers do not have the best information at their disposal.

How, then, can the requirements be better defined, and even so that the implementers and the people in charge of business speak the same language and even understand each other. Personally, I have found it good to hold an Event Storming workshop at the beginning of the project and every now and then during the project. The method is really functional because it focuses on the functions that take place in the system from a business point of view. In addition, the method is very effective in the fact that the silent/hidden information becomes visible. A particularly good method is that it ensures developers and those responsible for the business talk the same language and at the same level. In addition, the method improves communication between people. Personally, I have also used the method to familiarise new developers, and I can say that it is a really effective. I dare promise that when using Event Storming, there will be better conditions for the success of the project and for the champagne to be clinked as a sign of success.

Thanks for reading the text all the way out here. Next time I'll tell you how the Event Storming workshop works. If you were interested, comment below or send a message to me, I'd be happy to tell you more.