How to prioritize tasks based on their value

| by Marta Jasinska Follow 0 Followers on May 18, 2012. Estimated reading time: 1 minute |

Bob Marshall, one of the most vocal agile specialists, has written on his blog last week about what he thinks might be a better way to prioritize and define the tasks for development teams.

In the post, entitled ”The Value”, Marshall, CEO at and, 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.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Pragmatic approach by Dave Nicolette

I appreciate that this ties together good ideas from various sources, and that it is aimed at producing valuable outcomes in a practical way.

Blockages are not constraints by Johnny FromCanada

"constraints - things that prevent it from achieving its objectives... customer blockages"

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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss