Is it always possible to compare magnitudes? Let’s take a look at the diagram.
Let A, B, and C are tasks, and let x and y are the benefits obtained by the task. Suppose your customer requested to add a feature to your software product. If you add the feature, the source code becomes complicated, but the customer satisfied. On the other hand, if you use the time for refactoring to clean complex source code, maintainability of the source code improves, but customer satisfaction does not rise. In the figure, A is to add the feature, B is refactoring, and C is a task of doing both at the same time. The axis x is maintainability, and the axis y is customer satisfaction. Which task should you do?
There is fluctuation in the concept of magnitude. There is a simple definition for one-dimensional values, and as many people agree with it, it is unlikely that opinions on magnitude inconsistent. Which do you think is bigger, 2 or 5?
However, for the values of two or more dimensions, there is no such magnitude with that everyone agrees. If you ignore x with emphasis on y, A is the most important task. If you ignore y with emphasis on x, B is the most important. If you think C is the most important when considering x and y as important as x + y. If you think x and y are equally important, that is you compare the tasks according to x + y, C is the best. If you think x is twice as important as y, that is you compare them according to x * 2 + y, 5 * 2 + 2 == 4 * 2 + 4, so B and C have the same importance.
Jonathan Rasmusson introduces the “trade-off slider” method in the book “Agile Samurai” *7. This method is a way to talk with team members beforehand which axis takes priority when multiple axes are a trade-off. Sometimes the team members do not have time to do all the tasks, and they have to choose tasks to do. By talking in advance, you can avoid taking time to discuss which task to prioritize in the timeless situation.
However, this trade-off slider is not universal either. Let’s see the figure again. Suppose that there is no time to release your product and you can do only one of A, B, and C. If you decide to prioritize x in advance, task B is chosen. If you prioritize y, task A is chosen. In either case, task C that satisfies both benefits moderately is not chosen. Is that really OK? Is the pre-determined priority appropriate? How about to release the product with task C and then observe the customer to determine appropriate priority?
This argument assumes that task importance is independent. However, it is not so in real software development. For example, the following phenomenon occurs.
- After we did task D, the benefit x of task A increases.
- After we did task E, the implementation cost of task B decreases.
- It is easier to implement tasks F and G by one person than to implement them separately.
Tasks in the real world depend on each other and are complicated. So it is difficult to prioritize in advance.
Footnotes:
- *7 Rasmusson, J., 2010. The Agile samurai: how agile masters deliver great software. Pragmatic Bookshelf.