Technique Summary: BABOK 10.15, 10.16, and Agile 7.8

 By Julie Ramsey

Below is a summary of section 10.15 - Data Modelling and 10.16 - Decision Analysis  from BABOK® version 3 and Agile Techniques 7.8 Planning Workshops from the Agile extension to the BABOK guide version 2.

Technique 10.15 – Data Modelling
Purpose – Provide visual representation of elements important to the business, their attributes and the significant relationships between them to establish a consistent vocabulary for analysis and implementation.
Description – Data models are usually diagrams supported by textual descriptions.  They may be used during elicitation and requirements analysis and design. Data models support implementation and continuous improvement.
There are three variations of data models.  A Conceptual Data Model represents how a business perceives its information and is independent from a solution.  Logical Data Models include rules of normalization to manage the integrity of data and relationships.  These are associated with the design of a solution.  Physical Data Models are used by implementation subject matter experts to show how a database is physically organized.  Physical Data Models may address performance, concurrency and security.

  • Entity – A Data model shows data on entities which may represent something physical, organizational, abstract or an event.  Entities contain attributes and are related to each other.
  • Attribute – Pieces of information associated with entities are called attributes.  Attributes include how much information can be captured, allowable values and the type of information represented.
  • Relationship – The structure of the data model comes from the relationships between the entities.  The number of minimum and maximum occurrences allowed on each side of the relationship is called cardinality.  Typical cardinality values are zero, one and many.
  • Diagrams – The data model diagram displays the entities, attributes and relationships visually.  These diagrams may be called entity-relationship diagrams (ERDs).
  • Metadata – A data model may contain metadata to describe what the entities represent, when and why they were created, how to use them, how often, when and by whom.  There may also be restrictions, and details about security, privacy and audit constraints.

Below is a very basic data model.  Customer and Item are the entities, both have unique identifies and several attributes.  The relationship is read in both directions.  In this case a customer may be related to multiple items but each item relates back specifically to one customer.
Usage Considerations – Strengths

  • Define and communicate consistent vocabulary
  • Consistent approach to analyzing and documenting data and its relationships
  • May provide just enough information for a specific audience
  • Can expose new requirements as inconsistencies are identified

Usage Considerations – Limitations

  • If standards are followed too rigorously models may be unfamiliar to those without an IT background
  • Data models may cross multiple areas of an organization and go beyond the business knowledge of individual stakeholders

Technique 10.16 – Decision Analysis
Purpose – Formally assess a problem and possible decisions to evaluate the value of alternate outcomes given uncertain conditions or complex situations.
Description – Decision Analysis examines and models the possible consequences of different decisions for a given problem.  A decision is defined as choosing a course of action from several uncertain outcomes with different values.  Outcome values typically include financial value, scoring or a relative ranking. 
A variety of decision analysis approaches may be used based on the level of uncertainty, risk, quality of information and evaluation criteria.  Effective decision analysis requires understanding of values, goals and objectives relevant to the decision problem.  Additionally, the nature of the decision to be made, areas of uncertainty and consequences of the decision must all be understood.
Decision analysis approaches include defining the problem statement, evaluating alternatives and implementing one alternative.  Some examples of decision analysis tools are pro vs con considerations, decision tables and multi-criteria decision analysis (MCDA).
Components of Decision Analysis

  • Problem Statement – description of what the decision is about
  • Decision Maker – who is responsible for the final decision
  • Alternative – possible course of action
  • Decision Criteria – criteria used to evaluate the alternatives

Decision Matrices – These may be simple or weighted.  A simple matrix shows if each alternative meets each criterion and totals the number of matches for comparison of alternatives.  A weighted matrix assigns values to each criterion and ranks each alternate per criterion.  Those values are multiplied and added for a total score per alternative as in the example below.  The weights represent importance and the ranks represent the best match to each criterion.

Scale 1-5 Alternate 1 Alternate 2 Alternate 3
Criterion 1 (weight 1) 1*1=1 1*3=3 1*4=4
Criterion 2 (weight 5) 5*4=20 5*1=5 5*2=10
Criterion 3 (weight 2) 2*3=6 2*2=4 2*4=8
Weighted Score 27 12 22

Decision Trees – Used to assess outcomes with multiple sources of uncertainty.  Decision trees include decision nodes, chance nodes and terminator nodes.
Trade-offs – Relevant when the problem has multiple, conflicting objectives, trade-offs may be made by elimination of dominated alternatives or ranking objectives on a similar scale.  A dominated alternative is clearly inferior to another alternative because it is equal or worse by comparison or it offers small advantages but large disadvantages.
Usage Considerations – Strengths

  • Prescriptive approach for determining alternate options
  • Assessment based on criteria rather than descriptive information and emotions
  • Focuses on an honest assessment of importance for the various outcomes
  • Allows for comparison of financial and non-financial criteria

Usage Considerations – Limitations

  • May require more time than is available to decide
  • Requires the decision maker to understand assumptions, model limitations and provide input
  • Specialized knowledge may be required
  • Analysis paralysis may occur if too much stock is placed on the analysis and determining the values

Technique 7.8 – Planning Workshops
Purpose – Used to determine value that can be delivered in a given amount of time.
Description – Planning workshops facilitate commitment for delivery of a feature in an agreed upon time.  They enable collaboration and can respond to change resulting from feedback.  Backlog Refinement may take place in preparation for planning workshops and involves analysis to gauge size, scope and complexity of items in the backlog.
Planning workshops can be used at any planning horizon (Strategic, Initiative or Delivery).  At the Strategy Horizon a planning workshop will focus on goals, metrics to achieve them and initiatives to deliver value toward the goals.  Planning workshops at the Initiative Horizon result in release plans showing sequence to deliver user stories over the whole release.  At the beginning of an iteration, the Delivery Horizon planning workshop determines the regular time to review the next set of backlog items.
Planning workshops are performed on a frequent and regular basis in an agile approach because the solution changes frequently based on feedback.  They are used to prioritize and sequence the backlog considering feedback and changing needs.  In a Kanban approach, planning workshops increase knowledge sharing on the team.
Planning workshops consist of the what and the how.  What includes the goal, desired outcome, and highest priority backlog items.  How is determined by team discussion about the completion of each item.

  • Estimated and Ordered Backlog – Business analysts provide estimates and order items in the backlog as an input to the planning workshop.
  • Team Velocity – Considering prior throughput capacity of backlog items, called velocity, helps the team predict the amount of work that can be reasonably committed to in the next iteration.
  • Iteration Goal – An overall goal is set to guide the selection of features.
  • Backlog Item Selection – The Product Owner selects the iteration goal and highest priority backlog items based on business value.  The backlog includes items necessary to deliver a minimal marketable feature (MMF).  This could include bugs to be fixed, environment set up, research or any other activity that will add value.
  • Task Planning – Backlog items are broken into smaller manageable tasks to be completed by specific team members.

Usage Considerations – Strengths

  • Stakeholders communicate frequently on product vision and the solution
  • Plans can be changed as needed based on feedback from the prior increment
  • Synchronization across multiple teams is facilitated
  • Dependencies between backlog items can be discussed

Usage Considerations – Limitations

  • All team members must gather together to avoid interruptions and rework
  • Sufficient time must be set aside to avoid the need for additional conversations
  • Backlog items must be well understood or there is risk of creating a sub-optimal plan