Tutorial 3: MoSCoW rules (Hoang Tuan Long and Vuong Tan)

Question 2. MoSCoW rules

a. Using the MoSCoW rules discussed in class, prioritise the above requirements into one of the four categories.

1.      Customer database – customer data entry, querying and updating

2.      Quotation database – data entry, querying and updating of premiums

3.      Quotation screens – enabling telesales staff to quote prices to customers

4.      Phone acceptance of insurance policy (and ensuing processes)

5.      Printing of insurance certificates and insurance schedules

6.      Automatic printing of renewal reminders

7.      Phone acceptance of renewals

8.      Automatic printing of payment reminders

9.      Phone acceptance of payment via credit/debit cards

10. Management reports detailing daily/weekly/monthly premium sales

11. Management reports detailing new customer business v. existing customer renewal

12. Management reports profiling customer type/motor vehicle type/type of insurance

13. Automatic back-up of database on a transaction-by-transaction basis

14. Telesales security system with graded access to system functionality

MoSCoW prioritization

Must	Should	Could	Won’t
1,2,3,4	5, 7, 9, 13	6, 8, 10	11, 12, 14

The requirements 1, 2, 3, 4 must be MUST HAVEs. Obviously, customer and quotation are the two objects this telesales system is all about, therefore customer and quotation datababase is very crucial to the main operation. On top of that, the core business requirements of this system are to enable the telesales staff to quote prices to customers and for customers to accept the insurance policy, which is why requirements 3, 4 belong to the MUST HAVE. There is no point in implementing a telesales system which does not meet these requirements.

The SHOULD HAVEs of the system are 5, 7, 9, 13, because the system can work without them (the telesales still can quote prices to customers and customers still can accept the insurance policy by phone) and moreover these requirements really affect the business case. The phone acceptance of renewals or the phone acceptance of payment via credit/debit cards are the absolutely necessary functionalities for customers if they want to renew their insurance or make payment, so why are they not in MUST HAVE? It is because this system is urgent as the scenario describes; the renewals will not happen in couple of months, and there are many other ways to make payment, so they can wait.

The requierements 6, 8, 10 belong to COULD HAVEs, simply because they don’t really affect the business case here. The management reports detailing daily/weekly/monthly premium sales kinda help figure out good and bad points of the current sales activities, thus the system could have this function. We can say that these requirements are additional features it is nicer to have them.

Finally, there are requirements 11, 12, 14 in the WON’T HAVEs. These requirements have very little business value and the system does work really fine without them.

b.  Do you think the MoSCoW rules are an effective way of prioritising functionality?  What problems (if any) do you perceive with using this approach?

I think MoSCoW rules are an effective way of prioritising functionalities because:

·        They help indentify the functionalities which bring the most business value.

·        They help indentify the most important functionalities earlier, so developers can do them first.

·        They help indentify the functionalities which bring less business value, so developers can consider doing them later or not at all.

·        They help reduce confusion of different options from stakeholders because they force all the relevant stakeholders (customer, product owner, project sponsor and users) to be in one place to talk through their different options on what to be done and eventually reach the final agreement of prioritization.

However, we may encounter the problem of not being able to balance the 60% effort for MUST HAVEs and the other 40% for SHOULDs and COULDs. Once the requirements are placed in the MUST HAVE category, it is likely that the efforts invested in these requirements are too many and enough to take up almost all the project time. Eventually, the MUST HAVE functionalities are delivered perfectly, but maybe there are no functionalities coming from SHOULD or COULD HAVEs. This means we only bring out a system that works, not stably and beautifully works. Furthermore, this technique is supposed to prioritize functionalities, not removing them off the list like that. In conclusion, it is recommended that no more than 60% effort for MUST HAVEs for a project, with 40% SHOULDs and COULDs. Anything higher than 60% poses a risk to the success and predictability of the project, unless the environment is well understood, the team is established and the external risks are minimal.