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.
What is a Business Objectives Model?
A Business Objectives Model is an RML Objectives model that iterates through the business problems and business objectives of a project until arriving at the product concept (the solution the project will build). The Business Objectives Model for a product or project aligns the team on exactly why they are undertaking the project/product and what business benefit will be realized from it.
Each Business Objectives Model has four main components:
Business Problem- any issue that is preventing the business from achieving its goals
Business Objective- a quantifiable way that the business will know when the business problem has been solved.
Product Concept- the solution the team has decided to build or do on order to meet the business objectives and solve the business problems.
High- Level Features- so that the team understands the rough scope of the product concept (the product concept is described by a list of high-level features). These features become the L1 features in the Feature Tree.
At the highest level, business problems and objectives relate to money- either the business isn’t making enough of it or they are spending too much of it, but these iterate until there are lower level problems and objectives that lend themselves to features that would satisfy them. So a full Business Objectives Model might look something like this:
When would I use a Business Objectives Model on an agile project?
Like the Feature Tree, the Business Objectives Model is applicable to virtually any project, agile or not because it aligns the team on the rationale for the project or product and helps the PO or BA keep the requests and priorities in line with the original project/product vision.
The Business Objectives Model is made during the sprint 0 or planning phase of an agile project by the PO or BA with input from any of a light-weight business case, project charter, cost-benefit analysis or through interviews with key business and IT stakeholders.
Most of the time, the PO or BA is given a solution product or project to build and must work backwards (right-to-left in the diagram) to understand the rationale of the project. Occasionally, the PO or BA is brought in early in the discussions of a problem and can work left to right, understanding the problems and objectives before determining a solution.
On an agile project, you will occasionally find additional problems to solve for in the solution and will need to update the Business Objectives Model, but this should not be something that happens every sprint. Generally, after each release, the PO or BA will revisit the Business Objectives Model to add any new problems, objectives and features that have been identified or remove any that are no longer needed.
How do I create a Business Objectives Model?
Unlike Feature Trees and Process Flows, the Business Objectives Model is one of the most difficult RML models to elicit and create. Generally, the PO or BA gathers any existing rationale documentation (business case, cost-benefit analysis or project charter) to start a draft Business Objectives Model.
From there, the PO or BA will have to interview key business and IT stakeholders to fill in the blanks of the Business Objectives Model. Typically, the PO or BA will start from the Product Concept and work backwards, but he can use the questions below to start with any piece of information from the model to elicit the rest of the model.
From the Product Concept to find Business Problem: Why is that a problem? What is the impact of not having X solution/feature/user story?
From Business Problems to Business Objectives: What would it look like if this problem were solved? When are we looking to have the problem solved by?
From Business Objectives to lower-level Business Problems: What is preventing us from achieving this objective today?
From Business Objectives to the Product Concept: What can I build or do that would achieve this objective?
Some key things about the Business Objectives Model:
- Use the SMART (Specific, Measurable, Attainable, Relevant and Time bound) acronym to ensure that you have captured good business objectives and can be verified at the end of the project.
- Business problems should not be the lack of a solution (like lack of an automated process). When eliciting, push on those types of “problems” until you get to the root of why the lack of a feature or solution is an issue (like reduced productivity, cost of errors, etc.)
- Sometimes business objectives can be too large to easily measure throughout the project to know if you are on the right track. In that case, you can use success metrics (proxies for objectives, sometimes assumptions, that let you know you are at least heading in the right direction) to get earlier feedback.
- The lowest-level objectives should tie directly to a feature that will achieve 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.
- When defining business objectives, avoid unbound percentages- always have a starting value and target value to truly know if you have achieved your objective.
Once the PO or BA has elicited the information for the Business Objectives Model, then all that is left is to put it into the model template, understand the links between features, objectives and problems and review.
After the Business Objectives Model is “completed,” the PO or BA can use this as a prioritization and scope tool, by asking all stakeholders who bring in new requests “How does this feature/epic/user story tie back to our business objectives?”
How do I derive user stories out of a Business Objectives Model?
Unlike most of the RML models, the Business Objectives Model doesn’t directly lead to user stories for the backlog. However, the high-level features from the product concept will become Program Epics or Features in the backlog. And the business objectives allow the PO or BA to identify the Minimum Viable Product, Minimum Marketable Featureset or the Minimum Business Increment that can be built to satisfy the objectives.
Finally, the Business Objectives Model can be used to prioritize the backlog by how much each feature or user story contributes to a business objective. Since business objectives at the highest level relate to money, by tracing the user stories back through to the business objectives, they inherit a value. This value can be used to stack rank the backlog based on the value each story brings to the objective.
For example, if the business objective is:
The model helps derive that two high level features are:
Further, if the analysis shows that the Custom Radio Station will lead to a 25% increase in subscription revenue and the Social Media Feed will only lead to a 7% increase in subscription revenue, then in a value ranked backlog, the Custom Radio Station will be built before the Social Media Feed. Now, understanding that other things than value need to be taken into account when stack ranking the backlog (like cost, risk and criticality), prioritization based on value and the business objectives gives the PO or BA a first pass of the stack ranking.
Conclusion
The Business Objectives Model is a great model for any project to align the team on what success is and how they get there. Additionally, this model gives a one page view of why you are doing the project to justify its existence to upper management or executives. Finally, the Business Objectives Model, while difficult to elicit and create, bring a world of value to the project by allowing the PO or BA to prioritize the backlog based on the value each story or feature brings to the overall business objectives.
Author: 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.