How do stories fit in with other stories, or small stories with bigger ones? How can we move from skinny stories to richer ones?

This is part of Scalability of stories.

One way to think about story relationships is to look at the words that connect them.

These connector words show up when we talk about stories; they show up in formal logic; they often have analogs in user interfaces. That is natural: they represent key relationships.

The Basics

Required – “and” – “must have”

Some things are required in even the skinniest version – without it, the essence is gone.

Let’s take a high-level example, favorite of computer books everywhere: the ATM. What is the minimal version of an ATM? (This is related to the MVP idea – minimum viable product.)

You may decide it requires three things:

It lets you authenticate with a card and a PIN, AND
It can tell you the balance of your checking account, AND
It can let you withdraw $20-$100 (in twenties) from checking.

We can think of a dozen other features, but we’ll treat these three as the bare minimum: all must be present.

Optional – “Could have”

Some features would make nice additions. They are independent from each other. (Think of check boxes on a dialog box: each choice is turned on or off separately.)

For our ATM, we could have features that:

Tell the balance on your savings account
Let you withdraw from savings
Let you transfer from savings to checking
Let you transfer from checking to savings

Once you have the minimal system, you could add any of these next.

Dependent – “Then”

Some features require other features to make sense.

Most of the time these dependent capabilities are options stacked on top of a base.

For a word processor:

Enter and delete text
Then maybe spell-check text
Then maybe auto-correct

We do this because auto-correct doesn’t make sense unless you can enter text, and we can’t correct unless we can detect mis-spellings.

I interpret “A then B then C”, as “A, or else A and B, or else A and B and C.”

When it’s “A and then you must do B and then you must do C”, I find it easiest to treat it as “A and B and C”.

Limiting Options

Pick One – “Exclusive or” – Radio Buttons

Sometimes we need to allow for exactly one choice among several.

Example: Our word processor needs a storage format.

Pick one of:

RTF
XML
A custom format

Pick One or More

In some cases, we want one or more.

Example: Output formats for a graphics editor. We have to support at least one, but more is better (at least up to a point).

Pick one or more of:

PNG
TIFF
GIF
:

Pick N to M / At Least N / At Most M

These aren’t common but they speak for themselves.

Deleting – “No longer”

We may have a story to remove a feature.

Example: “No longer let a user select 56-bit encryption.”

(Exclusive-or may also imply a deletion.)

Independence

Stories and sub-stories are easiest to work with when they’re independent (all optional).

It’s not unusual for the first few stories to be required, and the others be optional. But give those “must-haves” a critical eye – is there really no way to make things simpler and more independent?

What Are Dependencies For?

Some dependencies are because of the domain.

Some dependencies are because of a particular solution.

Some dependencies are because of a plan you have.

Make your dependencies reflect your domain, perhaps your solution, but not your plans.