Loading

Prioritized Backlog using WSJF/MoSCoW

Feature Backlog Prioritization Using Weighted Shortest Job First (WSJF)

Cost of Delay (CoD) is the economic impact of a value delivery delay. In other words, it is how much you will fail to make if the product, or feature, is not ready on a certain date. The benefit of using it is to be able to make more-informed and better decisions because you're taking into account the economic impact. The Cost of Delay formula is based on the 3 parameters as shown below.

 

The Cost of Delay analysis will help Product Manager and Architect to do an initial prioritization of the Feature Backlog based on Monetary Value, Competitor Advantage, and Quality/User Experience Improvement.

To utilize this technique, the Product Manager and Architect will use a normal 1 to 10 scale to identify a Feature with an estimated score of 1 for each of the three categories to use as a baseline.

For example, Feature X can have a score of 1 for Monetary Value, Feature Y can have a score of 1 for Competitor Advantage, and Feature Z can have a score of 1 for Quality/User Experience Improvement. A score of 1 indicates that it has the least importance for that category however, it is possible the same Feature will have a score of 1 for all three categories. Once a baseline has been established other Features can then be compared to the baseline and given a relative score.

For example, Feature A has 5 times more Business Value than Feature X, and therefore receives a score of 5. Once a Feature is scored in each of the three columns, then all scores are totaled for an overall score. The Feature with the highest overall score would be given the highest priority in the backlog based on CoD. To further prioritize, Product Manager and Architect will consider institution knowledge and Feature complexity estimate to re-prioritize. In some situations, it better to implement Features that are more complex earlier than smaller ones even if the CoD is the same because this helps to mitigate risk. In other scenarios, its vice versa.

Example 1: Template for Calculating CoD and WSJF

 

Job Size is the complexity of the work (effort, risks, and unkowns), and follows the same 1 to 10 scale to identify a Feature with an estimated score of 1 to use as a baseline.

MoSCoW is a very popular approach to prioritize the Backlog:

It is important that the Product Manager and Dev Team agree to a healthy allocation of work for each Iteration. This will ensure less bottlenecks, resolving risks and dependencies sooner, preventing blockers, etc.

MoSCoW

  • Prioritizes stories into four categories:
    • Must - A story that just has to be made. Release has to be postponed if all Must's aren't done.
    • Should - An important and should be included. However, missing one or two isn't going to prevent release.
    • Could - A nice-to-have feature that can have high value-added for the product.
    • Won't (for now) - A feature that has been shifted out-of-scope for current release or otherwise removed.
  • M's and S's usually comprise into Minimum MarketableFeatures (MMF).
    • Just having Must's done doesn't necessarily make a market-worthy product.
  • A fast tool and suitable for large amount of stories.
  • Important to recognize the difference between Must's and Should's!
  • Can be made from technical or business point of view.
    • Comparing the differences between the two can be Enlightening.
  • When planning releases, a maximum of 70% of size should be Must's.
    • If more, the statistical probability of not getting the release out starts increasing.

 

Example 2: MoSCoW Matrix Template

Example 3: Backlog Prioritized using MoSCoW for development