Dimensional Planning - good enough software, early & often

Starting new product development with the question ‘What can we leave out?’ may seem paradoxical. We do this to start a conversation between customers and developers. As we go we develop a shared language, so that value can be delivered early and often. This is called Dimensional Planning.

Dimensional Planning was invented by our colleague Koen Van Exem around 2008. He used it to sell fixed scope, fixed budget, fixed time projects - those dreaded “fixed everything” projects.

I want it all

The customer wants it all and wants the best; you try to convince them that they will not need all the bells and whistles but the customer often won’t buy that. And you know only when the customer gets their hands on the software, they will understand what they really need. Dimensional Planning is a way to manage such a catch-22 situation and to facilitate a constructive conversation about a goal, and how to get there.

Dimensional Planning is built around a metaphor of road building. Roads can be more or less luxurious. Luxury comes at a cost though. The customer asks for a 6 lane highway, but in our experience delivering a dirt road and maybe a few cobblestone road releases will largely satisfy the customer’s real needs already. This facilitates a conversation about which Highway aspects the customer still finds valuable enough to pay for. Dimensional Planning can help to create space for negotiation even when everything seems to be fixed.

Dirt Road

A Dirt Road version is a basic, simple, bare minimal solution. It does the job, but nothing more. It can be quick & dirty from a functional point of view and it can include manual workarounds. If you launch for example a new web store for an uncertain market, you can build only the user facing part, while processing incoming orders manually. If it is successful, you can decide to automate order processing, if it fails, you have greatly limited your losses by only investing in the bare minimum.

So how do we determine what needs to be in a Dirt Road solution? It should be good enough to get feedback.

To work towards a Dirt Road version, we can set a release goal and a deadline, and use a release burn down to drive development. We continuously ask ourselves: do we really need this to get the feedback we seek?, shaving off work so that we will deliver to our goal.

Cobblestone Road

A Cobblestone Road version is a complete, usable implementation. It does the job like it should, but without extras, without anything fancy. For the Cobblestone Road release of our web shop, we automate order processing. We keep the user interface simple however. It does the job, nothing more, so simple dropdown lists, no smart searches, no extensive sorting and filtering, no continuous scrolling.

So how do we determine what needs to be in a Cobblestone Road solution? Or what does not need to be in there? You should be able to stop development after delivering the Cobblestone Road release: it does the job, it is functional, it gets you from A to B but no more. It does not excite, but no one makes a fuss about it either.

Just like with Dirt Road releases, it helps to set a release goal and a deadline, and use a release burn down to drive development. The decision criterion here is: if we would leave out this piece, would someone be hindered in doing their work? No? Then it is not part of your Cobblestone Road release.

Highway

A Highway release is a full blown implementation, with all the bells & whistles, luxuries, and nice-to-haves. Striving for perfection finds its place in the Highway release.

Chances are that by now, the customer has learned so much from tangible Dirt Road and Cobblestone Road results, that the current perspective on what comprises the Highway has changed dramatically from what the customer initially assumed.

How great should it be? How far do you want to go? What should be in the Highway release(s)? Well, anything can be in there, as long as someone is willing to pay for it. Just remember, kids, code can be a liability, as well as an asset.

Dimensional Planning in practice

We usually create a story map and assign different stories to the different dimensions. We end up with Dirt Road, Cobblestone Road and Highway slices. This implies we will have at least three releases. We can apply the metaphor also to large stories and split them up in different dimensions.

Dimensional Planning works well with User Story Mapping, as it helps slicing releases and finding release goals. User story mapping proposes to start with a walking skeleton - a minimal version of the software that spans everything to get architectural feedback. A walking skeleton is not a Dirt Road version: they seek different kinds of feedback. You can still do both, start with a walking skeleton, then do a Dirt Road version.

In a story map, it is not always as simple as story ‘X’ is a Dirt Road story and story ‘Y’ a Cobblestone Road or Highway story. Stories in a story map are often of ‘epical’ size. They need to be split in smaller stories. The three roads metaphor can facilitate this splitting process as well.

Using the metaphor of the three road helps in negotiating an earlier release with customers who want it all: it allows them to agree on a bare minimum version, because they know the bells and whistles won’t be forgotten. Along the way, the customer will realize they don’t need the full highway.

Read more

• Dimensional Planning
• Koen’s original slides
• Real options by Yves Hanoulle & Geike Hanoulle
• Impact Mapping by Gojko Adzic, another useful technique that helps you plan for value

Picture credits:

• Kristine Pethick, “Dirt Road to Playa Sucia”
• Jeremy Keith, Cobblestones.
• USDA NRCS Montana Roads10.tif

This post is part of a series on Dimensional Planning:

• Dimensional Planning - good enough software, early & often
• Dimensional Planning - a story
• Dimensions of Dimensional Planning
• Dimensions of Features - an example