Allow decimal points in scores

We're using a (value / estimate) method for determining the score of a feature. The division usually results in a decimal point (so one feature is a score of 3.1, another is 3.4). Right now, Ahah is turning both into a 3.

We'd like to be able to show one decimal place of score. Right now we're multiplying by 10, but that's making for some confusing (high) priorities, as we use the one decimal place score in other places in our company. 

  • Jason Slaughter
  • Sep 28 2015
  • Likely to implement
Release time frame
  • Attach files
  • Jason Slaughter commented
    October 26, 2015 13:11


    This does not work in a custom equation; it was the first thing I tried. If you try to make your equation "ROUND({stuff related to the score},2)" you get "Syntax error in equation" and the app won't let you save it.

    So if this is the workaround, then you need to fix your validation code in the scorecard.

  • Jason Slaughter commented
    October 27, 2015 19:20

    Ron confirmed in a support ticket that this workaround (even after they fixed the validation issue) does not work, as the number is still chopped to the nearest whole number. Given how many product managers are using the "[value] / [effort]" method of prioritization these days, and the fact that this will almost always result in decimal values, I hope that you can consider implementing this feature. 

  • Michal Anderson commented
    January 19, 2016 19:40

    Agree this is something that just became highly important to us as well.

  • David Behr commented
    March 27, 2016 12:05

    Ron - as agreed below it would be great to remove your first answer at it does make it look like there is a workaround at first glance, which is incorrect.

    When you do implement this , please can you also allow the step value to be a decimal - e.g. 0.1.  

    This will actually allow a more OKR-type experience in scoring key results as per

    In fact we have many things we like to score between 0-1 and I can also see decimals being useful to others.  There must have been a good reason to disallow decimals in the first place, but can't really see why.



  • Jason Slaughter commented
    February 8, 2017 21:03

    Is there any update on this? We've worked around this for ages by multiplying by 10, but we'd really like a proper solution.

    Again, this is really necessary for the (what I thought was quite common) method of scoring by (value of the feature / estimate of the work required).

  • Daniel Dahlström commented
    August 4, 2017 11:33

    When working with WSJF, this is an absolute necessity. For us, it may be crucial for the use of or not

  • Luke Hanson commented
    November 22, 2017 12:51

    Agree with the comments, this is essential for WSJF calculation to differentiate items with similar scores.

  • Chad Hilton commented
    January 12, 2018 21:49

    We have a similar need on numerous projects, specifically in the use of WSJF scoring approach. Any insight as to when this will be available?

  • Project Parker commented
    March 27, 2018 08:30

    The client I am on-boarding will need this for OKR's & WSJF calculations. Quite surprised this is has been outstanding for 2.5 years now, especially given the number of votes. The rollup of OKR's without decimal points makes reporting far less accurate than it could be.

  • Alex Knight commented
    May 18, 2018 17:03

    I too am using WSJF, and this would be really helpful to be able to set the format of the score calculation to 1 or 2 decimal places.  I think a workaround would be to multiple your calculated final score by 100.

  • Alex Knight commented
    May 18, 2018 17:08

    I just edited my WSJF scorecard by multiplying the calculation by 10, and it worked like a charm!  Updates to all my scores happened, without error.