Extreme Discovery — Event Mapping for Behaviour Driven-Development

Event Mapping can help teams to quickly develop a shared understanding of new software features, which can save time and reduce the risk of misunderstandings or miscommunications; but it also makes Behaviour & Test Driven Development more accessible to all — leading to more robust software development practices. Test-first development is considered an “important ingredient of success” according to Team Topologies.

The Problem

More often than not, the business requirements are mistranslated into awkward and buggy software throughout the long lifecycle of the required feature. This timespan is also known as Lead Time — from inception to production.

If the only way for a product owner to fully confirm the product does what he intended it to do, is to see it running in production — this creates a very long feedback cycle, sometimes months. If the engineers get it wrong or misunderstand the requirements- the cost can be huge.

If you have your software tested manually by QAs — that’s one step better, and you’re sure to catch a lot of mistakes this way. If the QA has (after many tears and emotional breakdowns) managed to automate the whole system — you’ve earned a few more quality points — but you’re still lacking a mechanism that keeps you on the straight and narrow, a direct link from the business requirements to the end product.

If you’ve heard of Behaviour Driven Development, you’ll probably know that this is exactly the problem it tries to address. BDD also grew directly out of Test Driven Development (TDD) — so it’s also about testing, but I’d like you to put testing out of your mind for a moment and focus on the problem outlined above.

How do the “business” (or their representative) convey to the “tech” what this new complex feature is? In other words — how to go about translating a bunch of vague and ephemeral business rules into specs for a software system, or provide precise instructions to the developers?

As a starting point, two well-known approaches suggest these workshops: Example Mapping, conceived with BDD in mind — and Event Storming — usually associated with Domain Driven Design (DDD). Both workshops are highly collaborative and involve people with different perspectives of the system.

What is Example Mapping?

Example Mapping proposes a workshop in which the Product Owner, Testers, and Developers all take part, fleshing out business rules and acceptance criteria by making a visual map of the “feature” — starting with different business rules that apply to it and gradually adding literal and concrete examples of those rules. These examples can then form executable scenarios (it’s common to write these in Gherkin format).

Matt’s original blog explaining the practice is available here

https://cucumber.io/blog/bdd/example-mapping-introduction/

What is Event Storming?

Event Storming is a highly collaborative technique for sketching out the timeline of a system (for either existing or future requirements) in terms of system-commands and system-events (which makes this technique very well suited to event-driven systems). Event Storming, a term coined by Alberto Brandolini, requires participants to write down system events that are of interest to the business on post-it notes and place them on a long sheet of paper that represents a timeline. This activity eventually delineates the system in terms of significant events that happen throughout its’ lifetime (e.g. “Order Was Dispatched”) and the commands which cause them (e.g. “Place Order for Items”).

The output of a small Event Storming session (they can produce timelines that are literally meters across), for our library lending system might look like this:

From the Event Storm we get the basic picture of important events in the lifetime of the system, and when they happen relative to each other (the time-axis goes from left to right)

Event Storming + Example Mapping = Event Mapping

Event Mapping borrows ideas from both of these practices, and the conceptual framework it suggests involves literally mapping the “events” and “commands” from the Event Storm onto Gherkin (BDD) scenarios.

Event Mapping starts with a timeline. When modeling dynamic systems (or, as Alberto Brandolini has shown, with Event Storming) — starting with a timeline of the system in question is essential — this allows us to understand clearly what happens when; as well as making these things highly visible to everyone in the room.

As with Event Storming, we start by putting stickies representing events (things that happen within the lifetime of the system, that are significant to the business) and commands (how the end-user interacts with the system) — we end up with a long timeline of events and interactions that allow us to discuss and understand the system.

As with Example Mapping, the objective of Event Mapping is to create a stronger link between the business requirements and the software process by writing executable scenarios that reflect those requirements. As opposed to Example Mapping, its’ focus is temporal rather than story-based. Event Mapping helps with what part of the system should we start building. As with Event Storming, it often ends up presenting a clear view of what the main features are.

An Event Storming session takes place on a horizontal timeline, but for the purpose of Event Mapping, I’ve turned the timeline 90° clockwise so that the timeline is vertical and it is easier to visually map the events/commands to steps. Using an online Miro board, it looks like this:

Once you get a clear timeline of events out of the Event Storm, you can start mapping the to the Givens/ Thens and the to the Whens. I wrote a blog post going into more technical detail about this, but it should be clear how the events (orange) and commands (blue), map to the G/W/T steps. Many more scenarios can be written with the aid of this timeline.

It can be seen here that this practice can also help to identify stories visually. These stories can then be mapped to executable scenarios.

The result can serve as a repository of executable specifications. Each Given/When/Then scenario can now be automated — and used to drive or guide the development of the software. Eventually, the scenarios will form the basis of the application’s regression test suite and function as living documentation.

Conclusion

Event Mapping is a simple but effective activity that can help you quickly get to the heart of the logic of your system, and help you map out candidate scenarios for automation. It can be used as a business analysis tool or as a full-blown BDD framework for writing the executable specifications, in a format that maps directly to Given/When/Then scenarios.

Event Mapping can also help your teams apply the practice of Test-Driven Development to your whole system. TDD is a core component of a modern software team’s Continuous Integration and Deployment strategy, both of which are pre-requisites for a successful Team Topologies implementation:

Team Topologies alone will not produce an effective software-delivery and operations organization. Beyond the structures and dynamics suggested in this book, important additional ingredients of success include:

- Good engineering practices: test-first design and development are all aspects of the systems, a focus on continuous delivery and operability practices […] designing for testability, and so on- (Team Topologies p. 37)

Armakuni can assist you with all these critical aspects of building a successful software development pipeline. We run workshops on Test-Driven Development, Continuous Integration and Team Topologies.