Ordering the Parts

When you’re estimating how long it takes to drive somewhere, the road constricts what can happen first and what can follow after that. The decomposed parts are almost certainly various stretches of road. Geography limits the order in which you can travel those roads.

When you’re estimating software development, you have a wide range of choices about the order in which you do things. The way you decompose the whole into parts is almost entirely up to your own ability to conceptualize it. This freedom comes with a cost. Some orders may be harder and therefore more expensive than others. Other times, there’s an initial cost to pay for the first of several similar items, but their order doesn’t otherwise matter.

• You can add the additional effort to one of these arbitrarily. This can be misleading if someone doesn’t notice the relationship between the items and reorders them.

• You can average the additional effort across all the items. This is misleading as it doesn’t represent the reality of the cost being paid with the first item.

• You can split out the scaffolding into a separate item. This is risky, as its relationship to the items might get overlooked. It’s not generally valuable, or perhaps testable, on its own. It needs to be paired with one of the User Stories.

All of these require special attention to avoid fooling people, but the consequences are generally low. Any of them can work, with a little care.

The assumed order of the identified parts can have an effect on the riskiness of the estimation. Working by functional slices, as discussed in ​Which Way to Slice?​, lets us judge how finished a work item is, reducing the risk of unnoticed incompleteness. There are differences, though, in how people form functional slices. Some people are satisfied if there is some measurable output. Using this definition, being able to test a method in a test harness counts as measurable output. At the other end of the spectrum is output that is being used. If people are using the functionality for their daily work, they are likely to notice most forms of incomplete implementation.

Build what Alistair Cockburn calls a “Walking Skeleton.” (Crystal Clear: A Human-Powered Methodology for Small Teams [Coc04])^[8] This gives a framework supporting a subset of usage from inputs to outputs. Elaborations can be hung on this framework to expand the range of usage. If there is a hard stop deadline, then prioritization of the most common and most critical use cases can reduce the risks of missing it. You can stop there and adjust the requirements to match what has been built.

This may seem like a cheat, but it’s not. It’s sometimes true that delivery is more important than being full-featured. Some of the requested features may be speculative to handle situations that have never arisen. Some situations may be so rare that it’s more cost effective to handle them manually than to automate them. A design that is grown from a Walking Skeleton should already have the means to detect and enable manually adjustment of situations that cannot yet be handled automatically. These are capabilities worth having in the delivered product.

Starting Your Walking Skeleton

As a rule of thumb, it’s best to start with the output of the system. Even if the system inputs are hardwired and it’s only suitable for one situation, you can use it in that situation to get feedback, as well as potential business value, earlier. If you’re replacing a legacy system, whether automated or paper, it’s easier to drive the fledgling new system from some point within the flow of the old system than it is the other way around. Then, work your way back toward the inputs. You’ll have some flexibility and can decide whether it’s better to elaborate the later stages, or continue to replace legacy functionality with the new skeleton.