fbpx

Visual Models in Agile – Business Objectives Model

Share This Post

Share on facebook
Share on linkedin
Share on twitter
Share on email

A Business Objectives Model (BOM) is an RML®️ model that iterates through business problems and business goals/objectives of a project to arrive at the software product concept. The BOM for a product aligns the team on why they are building the product and what benefit the product will provide. If you’ve made BOMs already or are attempting one for the first time, this article can help you make it better! The BOM is challenging to elicit and create, so you’ve come to the right place.

When Should I Make the BOM?

The BOM is made at the very beginning of a project, either sprint 0 or the planning phase with input from a light-weight business case, project charter, cost-benefit analysis or interviews with stakeholders. Unfortunately, it’s often the case that the Product Manager/Business Analyst is given a solution to build and must work backwards in order to understand and articulate the problem. Don’t be afraid to point out if the solution you’ve been given doesn’t align with business problems or objectives.

Agile projects acknowledge that change is constant, so you may need to revisit the BOM throughout the project. Be prepared to remind stakeholders what the problems and objectives are and to update the BOM as needed throughout the life of the project.  

How Do I Start?

You may be starting with known problems, objectives, or a product concept. If you’re lucky, you have a project charter or some other project initiating documentation to work from. If you can, begin by making a draft model. This makes starting the conversation with your stakeholders easier. Your draft may look something like this:

Agile BOM - How to start diagram

Once you have a draft, you can start interviewing stakeholders. Try using the questions and gut checks below to help build the BOM. You can start with any piece of the BOM that you already have and elicit the rest of the model. 

Product Concept to Business Problem Mapping Diagram

To Get from Product Concept to Business Problems

  • What happens if we don’t have the product?
  • What happens if we don’t have a particular high-level feature?
  • Why is not having the product or a feature a problem?
  • Business problems should not be the lack of a solution. When interviewing, push back on those types of problems until you understand why the lack of a product or feature is an issue. Keep in mind that your users have a job to do even if you take their laptops away. The lack of a solution should somehow tie into money (such as a process taking too long and therefore being costly).
Problem to Business Objective Diagram

To Get From Top Level Problems to Objectives

  • What would it look like if this problem were solved?
  • When do we need to have the problem solved?
  • Objectives should be verifiable at the end of the project.
  • Use the SMART (Specific, Measurable, Attainable, Relevant and Time bound) acronym to ensure that you’ve captured good business objectives.
  • Sometimes business objectives can be too large to easily measure throughout the project to know if you’re on the right track. Use success metrics to get earlier feedback.
  • When defining business objectives, avoid unbound percentages. Always have a starting value and target value to truly know if you have achieved your objective.
Top Level Problems to Business obejctives

To Get From Objectives to Lower Level Problems

  • What is preventing us from achieving this objective today?
  • What is blocking us from achieving this goal?
BOM: Objectives to Lower Level Problems

To Get From Objectives to Product Concept

  • What can I build or do that would achieve this objective?
  • The lowest-level objectives should tie directly to a feature that achieves them.
  • Each High-Level Feature should tie to a single business objective for traceability. If a feature supports multiple objectives, select the highest impact one. It’s ok if objectives tie to multiple

I Built It. Now What?

After the BOM is completed (for now), BOMs can be used to:

  • Identify the MVP. Which business objectives are the most important to enable?
  • Prioritize features. Which features support the most important business objectives?
  • Derive epics or high-level features for the backlog.
  • Reduce or eliminate scope creep. For each new feature request, ask your stakeholder how the feature ties back to business objectives.
  • Value user stories. Because business objectives at the highest level relate to money, user stories inherit value by tracing it to the feature and through to the highest-level objective. Assigning values to your stories allows you to easily stack rank the backlog.

Want to explore BOM creation further? Check out “Why are BOMs so hard?” by Geraldine Mongold. 

If you’d like to explore coaching or training in using Visual Models on your projects, we’d love to help! We’ve worked with hundreds of organizations who wanted to improve their project processes and communications. Let’s talk.

More To Explore

Three BA Mistakes to Avoid

We’ve all heard the quote, “What we have here is a failure to communicate.” Failure to communicate is the bane of the Business Analyst (BA). The BA has the responsibility

Marketing Automation or CRM – Which do I need?

Here at Blue Fish, we design and implement commerce-based solutions across a variety of industries and company sizes. In nearly all those solutions, our clients also have varying needs to