Hierarchical MoSCoW is a variant of the standard MoSCoW technique that you can use when there are multiple levels of abstraction and distinct sets of functionality in the collection of items you are prioritizing. An example of using this variation would be if you have a feature tree of your solution that decomposes the overall functionality of a solution from a generic set of high-level features, through one or more levels increasing feature detail, down to actual requirements for each lowest-level feature.
The difference between Hierarchical MoSCoW and standard MoSCoW is just like the difference between Hierarchical Cumulative Voting and standard Cumulative Voting. For the
standard versions you are prioritizing ALL items at the same level of abstraction in your items set; whereas with the Hierarchical versions, you are working with clusters of items that have the same level of abstraction, with high correlation amongst the group and low cohesion with other groups.
Like MoSCoW, Hierarchical MoSCoW still only provides a nominal-scale result. And unlike Hierarchical Cumulative Voting, Hierarchical MoSCoW does NOT really let you make meaningful comparisons of items at the same level of abstraction which are in separate groups.
See the Prioritization wiki page for a discussion of why to prioritize.
However, the major advantages of Hierarchical MoSCoW is that it can be relatively easily applied to even large items sets for prioritization; and by breaking the items into discreet sets (of features, functions, etc.) at increasing levels of abstraction, stakeholders can focus their attention on limited numbers of items without being overwhelmed by having to analyze all items at a single level of abstraction at once. This allows stakeholders to provide a relatively high-level of nuanced prioritization information.
Unlike Hierarchical Cumulative Voting, Hierarchical MoSCoW provides a nominal-scale result, unlike the more detailed ratio-scale result of HCV. However, unlike HCV, Hierarchical MoSCoW is not subject to
gaming by stakeholders; can be repeated by the same stakeholders on the same set of items as often as possible; and can be done as a collaborative exercise among stakeholders rather than the individual efforts that are required for HCV.
This assumes you have evaluated your prioritization needs and decided that Hierarchical MoSCoW is the technique you will use.
Working with all stakeholders involved in the prioritization process, review and refine the proposed prioritization process. This includes such factors as what items will be prioritized, the levels of abstraction that will be used, the criteria for assignment to a category, and how the decision to assign each item to a category will be decided if there is more than one person making the decision (voting, priority poker, etc.).
This information should be documented and approved by all stakeholders involved in the prioritization process. As a best practice, it is also a good idea to have all stakeholders who will consume the output of the prioritization process to review the criteria as well. The criteria documentation should be included with the prioritized information so that future consumers will understand what criteria where applied for prioritization category assignment.
Define the escalation process that will be used if agreement cannot be reached on the appropriate category that an item should be assigned to. This can include any standard conflict resolution process such as voting, sponsor over-ride, or any other mechanism that stakeholders and the project team can agree to. Defining the escalation process ahead of time should help prevent the prioritization process from getting bogged down or stuck on issues where there are conflicting priorities.
Define the exact set of items that will be prioritized and gather them together in a form that allows them to be easily reviewed. For Hierarchical MoSCoW this often means creating at least two artifacts:
The diagram below is a highly simplified (and partial) example of the visual component, representing the features of a retail shopping web site.
Decide where the prioritization decision will be recorded and how.
With the stakeholder(s) involved, begin the prioritization process by going through the items one set at a time, starting with the highest level of abstraction. Within each set, the items should be evaluated one-by-one and assigned a prioritization category. All items should default to the
Won't Have category initially, with the stakeholder(s) having to justify why the item should be a higher priority.
The MAJOR difference in this step versus what is done with regular MoSCoW is that the prioritization is done ONLY in context of the current group and level of abstraction.
So using the example diagram above, I would start at the top level and apply MoSCoW priorities to those six items I might rate 3 (Product View), 4 (Shopping Cart), and 5 (Purchase) as Must; 1 (User Information) and 2 (Product Search) as Should, and 6 (Inventory Management) as Could.
Challenge all attempts to prioritize at the
Must level. Based on the criteria defined in Step 1 above, the stakeholder(s) should be able to articulate why the item should prioritized at this level (for example: there is no manual work-around, the resulting solution would not be legal, etc.).
As each item is prioritized, the prioritization category should be recorded in the place and manner agreed up on Step 5 above.
Continue through the groups successively, continuing to move from higher levels of abstraction to the next lowest level. Evaluate all groups at that level of abstraction before moving on to the next level of abstraction.
Again using the example diagram, the next level of abstraction below the top-level are those with an
x.x number format. And each group is clustered under it's
parent item (1.x, 2.x, 3.x, etc.). So if the Product Search sub-group (2.x) is the next group to prioritize, I might prioritize them as:
Note that although 1 and 2 are
Must as far as the Search feature is concerned, as far as the overall initiative is concerned their priority is no higher than
Should because that is what the top-level feature is prioritized at.
After all items have been prioritized, go back through all items again (in summary form if necessary) and give prioritizing stakeholders the opportunity to change the prioritization levels of each item due to discussions and information reviewed about groups and items in the first round. This gives stakeholders the opportunity to adjust priority levels to reflect their greater knowledge of the items after the first pass and ensures no items have been missed.
Continue to re-evaluate the prioritization assignments as the situation changes. New items being added to the list, changes in the operating environment (such as changes to the project budget, scope, and timeline), and new information (such as different solution options) may all require a prioritization assignment to be changed.
Using the example diagram above, what Hierarchical MoSCoW lets you do is say is something like:
We SHOULD build a search feature. But IF we do build one it MUST support Search by Keyword and Product; it SHOULD support Search by inventory status and combinations of all other search options; and COULD support Search by Price.
And if appropriate, you can continue the process onto the next level of abstraction such as what is meant by a Search by Product feature. And possibly on to another level. Until you have reached a level of detail and prioritization that achieves your goal.
Criticalmean. Achieving group consensus on definitions and criteria can be challenging.