I feel a Priority field should be added to issues. It's pretty standard with all other task tools.

Comments

boobaa’s picture

boobaa
he/him
commented
Status: Active » Closed (works as designed)

Business value field is being used for priorities.

psychobyte’s picture

psychobyte commented

Is there a reason for that? It would seem that you would have to know what the largest or lowest values are in order to set the priority.

If I wanted to set the highest priority issue, i would have to lookup the highest priority value then increment by one. What if I wanted to set the lowest priority issue? I would have to find the lowest value then decrement. What happens at zero? Are we using negative values now? Seems strange.

I don't see people spending the time figuring out where where on the Business Value scale an issue belongs, "Hmmm, should I set the Business Value to 76 or 79?" What does a Business Value of 10023 mean?

Also, what happens when issues are completed. Those Business Values may no longer be used and the scale now has gaps in it.

If I had a preference, giving user's a default set of priority levels is so much simpler.

Kohán Péter’s picture

Kohán Péter commented
Assigned: Unassigned » Kohán Péter
Status: Closed (works as designed) » Needs work

The reason why we use business value instead of priority field is that we have the kanban board support if an issue is set as an agile one.

On the kanban board we have to order the issues, and it is done on the "business value" field.

It is a valid reasoning on your side, that the method of determining the highest and the lowest business value is not an UX friendly way to handle priorities.

The only meaning of an issue with 10023 business value and an other with 76, that where we show the issues on the kanban board.

If an issue is completed, it does not change its business value. We will show that in a different column on the kanban board, and if you do not use the agile option, you can use the different filtering options at the issue list to hide closed issues. But anyway their business values will not interfere with issues in other statuses.

I think that you have absolutely right on the UX side. Because of the agile mindset, I would leave the business value field as is. An option to make it easier to use is to have predefined business values for those, who do not use agile, like: (40 Critical, 30 High, 20 Medium, 10 Low, or whatever) and have an extra field on the UI where you can set these, and hide business value field, when not using agile.

I really appreciate your interest and feedback on IssueQ. Currently we are going through some hard time maintaining it, but I hope we can go on with it soon. Thank you!