Prioritisation of requirements has always been important. Even more so in Agile projects. This is because in Agile time is fixed and it is scope that is more flexible.
The timebox nature of Agile methods such as Scrum and Atern mean that it is important that the whole team understands the priorities and has the same understanding of what the priorities mean. Prioritisation is therefore vital to making progress on the right things and enabling the meeting of deadlines that results in successful delivery.
Prioritisation can be applied to many aspects of a project including requirements, tasks, products, use cases, user stories, acceptance criteria and tests. Typically, it is usually applied to Product Backlog items/User Stories that represent the requirements or features that are to be implemented.
One of the most popular prioritisation methods within Agile projects is the MoSCoW technique. The acronym MoSCoW stands for Must have, Should have, Could have and Won’t have this time. With the o’s having no meaning in the acronym.
The definitions of each of these four priorities is defined as follows:
Must have
- Essential features without which the end product would be unusable (Minimal Usable Subset)
- Product cannot be delivered or released without all of these having been completed
- Delivery on target date without these features does not constitute a successful delivery
- If there is a manual way around the absence of a Must have item then it should most likely be reclassified as a Should have
- Requirements that if not delivered would result in an solution that is unsafe or not legal should be considered Must haves
Should have
- These requirements are important but not vital
- Leaving them out may result in manual workarounds that have additional costs or inefficiencies yet the deliverable would still be beneficial and useful without them
Could have
- Wanted or desirable items that are less important than
- Nice to haves
- Leaving these out should have less impact compared to Should have items
Won’t have this time
- This list contains all the requirements that won’t be included at the present time
- Recorded so that requirements are captured for future iterations and deliverables
- Logging these items helps prevents scope creep later on as it helps to clarify the scope of the project and the iteration
Downgrading requirements from Must have to Should have does not mean that they won’t be delivered it simply means that their delivery in this iteration is not guaranteed. All those involved in a project must ensure that they do not assign everything to the Must have priority as this will almost certainly lead to failure as there is no contingency present so if anything, even something minor takes longer than expected or if a team member is off sick for even a short period of time then the iteration would fail to deliver on its Minimum Usable Subset.
Atern advocates that each iteration within a project should be made up of the following proportion of each priority level:
This ensures that there is sufficient chance of achieving the Must have (Minimum Usable Subset) features, even if Should have, and Could have are not achieved. The team will therefore focus on the Must have features first to ensure the best chance of success, if any of these take longer to implement that expected or if other issues arise that could affect the ability to deliver all of the features then it is the Could have items that are first to be dropped from this iteration.
MoSCoW allows three potential outcomes to be identified at the prioritisation stage, the best outcome being the delivery of all Must, Should & Could have items, the worst case being that only the Must have items will be delivered within the iteration and the most likely outcome being the delivery of all Must have items and most or all Should have items.
Expectations should be set that the stakeholders in the project should expect to receive most likely outcome… all Must have items and most or all Should have items. Consequently project team members should also be expected to commit to delivering all Must have and most or all Should have items within the timeboxed iteration during iteration planning sessions so long as the estimated work fits with the available duration of the iteration.