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.
