January 9th, 2019 by inflectra
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.
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.
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:
According to Agile Analyst Andrew Brian, a good a definition of each would be:
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.
We would recommend the following approach:
Each of the metrics would be using a simple custom list of values (1-10), so create a custom list containing these 10 values:
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:
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:
And if you have any questions, please email or call us at +1 (202) 558-6885