Recently, in the mailing for Steve Freeman and Nat Pryce’s book Growing Object-Oriented Systems Guided by Tests, I followed a discussion that included this comment:

I guess the skill is knowing in what makes as small as possible but valid slice (as you say in the book)

Even though I’ve written before about splitting stories, I have refined my ideas about how to deliver a useful, significant, but small slice of software. I use a simple technique which I describe this way:

  1. Write out any, and I mean any, meaningful end-to-end scenario in detail with concrete values at every step.

  2. Now that you’ve chosen one real scenario, go to each step in that scenario and ask the question, “What would I need to assume to eliminate this step?” If you find those assumptions make for a reasonable scenario, then use that assumption to simplify the scenario.

  3. Repeat step 2 until exhausted or unable to come up with a simplifying assumption with five minutes’ thought.

I’ve used the example of online bill payment in many of my classes and applied this algorithm. You’d be surprised how simple, but useful a bill payments system one can build.

In fact, let’s look at this example in a bit more detail.

What does a typical bill payments system look like? I imagine that TD Canada Trust has a fairly representative system, so I’ll use that as my example.

First, select the “Pay Bills” option.

Selecting Pay Bills

Next, select the account to use to pay the bill.

Selecting the account

Next, select the bills you’d like to pay. Once in a while, I want to pay multiple bills at once, such as when my business has to pay the property taxes on a handful of rental properties.

Selecting the bills to pay

Next, enter the amount you want to pay, the date on which to pay it, the account from which to pay it (why again?) and whether you want to repeat this payment automatically.

Entering the details

Verify the payment details: the amount, the account, the creditor, the date, and the system schedules the payment.

Verifying the details

From this, I can describe the scenario in a form that looks like an executable example:

Pay a bill online

  • Given that Joe has already logged in
  • Joe says “I want to pay a bill”
  • Joe selects chequing account 12345 from which to pay the bill
  • Joe selects Visa bill with account ending in 2222 as the bill to pay
  • Joe says “I want to pay $5,000″
  • Joe selects a date 14 days from now as the date on which to pay the bill
  • Joe selects “only once” as the frequency with which to pay the bill
  • After Joe sees a summary of the bill payment he has asked to schedule, he says “I confirm that I want to pay this bill”
  • Now the system schedules to pay the bill as requested and sends Joe an email to confirm the transaction with a link to cancel or change the scheduled payment

Apart from the numbers, this scenario perfectly accurately reflects how I pay my bills online, although I only wish TD Canada Trust would send me the confirmation email I threw in as the system’s response. We have completed step 1 of the algorithm: we have specified a complete scenario with concrete values at every step.

You’ll notice that we didn’t specify Joe’s username and password. We don’t intend to re-test logging in here, so we don’t bother with those details. We will have tested that elsewhere.

Now we move to step 2 of the algorithm: looking for assumptions we could make about paying a bill online that would eliminate steps in the process. To do this, we have to be prepared to sacrifice any semblance of a decent user experience. Don’t worry: once the Walking Skeleton runs, you’ll be able to add all the bells and whistles that will make this feature a pleasure to use. For now, we want to eliminate any detail that distracts us from connecting our feature to the key interfaces it must deal with. In this example, I know I want to expose an HTTP interface to clients (eventually the web) and that I need to connect to the Big Ugly Banking System, but beyond that, I don’t know that anything else matters. Within this context, then, we can start making our simplifying assumptions.

That is, until someone remembers that, being a bank, we need to keep a strictly accurate record of all transactions. That means we should add a final step to the scenario: the system records the transaction in its log. While some might consider this a superfluous detail, banking regulators would call it quite essential, and so I find it hard to ignore. This means that we have a third essential interface to which to connect: the transaction logging facility. For our purposes, I’ll assume that we have one and that it has the usual properties: transaction posting date, description, and debit or credit amount, who performed the transaction and when.

This itself makes me ask whether we need to log the transaction yet, because in our scenario we’ve scheduled a payment, and not made one. Scheduling a transaction leads to issues of canceling, editing, and building a process that completes the transaction on the day the customer scheduled it. This leads to our first simplifying assumption: Joe pays the bill immediately.

This simplifies the scenario because we no longer need Joe to tell the system when to pay the bill: the system always pays the bill immediately. Our revised scenario looks like this:

Pay a bill online

  • Given that Joe has already logged in
  • Joe says “I want to pay a bill”
  • Joe selects chequing account 12345 from which to pay the bill
  • Joe selects Visa bill with account ending in 2222 as the bill to pay
  • Joe says “I want to pay $5,000″
  • Joe selects “only once” as the frequency with which to pay the bill
  • After Joe sees a summary of the bill payment he has asked to schedule, he says “I confirm that I want to pay this bill”
  • Now the system schedules pays the bill as requested and sends Joe and email to let him know that the bill was paid

I like to start at the top and look for simplifying assumptions. First, I see that Joe has to select the account from which to pay the bill, which implies that the system presents a list of accounts to Joe, which we recognize we need to do, but not in the Walking Skeleton. Ultimately, Joe simply needs to specify the account number to debit to pay the bill, so for now we’ll make him type that in. Our revised scenario looks like this:

Pay a bill online

  • Given that Joe has already logged in
  • Given that Joe has already logged in
  • Joe says “I want to pay a bill”
  • Joe says “I want to pay from account 12345″
  • Joe selects Visa bill with account ending in 2222 as the bill to pay
  • Joe says “I want to pay $5,000″
  • Joe selects “only once” as the frequency with which to pay the bill
  • After Joe sees a summary of the bill payment he has asked to schedule, he says “I confirm that I want to pay this bill”
  • Now the system schedules pays the bill as requested and sends Joe and email to let him know that the bill was paid

Next, I see that Joe again has to select the bill to pay, which implies that the system presents a list of bills to pay. We could simplify this by requiring Joe to enter the payee identification number and the account number, even though this means saddling Joe with knowledge of payee identification numbers. In particular, the system neither has to store nor present a list of bill payees, and Joe doesn’t need to register a creditor before paying them.

I’m making up this notion of payee identification numbers because I don’t know how banks really implement this. I imagine whatever they do, it boils down to companies registering as payees for bill payments, which results in issuing them some kind of identification number. If some kind soul wants to educate me on how this really works, I’d gladly edit the article to bring it closer to the banking industry’s real implementation.

Our revised scenario looks like this:

Pay a bill online

  • Given that Joe has already logged in
  • Given that Joe has already logged in
  • Joe says “I want to pay a bill”
  • Joe says “I want to pay from account 12345″
  • Joe says “I want to pay to payee number 66666″
  • Joe says “I want to pay to account number 2222″
  • Joe says “I want to pay $5,000″
  • Joe selects “only once” as the frequency with which to pay the bill
  • After Joe sees a summary of the bill payment he has asked to schedule, he says “I confirm that I want to pay this bill”
  • Now the system schedules pays the bill as requested and sends Joe and email to let him know that the bill was paid

Next, I notice that Joe has to specify the amount to pay, and I can’t think of how to eliminate that detail without complicating matters. It does make me think about potential future features, such as “pay balance off in full” and “pay minimum payment required”, which I note down before returning to this scenario. Joe will simply have to tell us exactly how much to pay towards the bill.

Next, I notice that Joe has to confirm that he only wants a one-time payment. We can eliminate this detail by assuming that Joe can only pay the bill once. We know that customers want recurring payments, but that only distracts us from implementing the Walking Skeleton. We can eliminate this step, and our revised scenario looks like this:

Pay a bill online

  • Given that Joe has already logged in
  • Joe says “I want to pay a bill”
  • Joe says “I want to pay from account 12345″
  • Joe says “I want to pay to payee number 66666″
  • Joe says “I want to pay to account number 2222″
  • Joe says “I want to pay $5,000″
  • After Joe sees a summary of the bill payment he has asked to schedule, he says “I confirm that I want to pay this bill”
  • Now the system schedules pays the bill as requested and sends Joe and email to let him know that the bill was paid

Next, I notice that Joe has to confirm the bill payment before the system will process the payment. While this step might seem essential for security reasons, remember that we don’t necessarily have a graphical web interface for our Walking Skeleton implementation, and so we might not even have the opportunity to ask for confirmation of the bill payment. On this basis, we eliminate this step by assuming that Joe has looked over the details before pressing the button to pay the bill. Our revised scenario looks like this:

Pay a bill online

  • Given that Joe has already logged in
  • Joe says “I want to pay a bill”
  • Joe says “I want to pay from account 12345″
  • Joe says “I want to pay to payee number 66666″
  • Joe says “I want to pay to account number 2222″
  • Joe says “I want to pay $5,000″
  • Now the system schedules pays the bill as requested and sends Joe and email to let him know that the bill was paid

I can’t see any further simplifications, so I choose to stop here. I suspect this constitutes a close-to-minimal protocol for the “pay a bill online” feature. The programmer in me sees this as a single message, which pleases me, because of the simplicity of the interaction. The customer in me can see clearly all the extra stories we need to complete to make this feature available for public use, which makes planning easier. It feels like a win for everyone, except perhaps for Joe, who has a crappy interface to work with.

Now that we have a Walking Skeleton bill payment feature, we can identify the stories we want to deliver beyond the simplest case, and can decide which ones we need to roll this feature out to paying customers.

  • Let Joe choose from a list of available payees which company to pay
  • Remember the payees that Joe has previously paid and present them as “favorites” so he doesn’t have to search for them
  • Remember the payee accounts that Joe has previously paid so that he doesn’t have to enter them each time
  • Let Joe delete accounts he no longer needs to pay
  • Give Joe the option of paying the minimum payment required by the payee
  • Give Joe the option of paying the full balance owing
  • Let Joe schedule his payment in the future
  • Let Joe cancel pending payments
  • Let Joe change pending payments
  • Send a reminder to Joe to pay a bill he has paid at least three of the past six months (try to detect a recurring payment)
  • Let Joe schedule a payment to recur every month (same day each month)
  • Notify Joe in advance of automatically detected recurring payments and ask him if he wants us to pay the bill for him
  • When emailing Joe about a bill payment, include links to review the scheduled payment, change it, or cancel it, if appropriate

I imagine we could come up with more together, but I find one common thread with all these stories: once we implement the Walking Skeletion, we can implement most of these stories independently of the others. We know that more independent stories means greater opportunities to change priorities as needed as well as greater opportunities to drop features in favor of other more lucrative options. Once again, everyone wins.