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.
Release time frame |
Ron,
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.
Attachments Open full size
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.
Attachments Open full size
Agree this is something that just became highly important to us as well.
Attachments Open full size
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 https://big.ideas.aha.io/ideas/APP-I-2013
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.
Thanks
Attachments Open full size
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).
Attachments Open full size
When working with WSJF, this is an absolute necessity. For us, it may be crucial for the use of aha.io or not
Attachments Open full size
Agree with the comments, this is essential for WSJF calculation to differentiate items with similar scores.
Attachments Open full size
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?
Attachments Open full size
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.
Attachments Open full size
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.
Attachments Open full size
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.
Attachments Open full size
When converting the Aha! Score to calculate WSJF (https://www.scaledagileframework.com/wsjf/) the output most instances involves a decimal. I have seen others here multiply their output by 100 but it then deludes the true scale of the score. Can we change the AHa Score! from an integer data type to a float data type?
Attachments Open full size
I am serving a "Solution Management" role in SAFe.
Here's my setup which I use instead, now:
For Biz Value, Time Criticality, Risk vs Oppty Enable, and Job Size, i use inputs as:
Attachments Open full size