Dimensional Planning
From dirt road to flying cars
In Scrum the Product Backlog is an ordered list of features. Unfortunately the linearity of the ordered list is not consistent with the way us humans think about problems. Problems even in the business space are multi-dimensional. So, we probably also should think of solving our problems in multiple dimensions. This is where Dimensional Planning comes in handy when splitting Product Backlog Items in your Product Backlog during the Refinement or Grooming meetings.

There are different comfort levels to which we can solve a problem. For example, the first online shops merely re-sold items on the internet from the local shops around their home-town. The next step involved building a warehouse and getting in touch with suppliers directly. This is an example of the multi-dimensionality of the underlying business problems. First, you have to satisfy a smaller user base. After that you can use the money you already earn to solve the business-to-business problem in your backend in order to be able to scale.

In this article, we’ll use an analogy to illuminate how we might split up a Product Backlog item, and providing more and more value as we go. When traveling, people first started with a rough dirt road to get from A to B. After quite some time when you wanted to go by horse wagon, a cobblestone road was constructed - certainly not comfortable, but one step more comfortable. Nowadays we see asphalted roads, and large highways with even more comfort at each of these stages. While breaking down a Product Backlog Item we might also realize that there are areas which look more closely like a flying car: to some extent science-fiction, and we certainly need to do some more research before being able to build it. Let’s take a deeper look into each of these different dimensions, and how we could split a larger feature down in this analogy.

Dirt road
A dirt road is a little road that started to exist since people wanted to go from A to B. Beyond the first explorer who discovered B and came back, as more and more people walked to B, more and more of that path became more and more obvious.

A dirt road for a software system is one step further than a spike solution. In a spike solution, we produce code to explore a solution for the underlying - and throw away that code afterwards. A spike solution helps us learn about the underlying technology, or the business problem. On purpose we throw away the code afterwards, since the sole purpose of a spike solution is the learning.

But a dirt road in a software system makes use of that learning. After solving the problem on how to identify with the remote billing system, we can build a first connection to that system, and submit data to it. Another way to implement a dirt road in software was used by early internet shops. They offered products they bought from local shops nearby, and simply re-sold them over the internet. The whole process behind the curtains though was manual and uncomfortable. Still customers could get their products.

Cobblestone road
Since people started to tell great tales of B, more and more people wanted to go from A to B. They eventually started to extend the dirt road to a cobblestone road to help the families that wanted to move their stuff to B permanently help getting there.

A cobblestone road in software often shows rough edges. For example for a password changing feature the validation logic for secure passwords may be missing in the first go. Users then may be able to use rather short or rather simple passwords. Another example for this was the missing copy-and-paste functionality in the first iPhone series as well as the missing cellular services in the first iPad series.

The cobblestone implementation often is a bit more comfortable than the dirt road implementation, but it’s still far from being perfect. Most of the time a cobblestone implementation is used to receive early feedback about a rough feature, and generate some early revenue with early adopters. The implementation will be sufficient to get going, but probably not satisfying enough to stay in the market in the long run. That’s why we will need an asphalted road sooner or later.

Asphalted road
An asphalted road provides better driving comfort for any car driving on it. Building and creating it causes a lot of sweat and work before we can open up the road to the public. In the long run though citizens will appreciate the effort we put into the asphalted road.

In comparison to the cobblestone road, an asphalted road in software will provide necessary and useful validation logic for inputs from its users. We will make sure that the majority of our users will feel great about using it.

But as in road construction work, an asphalted road surely needs maintenance from time to time. That is when we need to update our well implemented feature to fit the world two years from now. That said, we probably don’t want to build all of our cobblestone roads into asphalted roads, but we surely want to build the majority of our core functions in this manner.

But for our product to compete on the market, we also want to have a unique selling point, or even several of them. We should therefore think about building a highway for these features.

Highway
A highway consists of multiple lanes where people can drive in parallel and reach their goal in the fastest way possible. Often we find premium services like the fast lane on highways, or that trucks are not allowed to overtake cars. But a highway also needs more maintenance effort, and especially with construction work special speed limits and delays may be in place, eventually leading to traffic jams.

 The highway in our software consists of the deepest and most rigorous feature implementation that we can think of. A highway should also provide the biggest comfort in terms of efficiency and usability. That said, we need to put more investment into building and maintaining it. That’s why we are unlikely to end up with a system consisting of highways all over the place.

But a highway is surely not the place to end our thoughts. There might also be some things that we want to incorporate for tomorrow. Usually these come in terms of future ideas that we are not able to realize, yet: flying cars.

Flying cars
The first flying car will probably provide a lot of comfort to its user. With it you will be able to avoid the majority of the traffic jams on the ground, and will reach your destination in the most efficient way possible. But we shouldn’t forget that flying cars right now are science-fiction, and we probably won’t be able to build them in the close future.

You have to walk before you can run. That said, you probably need to create a walking skeleton [Coc2006] implementation first, then add some more flesh to the corpse to stabilize it, and eventually add skin and infrastructure to make it run. Product Backlog items can be split in the same manner, from a spike solution to an uncomfortable dirt road implementation with corners and rough edges. After that there is often a more convenient implementation for your feature on the level of a cobblestone road before going to the asphalted road. While a highway might be reasonable for some features, also consider how much of science-fiction you already thought up in your product backlog in terms of flying cars.

Bibliography
[Coc2006] Agile Software Development: The Cooperative Game, 2nd edition, Alistair Cockburn, Addison-Wesley Longman, 2006
[vEx2007] Dimensional Planning, Koen van Exem, Walter Hesius, XP Days Benelux 2007, http://www.xpday.net/Xpday2007/session/DimensionalPlanning.html