DSDM Practice - MoSCoW prioritisation Flashcards
MUST
Minimum Usable SubseT of requirements guaranteed to deliver
- cannot deliver a viable solution without it
- legal/compliance requirement
- unsafe without it
i. e. the project must be cancelled without it
Should have
- important but not vital
- maybe painful to leave out
- may require a workaround without it
Could have
-wanted or desirable but less important
-less impact if left out (compared to should have
These requirements form the bulk of the contingency
Won’t have this time
These are requirements which the project team has agreed will not be delivered (as part of this timeframe). They are recorded in the Prioritised Requirements List where they help clarify the scope of the project. This avoids them being informally reintroduced at a later date. This also helps to manage expectations that some requirements will simply not make it into the Deployed Solution, at least not this time around. Won’t Haves can be very powerful in keeping the focus at this point in time on the more important Could Haves, Should Haves and particularly the Must Haves.
MoSCoW differentiation from traditional projects
-not all requirements are must haves
-project timelines will not shift if all requirements can’t be met
By the end of Foundations the end date for the project and the first project increment are determined
Requirements may have three individual MoSCoW priority ratings
MoSCoW for the project
MoSCoW for the Project Increment
MoSCoW for this Timebox
MoSCoW DSDM recommendations are?
Getting the percentage of project/Project Increment Must Haves (in terms of effort to deliver) to a level where the team’s confidence to deliver them is high – typically no more than 60% Must Have effort
Agreeing a pool of Could Haves for the project/Project Increment that reflects a sensible level of contingency - typically around 20% Could Have effort. Creating a sensible pool of Could Haves sets the correct expectations for the business from the start – that these requirements/User Stories may be delivered in their entirety in a best case scenario,
Must have requirements above 60% create a delivery risk unless…
unless the team are working in a project where all of these criteria are true:
Estimates are known to be accurate
The approach is very well understood
The team are “performing” (based on the Tuckman model)
The environment is understood and low-risk in terms of the potential for external factors to introduce delays
Requirement prioritisation must occur
uncompleted requirements should be reviewed throughout the project to ensure that they are still valid. As a minimum, they should be reviewed at the end of each Timebox and each Project Increment.
New requirements must be rated as they are introduced
MoSCoW priorities and their alignment with the business vision
The MoSCoW priorities are necessary to understand the Minimum Usable SubseT and the importance of individual requirements. The Business Visionary must ensure that the requirements are prioritised, evaluated in business terms, and delivered to provide the ROI required by the Business Case, in line with the business vision.
When are requirements first considered for MoSCoW prioritisation
During the Feasiability phase as the req are aligned to the business case
- revisited during Foundations
- revisited per increment and timebox
