Suzanne Robertson James Robertson

Integrating Business Events into your Agile Framework

How you can use the natural partitioning of business events to flexibly synchronise your agile development.

Business Event partitioning has been around for a long time and has helped Business Analysts to improve their requirements discovery and to develop better skills for identifying the real business problem. The new ideas we have been applying in the last few years are related to how Business Analysts, Product Owners, Developers and Testers can use Business Events to integrate business requirements with agile development. In other words, to take advantage of being able to use Business Events to better communicate with each other, to break a problem into business related pieces and to do early prioritisation and iterative discovery and delivery.

Whatever it is you are working on, it is almost certainly made up of many, sometimes very many, pieces. Each of the pieces interacts with other pieces to achieve some valuable result. This means that there is a need to organise all the pieces so that you and your colleagues can work on relevant slices of the larger problem, and at the same time keep track of how the smaller pieces work together within each slice. The Business Event is the best tool we have been able to find to help you do this.

What is a Business Event?

A business event is something that happens, and when it happens it causes a pre-planned response by part of the business, or as we shall call it here, “the work”. The work can be carried out by any combination of human procedures and/or automated technology.

One category of business events are the things that happen inside an adjacent system. An adjacent system might be a person, department, piece of technology or anything else that is the source of a business event. When the business event happens, the appropriate piece of the work is made aware because each happening produces a flow of data from the adjacent system to the work. A business event is a significant happening – it is not just a mouse click. It is often a request for a service that your business provides, and the outcome is the provision of the service or product.

For example, Figure 1 illustrates the business event Customer makes an order. The adjacent system, in this case the Customer, is where the event happens. The data flow (caused by the event) is the Customer Order. This flow is usually called the “triggering data flow” because it triggers a response by the work. In this case, if you look inside the work, the response would be something like - fill the customer’s order, create the invoice, record the order and invoice and send the goods and the invoice to the customer. All this would be done according to the work’s business rules. Note that these business rules might be carried out by people, technology or a combination of the two. The business event response helps focus on all the work that the business needs to carry out to respond to the business event. This approach uncovers all the business rules – not just the rules that are implemented with software.

Keeping Track of the Business Events

Whenever a new business event is confirmed to be relevant to the scope of the work, the business analyst keeps track by adding the event to the work context diagram. Figure 1 showed a work context diagram that only includes one Business Event: Customer makes an order. In Figure 2 there is an additional business event, Customer decides to make a payment. You can see the additional flows for this event on the diagram.

Every time you discover a new business event, and it is agreed to be within the scope of the work that you are studying, you add it to the work context diagram. We are using data flow notation as a convenient way of identifying the scope of the work. Each business event represents a bounded chunk of functionality that you can study independently of the other events while keeping track of how the individual events fit into the whole. As the number of business events increases an event list (illustrated in Figure 3) helps you to manage and prioritise your investigation. Naturally enough, your list of events would be considerably longer.

Event Number	Event Name	Input	Output(s)
1	Customer makes an order	Customer Order	Delivered Goods + Invoice
2	Customer decides to make a payment	Customer Payment	Receipt for Payment

A business event triggers a significant and independent chunk of functionality that can be prioritised so that you are always working on the events that yield the greatest value. Business events also help to organise your investigation. You can apportion the events among your team, and due to the independence of the events, there is not a lot of need for team members to have excessive interaction.

Working with an agile development team

Business events are highly effective for agile teams. The response to a business event, is a stand-alone chunk of the work with a well-defined outcome. It also has well-defined input and outputs. This makes it not only a convenient unit to study and find its requirements, but also a sensible unit to develop.

Figure 4 illustrates this approach. The scope of the work is determined by the collection of business events - our previous example looked at two business events. For each of your business events, we advocate writing a business event story. This is a story in the conventional sense of role-function-outcome. More on this later.

For each business event story the business analyst, product owner and developers, can define the details of the response to the business event by writing a number of functional stories. These represent a breakdown of the functionality. They can be further broken down by the developers by writing the detailed tasks necessary to implement the functional story.

Figure 5 illustrates the thinking behind a traceable technique for deriving the Business Event Story for a Business Event. Focus on a Business Event from your work context diagram – we have used Event 2; Customer decides to make a payment – and annotated it to show how to derive the Business Event Story.

The resulting Business Story is:

• As a Customer
• I can make a Payment
• So that my Supplier can record my Payment and give me a Receipt

Continuing with this approach, the business analysts, product owner and developers can work together to derive the Functional Stories from the Business Story. They would ask the question: what are the functions that the product we plan to build will need to carry out to support this Business Story? In this example the Functional Stories derived from this Business Story would be something like Locate Customer Account, Record Payment, Issue Receipt.

The developers can now derive all the detailed tasks necessary to implement each Functional Story. If there are changes or questions to either the Business Story or the Functional Stories, business analysts, product owners and developers have a common communication language.

Other sources of information about subjects discussed in the article:

Business Analysis Agility: Delivering Value Not Just Software amzn.to/2CnVhTN Video youtu.be/l_9u5UI12uo

Reviews on many books by authors who continue to enrich the field of requirements and business analysis at volere.org/resources/books

Or on the Volere Requirements LinkedIn group linkedin.com/e/vgh/2491512

Suzanne Robertson and James Robertson are principals and founders of The Atlantic Systems Guild systemsguild.com and joint originators of the Volere requirements process, template, checklists and techniques volere.org

You can contact the authors at
suzanne@systemsguild.net
james@systemsguild.net