How to order large amount of business requirements properly?

Question

We continuously develop, operate and maintain a hardware-software system. The last year a load of complex business requirement (100-150) is accumulated but unfortunately not processed well. The current goal of our BA-s to prioritize somehow this list and/or add some business value on it. I want to add some intention about the BA-s, how to order this amount of requirements. The client has no KPI assigned to the requirements.

The most promising is the MoSCoW method, but I assume that our client could not be effective this amount of requirements. Is there any best practice how to resolve this situation?

Answer 1

There is a bunch of techniques to prioritize your backlog. Scoring models (value vs effort, value vs complexity, RICE etc), KANO, MoSCoW, adoption of Delphi method (Buy a feature, Cost of delay), yadayadayada.

The successful application of prioritization framework depends from your situation. If you have a dedicated person who can justify all business needs, you should have no any issues. Just give this person title "Product Owner" and explain him Business Value concept.

Your team have pipeline about 100 change requests per year (2-3 per week), most probably you operates with bunch of different stakeholders (hopefully whey are not conflicting). The real challenge is how to align such amount of people around the similar priorities understanding. In my practice in such situations the "Cost of delay" method was most successful. This concept is pretty clear for most of the business people since it's explains everything on their native language. For reference you may check how WSJF matrixes in SAFe have been designed, it's very practical.

Here is good read about existing techniques. https://roadmunk.com/blog/product-prioritization-techniques/

And, btw, congratulations. If someone send you 2-3 change requests per week, it means the business people is really interested in your job :)

Answer 2

If we refer to the list of requirements as a backlog, I think the Agile thing to do would be a series of backlog grooming sessions in which a suitable user representative or business representatives meets with the BAs and the PM to review the backlog. During these sessions, the any irrelevant items from the backlog should be removed, any inaccuracies in the backlog tickets addressed, and the entire thing prioritized based on best guesses if nothing else. Then it is also important to periodically meet to re-groom the backlog as the situation changes. Ticketing software like Jira can help a lot with this sort of thing.

Answer 3

Do you have Product Owner(s) for the backlog? The business stakeholders ought to have ownership of prioritisation. A PO might reasonably delegate some analysis to the BAs but if your BAs are responsible for the actual prioritisation that suggests the business is not sufficiently engaged in what they are doing.

The limitation with MoSCoW is that it gives you only three real priorities to play with. Assuming you have more than three iterations worth of work then you'll have to do prioritisation again for each iteration to decide which Musts, Shoulds or Coulds get done next. That may be seen as an advantage - regularly reviewing priorities is a healthy thing to do. Personally though, I find it more convenient to number priorities from 1-1000, which gives plenty of scope to leave gaps between numbers. It's then easy to renumber priorities only when necessary.

Another problem I have found with the MoSCoW approach is that it can lead to some tricky discussions with stakeholders about what is really a Must or a Should or a Could. Those words may be too overloaded with significance to satisfy some stakeholders. All they should really care about is the much more abstract concept of relative priority, 1 to N...