The high-level vision is made up of Stories of Unusual Size

We have a good idea of where it is we want to go. We have some high-level stories which are quite large. We’re about to play some of them in our iteration, and we want to know what the real scope of the stories is. We’re also pretty sure that some of these SOUSes are too big to get done in the space of a week or two.

To get feedback more quickly, we split the stories up

Occasionally it’s possible to release part of the original, high-level story. More often, we can split the story up so that we can get feedback about that bit of the story.

Whatever we do with the story, in order to get feedback, it has to show something that the business can understand and on which they can give us feedback. If you can’t get feedback, nobody cares. If nobody cares, it’s not a story.

(If you’re having problems getting feedback from your business, try delivering something.)

We can’t split the story up into horizontal layers

The business don’t care if

• We created a CustomerData table with the right columns
• We can migrate all the old data into the new database
• We are using Spring as our framework
• We are using magical pixies to make our site look nice instead of CSS.

They care if

• They can see interesting information on the website
• They don’t have to use two different applications for the same job
• They can get changes made quickly and easily
• The site is fast enough and makes for a good user experience.

Here are three ways of splitting up stories

The only valid way to split stories is into slices which the business can understand. That means that there has to be some effect on the interface that the business use! Even if there’s another computer somewhere else that uses our site, and no user interface at all, we should be able to define the effect of our stories in terms of their effect on the interface.

QAs are used to this. They have a great acronym, “SMART”, to remind them that stories should have acceptance criteria, which should be:

• Specific – no generalizations (“It must be quick enough” vs. “It must load 90% of the time within 1 second”)
• Measurable – nothing that can’t be given a quantative measurement (“Users are happy” vs. “Users who express their level of happiness should give us at least 7/10”)
• Achievable – nothing that can’t be done (“I want my site emblazoned on the side of the moon”)
• Relevant – keep it related to the story at hand (“I want the three latest blog posts and a pony”)
• and Timeboxed– work out when it needs to happen (“I want to be able to duplicate the works of Shakespeare using the random word generator”)

Three ways that I’ve found to split up stories are:

• By splitting up the output of the interface
• By splitting up the input of the interface
• By splitting up the behaviours, or business rules, that connect the input and the output.

We can split stories using the outputs

Think of a webpage. If you’re reading this on WordPress, it’s a great example. We’ve got several components on the screen:

• The blogroll
• The archive
• The comments
• The admin area
• The footer
• The date of each post
• etc.

Let’s say our business have asked for a blog roll. The usability experts have come up with a design that shows the date of each post, who posted it, tags, categories and comments.

We can start capturing blog posts immediately. Not all blog posts have comments. We need to capture the date to show them in order, but we don’t need to worry about how to display the date. Not all posts have tags or categories, either! So our stories might be titled:

• Blog posts
• Display date on blog posts
• Tag blog posts
• Categorize blog posts
• Comment on blog posts
• Stop robots spamming blog posts
• etc.

An output might be a page with components on it, a particular flow through an application, or a report with content and formatting.

We can split stories using the inputs

We can split the story up into the different types of input, and the way in which they effect the output. Search filters are a really great example of this. Take a look at Google’s advanced search.

I doubt that Google started with all those different search options. Maybe they started by letting you search for all words. Then by letting you search for exact words. Then by letting you search for all words, or exact words, but not the unwanted words.

The form of the output is exactly the same – a list of search results – but the actual content changes depending on what the input was. We don’t need to support all those inputs to begin with! So, our stories for a Google Advanced Search page might be titled:

• All these words
• These exact words
• Not these words
• Paginate results
• Search by language
• Search within a domain
• etc.

We might also want to split stories using the state of the application – the context in which it’s running. This is similar to changing the input. For instance, the iGoogle home page contains some widgets, and has a search bar. We can change how the widgets and search bar look depending on:

• the skin choice
• the order of the widgets
• the different tabs
• etc.

Each of these might also be a different story. The context is another input, and the output changes depending on it.

We can split stories using the business rules

Let’s say we’re building a payroll system.

The simplest payroll we can create is for a full-time employee, who has an annual salary, and who gets paid monthly. Sometimes these employees might just have arrived, so they won’t be paid a full month’s salary. Sometimes they might be in the process of leaving. Perhaps an employee works part-time, so we actually have to look at how many hours they worked that week. Maybe they do overtime. Some of them will get performance bonuses. Some will be on commission. They might have pension contributions, or expenses.

All the information is captured in a database already, so our context isn’t changing. Our input to the system is just an id! Our output is a cheque with an amount. But our amount changes as we introduce each story – which means it won’t work for everyone to start with.

We can support the simplest cases first, and add business rules incrementally to deal with the difficult cases. So, our stories might be titled:

• Full-time employee
• Part-time employee
• Employee who just joined
• Employee who’s leaving
• Overtime
• Pension contributions
• Expenses
• Commission
• Bonuses
• etc.

As we start adding things to this list, we can start dealing with more and more employees. We can let the legacy system deal with the people who aren’t on the list. It might be a manual legacy system! But even if that’s the case, we can start cutting down the work of the admin staff very quickly.

You can use scenarios to help split up stories

When we think of examples of the behaviour of our application, we think of stepping through them in the same way that QAs do when testing.

We can say:

• Given a context
• When some events happen
• Then some outputs should occur

If we have different contexts that change the outputs when the same events happen, then we can split the stories according to those contexts. So using an example of an ATM which does different things depending on the balance of my account and whether or not I have an overdraft limit, I can start splitting the “Withdraw cash” story into “enough money” and “overdraft” stories.

If different events cause different things to happen, there are probably different components on our interface that can be delivered independently. So putting in a value for the amount of money, and pressing the buttons that deliver predefined amounts of cash, might be two different stories.

If we find that we’re getting the wrong outcomes for particular contexts and events, we’ve probably got some business rules that we need to include (and we’ll have to have a strategy for dealing with the exceptions in the meantime). For instance, my card used to work very well in the ATMs abroad! But now, I have to phone my bank and let them know where I’m going ahead of time – they’ve put in a business rule to help cope with international fraud.

So our single story – “I can use an ATM to withdraw cash” – becomes:

• Withdraw cash if enough cash
• Withdraw cash if enough overdraft
• Quick buttons
• Limit use abroad
• …and we can probably find some more if we talk to people who know the domain.

These stories are not necessarily releasable

Sometimes, the business will have a minimum feature set that they want to release. This might be because of training, because they have a certain number of commoditized features that they need to enter a market, or because rolling out the software or making changes to it in a live environment is expensive.

However, the stories should each have something that the business can start playing with, that QAs can test, that we can get feedback on and that we can showcase and feel proud of.

But they might be!

We sometimes discover that a story we’ve broken down can be released with only part of the original functionality in place. This is great, if you’ve got an immovable deadline!

“We’ve just bought out another company. That’s 1,000 new employees, and they all need paying at the end of the month…”

OK. Let’s work on that first release.