I have initially faced problems with identifying & explaining the prioritization of requirements for the project, so I have often used the MoSCoW rules which have helped me to analyze and project the requirements for the prospective client
Must have (Mo): Usually such requirements are classified as essential, without which the deliverable automatically gets termed as unworkable and useless. Their delivery at the end of the appropriate timebox is guaranteed. If any one of these ‘Must haves’ is not ready then nothing can be released: if it could be, then they were not really ‘Must haves’ in the first place.
Should have(S): These are important requirements for which there is a work-around in the short term, or where expectations can be managed. They are things that would have normally have been classified as ‘Must haves’ in a less time-constrained situation, but the deliverable will still be useful and usable without them initially. They would, however, be expected to be delivered soon afterwards, since the work-around is not usually a long term solution.
Could have(Co): These are requirements that can more easily be left out at this point. They may well be included in this delivery if their inclusion is easy to achieve without jeopardizing the delivery of the ‘Must haves’ and ‘Should haves’. A ‘Could have’ may be differentiated from a ‘Should have’ by considering the degree of pain caused by its non-inclusion in terms of business value or number of people affected.
Want to have but won’t have this time round (W)): This refers to those valuable requirements that can wait until later. It is often useful to keep these in the initial priority list, since, although they are not due for delivery yet, knowledge that they will be coming later may influence design decisions and the approach taken to the planning of subsequent deliveries
If you want some perspective on how you or your
company needs to enhance their Sales/Client Management Capabilities,
please email me at shubhanjan.saha@gmail.com
Must have (Mo): Usually such requirements are classified as essential, without which the deliverable automatically gets termed as unworkable and useless. Their delivery at the end of the appropriate timebox is guaranteed. If any one of these ‘Must haves’ is not ready then nothing can be released: if it could be, then they were not really ‘Must haves’ in the first place.
Should have(S): These are important requirements for which there is a work-around in the short term, or where expectations can be managed. They are things that would have normally have been classified as ‘Must haves’ in a less time-constrained situation, but the deliverable will still be useful and usable without them initially. They would, however, be expected to be delivered soon afterwards, since the work-around is not usually a long term solution.
Could have(Co): These are requirements that can more easily be left out at this point. They may well be included in this delivery if their inclusion is easy to achieve without jeopardizing the delivery of the ‘Must haves’ and ‘Should haves’. A ‘Could have’ may be differentiated from a ‘Should have’ by considering the degree of pain caused by its non-inclusion in terms of business value or number of people affected.
Want to have but won’t have this time round (W)): This refers to those valuable requirements that can wait until later. It is often useful to keep these in the initial priority list, since, although they are not due for delivery yet, knowledge that they will be coming later may influence design decisions and the approach taken to the planning of subsequent deliveries
No comments:
Post a Comment