shawnalpay
commented
1 day ago I would like to attempt to harden these assumptions with the broader practitioner group
@cnharris10 I want to make sure of something: when we present these to stakeholders, can you confirm that you want the pitch to be "derivatives-first unless TBD principles X, Y, and Z"?
Also, we'll need a couple of examples of current and/or future columns that show what both options could be. For example: we gave you derivative BilledCost in FOCUS, but we could have given you primitives A, B, C, and D instead -- and here's some thinking as to why we gave you the primitive instead of the derivatives. This topic can (and does!) quickly spin into Philosophy Corner, so I believe we'll need to bring some concrete examples to the discussion.
I certainly don't want to put the cart before the horse and go too far with the "doing" of this Work Item -- but on the other hand, if we don't queue up the problem sufficiently, then I suspect it may get deprioritized by the stakeholders.
cnharris10
Related to #494
Problem Statement
Since the beginning, the debate around building FOCUS around "Derivatives" (or "Cakes") or "Primitives" (or "Ingredients") methodology has been reignited across all releases. This debate centers around the question of whether it is more optimal to present finalized metric values (i.e. "derivatives" or "cakes") or provide various constituents (i.e. "primitives" or "ingredients") to allow calculation of finalized metric values, likely with the assistance of documentation.
To date, the FOCUS spec has been inconsistent in its approach.
In some cases, we provide "Derivatives" with finalized metric values including:
In some cases, we leverage "Primitives" to build finalized metric values included:
In some cases, we provide both:
Across multiple releases, we continue to have similar debates and have produced a non-normalized spec (which might be ok) because we aren't following guiding principles in this regard.
Objective
Given that we have a non-normalized approach and to mitigate further, repetitive debates, we should decide on if it makes sense to follow a methodology that follows a certain route when looking at proposals for expanding the FOCUS spec in subsequent releases. This may include picking one route over the other, a hybrid, or a prioritized approach that starts with one route and eventually includes the other.
Along with a decision on this principle, we should coalesce a section of guiding principles in the design of FOCUS and expose to practitioners within the spec and/or across other documentation channels.
Supporting Documentation
N/A
Proposed Solution / Approach
When designing the
CommitmentDiscount{Quantity,Unit}columns in v1.1, the TF-1 group debated this topic over a series of weeks and arrived at the conclusion that, at scale,it is more optimal to build for the "Derivatives" approach over the "Primitives" approach first and then fill in missing "Primitives" subsequently, as prioritized.
The following a list of pros/cons for each approach.
Derivatives Pros:
Cons:
Primitives Pros:
Cons:
--
Given the above list, I would like to attempt to harden these assumptions with the broader practitioner group to see if this path makes sense to adopt as a standard design practice for the spec or an additional approach make sense.
Epic or Theme Association
Provide the rational for the Epic or Theme.
Stakeholders
Provide names and roles of key stakeholders.