Skip to main content

Author: Candase Hokanson

Deep Dive Models in Agile Series: Decision Models, Edition 6

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 is the last paper in this current series and covers Decision Models, which include both Decision Trees and Decision Tables. Previous articles in this series included Process Flows, Feature Trees, Business Objectives Models, Business Data Diagrams and State Models.

What is a Decision Model?

Decision Models include two RML System models (Decision Trees and Decision Tables) that detail the system logic that either controls user functions or decides what actions a system will take in various circumstances.

Like the State Models, these two models are covered together in this paper because they show the same information in different formats. Oftentimes a PO or BA will use only one or the other of the two Decision Models based on circumstances. Decision Tables are used when the PO or BA wants to ensure that every permutation of applicable decision choices has been explored. Whereas, Decision Trees are more consumable for business stakeholders and are typically used to show a collapsed view of a Decision Tree by only modeling the decision choices that lead to an outcome. Decision Models are great for any project with logic that the system needs to enforce and even as the acceptance criteria for the user stories in some cases!

The Decision Table is the tabular format of decisions and their outcomes with each column in the Decision Table representing one potential permutation of decisions in the system. The Decision Table contains three main areas: the conditions (or decisions), the outcomes, and the columns where each permutation of each decision choice is listed with the appropriate outcomes marked. This model is read vertically (see example below) in that the user will take one column and read down: “If Condition 1 is choice 1a, condition 2 is choice 2a and condition 3 is choice 3a, then outcomes 2, 3 and 4 occur. The vertical columns each represent a business rule for the system.

Hokanson 121416 1

A Decision Tree, like the State Diagram, is a more visual way to show the decision logic in a branching tree format by only showing the decisions and choices combinations that lead to an outcome in the system. This model is great for verifying branches of system logic with business stakeholders. See the example of a decision tree below:

Hokanson 121416 2

When would I use a Decision Model on an agile project?

There are two main use cases for Decision Models on agile projects. One is to detail specific pieces of system logic for a user story. In this case, the Decision Model is identified and created for the user story it supports about 1-2 sprints ahead of the sprint the decision logic will be implemented in. The PO or BA would identify that a user story requires the system to execute decision logic to come up with a response for the user. This can be identified by the PO or BA during elicitation if she hears words like “If the user does X, then the system does Y, etc.” From there, the PO or BA would elicit all the possible decisions that occur in the system and walk systematically through each combination of decision choices in a Decision Table to ensure that all outcomes are accounted for. Optionally, a Decision Tree can be created to ask questions of business stakeholders and complete the system logic.

The alternative use for using Decision Models on an agile project is to identify and represent the acceptance criteria. Acceptance criteria are often written in the Given-When-Then format. “Given a certain precondition in the system, when some trigger occurs, then the system will take some action or display some response.” This aligns very well to a Decision Table as the preconditions and triggers can be modeled as decisions or conditions, and the outcomes are still outcomes in the Decision Table. One caution here is that if written acceptance criteria already exist in the Given-When-Then format, the PO or BA usually does not need to create a Decision Table to model the acceptance criteria. This technique would only be used on larger stories where the precondition list or trigger list is longer (3-5), and thus the number of combinations of preconditions and triggers is higher. In this way, the PO or BA can be sure that every path in the acceptance criteria has been explored to find any needed system response.

How do I create a Decision Model?

The first step in creating a Decision Model is for the PO or BA to identify all the decisions being made by the system for a particular outcome. This can be a list in the Decision Table or decision diamonds in the Decision Tree. Typically, a PO or BA will start with a Decision Table and move to a Decision Tree as needed.

After brainstorming the decisions in the system, the PO or BA has to identify all the applicable choices for each decision. Decisions can be binary (Y/N) or non-binary. If the decision is non-binary, the PO or BA needs to check that the decision choices are Mutually Exclusive and Collectively Exhaustive (MECE). This means that all choices are accounted for and that there is no ambiguity in choices (if a number is a non-integer, choices like 1, 2-5 and >5 would not meet MECE and instead, the PO or BA would need something like: <1, >=1 to <5, >=5). For this reason, a lot of POs/BAs prefer to use binary decisions, but it can complicate a table or tree.

Finally, the PO or BA walks through each combination of decision choices and identifies the appropriate system outcome for that combination of decisions. See the example Decision Table below:

Hokanson 121416 3

In this case, if the listener chooses not to select artists, then the system cancels station creation and doesn’t care about the number of artists chosen. In Decision Tables, this case, where the choice of the decision or condition doesn’t matter, can be shown as a “-.“ Additionally, Decision Tables can show ordered outcomes by using numbers in the outcomes (i.e. 1 and 2). For example, in an e-commerce site, when a customer wants to use a gift card to pay for something, the system may first (1) deplete all funds on the gift card and then (2) ask for a second payment method if the gift card did not cover the full cost of the order.

Decision Trees show this same information in a branching tree format using the same elements as the Process Flow: steps and decision diamonds, except the steps are now steps the system takes in the form of outcomes. As mentioned above, Decision Trees are usually created after Decision Table to verify the decision logic with business stakeholders. However, if the PO or BA decides to start with the Decision Tree, the process for creation is essentially the same: 1- brainstorm the decisions, 2- identify the choices and 3- walk through the decision/choice combinations to arrive at outcomes. See the example below:

Hokanson 121416 4

How do I derive user stories out of a Decision Model?

Decision Models usually supplement user stories to ensure that all paths are identified, so they usually lead to additional acceptance criteria. Each Decision Model created will usually be for a single user story, and each permutation of decisions and choices is one acceptance criteria. For example, if we had a story of:

Hokanson 121416 5

With acceptance criteria of:

Hokanson 121416 6

The PO or BA might see the need to create the Decision Models above to ensure that all acceptance criteria are accounted for, which would identify the following acceptance criteria:

Hokanson 121416 7

These models are great for identifying missing acceptance criteria (and thus test cases) that might trip up an agile team and cause a story to “Fail” a sprint by not considering exception cases in the acceptance criteria.

Conclusion

Decision Models are great models for POs or BAs to use when they are unsure they have properly captured the acceptance criteria for a story. These models allow the PO or BA and business stakeholders to be aligned on the system logic and expected system behavior before a story is taken into a sprint which allows the PO or BA to give better information to the agile team.

This concludes the Deep Dive Models in Agile series. Over the course of six short papers, we have covered: Process Flows, Feature Trees, Business Objectives Models, Business Data Diagram, State Models and Decision Models. Which visual models do you use most on your agile projects?

Deep Dive Models in Agile Series Pt 5: State Models

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 state models which include both State Diagrams and State . Other editions in this series include Process Flows, Feature Trees, Business Data Diagrams, Decision Trees/Decision Tables and Business Objectives Models.

What is a State Model?

State Models include two RML Data models (State Tables and State Diagrams) that show the transition of an object through various states or statuses, including which transitions are valid and what triggers an object to transition state. A state is a short-form description of a stage in a data object’s life that influences the behavior of the system.

These two models are covered together in this paper because they generally show the same information, just in different ways. These models are great for any object which has state of which there might be business rules, like workflow processes!

The State Table is the tabular format of state data with one State Table being created for each object that has state transitions. It consists of a table of all the applicable states for the object across the top row and left-most column. Each intersection of row and column is then systematically filled in for whether the transition is valid and what the trigger is. State Tables are especially good when the PO or BA wants to ensure that every possible transition for an object has been identified. See the example below:

Hokanson 112916 1

A State Diagram is a more visual way to show the transition data in a State Table by only showing the valid transitions of an object and their triggers. The State Diagram is great to illustrate the happy path and alternate paths of an object’s state lifecycle to stakeholders. While the State Table allows the PO/BA to ensure that she has considered all possible state transitions, the State Diagram is more consumable for business stakeholders. See the example below:

Hokanson 112916 2

When would I use a State Model on an agile project?

Unlike most of the other models in this Deep Dive series, State Models are not applicable for every agile project. Projects that need State Models typically include workflow projects and projects that have data objects with many complex decision logic or business rules around them.

If the PO or BA knows upfront in the project that the project will involve workflow (like approval processes), then she may begin eliciting the statuses or states of the workflow items in a Planning or Sprint 0 phase. This allows the system to be designed by the architects with some knowledge of the complexity of the workflow that needs to be implemented.

For most projects, State Models are created during the Execution or sprint phases, usually about 1-2 sprints before the story to implement them is worked on. The PO or BA would identify the need for a State Model, generally with clues like states or statuses for an object or a list of automated state changes in the system that need to be modeled out.

From there, the PO or BA would elicit the full list of states and potential transitions from the stakeholders, create a State Table to ensure that everything has been captured (or update if not) and, optionally, create a State Diagram to review the updated information with the stakeholders prior to the story being worked on.

If the work on the workflow or lifecycle of a data object spans multiple sprints or releases, then the PO or BA would keep the State Table or State Diagram updated with new transitions or states until the work has been completed.

Additionally, State Models can be used with Process Flows. Once the states and transitions for an object have been identified by the PO or BA, he can overlay the states as circles on the process flow step that causes a transition. See example below:

Hokanson 112916 3

How do I create a State Model?

To create either state model, State Tables or State Diagrams, a PO or BA must first identify an object in the system that has state. This could be something like quotes, orders, profiles, accounts, requests, alerts, etc.

With that information, the PO or BA will work with the stakeholders to identify a first list of applicable states for the object and maybe some of the valid transition. Then the PO or BA would create a State Table.

To create a State Table, the PO or BA will put all identified states in the top row of the excel table and the left-most column of the excel table. Working from column to row, the PO or BA will walk through each intersection of the states to determine if the transition is valid and, if so, what the trigger is. See the example below:

Hokanson 112916 4

From this, the PO or BA would brainstorm individually whether any states are missing and ask questions of those to the applicable stakeholders. Finally, once the State Table is in a good place, the PO or BA may decide to create a State Diagram showing the valid transitions for easier reviewing with stakeholders.

The State Diagram covers the states (circles) and transitions (lines with text), but also adds two additional pieces of information that the State Model doesn’t: Start State and End State. In a State Diagram, transition lines should only be entering an “End State,” never leaving because otherwise, it is not an “End State.”

Hokanson 112916 6The state of an object’s life-cycle that the object always begins its life-cycle in. These are typically a new or drafted type state.

Hokanson 112916 5

A state in an object’s life-cycle from which the object can never transition out. Once the object reaches one of these states, the life-cycle is completed.

To create, the PO or BA will identify if the object being modeled has a start or end state, then add all states from the state table and the valid transitions with either triggers or user story references. See example below:

Hokanson 112916 7

How do I derive user stories out of a State Model?

Once the State Table or State Diagram has been created by the PO or BA, each transition between states is likely to be a user story in the backlog, and each end-to-end path (from start state to end state) is likely to be at least one epic (think happy paths and alternate paths).

For example, if the State Diagram above is the State Diagram for our project, two stories that might come out of that are:

Hokanson 112916 8

For this example, since it is a simple one (most objects with state have 5-9 states that can be transitioned between instead of just 3!), the epic might just be “As a SeiSounds listener, I want to be able to control the privacy settings of my custom radio player so that I can keep my songs private or share them with friends.”

Conclusion

State Models, while not as universally applicable to agile projects like other visual models, are great for identifying user stories and epics in workflow or similar projects. These models allow stakeholders and developers together to understand the full life-cycle of a data object and what transitions should be allowed, restricted or even automated.

This helps the PO or BA write user stories around these data objects and ensure that no edge cases of state or transitions are missing.

Deep Dive Models in Agile Series: Business Data Diagrams, Edition 4

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 Part 1, Part 2, and Part 3 by following the links.

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.

Hokanson 110916 1

When would I use a Business Data Diagram on an agile project?

The Business Data Diagram is a model that is relevant to virtually any software product – because almost all products deal with data. Even the simplest of BDDs, with only a 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 the 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:

Hokanson 110916 2

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:Hokanson 110916 3

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 a complete set of user stories around users interacting with the data following the create, use, edit, delete, move and copy actions.

Deep Dive Models in Agile Series Pt 3: Business Objectives Models

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.

Related Article: Deep Dive Models in Agile Pt 2 – Feature Trees

Now for something different in the series: Business Objectives Model. Take a look at the first or second editions on Process Flows and Feature Trees if you’ve missed them. Other editions in this series will include: Business Data Diagrams, State Tables/State Diagrams, and Decision Trees/Decision Tables.

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 in 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:

emma 102716

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 backward (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 backward, 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 Feature set 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:

Business Objective Increase quarterly subscription revenue
from $72,000 to $80,000 within two quarters (from development start)

 The model helps derive that two high-level features are:

Feature 1 Custom Radio Station
Feature 2 Social Media Feed
 

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.

Deep Dive Models in Agile Pt 2: Feature Trees

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.

Next up in this series is the Feature Tree. If you missed the first edition on Process Flows, you can find that here. Other editions in this series will include: Business Data Diagrams, State Tables/State Diagrams, Decision Trees/Decision Tables and Business Objectives Models.

What is a Feature Tree?

A Feature Tree is an RML Objectives model that shows the full scope of features for a project or product on a single page in a tree format. A feature is just a short form description of the functionality provided by the project or product that brings value to the end user. The Feature Tree is great for bringing new people on a project up to speed and showing executives, business stakeholders, or customers all the features that are in scope for a project or release.

The Feature Tree is similar in shape to a fishbone diagram or an Ishikawa diagram but shows levels of features instead of root-cause analysis. It is easier to read than a flat list of features for a product because the Feature Tree groups them into logical buckets, but Feature Trees are very similar in function to Story Maps or Affinity Diagram which are also other ways to organize features visually for consumption. See an example Feature Tree below.

featuretree1

When would I use a Feature Tree on an agile project?

Feature Trees are useful for almost any agile project because they are just a good way to organize information about the project. The Product Owner (PO) or Business Analyst (BA) will usually elicit the start of a Feature Tree during a sprint 0 or planning type phase, possibly with information from a project charter or light-weight business case. From there, the PO or BA will organize the features into groupings, understand the connections between L1, L2, and L3 features and identify if there are any missing features. Depending on the story hierarchy you are using on your project, you might use Program Epic -> Feature -> Story or just Feature -> Epic -> Story for your L1, L2, and L3 features with the story level being optional (see illustration below).

featuretree2

Since you won’t always know the full scope of the product during sprint 0 or planning, the Feature Tree is always evolving, even throughout development, as the PO or BA finds new features to add to the backlog.

The Feature Tree also helps organize the hierarchy of your backlog as you know have an easy visual of how things are related.

Some ways Feature Trees are modeled to be especially useful on agile projects:

  • Color coding: the PO or BA can color code the features by release or sprint/iteration, which makes it easy to see at a glance if certain features are in or out of scope for a release
  • Prioritization by location: the PO or BA can order the Feature Tree such that more important items are closer to the “trunk” of the tree, allowing for visualization of the backlog prioritization
  • Gap Analysis or Current/Future State: instead of color coding by release, the PO or BA can color code for gaps or current vs. future state of the system (with red, blue, green or little-colored circles we like to call skittles)

How do I create a Feature Tree?

Like Process Flows, Feature Trees are one of the easier RML models to elicit and create. First, the PO or BA should find out if there are any existing lists of features for the project or product from a vision and scope document or a project charter.

From there, the PO or BA would host a brainstorming session to identify potential features and maybe even group them in an affinity diagram or story map. After that, the PO or BA would need to decide the format for their features. This paper is about the Feature Tree as a convenient way to organize the information, but a two level story map or affinity diagram will convey a lot of the same information (just perhaps not tie back to the backlog as well depending on the structure).

The model itself once the PO or BA has decided upon that format is pretty straight forward with only 2 elements:

Trunk/Product Concept– On the trunk of the Feature Tree is the Product Concept; this is a short form phrase that says what the product or project is. This will come from the Business Objectives Model which will be discussed in the next edition of Deep Dive.

Branches/ Feature- Coming out from the trunk are branches which have levels just like real tree branches. The largest branch type is the L1 features. Like the product concept, the L1 features will be described at a high level from the Business Objectives Model. These L1 features will be further broken down into L2 and L3 features (smaller branches) depending on your story hierarchy.

How do I derive user stories out of a Feature Tree?

Once the PO or BA has a good starting draft of the Feature Tree, the epics or features (again depending on your hierarchy) almost fall out of the Feature Tree. Each L2 or L3 branch becomes a feature, epic or story and each L1 branch becomes a Program Epic or Feature (based on SAFe or generic agile hierarchies). See example Feature Tree below:

featuretree3

So a feature for “Create Station” below might become the following epics/ features in your backlog:

featuretree4

Additionally, as mentioned above, you can add color coding to denote releases or sprints like below:

featuretree5

Conclusion

Feature Trees, like Process Flows, are super easy RML models to use on agile projects and derive features, epics, and user stories from because they organize the scope of a project or product onto a single page.

Executives, business stakeholders, and customer love this visual model because it shows them what is in and out of scope easily and potentially even shows them when they will get certain features. Developers and testers like the Feature Tree because it gives them the big picture of the entire project while they are working on specific user stories. Finally, the POs and BAs find this model useful for backlog population early in the project and maintenance throughout, so it is one of the most commonly used RML models on agile projects (second only to Process Flows!)

One note of caution is that because it is so easy to add additional features and scope to the Feature Tree and thus to the backlog, the PO or BA has to be vigilant in the management of the backlog to ensure that only the most valuable features get built for his/her project.