Introduction
This short paper series, “Deep Dive Models in Agile”, provides valuable information for the Product Owner community to use additional good practices in their projects. In each paper in this series, we take one of the most commonly used visual models in agile and explain how to create one and how to use one to help build, groom, or elaborate your agile backlog.
This week we are covering one of the key OPSD (Objectives, People, Systems, Data) bounding models, the Business Data Diagram. If you missed any of our previous editions, you can find them here. Other editions in this series include: Process Flows, Feature Trees, State Models, Decision Models and Business Objectives Models. You can always send a comment to [email protected] if you would like to request additional models for this series.
What is a Business Data Diagram?
Business Data Diagrams, or BDDs, bound the system from the data perspective. BDDs are also known as entity relationship diagrams or ERDs. BDDs are meant to convey a business view of how the key data objects for a product connect, and should be structured in a way that reflects how users think about the data. The point of this model is not for designing back-end tables; this model should not represent physical relationships in a database, although it might be used to inform a database. The BDD instead allows the PO or BA to focus on what data is missing from the system, based on the relationships between entities and what business rules haven’t otherwise been identified.
The BDD consists of three main items: business data objects (think of the NOUNS you care about in your system- product, account, user, etc.), the relationships between them (a user may have an account), and the cardinality (0 to 1, 0 to many, etc.) of those relationships (a user may have only one account and an account belongs to only one user). This is the top level view of the data in the product or system. Sometimes more detailed data models are needed for the product, such as data flow diagrams or data dictionaries.
When would I use a Business Data Diagram on an agile project?
The Business Data Diagram is a model that is relevant on virtually any software product – because almost all products deal with data. Even the simplest of BDDs, with a only handful of business data objects, can help to elicit business rules that the system must conform to, and help brainstorm data management user stories for your backlog.
Because the BDD is so invaluable in establishing a foundational understanding of the data for your team, the PO or BA will typically draft at least the first iteration of this model early on in the project (say during sprint 0 or a planning phase). The model itself can evolve as more business data objects are identified as in scope for the product. BDDs can also help to identify other models that might be needed early on in the project, like which business data objects have state lifecycles that might require additional workflow and state modeling.
The PO or BA would elicit the known business data objects and relationship rules from business stakeholders and data subject matter experts that are familiar with managing and utilizing the data in operations. IT analysts and data architects should collaborate closely in these activities, as they are likely spinning up their more technical data and architecture models in parallel.
How do I create a Business Data Diagram?
The first step in creating a business data diagram is for the PO or BA to identify the scope of business data objects. Even early on in the project, these can become readily apparent based on the key nouns that get repeated in elicitation sessions and from other requirements models and documentation. For example, if the product is an e-commerce website, the data objects will include things like shopper, cart, product, and store. If, instead, the product is a workflow automation product, the data objects might include reviewers, approvers, and cases.
The initial list of business data objects can be elicited from business stakeholders during a brainstorming session by thinking of the nouns in the system as described above. Then, the PO or BA would work with the stakeholders to refine the list to only those in scope for the given product.
During this exercise, the PO or BA, with the help of the business stakeholders, may find business data objects that are really just attributes of another data object. A key way to identify if an item is an attribute or object is to look at any 1:1 relationships that don’t have relationships outside of the obvious parent object. For those objects, then ask the question “if I update this item in the system for one of the parent objects, does it update for the rest?” As an example, is a customer address its own object or an attribute of customer? If the address is stored separately and can be updated to update against all customers who share that address, it is likely its own data object. If not, it is likely an attribute. This blurs the line a bit between design and the requirements, so it is imperative that the PO or BA work with a technical analyst or database architect to ensure that the information is at least aligned.
One caveat to this line of questioning on attributes: generally attributes are not shown on BDDs and are instead captured in data dictionaries. However, from the business’ point of view, it may be important to show an attribute on a BDD. This typically occurs when the attribute in question is used for the business as a proxy for the parent object (like account number and customer, for example). Deciding whether to add attributes to the BDD will require a discussion between the PO or BA and the business stakeholders.
Once an initial set of business data objects have been identified (at least what’s known to be in scope for now – this can expand the backlog grows), the PO or BA then systematically walks through the pairs of business data objects to determine which of the business data objects are related. This includes thinking carefully about indirect relationships – asking questions like: “COULD this relationship be any different, if not related through the parent?” One common example of this is child/parent/grandparent relationships. A child does not have a direct relationship to grandparents because the only way to have grandparents is through parents. Thus, this is an indirect relationship and child and grandparents would not be directly related in a BDD. However, this might spur some interesting conversation – what about cases of adoption? Does the relationship have to consist of a blood relationship?
Just getting the correct relationship lines formed may require iteration, and this gets increasingly complex with the number of objects in the system, as the PO or BA has to think about the possible relationships between each pair of business data objects. One helpful technique is to first put all of the business data objects in a circle and systematically go through each business data object in the circle and draw lines to the other business data objects that connect (or, do this in a table similar to a state table to identify all of the possible relationships).
Once the relationship lines are formed, the PO or BA determines the cardinality of the relationships. Cardinality is the number or nature of the relationship between two business data objects. For example: a mother may have 1 or more children, but a child can only have 1 biological mother. The idea of cardinality may seem unimportant, but this is one the key places that the PO or BA can find business rules in a BDD, so it is important to walk through each set of related business data objects and ask how many can be related in each direction. The BDD consists of four main cardinalities, although by using numbers to show cardinality instead of the crow’s feet notation, any number of relationship cardinalities can exist. These cardinalities are:
- (0,1) - An object has either none or a single one of another object. An example of this might be that a site visitor to a website could have no account or could have a single account with the website, but the website prevents creating multiple accounts.
- (0..n) - An object can have none, one or any number of another object. For an e-commerce website, this might be that a product for sale could be associated with no orders (no one has bought it yet) or any number of orders.
- (1) - An object and belong or relate to one and only one of another object. This is a relationship that is suspect to be an attribute instead of an object if it really can only relate to one of another object. An example of this might be a customer address. If an address belongs to one and only one account (by the test of, if updated for one, does it get updated for others), then this might be an attribute.
- (1..n) - An object relates to at least one of another object but can belong to any higher number of that object. For example, an order for an e-commerce site must have at least one product in it to be processed, but can have any number of products in it.
If there are specific business rules in the system that set maximums on the 0..n or 1..n relationships, these can be included in the bounds for context. For example, the PO for SeiSounds might want to specify that each account can only be associated with a maximum of five users or listeners to avoid friends buying one paid subscription and sharing with everyone else. See the example below:
How do I derive user stories out of a Business Data Diagram?
Data can only ever be Created, Used, Edited, Deleted, Moved, or Copied. This gives the PO or BA a helpful checklist to review against every data object against to verify that there is a complete set of Process Flows, which helps to identify epics or user stories. For each business data object, the PO or BA should ask how a user in the system would create, use, edit, delete, move or copy that data object or if that action is not allowed or allowed only by certain user types. These all lead to either Process Flows for how a user would complete that action or user stories to build functionality for that action on the business data object in the system.
However, the PO or BA should also look to identify the unique combinations between business data objects. For example, if the business data objects for the product are shopper, accounts and carts, one combination to think about for these three objects is to take two instances of shopper, one cart, and the use action to form a user story for the ability to share the contents of one cart with a friend’s shopper account. This is a daunting task and the PO or BA will not identify all the possible combinations on the first pass, but he should take a look through the drafted BDD and pick selections of 2-3 objects that are related in some way to brainstorm additional user stories.
Typically, this first pass exercise is completed during the sprint 0 or planning phase to populate the backlog with features and user stories.
As sprints progress, the PO or BA will use the relationships defined in the BDD to understand acceptance criteria around business rules for two objects. For example, if in an upcoming sprint, the team is coding payment information for an order in an e-commerce system, and the BDD has that an order can have 1..3 payment types, then some acceptance criteria for that story might be: Each order has at least one payment type; each order can have up to 3 payment types; and if an order has more than 3, the system should generate an error.
A few examples from SeiSounds might look like this:
Remember that this model is great for identifying business rules, but business rules are ideally stored separately from the backlog or requirements. These are things that will exist with or without a software solution for them, and they inevitably change as the business changes. Avoid specifying these business rules only in the acceptance criteria of a user story, and instead maintain separate tables of these (that the user stories reference) that can be easily updated down the road.
Conclusion
Business Data Diagrams are one of those MUST HAVE models for any product that is dealing with data. The exercise of creating the model itself creates a powerful, shared understanding of the underlying data constructs as users understand it. Instrumental in helping to identify additional, more detailed models that might be needed, the BDD can also help you get to a complete set of user stories around users interacting with the data following the create, use, edit, delete, move and copy actions.
Authors: Megan Jackson Stowe and Candase Hokanson, Seilevel
Megan Jackson Stowe, Senior Product Manager, Seilevel
Megan is a Senior Product Manager at Seilevel. As a Seilevel Certified Instructor and practitioner, she helps ensure clients’ teams are building the right thing (delivering the full business value intended), while also building it fast. With a heavy focus on the agile methodology, Megan spends much of her time acting as a product owner while training and coaching other product owners on business analysis best practices within an agile framework. She also contributes to the Seilevel methodology regularly through SeiLabs, the company’s Research & Development team. Some of Megan’s training & project experience includes:
- Developed and executed a full product owner course customized exclusively for a Fortune 100 company.
- Trained, mentored, and coached business analysts, product owners, and product managers to define requirements, adopt best practices around requirements management tools, and manage scope
- Developed requirements for a variety of systems, serving in the business analyst or product owner role, such as: financial advisory regulatory and compliance surveillance systems, university review and promotion workflow tool, learning content management system, global consolidated sales tool, bank management accounting and profitability application, and others
- Refined requirements document templates and best practices around completing those documents for organizations
Candase Hokanson, Senior Product Manager at Seilevel
Candase is a Senior Product Manager at Seilevel and a PMI-Agile Certified Practitioner who trains and coaches product owners, scrum masters and business analysts on agile approaches as well as championing products in those roles for clients. She works with teams to unite every team member around the common end goal of delivered business value to save up to millions of dollars in development costs for features that won’t be used or that don’t contribute to the anticipated business value. She also works with clients to help scale their agile practices beyond one team or one pilot to the entire organization.