Focus on value is at the very core of the agile mindset. There is neither a method nor paper which does not emphasize it in different contexts. For example:
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” – 1st Principle of Agile Manifesto
“The Product Owner is responsible for maximizing the value of the product and the work of the Development Team” – The Scrum Guide
“[…] there is no doubt that focusing on the 20% of the features that give you 80% of the value will maximize the investment in software development and improve overall user satisfaction.” – Standish Group Chaos Report
In general, doing less valuable work or producing less valuable items is (at least partially) considered to be a wasteful activity. Thus the need to pinpoint those most valuable items and put them on top of whatever list is used to track them (e.g. product backlog). This ordering or prioritizing valuable items is essential activity and it really depends on what an organization or customer perceives as “valuable”. What value actually means to them should be defined as well, prior the prioritization takes place. However, is it enough to know just the value? Let’s see…
When talking about prioritization, there is, of course, a default High-Medium-Low prioritization technique (or whatever alternative names might be in different cases). The concept is a very simple one – just use “High”, “Medium” and “Low” buckets (“HML buckets”) to categorize the features in the backlog. In reality however, segmentation of this kind is close to wishful thinking. It is very hard to classify features (or requirements for that matter) without a bias. Often, the attention to value is lost in the process altogether. In addition, different actors have different understanding of what “high priority” means, so most of the time, people tend to categorize their own items as “high priority” items, so the very purpose of the categorization is quickly lost.
Note that this is the length which is usually covered with the one- or two-day Scrum trainings.
A very effective way to mitigate this pitfall is to actually give meaning to HML buckets, so that different actors have a shared understanding of what the class actually means. DSDM (Dynamic Systems Development Method) people have understood this very early, so they came up with a well-known MoSCoW technique. It is a well-known and effective technique to define the minimal feature set (or set of requirements) for the product. The basic idea is in the notion that not all the features are equally valuable to the customers. So, using the technique, we categorize our MUST haves, SHOULD haves, COULD haves and those items we WOULD like to have in the product (hence the acronym – MoSCoW). This way, all those “high priority” items suddenly might not seem so high priority after all if they are not essential for the product (“must have”). By using the method, we form a safe and stable space for building a meaningful increment and give a powerful tool to business people to optimize the ROI (return on investment). Notice how it is all possible by just simply changing the wording (i.e. names of prioritization classes).
This is the most frequent situation I encounter when working with fresh or inexperienced Product Owners (or whatever synonym is used within an organization – Product Manager is the usual one).
Although it is a significant improvement in sense of prioritization, it seems that the same question still remains – How do I prioritize items within the single category (e.g. How do I order “must haves”)? What do I do with items that have the same value?
The solution might be in adding one more dimension.
Prioritization Framework (a.k.a. Value-Complexity Matrix)
In one of the recent companies I had been consulting, I started off with Product Owners working with one-dimensional product backlog. I watched them struggle with prioritization, and how far MoSCoW reaches. During one of our coaching sessions, while looking for solution to the issue, I hinted that backlog doesn’t need to necessary have just one dimension. Brainstorming went further to the idea that if we add a complexity dimension to our list of business-valuable items (i.e. product backlog), we end up with two-dimensional matrix, which we could use as a prioritization framework.
Since we already had items roughly ordered by their projected business value, we could rather quickly position them on the matrix, using their estimated complexity as shown below:
It was much clearer how to choose between the items and prioritize them further.
Note that there are four sections within this matrix. The following two are obvious choice:
- high value / low complexity – normally, you would want to do these first; they require the least effort and will provide maximal value; items in this category are so-called “low-hanging fruits”, so you want to get them first;
- low value / high complexity – you want to avoid this; it traps you in endless complexity without providing any significant value, thus hurting ROI.
The other two sections are debated a lot, and are a bit trickier than the former two:
- high value / high complexity – difficult but valuable;
- low value / low complexity – could quickly be done, but have low value.
I’ll come back to them quickly, I just want to stress another important thing before that. Notice that the framework is fractal in nature, meaning that the same splitting mechanism could be applied to any of the sections, infinite times. This has two great side-effects:
- you can apply the same prioritization principles within each of the sections;
- you don’t have to choose the whole section over another.
By applying the principle, we ended up with something similar to the following example. It illustrates nicely how you can prioritize each individual item and what to do with those tricky, high-value/high-complexity and low-value/low-complexity sections:
To make another relation, note that this might seem awfully similar to the PACE prioritization matrix – and it is, since it is a variation of it. The same fractal principle can be applied to the lower sections of the diagram as well, bringing some of the areas of low-value/high-complexity section into play, especially those near the centre area. If you keep applying the principle, you would end up with the diagram as shown below:
Now it seems really easy to categorize and order the items. Essentially, the POs reinvented the approach, but it was well worth it – they understood it from the inside out and wholeheartedly adopted it, effectively using it to the business benefit.
The approach we had taken is very effective and well-proven in daily practice. Whether you go with PACE or do a quick value-complexity breakdown, you will gain a perspective and be able to distinguish between the items. It also helps both avoiding the product management trap and maximizing ROI. However trivial it might seem, it is a valuable addition to every PO’s toolbox.
