MoSCoW is a technique for helping to understand priorities where a projects time has been fixed, understanding the relative importance of things is vital to making progress and keeping to deadlines. MoSCoW allows prioritisation to be applied to the required tasks and meet the requirements set out by the client. For the team instead of saying a problem is high or low importance and priorities MoSCoW has a specific uses like Must, Should, Could or Won’t.
- Must Have
- Should Have
- Could Have
- Won’t Have this time
Have that implies when the result that are produced it will meet these constraints and demands set out in this section. For the client it states what the product will consists of providing a way to determine whether a project has been a success or failure due to if the set out MoSCoW priorities have been met.
An example of this could be an apple and shows how an apple has to meet the demands of the client (consumer). This can be applied to any client who has requirements and demands to be met.
- Must – be the fruit Apple
- Should – Be Edible
- Could – Be red
- Won’t – be a Banana
In developing the idea with the clients we have been asked to outset a MoSCoW initially as a discussion between the group and clients. This will allow us to determine the expectations of the project. This will then give us the opportunity to justify if our project was a success depending on if we meet the demands of the outset MoSCoW.
Must: Describes a requirement that must be satisfied in the final solution for the solution to be considered a success.
- Must use the High resolution Magna Carta image within the application. Large zoomable image where users can see the small details in the document.
- Must have a translation of at least the key clauses from Latin into English.
- Must have specific details about the document such as explanations of abbreviations and crossings out.
Should: Represents a high–priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if strictly necessary.
- The application should be made and optimised for an iPad.
- We should make it to be displayed in the Cathedral chapter house as a digital installation.
- We should use default gestures that are recognised by everyone to zoom into Magna Carta image, swipe gestures to access different parts of the application.
- We should have a variety of description of the clauses for different age ranges.
- Some supporting media (image) for each clause.
Could: Describes a requirement, which is considered desirable but not necessary. This will be included if time and resources permit.
- We could make it so it can be used in an iPhone/Mobile but realistically it would be too small to look on a phone.
- We could make different translations of the document (Limited to what translations the cathedral already has)
- Could have a range of multimedia to support the clauses (video, audio)
Won’t: Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future.
- We wont have the Magna Carta image as the centrepiece of the application with hotspots imbedded as clauses.
When the project progresses further and the MoSCoW will be updated if any of the factors change due to client impact. Project development could also impact the outlined MoSCoW. Prototyping and testing could force it to be changed. At the point where the client and group both feel the MoSCoW is achievable there will be no further changes made as this is the requirement that both are expecting to meet.
Dsdm.org, 2015. 10. MoSCoW Prioritisation | DSDM CONSORTiUM. [online] Available from: http://www.dsdm.org/content/10-moscow-prioritisation [Accessed 18 Mar. 2015].
Update: Updated Moscow