My first Publication Agile-Data-Warehouse-Design-eBook | Page 139

118
Chapter 4
suggest an importance of 1,000. This event may not stay the most important;
stakeholders can easily give a higher importance to an event that was modeled in
less detail at the last minute but this opening gambit gets the rating game going. In
Figure 4-15 the initial CUSTOMER ORDERS event has remained the most impor-
tant and is followed by PRODUCT SHIPMENTS rather than CARRIER
DELIVERIES (perhaps stakeholders realize that data will not be readily available
from carriers). Stakeholders have also rated the customer support events as cur-
rently unimportant!
You may not wish to ask all the modelstorming stakeholders to vote on impor-
tance. Arguments may ensue! If you are using Scrum to manage your agile DW/BI
development, prioritizing requirements is the role of the product owner who
manages the product backlog. A subset of the stakeholders can act as a proxy for
the product owner and provide input to the product backlog prior to release and
sprint planning meetings. At these meetings, event importance will be adjusted by
the product owner in the cold light of source data profiling results and the DW
team’s ETL task estimates.
Add a dimension
importance row and
rate each dimension
higher than its most
important event
Dimension Rating
Rules
When all events have been rated and any tied positions resolved—remember
important events should have unique importance ratings—add a dimension
importance row to the matrix (as in Figure 4-16). Dimensions are rated after events
because dimensions are only important if the events that use them are important.
Now that the stakeholders have decided which events are important, you rate each
dimension higher than its most important event, because it must be implemented
before any fact table based on the event can be implemented (due to foreign key
dependencies).
Dimension importance rating follows the same rules as event rating with a few
additions/variations:
A dimension should be rated higher than its highest importance event, unless it
has already been implemented, in which case it should be 0. E.g., if Event B
with importance 500 is the highest rated event using Dimension C then C must
have an importance between 505 and 595.
A dimension should be rated lower than any higher importance events that do
not use it.
Dimensions are rated in 5 or 10 importance point increments, so they fit
between events and BI functional requirements (report user stories). Hence the
reason for the 100 point gaps between events.
Rate conformed dimensions higher than non-conformed dimensions.
If an event’s importance is changed its dimensions must be re-rated.