Hierarchical MoSCoW Prioritization

IMPORTANT! If you are going to use any prioritization method, be sure that you actually implement more than just the highest level of priority items. If stakeholders consistently see that all that will implemented are the highest priority items, then soon they will stop believing that priority levels mean anything and that everything that is not flagged as the highest priority will not get implemented. And if that occurs, then either everything your clients prioritize will be the highest priority or they simply will no longer cooperate because they have lost confidence in the process.

 

NOTE: Hierarchical MoSCoW is (as far as I can tell) my own idea. I don’t think it's a revolutionary idea and it's entirely likely someone else has written about this before. I just can't find any indications that they have. I had the idea when I first came across Hierarchical Cumulative Voting and thought of a way to leverage that approach to MoSCoW. I had often had the problem of trying to communicate that … Yes, item B is prioritized as MUST, but it is only a MUST IF you include feature J which is classified as a SHOULD. I've tried it out a few times with select stakeholders and received good feedback, but it does add a layer of complexity over standard MoSCoW that requires a slight shift in thinking. Your feedback and suggestions would be appreciated. Or if someone else has already written about this, please point out their work so that I can incorporate and cite it.

 

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.

Step 1

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.

 

Step 2

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.

 

Step 3

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.  

Step 4

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:

  1. 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.]
  2. 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.

  Example - Hierachical MoSCoW Prioritization  

Step 5

Decide where the prioritization decision will be recorded and how.

 

Step 6

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.

 

Step 7

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.).

 

Step 8

As each item is prioritized, the prioritization category should be recorded in the place and manner agreed up on Step 5 above.

 

Step 9

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.

 

Step 10

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.

 

Step 12

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.

 

Advantages

 

Disadvantages

 

Tips

 

References

  1. Blog Post: MoSCoW Anxiety. By Ivar Jacobson International.   March 1, 2012.
 

Related Resources