How to prioritize tasks based on their value
In the post, entitled ”The Value”, Marshall, CEO at Dyphoon.com and NewsMice.co.uk, explains how he, together with the late Grant Rule, who functioned as managing director of the SMS Ltd, worked on the “teachable method of assessing business value”. The idea was to provide product owners with tools that can make prioritization easier and much more beneficial to the whole organization. Since both Marshall and Rule were supporting different ideas of team organisation - FlowChain and SlamIT - they wanted to agree on a method fit for both systems.
Marshall has based his proposition on the Theory of Constraints (TOC) by Eliyahu Goldratt, a business management expert and the author of "The Goal". According to the TOC in every system there is at least one and at most a few constraints - things that prevent it from achieving its objectives. Marshall argues that in software development the goal is to release features that the user (customer) can utilise to achieve his goals. On a higher level it means that the aim of development is to remove customer’s constraints. Marshall concludes that only the tasks that are removing said constraints are of value and as such they are of highest priority to the product owner.
There are situations when customer blockages can not be resolved by software. Marshall argues that the development process should stop at times like that and wait until the constraint is removed by another part of the system. Identifying the most immediate issues the customer is facing is not easy, even when there is a close relationship between the development team and the users.
There are of course other techniques of prioritization, like the MoSCoW Method, the Nominal Group Technique and others. What makes Marshall’s proposition different is the assumption that at any time you can pinpoint the one task which brings value to your business.
Blockages are not constraints
Constraints or bottlenecks are restrictions on flow, but not outright blockages (in Lean). I believe David Anderson makes this point clear in the book "Kanban". Despite this slight liberty of language, the point of the article still stands.
The key insight is that your software solution is really just a part of a whole customer system, which is the higher level at which any Lean investigation should be looking. So the real challenge for a software vendor lies in identifying & prioritizing the set of constraint scenarios that optimally or at least reasonably covers the problem space of your entire set of customers. No small feat.