George Dinwiddie’s blog

This week, Chris Matts tweeted, “Contemplating whether GIVEN-WHEN-THEN is back to front. The system should do <outcome> WHEN <event> PROVIDED <stimulus context>… Hmmm.” Let’s try an example. “Given I have $500 in my account, when I withdraw $50 then I have $450 in my account” becomes “The system should show $450 in my account when I withdraw $50 provided I had $500 in my account before.” It doesn’t exactly roll off the tongue, does it? Putting the result first makes the sentence both more complex and more passive. Yet I can understand the impulse that triggered this tweet. (Continued)

Also while in Las Vegas for the ADP/West Conference, Bob Payne and I sat in the Agile Philanthropy booth and recorded a podcast on Acceptance Test Driven Development and the 3 Amigos. This is the latest in a series of Tips and Advice podcasts that Bob and I have done.

In my previous post, Avoiding Iteration Zero, I suggested starting with “the one obvious thing that needs to be done? (Hint: it’s not ‘login.’)” As Jon Kern has recently mentioned, this same topic has come up elsewhere. I was also in that list discussion.

Jon is, of course, right in a narrow sense. You can start with login, if you want. You can also start with an Iteration Zero. (Or, an Iteration Minus One, as I’ve seen one organization do when their list of pre-planning outgrew one iteration.) I’ve observed that you can generally get better software, faster if you start somewhere else.

There are some very good reasons for this. (Continued)

I’ve written about User Stories before and made available a handout that includes a page on splitting stories that, in addition to listing some splitting heuristics, includes several links to several lists of techniques for splitting stories.

What it doesn’t include is an even simpler way to split stories–the simplest way I’ve found yet. (Continued)

Since learning about them some nine years ago, I’ve found User Stories to be much handier for expressing what the system should do than the monolithic requirements documents I dealt with in the past.  User Stories have a number of advantages:

• They can easily be shuffled into a different order.
• You generally know (by the acceptance criteria) whether or not they’re done.
• They don’t contain a lot of duplicated or contradictory detail.
• The detail gets elaborated when it’s needed (rather than a long time prior, letting the details get out-of-date and/or forgotten).

I’ve created a two-page handout on writing and splitting User Stories.  I’m publishing it here in case it helps others.  And I would welcome any feedback on it.