January 9th, 2019 by Adam Sandman
No it's not a reference to current geopolitical affairs (luckily), the MoSCoW method refers to a common way of describing different priorities. This article explains different ways customers can manage priorities in agile projects, and how you can use custom reports in SpiraTeam to display calculated prioritization metrics.
Simple Prioritization Methods
The most simple (and common) prioritization method is the numeric ranking that is shipped by default in SpiraTeam:
| Rank | Name |
| 1 | Critical |
| 2 | High |
| 3 | Medium |
| 4 | Low |
Note that we deliberately chose an even number of choices to avoid everyone defaulting to the middle choice. We call this the curse of the middle choice because people tend to choose the middle option as the "safest" choice. So when you have four options, the real choice is between those items selected as High vs. Medium, since 80% of the items will typically be in those two categories combined.
The MoSCoW Method
This method also subscribes to the four choice approach that we advocate, but uses the following descriptive names that are remembered by the MoSCoW acronym:
- Must Have
- Should Have
- Could Have
- Won't Have
According to Agile Analyst Andrew Brian, a good a definition of each would be:
- Must Haves are User Stories that must be included to create the MVP (Minimum Viable Product). Must Haves form the core of the scope of work that will need to be delivered.
- Should Haves are User Stories that are not critical to the MVP, but are considered to be important and of a high value.
- Could Haves are User Stories that are “nice to have.” They could potentially be included where time and resources are available. However, these User Stories will be the first to be removed from scope if the project is at risk of missing delivery of the MVP.
- Won’t Haves are User Stories or Features that the Product Owner has requested but are not going to be built. These User Stories or Features may be built in the future but are not part of the scope of the current work.
Dealing with a Plethora of Could Haves
One of our customers (shout out to Brandon Thomas) had an issue using these simple methods - they had applications with backlogs containing hundreds of “could have” items that they intended to eventually implement through service releases. The problem with grouping items into a priority was that you cannot effectively compare between hundreds of items all listed within a single priority level to sort the list in a meaningful way. So, they wanted to adopt an actual priority metric in those situations to use in addition to a priority level, similar to calculating a risk score (which is something we're adding in SpiraPlan 6.0 by the way). That way, each incident is issued a numeric priority value allowing the group to easily distinguish the most valuable items.
Using this kind of method, the business users define categories to consider when formulating priority for an item (4 categories listed below for example).
|
Scope of Impact |
5 |
|
Degree of Impact |
10 |
|
Urgency |
2 |
|
Difficulty to Implement |
1 |
|
Total Priority Score |
100 |
Each category has a point range or weight (in this example 1 to 10). The business defines what constitutes each score within a category, assess each incident based on their criteria, then multiplies each score together to arrive at an overall priority point value.
This is an example of how Degree of Impact from the above list may be defined:
|
Score Range |
Evaluation Criteria |
Priority Description |
|
1 to 3 |
For Defects/Issues: Severity of the problem is cosmetic in nature, representing a hindrance or pain point. It may reduce productivity slightly but does not prevent work from being conducted
Change Requests/Enhancements: This is a small cosmetic change which would only slightly improve the overall customer satisfaction or usefulness of the product |
Minor severity/business benefit |
|
4 to 6 |
Defects/Issues: Severity of the problem is potentially significant, requiring use of a workaround to mitigate the impact. The workaround may be complicated, costly or only partially effective
Change Requests/Enhancements: This change would be moderately beneficial to the business, boosting productivity, greatly increasing customer satisfaction, or allowing for new business processes to be accommodated |
Moderate severity/business benefit |
|
7 to 10 |
Defects/Issues: Severity of the problem is potentially catastrophic, meaning critical business processes cannot be performed within the application. There may not be a workaround available.
Change Requests/Enhancements: This change would be extremely beneficial, if not required from a business perspective. It allows for a strategic company objective or federal compliance requirement to be met. |
High severity/business benefit |
The existing priority levels such as “2-High” or "Should Have" correspond to priority score ranges in the table.
Implementing using SpiraTeam or SpiraPlan
We would recommend the following approach:
1. Create a Custom List of Score Values
Each of the metrics would be using a simple custom list of values (1-10), so create a custom list containing these 10 values:
2. Create Custom Properties for the Categories
Next we need to create four List custom properties (one for each category) that all use the same custom list:
So when you create it for all four categories:
-
Scope of Impact
-
Degree of Impact
-
Urgency
-
Difficulty to Implement
You would get:
3. Write the Custom Report
Now that you have these three custom properties, you can create an incident that uses the values:
So to get a report with the final score, you can use a modified version of the Incident Summary Report, where you add the following calculated column:
<th>Priority Score</th>
and
<td>
<xsl:value-of select="CustomProperties/CustomProperty[Name = 'Custom_01']/Value * CustomProperties/CustomProperty[Name = 'Custom_02']/Value * CustomProperties/CustomProperty[Name = 'Custom_03']/Value * CustomProperties/CustomProperty[Name = 'Custom_04']/Value"/>
</td>
Which when generated gives the priority score value, along with the individual category values: