Units of Work

When I was a physics student one of the things that I learned to do was "unit analysis". That's where you simply consider what units an answer has: is it in meters, or meters squared? Surprisingly, there is an enormous amount that can be learned just by doing unit analysis. Recently, I applied unit analysis our scrum backlog (the process by which my company chooses what tasks to work on) and I learned something surprising.

Unit analysis (also known as "dimension analysis") it a lot more powerful than you might think. The simplest and most common thing it can be used for is to catch simple errors in your formulas: if you find out that the speed is 25 m then something must have been wrong with your formula because speed is measured in m/s. But it can be even more powerful than that: there is a course from MIT showing that even some complex problems ("When it hits the ground, what's the speed of an object that was dropped from a height h?") can be solved to within a constant factor.

There's another important approach that I learned from physics: sometimes effects which are not obvious for "normal sized" values become more clear if you consider the extremes. The extremes don't have to be realistic, they just help you to better understand the problem. A famous example of this was Einstein's thought experiment: "What would you see if you were riding on a beam of light?"

Back in the programming world, my company is one of many that are starting to use agile development methods, particularly scrum. One of the basic practices of scrum is what's called a "project backlog". Basically, this is a list of features to be developed. (We keep one backlog for maintenance plus one for each large project.) The features are broken down so all have reasonable sizes and the "product owner" (a representative of the business interests) ordering the list by business priority. When each scrum iteration begins the scrum team estimates the top items on the backlog and they take on the number of tasks they think they'll be able to complete in that iteration. If business priorities change then the list can be reordered before the next iteration begins.

So the key idea is to break things into bite-sized features and then develop these in order of their business value. Let's apply dimensional analysis to this simple concept.

One interesting question is just what is the definition of "business value"? A few interesting options leap to mind: perhaps it's the net present value of anticipated return from the feature? Or since we practice "managing for value" perhaps it should be a metric that includes cost of capital to better take into account the effect on the company's stock price? For now I won't worry about it: I'm just going to assume it's measured in "business value".

My contention is that "business value" (however that is defined) is NOT the right criterion to use in ordering the features - one also has to take into account the development effort required. To illustrate, I will use a thought experiment. Suppose that there were 20 tasks that needed to be done. Ten of them are new screens that have a business value of 8 and the other ten are reports that have a business value of 6. (Really, business value is never exactly equal, never exactly known, and never a simple small integer, but this is a thought experiment.) Let us also suppose that the screens are very hard: we can only do 1 per sprint, while the reports are easy: we can do them all in a single sprint.

In this extreme case it's obvious we should do the reports first so our first sprint will deliver 60 units of business value rather than 8! The correct units for prioritization is "business value / development cost" not simply "business value". It is acceptable to work with a rough estimate of cost ("small / medium / large / extra-large" would do it) while ordering the list and wait until the scrum kickoff meeting to refine it to a precise number of hours, but if the decision is based solely on business value then we will often wind up working on the wrong tasks.

Posted Sun 30 March 2008 by mcherm in Programming