What is it?
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.
Why do it?
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.
How do I do it?
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 prioritization context that will be used. Are you prioritizing for one of a sequence of releases? A single major development effort? For highest business value? To greatest efficiency? Is there a specific time-frame that the prioritization is being considered for? Like the assignment criteria in Step 1 above, this should be documented and kept with the prioritized items.
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:
- A Feature Tree or similar diagram that visually breaks-down the items being prioritized into the appropriate levels of abstraction and groups. [This is not necessary, but the visual structure is very useful to stakeholders and those who will review the prioritization results.]
- Depending on the level of information you have on the items being prioritized, you may also want to create an associated document (index cards, Word document, Excel document, sheets of paper, etc.) that has the detailed information for each item clustered in the same way that it is represented in the diagram. This way participants can easily reference more information (assuming it is available) about the items they are prioritizing.
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:
- 2.1 Search by Keyword (MUST)
- 2.2 Search by Product Category (MUST)
- 2.3 Search by Price (COULD)
- 2.4 Search by Inventory Status (SHOULD)
- 2.5 Search by Multiple Factors (SHOULD)
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.
What Should the Results be?
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.
- Like standard MoSCoW, Hierarchical MoSCoW is among the best techniques to use when there are a large number of items (50+) to be prioritized. And it is among the few techniques that is viable when there are a very large number of items (100+) to be prioritized.
- Like standard MoSCoW, it is often easier for stakeholders to use than other prioritization techniques that may require stakeholders to define just how much of a higher priority one item versus another, with each item being compared to every other item.
- Unlike standard MoSCoW, Hierarchical MoSCoW allows items to be prioritized within a specific context (the abstraction level and group) rather than all items at a single abstraction level having to be prioritized with no other context.
- Stakeholders may have concerns about prioritization in general, which the terms used in MoSCoW can enhance. See reference below for a post from Ivar Jacobson International discussing this and a possible way of attempting to mitigate it.
- Ensuring a common understanding of exactly what criteria should be used for assigning an item to a particular category can often be difficult. Stakeholders often have their own internal understanding of what terms like “Must”, “Should”, “High”, and “Critical” mean. Achieving group consensus on definitions and criteria can be challenging.
- As with Hierarchical Cumulative Voting, it is worth noting that the structure used for Hierarchical MoSCoW is very similar to a feature tree. So including a feature tree among your elicitation work can give you a big jump on using either Hierarchical MoSCoW or Hierarchical Cumulative Voting as a prioritization technique.
- Blog Post: MoSCoW Anxiety. By Ivar Jacobson International. March 1, 2012.
- Research Paper: A Comparison of Nine Basic Techniques for Requirements Prioritization. By Mikko Vestola. Helsinki University of Technology.
- Wikipedia Page: MoSCoW Method. Accessed June 9, 2013.
- DSDM Atern Handbook. MoSCoW Prioritization. By the DSDM Consortium. Accessed on May 20, 2014.
- Article: First Things First – Prioritizing Requirements. By Karl Wiegers. Software Development. September 1999.
- Book Chapter: Requirements Prioritization. By Patrik Berander and Anneliese Andrews. In Engineering and Managing Software Requirements. Edited by A. Aurum and C. Wohlin. Springer Verlag. 2005.