Method for scoring backlog items in Jira based on impact to company goals versus level of effort

Question

My development team uses Jira Cloud, and I'm looking for some way within Jira to prioritize the backlog items (mainly "new features" and "stories"). I'd like to do this by manually assigning scores to each backlog item for the following criteria:

• Company goal: revenue growth
• Company goal: customer satisfaction
• ... a few more company goals
• Level of design effort
• Level of development effort
• Level of QA effort

I'd then like an overall score for the ticket to be automatically calculated using a formula that I can specify, assigning a different multiplier to each goal and also applying a multiplier to all of the level of effort items and subtracting those.

So the formula to calculate the ticket's overall would be something like:

• 21 * (Company goal: revenue growth) +
• 13 * (Company goal: customer satisfaction) +
• 8 * (Company goal: resource efficiency) +
• 5 * (Company goal: employee satisfaction) +
• 3 * (Company goal: responder fulfillment) +
• 2 * (Company goal: responder acquisition) +
• 1 * (Company goal: recognition as a market leader)
• - 5 * (Level of design effort)
• - 5 * (Level of development effort)
• - 5 * (Level of QA effort)
• = overall score

And I'd like to be able to order tickets by overall score and use that overall score, along with other criteria, to place tickets into sprints.

I would like this to work very similar to this feature from another tool: Aha Scores

Answer 1

Looks very objective but counterproductive

While this approach looks super objective, I don't recommend it for the following reasons:

1. Sprint goal: Selection of stories for a Sprint should be driven by the Sprint goal. While the main stories for a Sprint should be selected (explicitly or implicitly) based on high value and low effort, some other stories may be selected to make the value delivery whole. Your approach will result in a collection of assorted stories without a coherent Sprint goal.
2. Product Owner: This will undermine the Product Owner's authority to change priorities, as conditions change. There is no substitute for the judgement call by a Product Owner with a clear vision.
3. Too much work: I have done a lot of Planning Poker sessions to estimate story points. Getting consensus on that one score itself is a slow process. Scoring on 10 different criteria for each story is a lot of work for the team.
4. Relative story points: Overall story points can be estimated, in relative terms. Level of design effort, development effort and QA effort cannot be estimated accurately. Read this previous thread: Why use story points instead of hours for estimating?

Answer 2

TL;DR

Even if you can do prioritization through automated formulas, don't. It's an agile anti-pattern that will generally do more harm than good to the overall management of your product delivery schedule.

There's a place for formulas and ranking systems, but the product backlog or your ticketing system isn't it. Prioritization is fundamentally a set of interdependent strategic decisions, and strategic decisions (especially strategies involving complex trade-offs) are very difficult to model mathematically.

Consider the entire field of game theory and the huge volume of complex study that flows from it. You'll get a very small taste of why strategic decisions should currently be handled by people rather than static formulas.

Handling Prioritization and Trade-Offs

Complex, automated prioritization is an agile anti-pattern. While a scoring system can (and probably should) be used by the Product Owner when working with stakeholders to identify features or prioritize the Product Backlog, a complex ranking system doesn't belong inside the backlog or inside a ticketing system like JIRA.

Regardless of your ticketing or backlog system, backlog items should certainly express an ordinal or classed priority, but should not leave it up to ticket writers or an automated system to actually define the priority. Systems that do this either become unmanageably complex, or people start gaming the system so that everything is "priority one." This helps nobody.

False Precision

The real issue is that prioritizing work always requires trade-offs. Sometimes those trade-offs can be quantified, but more often than not overly-complex formulas simply lead to a false sense of precision. This is why IT work in particularly is often better-expressed in story points rather than man-hours, because "five times harder than our usual work" is generally more useful than the false precision that comes with saying something complex will (or should) take 23.651 man-hours.

Did you notice? Even though I didn't say "exactly 23.651 man-hours" in the paragraph above, didn't the precision of the figure imply a highly-refined exactness to you? It doesn't sound like an estimate, and I can assure you that most stakeholders will treat precise numbers like that as money-back guarantees rather than forecasts or rough estimates.

Answer 3

We were able to make the Abacus plugin for Jira Cloud work for this.

Answer 4

You can use Jira Automation

Create Fields for user to input Company goal: revenue growth Company goal: customer satisfaction ... a few more company goals Level of design effort Level of development effort Level of QA effort

Create Overall Score field

Then in Automation set to on a Change to those fields the Automation is triggered Use Smart IDs to grab the user entered Value and multiply by your factor and store as a SmartID for later use in the automation ie ie smart ID = revgrowth {{issue."Company goal: revenue growth"}}*21

To Check output the new smart IDs in log

Then create another new Smart ID that combines the score in the way you want from the Calculated Smart Ids

ie Smart ID = OverallScore {{revgrowth}} + {{customersatisfaction}} - {{designeffort}} - {{deveffort}} - {{QAeffort}}

Then in edit Overall Score field = {{OverallScore}}