Scrum use Business Value as one of the key pieces of information to base the order of the backlog on.
Jira Agile uses an integer for this, and the value is used in different burndown charts.
Our team has been using business value for quite a while. But it doesn't work that well because it seems very difficult for the product owners to differentiate a 1 from a 2 from a 3 from a 5, etc. So I am wondering if we should start using something more understandable like the MoSCoW terms (http://en.wikipedia.org/wiki/MoSCoW_method).
The question is if I should introduce a new drop down list with these values and set the business value "myself" after the Product Owner has set it using the MoSCoW terms, or if I should replace the business value field with a MoSCoW drop down list.
Any comments to either (or additional)?
I don't see the business value as priority, more of a factor to use when prioritising. I see it more of small value, or great value to the business. (think $)
But alas, I have yet to convince our PO's to start using business value at all, so my opinions might not be worth much. :)
Personally I would go for t-shirt sizes instead of MoSCoW. Like XS, S, M, L, XL. These can easilly be translated a value behind the scenes like 1, 2, 3, 5, 8 if you want.
I'm not sure how this would be better for the product owner. The concept of a t-shirt XL as the most important priority (or XS?) feels a bit strange to me. Have you tried it yourself?
I have a similar problem and my theoretical thought is:
I also see Business Value and MoSCoW as the same thing but the one being Measurable as an integer where the other is more user Friendly.
My ideal configuration would be to be able to assign labels to Business Value so that the user selects a label and the system calculates based on the value of each label.
In a similar way I would organise the story points / units but using T-Shirt sizes
What I don't know is if JIRA allows that kind of customisation but based on my feeling I doubt it.
I am keen to put somthing like that in practice but looking for other people's use cases atm.
I guess it all comes down to what you mean by "calculating". For our part we do not need to calculate anything based on biz. pri - we only need to list. So the information is basically for the ordering of the priorities. Of course - ordering using Moscow would end up with "Could" on the first (or last place), so we kept on using 1, 2, 3, 5, 8 and 13 for biz. pri.
In regards to possibilities - maybe cascading select can give you something - e.g. you choose Must, and when you order it will order based on the primary key 1 of must and not the alphabet. But I haven't tested it myself :)
Atlassian ranks project attributes as the third most important factor impacting performance in the category of data. It’s not surprising, since project attributes are precisely the rules used to ma...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events