Written by Isaac Hogue for LeadingAgile.
Value is a funny thing. In enterprise agile coaching, I’m frequently encountering teams that are trying to either (1) complete every single project at the same time because they are all equally valuable, or (2) using a nebulous unit of sorts (say a 100 point scale) to indicate how valuable a work item may be.
In the first case, its usually pretty straight forward to identify that all of the projects are not truly equal in importance and we limit the number of work items to the actual capacity of the delivery system.
In the second case, a team has typically taken my advice and is now trying to figure out what work items are really the next most valuable to the business. Frequently these teams will ask for a value scale, one that helps them to figure out if they need to build item ‘A’ or item ‘B’ next. My answer in this case is almost always a question. It goes something like this:
Me: “Which of the two items have a higher cost of delay?”
Team: “I don’t know, I think item ‘B'; but, if we ask person A or B from some other part of the organization they would probably say item ‘A’.”
Me: “Well, do you know the cost of delay for both items, it should be simple math to choose between them if you do”
Team: “No, we have a guess, but we really don’t know”
It is usually around this time that the teams will start asking for a method or system that can be used to help establish value for work. My answer is usually a bit over simplified; but, then again, perhaps it isn’t. My answer is usually ‘currency’. If the business exists to make money, then the value we are placing on work should always tie back to the potential for currency.
If a team is making tradeoffs based on value, I would like to see how that work item will turn into real money for the business.
What are your thoughts? Have you found any other approaches that work equally well?