|Twenty Ways to Split Stories
|The ability to split stories is an important
skill for customers and developers on XP teams. This note suggests
a number of dimensions along which you might divide your stories.
(Added July, 2009: summary sheet
Splitting stories lets us separate the parts that are of high
value from those of low value, so we can spend our time on the
valuable parts of a feature. (Occasionally, we have to go the other
way as well, combining stories so they become big enough to be
interesting.) There's usually a lot of value in getting a minimal,
end-to-end solution present, then filling in the rest of the
solution. These "splits" are intended to help you do that.
The Big Picture
||It's easier to research how to do something than to do it
(where the latter has to include whatever research is needed to get
the job done). So, if a story is too hard, one split is to spend
some time researching solutions to it.
||Developers may not have a good feeling for how to do something,
or for the key dimensions on which you might split a story. You can
buy learning for the price of a spike (a focused, hands-on
experiment on some aspect of the system). A spike might last an
hour, or a day, rarely longer.
||If there's a manual process in place, it's easier to just use
that. (It may not be better but it's less automation work.)
For example, a sales system required a credit check. The initial
implementation funneled such requests to a group that did the work
manually. This let the system be released earlier; the automated
credit check system was developed later. And it was not really
throw-away work either - there was always going to be a manual
process for borderline scores.
||Sometimes, what you want already exists, and you can just buy
it. For example, you might find a custom widget that costs a few
hundred dollars. It might cost you many times that to develop
||Other times, the "off-the-shelf" solution is a poor match for
your reality, and the time you spent customizing it might have been
better spent developing your own solution.
||A batch system doesn't have to interact directly
with the user.
||You don't face issues of "what happens when two
users try to do the same thing at the same time." You also may not
have to worry about user accounts and keeping track of the
||It's easier to not have a user interface at all.
For example, if you're testing your ability to connect to another
system, the first cut might settle for a unit test calling the
|Character UI or Script UI
||A simple interface can suffice to prove out
||At one level, you can use basic widgets before you
get fancy with their styles. To go even further, something like
Naked Objects infers a
default user interface from a set of objects.
||It's easier to calculate something once than ensure
it has the correct value every time its antecedents change.
Sometimes, you can use a halfway approach: periodically check for a
needed update, but don't do it until the user requests it.
||While it's less work to ignore errors, that doesn't
mean you should swallow exceptions. Rather, the recovery code can
||Let's you get the objects right without the worries
about changing the mapping of persisted data.
||You can break some features down by quality of
result. E.g., a digital camera could start as a 1-pixel
black-and-white camera, then improve along several axes: 9 pixels,
256 pixels, 10,000 pixels; 3-bit color, 12-bit color, 24-bit color;
75% color accuracy, 90% color accuracy, 95% color accuracy."
||"Perfect uptime is very expensive. Approach it
incrementally, measuring as you go." (William Pietri)
||"A system that works for a few people for moderate
data sets is a given. After that, each step is a new story. Don't
forget the load tests!" (William Pietri)
|Less "ilities," e.g., slower
||It's easier to defer non-functional requirements.
(A common strategy is to set up spikes as side projects to prove
out architectural strategies.)
||Fewer is easier.
||(Use case terminology.) The main flow - the basic
happy path - is usually the one with the most value. (If you can't
complete the most trivial transaction, who cares that you have
great recovery if step 3 goes bad?)
||Hardware architects have a "0, 1, infinity" rule -
these are the easiest three values to handle. Special cases bring
in issues of resource management.
||It's usually easiest to get one right and then move
to a collection.
||One level is the base case for a multi-level
||In general, you have to do a base case first (to
have any assurance that recursive solutions will terminate).
These "splits" may help give you ideas when you're looking for a
way to move forward in small steps. While it's important to be able
to split stories, don't forget that you have to reassemble them to
get the full functionality. But you'll usually find that there is a
narrow but high-value path through your system.
[Developed for XP Day speech, Sept., 2005. January 6,
2006: Thanks to William Pietri for sharing his suggestions on the
fidelity, reliability, and scale dimensions. Fixed typo,