Value vs Cost view of issues
Problem to solve
Product Managers need to prioritize which issues should be worked on first. One way to look at that is to examine the value delivered by the feature vs the cost to deliver the feature. Aka bang-for-buck.
Intended users
Further details
It's hard to accurately determine value and cost. One proxy for value can be how much interest an issue has garnered, as measured by thumbs-up (weight assigned to an issue. While these aren't perfectly accurate, they could be sufficient for some kinds of planning. Further iterations can improve on the measures, but we can start by this simple MVC. Since those two mechanisms already exists, we don't need an interface to add cost and value determinations.
Proposal
Add a new view to the Issue menu named Value vs Cost.
The page renders issues graphed with cost (weight) on the X axis and value (thumbsup) on the Y axis.
It may be necessary to filter the issues list so that the display is a manageable subset. It would certainly be necessary for the gitlab project, but other projects may not have that many issues, so we should start without filtering.
It's common for a view like to divide the graph into 2 or 3 sections, for high/medium/low values of cost and complexity. For simplicity, we could simply list issues in each quadrant rather than placing them exactly according to their measures.
Similar tools allow dragging and dropping issues between the various quadrants, but that is explicitly out of scope for this MVC.
Permissions and Security
Anyone with permission to view issues should be able to see this view.
Documentation
Availability & Testing
What does success look like, and how can we measure that?
- Usage of this view should exceed 4% when compared to usage of issue boards within 2 months.
- Usage of GitLab by Product Managers should increase.
What is the type of buyer?
Since this is generally spanning multiple teams (engineering and product), it the buyer is likely at least a Director level.