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

  • Don't want to put this in an answer because I'm really just pasting what I found through google, but all the top searches are either this free addon or forums suggesting it: marketplace.atlassian.com/plugins/…
    – Daniel
    Dec 6, 2016 at 1:08
  • Thanks for the suggestion, @Daniel , but I am told that one is not compatible with Jira Cloud. My teammates are looking into marketplace.atlassian.com/plugins/com.mumosystems.abacus/cloud/…
    – Mike Eng
    Dec 6, 2016 at 17:30
  • I was going to ask a very similar question and ran across this. +1
    – Tim
    Feb 24, 2017 at 20:01
  • I have seen some pseudo-scientific approaches in my time but this is really anti-Agile. Honestly, it's opaque, unsustainable, slow to respond and completely arbitrary. Good luck making it a success but I doubt it will be. Mar 7, 2017 at 10:16

4 Answers 4


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?
  • 1
    Thanks for the input. There's some valuable info there, so I voted up your answer. I didn't emphasize it much in my question, but the key to us using this is that we're using it along with other criteria to prioritize - we're not using it strictly to determine how to sort items into sprints. You addressed the "should you do this" rather than answering "how to do it" (the actual question), which is why I didn't accept it as an answer.
    – Mike Eng
    Mar 7, 2017 at 14:18


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.


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

  • Care to put a bit more details into your answer, for others? Why did you choose that plugin? How does it work? What makes it the best option?
    – Sarov
    Mar 7, 2017 at 18:37
  • @Sarov I don't know the details of the implementation and configuration of it, since I'm not a Jira admin on my team - someone else handled that. But it basically does exactly what I was looking for as described in the question. I chose it simply because it works.
    – Mike Eng
    Mar 20, 2017 at 13:51

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}}

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.