These are the requirements that provide the main pool of contingency, since they would only be delivered in their entirety in a best case scenario. Less impact if left out (compared with a Should Have).One way of differentiating a Should Have requirement from a Could Have is by reviewing the degree of pain caused by the requirement not being met, measured in terms of business value or numbers of people affected. The workaround may be just a temporary one management of expectations, some inefficiency, an existing solution, paperwork etc. May need some kind of workaround, e.g.May be painful to leave out, but the solution is still viable.Categorising a requirement as a Should Have or Could Have does not mean it won’t be delivered simply that delivery is not guaranteed. If there is some way around it, even if it is a manual and painful workaround, then it is a Should Have or a Could Have requirement. Cannot deliver a viable solution without itĪsk the question ‘what happens if this requirement is not met?’ If the answer is ‘cancel the project – there is no point in implementing a solution that does not meet this requirement’, then it is a Must Have requirement.No point in delivering on target date without this if it were not delivered, there would be no point deploying the solution on the intended date.These may be defined using some of the following: These provide the Minimum Usable SubseT (MUST) of requirements which the project guarantees to deliver. The specific use of Must Have, Should Have, Could Have or Won’t Have this time provides a clear indication of that item and the expectations for its completion. There may be prolonged and heated discussions over whether an item should be one place higher or lower The use of a simple sequential 1,2,3,4… priority is weaker because it deals less effectively with items of similar importance.A categorisation with a single middle option, such as medium, also allows for indecision Nor does this categorization provide the business with a clear promise of what to expect. The use of a simple high, medium or low classification is weaker because definitions of these priorities are missing or need to be defined. ![]() It also overcomes the problems associated with simpler prioritisation approaches which are based on relative priorities: The use of MoSCoW works particularly well on projects. MoSCoW is a prioritisation technique for helping to understand and manage priorities. (User Stories are a very effective way of defining requirements in an Agile style see later chapter on Requirements and User Stories for more information.) Prioritisation can be applied to requirements/User Stories, tasks, products, use cases, acceptance criteria and tests, although it is most commonly applied to requirements/ User Stories. In a DSDM project where time has been fixed, it is vital to understand the relative importance of the work to be done in order to make progress and keep to deadlines.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |