Issue Prioritization Pilot
As part of the working group, we've figured out a potential model that is worth validating via a pilot so we can collect data on its efficiency.
Model Inputs
- Value:
value::low
,value::medium
,value::high
- Urgency:
urgency::low
,urgency::medium
,urgency::high
- Value Profile:
reason::grow
,reason::protect
-
Create easy to understand definitions for each value label -
Create easy to understand definitions for each urgency label -
Create easy to understand definitions for each value profile (other two will come later) -
Update the Feedback Template with information and context on how to use the labels (and keep them up to date over time) -
Determine how and where to set the Duration input (estimated weeks to complete issue / epic)
@spouliquen1
Label modifiers:
-
value::low
= 1 -
value::medium
= 2 -
value::high
= 3 -
urgency::low
= 1 -
urgency::medium
= 2 -
urgency::high
= 3
SFDC Data:
- Customer
- Opportunity value (IACV)
- Account value (ARR)
Calculate Value
Step 1 - Calculate Value: ** This should include epics AND issue
- Sum total number of value points for a single customer broken down by value profile.
- Determine value per point for each value profile.
reason::grow
(value per point = IACV / value points),reason::protect
= (value per point = ARR / value points). - Determine customer value for each linked issue.
customer issue value = value points x value per point
Step 2 - Calculate Cost of Delay
- Multiply
customer issue value x urgency points = customer cost of delay
- Average all customer CoD to get a combined issue value -
average cost of delay = (customer cost of delay + customer cost of delay...) / total count of customers
Step 3 - Divide by Duration
average cost of delay / duration (weeks)
Upgrade User Requested Issues Dashboard & adding more dashboards
@dsakamoto
Push prioritization to Issue in GitLab
-
Determine labeling system that maps Cost of Delay / Duration into some finite amount of ranges that can be mapped to a scoped label set and automatically applied/updated on a given issue.
@gweaver
Details
-
The calculations should run on a daily basis and assume that any of the input data is mutable and has changed since the last time the calculations were run.