Kimball Dimensional Modeling theory and practices are the most widely accepted processes for consolidating data from different sources into a central “Delivery Area” for consolidated cross functional reporting. Or simply a process for normalizing and standardizing data from several data marts into a data warehouse for Business Intelligence (BI) reporting.

From “The Data Warehouse Tool Kit”; Second Edition; Kimball, Ross; 2002; John Wiley and Sons, Inc.; Page 22:

Finally, dimensional models are gracefully extensible to accommodate change. The predictable framework of a dimensional model withstands unexpected changes in user behavior. Every dimension is equivalent; all dimensions are symmetrically equal entry points into the fact table. The logical model has no built-in bias regarding expected query patterns. There are no preferences for the business questions we’ll ask this month versus the questions we’ll ask next month. We certainly don’t want to adjust our schemas if business users come up with new ways to analyze the business.

The main tool used to discover the applicable Dimensions for a model is the Business Process Dimensions Matrix, see Figure 1. Each row represents a Business Process and Each Column a Dimension available within the Delivery Area that is populated manually or through the consolidation of the source data.

Figure 1. Kimball, Ross; et al.; Page 79.

On this surface this looks like a Waterfall approach… Identifying all the requirements upfront before development starts. I disagree. This document should be an organic repository that is constantly updated with changes like new Dimensions or Business process as additional data sources are added to the system. Further, I believe this matrix is the perfect primer for authoring User Stories. For Instance the first Business Process would translate to:

As an Inbound Contact Center Supervisor I want to see Voice, Chat, Email and Fax metrics summarized by Date, Time, Agents (Users), Goals and Locations So that I can…

The last section of the User Story where the reason or benefit is recorded also derive from a central tenant of BI practices. That central tenant is, “Every report must answer a question to aid in the conclusion of one or more business decisions.” The question we’re answering does not show up on the matrix, but should be part of the BI project management artifacts and the User story is the perfect place to record it.

If you’re reading this you may be a BI solution developer and suffered the frustrations of pointless and repetitive presentations (reports and dashboards) because your customers don’t know what they want. Someone on the project must take it upon themselves to get the stake holders to commit to the questions they want to answer. In Agile Scrum, it would make sense that the Product Owner maintains the matrix and the user stories and therefore should be responsible for those commitments. Here’s an Example of the resulting user story.

As an Inbound Contact Center Supervisor I want to see Voice, Chat, Email and Fax metrics summarized by Date, Time, Agents (Users), Goals and Locations So that I can more accurately forecast future staffing needs.

The wide acceptance of Kimball practices predates the wide acceptance of Agile Iterative Development practices. Therefore, several professionals in the space are unwilling to adapt their practice of Kimball methodologies. Hopefully this discussion will aid in efforts to convince these BI resources to modify their approach to conform to the Software Development Life Cycle (SDLC) methodology the rest of the development team uses.