Delayed Gratification

(Or, "Why I believe fixed length release cycles are best")

---

Anyone who’s done some kind of Scrum reading or training classes will have had some exposure to the release planning techniques and ideas involved. There is plenty of information, ideas and opinions out there about that stuff, in particular how to organize your releases around themes, epics and stories, how to prioritize your backlog and how to run a release planning meeting. I, however, have been thinking a bit about things one level up from the mechanics, and here wish to discuss some of my opinions and ideas on how a business should look at managing releases. In particular I’m interested in how to balance responsiveness to changing needs and predictability on longer term commitments. I’m also interested in simplicity and optimizing the way product development works. Agile software developments offer the promise of delivering high value sooner, of responding to changing needs. But in order to deliver on this promise it is my belief that certain preexisting attitudes and tendencies that are ingrained in many of us need to be reconsidered.

In scrum, at the end of any sprint the software should be “potentially releasable.” Usually we choose not to do that though because:

1. There isn’t enough value to justify the “cost” (deployment, distribution, training etc.) of releasing
2. Customers (users too!) aren’t necessarily best pleased to have their software in a seemingly constant state of flux.

An easy way then to manage releases is to let business needs dictate release dates. This doesn’t require us to have any new special rules or planning processes, and it sounds reasonable: “Yeah we’re gonna need that BIG FEATURE out by CERTAIN MONTH for IMPORTANT CUSTOMER, so we should release then. And then we’ll fit in whatever else from the top of the backlog we can.” Sounds pretty good, right?

Ken Schwaber’s Scrum guide, in describing release planning meetings says nothing more than that they establish a “probable delivery date and cost that should hold if nothing changes.” He doesn’t seem to be advocating anything different.

But is this optimal? Are there potentially better alternatives? I think so. Here’s how I think it should be done and why.

In a nutshell I think we should take a leaf out of the finance and accounting book and use a year chopped up into quarters (i.e. 3 month long chunks) for planning and release purposes. In other words:

• I wouldn’t much bother trying to look further than a year ahead
• I would [try and] release every quarter (maybe sometimes you can skip, although I think if you have your deployment act together this is unlikely)
• I would encourage the business to plan things around this quarterly release schedule…that is to think of things in terms of “I’d like this in the 1st quarter release” or “I can wait until the 3rd quarter release,” not “I want this in October.”

Why? Well, hopefully the idea of not looking more than a year ahead is not too controversial. All I’m saying is that things change so much in 12 months that looking further ahead is usually crystal ball gazing. That’s an idea you’ll see in many communities, whether agile, scrum, lean startup or whatever. I think it makes a lot of sense in many places, certainly in Perceptive MI.

Also fairly easy to swallow I think is the notion of thinking in 3 month chunks. Three months is around 12 weeks, or 6 two-week sprints. It’s long enough to get something of substance and value done, but a short enough time-horizon to keep everyone focused and avoid the risk of over-committing badly. It’s also probably not too long to wait for a new feature. Of course unexpected needs and critical defects occur, and interim or maintenance releases are always possible, particularly when using Scrum, since we’re potentially shippable at the end of a sprint.

But this notion of rigidly sticking to a plan of releasing every three months…I know that is a little different and needs explaining. Well, for starters it provides a nicely time-boxed predictability. There aren’t so many surprises. There isn’t the need to frequently revisit and negotiate the question of when releases will occur – everybody knows, it’s once a quarter.

This predictability is not just comforting and simple, it provides other benefits too. For starters it makes it easy to handle certain common situations. Let’s consider four:

1. The madly urgent problem/bug in production
Everyone is familiar with this situation. One moment everything is calm and ticking over nicely, the next minute chaos abounds: a bug without workaround has been found, or a really important customer has to have something and only just thought to ask.

Either way, within our proposed framework dealing with this is straightforward. There are really only two choices. The first question to ask is, “Can this wait until the next sprint?” The answer is going to depend on how truly urgent the matter is, and how long it is until the next sprint begins. With two week long sprints it’s never far away. Few problems require more immediate attention. For those that do, the team would simply abandon the current sprint and focus on the urgent issue at hand.

2. The unexpected feature
When planning for a new three month release cycle you usually have a fairly good idea of what you want to get done in a timeframe that short. Nonetheless, there are a number of very good reasons why a feature that nobody was aware of then can suddenly emerge and need attention.

This is not really a problem though when using Scrum. The Product Owner (and by extension stakeholders and other interested parties) are able to completely change the priority ordering of the product backlog every two weeks. Simply bump the new feature up to the top and it can get all the attention it needs at the next sprint. This means that, worst case, the business waits two weeks for things to start on something that was previously completely unplanned.

3. The client driven enhancement
Somewhere between the unexpected feature and pure market driving planning lies the customer driven enhancement. The distinction here is that one has the capacity to pick and choose whether to bump out current plans and place it into the release cycle that’s in progress or negotiate as needed to place it in the next.

4. The market driven plan
Above the cut and thrust of weekly operational driven needs and urgent customer requests is the longer term approach to product development. This is simply identifying desirable features based on market trends and selecting appropriate release cycles to implement them in up to a year ahead.

You see how with all of those there’s an established pattern and we work to fit things in? This reduces or even eliminates the need to frequently invest energy into discussing and negotiating with colleagues outside the Scrum team (IT, domain experts, business development, professional services etc.) over when a release will occur. The schedule is published and everyone can consult it and even, with time, comes to anticipate it. Things will happen without energy needed to push or chase it: IT can grow to anticipate doing deployments for example. Business development can talk confidently about the likely lead time for including new features to service particular customer needs.

Finally, ultimately, it encourages better planning and discipline on the business as a whole, from sales through to professional services and product development. I believe this leads to a better run business, better thinking, less burn out, and people selecting the right opportunities to pursue. I cannot see how that is a bad thing :-)

For me, this approach to managing the release cycles for a software product intuitively makes sense. The combination of simplicity, predictability and responsiveness that can be achieved is highly desirable and a worthwhile reason to move away from the more traditional approach to variable length release cycles driven by external events. What do you think?

Scrum Master: Tools of the Trade

(or "How Rally Could Improve Their Software")

---

When a team is employing Scrum to project manage their software development efforts one facet for consideration is how to keep tabs on things: the backlog, the stories and associated acceptance criteria, the current state of affairs and so on.

The things one uses to do this are the “tools of the trade” for a Scrum Master, indeed for the whole team.

Much advice is given about keeping this simple. Much advice is given about the idea of visual management techniques including “information radiators” that constantly, clearly and loudly proclaim the state of affairs. These should be intuitive to read, easy to work with and not intrusive.

The quintessential approach to this is the use of a team area with a task board of some kind along with perhaps a burn down chart. We've done this at my company in our early days of agile adoption and it worked extremely well. The main benefits I saw were:

• You can take in the state of an iteration in a glance. For instance, got most of your Post-its on the left and it's near the end of the sprint? Looks like trouble...
• You don't really have to train anybody how to use it, it's dead simple
• People not intimately involved in the project day-to-day (read: management and executive sponsor types) can quickly "read" it and get value from it
• It's quick and easy to work with...adding a story, task, note, changing status...
• It's always present, you don't have to "go" to a website, tool or what have you

Of course, it works best when you have a fully co-located team. When there are team members that can't visit the task board in person then this approach weakens considerably. This is one reason why a team may turn to a tool to aid them in creating a virtual task board. Part of me feels that this is treating the symptoms rather than the root cause...that is, you should look again at whether you really need to have a team spread out over different offices. However, I also recognize that that optimal arrangement isn't always practical, whether for financial or political or other reasons within an organization. Sometimes your talent is spread across the world and you can't bring it together. Anyway, I digress...

The other seemingly valid reason for a tool to replace the simple white board and Post-its I consider to be related to managing a group of teams or a portfolio of products. There will be very legitimate needs to roll up the status associated with individual software development teams to obtain a higher level view of the work of an engineering department. If teams are in different offices or countries, it's clearly impossible to run from one team room to another to update oneself on how all the teams and products are doing.

So clearly there are at least a couple of reasons why you may reach a point where you need a tool to help your agile teams coordinate and track their efforts.

My company reached this point. We chose Rally.

Here's a quote I happened across on the Rally Products Overview web page (it doesn't always show up, seems they cycle through various quotes) -- “The usability of Rally is one of its main selling points.”

Now I'm sorry, I don't mean to offend either the man being quoted or the people who've worked hard at Rally building this software. But it's far from a shining example of highly usable software.

It's my assertion that information radiators like a task board that a co-located team would use are basically the Gold Standard.

So, if you’re going to try and create some software that can be used in place of this then you should try damn hard to get as close as possible to that Gold Standard. I know there are other issues like concurrency, responsiveness, reporting, user management and so forth. But at the heart of a bit of software like this, it is my belief at least, should be a tool that empowers a team, not a tool that is awkward to use and gets in the way.

So what's my beef with Rally usability? Well, having thought on it a bit I believe my criticism falls into three main areas.

1. The Software is not Task-Centric

And when I say this, I'm not talking about the tasks one can break stories down into. I'm talking about the fact that different roles on a Scrum team regularly and repeatedly engage in certain tasks but that there are no options in Rally that particularly support or enable these. Instead it feels an awful lot like a small set of database tables with some views layered on top and then exposed as HTML. Various ways to slice, dice, subset and drill down my releases, iterations, stories and so forth is fine, but I'm looking for something more.

• I want a tool that supports the Product Owner in release planning.
• I want a tool that supports the Scrum Master in sprint planning.
• I want a tool that supports the team on daily stand ups.
• I want a tool that supports the team during sprint reviews.
• I want a tool that supports the team during retrospectives.

Rally does of course contain various list views and so forth that help with this, but it seems to me that none of them are really conceived to aid any of these roles in any of these tasks. It's more a small set of Lego bricks you can arrange as you see fit to achieve your ends. And yet it would be so much more useful it the "bricks" were assembled into larger constructs that supported the various Scrum ceremonies and tasks that people on the team perform.

2. The Software Looks, um, Less Attractive than I Would Like.

I know people have worked hard on this, and I don't mean to completely disparage their efforts. I'm not even saying I could necessarily do much better (although I'd like to think I could...) but consider:

• In general, there's a "designed by an intern programmer circa 1996" feel to things
• The Dashboard looks like Jetspeed 1 That's not a good look for anybody.
• In general, screen/form layouts are pretty unattractive and hard to scan: content is not well bounded, poor typography, colors, etc. Take the basic detail view of a user story, or the pop-up edit a story view…labels not emboldened, field boundaries unclear, it just looks like my 12 year old designed it after reading "HTML in 24 hours".
• Look at the new Reports --> Epic Progress app that was just released. Was somebody really happy with how that looks? If I was Product Owner I surely would not be.
• Why does editing a story have to spawn another browser window? Why not in-place? Rally allows a certain amount of in-place editing in list views so why not the full form? Nobody wants extra browser windows hanging around…
• Speaking of in-place editing, there's a disconcerting "twitch" or "jump" when on the Plan --> User Stories view and you in-place edit something.
• The tabs don’t stand out enough so it’s hard to “read” where you are, especially since so many “views” look so similar. There's not enough contrast with almost everything being in very drab black/white/blue. Use some more of the Rally Red maybe. Also I find the tabs are not very responsive, they “lag” as you move over them.
• Why is the icon you can click and drag to reorder things different between Plan --> Backlog and Plan --> User Stories?

There's more, but that's a good representative selection of the things that strike me as looking unattractive.

3. It's Just Not Intuitive

I know agile and Scrum pretty well. The software then ought to be fairly intuitive to work my around. And yet it isn't...

• It's Confusing how the backlog tab only shows things that *haven’t* been assigned to a sprint and/or release (can’t even remember which, but stuff disappears from here)
• It's confusing how story hierarchies are shown in Plan --> User Stories but not Plan --> Backlog…in fact the whole parent/child thing is confusing. Why not have first class support for the common theme --> epic --> story structure?
• Plan --> Releases gets its own tab just for defining a simple release "record"? Navigation from here to see “stuff” slated for a particular release is non-obvious. Could be much nicer.
• “Page Tools” vs. “Actions…look different, kinda confusing…
• Column headings etc. look lost...it's just not clear that they are column headings.
• Plan --> Plan … really? What does that mean?
• Track --> too many options. None seemingly optimized for daily stand-ups which is the #1 tracking activity in Scrum.
• The "Task Board" doesn't work unless your stories have been broken down into tasks. OK, maybe that's why you call it a task board, but not everybody sees value in further decomposing stories. I don't, rendering the task board useless. Even if I did want to break stories down into tasks the view doesn't lend itself well to, say, sharing via WebEx for a stand-up with a distributed team.
• The URLs are useless: I can't copy/paste a URL and IM it to a colleague. No matter what I'm doing the URL is always https://rally1.rallydev.com/slm/rally.sp

OK roasting more or less over. Given that the product is a tool for use by agile teams and that it's developed using agile principles and practices, I'm not convinced it's an especially good "advert" for agile. I'd like to think that if Rally were being truly effective here then there would be a much nicer product as a result.

This is of course all just my own personal opinion, and I freely admit I have not worked with the product for that long. Maybe I'll grow to love it and think it the best thing since sliced bread. Presently however I do not. I think there's a lot of things that could be done to improve above and beyond adding things like the Epic Progress app (do we really need yet another view of progress?). I suspect this scathing rant bars me from applying for the Product Owner job in Boulder ;-) but if I did have that job, these are the things *I'd* be prioritizing high on my backlog. I note they are also looking to hire a Usability Analyst which has to help, although they're only looking for someone with 2+ years experience and I wonder if they don't perhaps need someone a tad more seasoned...

Scrum, Crop Rotation and the Fallow Field

Since the dawn of agriculture (well, maybe…certainly some when in the last 10,000 years) farmers have realized that growing the same crop in the same field, year in, year out depletes the nutrients in the soil. Eventually this leads to the field failing to produce as well as it used to, or even becoming unusable.

One might see a parallel here with scrum teams: although the rhythm of short release cycles, time-boxed sprint planning meetings, daily scrums, sprint reviews and retrospectives provide a stability, might they not also eventually lead to burn out and reduced productivity? I venture to say that they might.

So can agricultural techniques offer any further parallels that might inspire us with ideas for how to help keep a scrum team producing? Well, with the employment of a little imaginative (some might say dubious) metaphor, I believe they can.

First, consider the idea of leaving a field fallow: the idea here in farming terms is that one might operate a three field system, with only two fields at a time being planted. The third will be left empty, or fallow so that it might recover. Things shuffle around so that each season a different field is left fallow.

So what would it mean to leave a scrum team fallow? Simple. After a successful release, have a sprint with no formally planned activities. Sound wasteful? Consider that this would allow for the team to celebrate the release, decompress from the work and general renew their energy levels. In addition there could be some planning activities or less rigidly time-boxed investigatory work in anticipation of the next release cycle.

But there’s more. According to Wikipedia, the Romans and several civilizations in Asia and Africa used more sophisticated crop rotation methods to keep their fields productive without having to leave them fallow so often. In these schemes, by carefully selecting the right crops they were able to restore the nutrients depleted in one season with soil enriching crops subsequently.

I think the parallel for a scrum team is the idea of working on something different to the main product they are responsible for during a release cycle. This might be helping out with a different product, pursuing the development of some tool or infrastructure they think would help the team in future, training or other creative ideas.

As a child I can remember my grandmother offering up many pieces of advice, including the notion that "a change is as good as a rest." Personally, I’ll take a rest over a change any day, but in truth both work. And there’s no reason not to employ both as productive investments in the overall health of a scrum team between release cycles.

Raspberry Crumble

Ingredients

• Some raspberries (quite how many depends on size of baking dish, preference etc. but probably between half and one pound is good.

4oz butter. Must be fridge-cold and cut into small lumps.

1 cup all-purpose white flour

1/3 cup brown sugar

Making it...

Stick the raspberries in an ovenproof baking dish of some kind. If you have a sweet tooth sprinkle with a little sugar.

In a blender or foodprocessor, blitz the butter, flour and sugar briefly. This is the cheats way of making it form a kind of breadcrumb like texture. Don't do it for too long and don't expect too much. If you want it to be nicer use the old fashioned approach of combining with fingers in a bowl.

Put the crumble mixture over the raspberries and bake in over for 40 minutes at 350F.

We like it with copious amounts of Hagen Daz vanilla ice cream, but real custard is also awesome too.

Mountain Living Considerations

A friend of mine is considering moving up from the plains along the Front Range of Colorado to the higher elevations such as where I live. Here are a few things I think anyone contemplating such a move might want to know...

• It gets cold in the mountains so house orientation, big windows for passive solar heating, a good heating system, woodstoves as backup (and even primary heating source since they are cheap) and quality home construction/insulation are important
• Snow slides off metal roofs, asphalt not so much.
• New houses have new septics, old houses may not. They are expensive to replace.
• You want a good well, i.e. one that has a good flow. Don’t compromise.
• Mud drives are muddy in spring for weeks. Stone chippings can hide this a bit but ultimately, it seems, you will still get muddy unless you bank on frequently topping up the chippings. Asphalt drives work but look completely out of place to me.
• Steep drives are a pig to clear of snow. Although you could contract somebody to do it that somehow defeats the sense of independence one gets from living here.
• Limited cellphone coverage. AT&T where I am and much of Gilpin.
• Check broadband internet availability
• Having lots of aspen trees on the lot is awesome because you might lose pines to beetle…
• Note where school bus routes are since those roads get plowed by the county first
• Surrounded by trees, by creek/pond/lake, with a view. Pick one, or prepare to pay a premium….
• Housing styles vary from Front Range bedroom community transplants to super rustic cabins. This may or may not be important to you but some people don’t care for houses that look way out of place. Personally I favor a home that looks like it belongs in the mountains.
• Steep narrow roads aren’t as bad as you think in winter with 4WD and snow tires. They are much more exciting in spring with the constant thaw/freeze cycle. You do need those snow tires though.
• Winter is undeniably longer, but it’s still sunny up here just like the rest of Colorado. You can get your warmth fix by going on vacation to the plains a few thousand feet below.
• It may take a bit of getting used to, but actually not having Safeways, Target etc. just around the corner is kinda nice. A little more planning to avoid meal disasters perhaps, but its not too bad.

Lastly, something I read years ago that left me eager to move to the mountains is this primer on mountain living from Gilpin County. You'll either read it and want to move tomorrow, or it will scare the crap out of you and you'll never entertain the idea again.

Autonomy. Mastery. Purpose.

Many thanks to Steve who helped out with this. I actually re-purposed our internal post for here and left out 99% of his work (no offense, just wanted this to be "my" post rather than posting your stuff Steve without permission...and I'm too lazy to ask ;-)

Here's my list of recommended best practices for the three different roles in scrum:

Scrum Master

Product Owner

Team Member

Yes that’s right. The lists are empty. Well, why is that you may wonder? Funny you should ask…

First of all "best practices", besides being a rather hollow business-speak term, are things that don't really work everywhere for complex pursuits like software development. Principles can help guide you, examples of what other people have tried might prove inspirational. But "best practices" as typically bandied about today are not really right for broad Scrum adoption in a corporate setting. Go ask any of the signatories of the original Agile Manifesto.

Standardization and one-size-fits-all mentality is a very command-and-control approach to applying Scrum and completely at odds to what it’s really trying to tell you. Most intelligent, thinking people (that is the kind we want working here, right?) don’t "own" things that are foisted upon them. They might tolerate them. We want people to own things. That’s how good stuff^TM gets done.

Experimentation, discovery, retrospection and continuous improvement are at the heart of scrum.

Let's have a quick reminder of the Agile Manifesto (www.agilemanifesto.org) where we value...

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Really we’re missing the point if we try and find and mandate best practices for Scrum within a large corporate environment.

So what should we be doing?

Again, funny you should ask...

In his book, Drive, Daniel H. Pink explains how intrinsic motivation is key when it comes to work with even the most rudimentary cognitive component. People are looking for three things: autonomy, mastery and purpose. Given what my company does (help bring novel drugs to market as quickly and safely as possible) we should not be short on purpose. We just set things up to afford people as much autonomy and opportunity for mastery as we can and we’re golden. There's no point writing more on that when instead you can watch this excellent presentation of the research behind this in the following short video.

If you’re sitting there wondering if you can spare the 10 minutes needed for this video just watch it. If you play any role in managing or influencing teams of people creating software, watch it. If you care about how to truly motivate them, watch it. If you still think that we should be adding more and more process and templates and documentation and best practices to “enforce” adoption of a “standardized” form of scrum, watch it.

We have to trust the teams to learn and grow, not dictate exactly how they will implement Scrum.

OK, if you really want a best practice for Scrum here is one: DON'T BE LATE TO THE DAILY SCRUM!

Cucumbers, and why it suddenly matters that I suck at regular expressions

This week I have been playing with a new testing tool. Well, sadly not all week as my wonderful HP 8710 laptop snuffed it on Monday morning and despite my best efforts could not be coaxed back to life. This blog post (and my playing with the new testing tool) comes to you from my new Lenovo T410. It’s a bit “toy sized” but it does boot in under 10 minutes (a welcome contrast to the HP) and the build quality is better (although it’s hardly got the aesthetics of a MacBook Pro.)

Anyway, the new testing tool I’ve been playing with is Cuke4Nuke which allows Cucumber to work more easily with .NET projects. That sentence probably is pretty baffling so let me back up and explain what all this Cucumber-y themed goodness is about.

You have (hopefully…) heard of Test Driven Development (aka TDD) as an approach to developing software. For those not too clear what it is, a quick explanation goes like this: Instead of writing your application code and then writing a unit test afterwards (you are writing unit tests, right?) you start out writing your unit test first. Now, this may at first blush sound somewhere between stupid and impossible. If you’ve only heard that one line explanation you’re missing a subtle but key point: when you start writing that unit test first, you need only write enough for it to fail. Then you go remedy that fail by writing production code. Obviously at the outset that point is reached pretty quickly…the moment you reference the class under test (which doesn’t exist yet!) your test will fail. You can’t even compile it:

public class TestWidget
{
    public void Widget_Assemble_Success()
    {
        Widget w = new Widget(); // can’t compile
    }
}

So then you switch to your application production code and implement the class under test. But (and this is important) only enough to make the test succeed. At the outset that doesn’t require you do any more than simply create the class:

public class Widget
{
    //implementation to be done
}

At this point your test will now compile (and pass, kinda) and you can work more on the test until, once again, it breaks or fails. In the example here that’d be trying to call the Assemble() method on the Widget class. Again we couldn’t compile as this method doesn’t exist in the production code class. We’d remedy that over there and then finally add some kind of Assert into our test, which would fail and then finally we’d get to the meat of implementing the method under test.

That little “dance” back and forth between the test and the class under test may sound a little convoluted and unnecessary, but it’s what helps tease out the initial design of your class under test. It’s what puts the “test driven” in test driven development. It really makes you think about the API, the method signatures, naming etc. of your class under test and after you have the “aha” moment that comes with this approach it’ll all fall into place. Suffice to say I’ve found it really helps not just with driving the design but also with maintaining focus too. Trying to write sizable amounts of production code before unit tests was always liable to lead to me wandering all over the place. That could just be me of course.

OK, back to Cucumber. Cucumber is not in fact a TDD tool or framework. But it’s related. It’s a BDD (behavior driven design) framework. This is a step forward in the evolution of test first development, and for me brings together a number of interesting threads:

• user stories


• specification details, acceptance criteria


• customer/product owner involvement

There’s a (sometimes unpopular) truism in software development: it doesn’t really matter what the requirements say, the software does what it does. The truth is in the source code. That is the only artifact that is up to date and can unambiguously (hard to read code aside) tell you what the software does.

Now what’s really cool here as far as I’m concerned is that Cucumber (and other BDD related tools) let you bring the specification in alongside your source code. Not just in a “store the requirements doc in version control” sense, but something much more useful. Your specifications in Cucumber are written as a series of features (think stories) along with some scenarios (think concrete examples of expected behavior) which then get hooked up with some glue code to the actual production code to test that they work. In other words, the plain English requirements are now an executable specification. With the click of a button you can test which of your features are correctly implemented.

This makes a boatload more sense than deriving tests from a requirements document. The tests *are* the requirements document.

This elegant brilliance (yes, I gush) comes at a price however.

Firstly, your feature requirements have to be written in a particular format. This doesn’t actually seem to be too onerous, and results in some pretty readable material. Here’s an example feature for a system designed to act as a database of hiking trails:

Feature: Search for trails
    As a hiker
    I want to find nearby trails
    So I can go for a hike

    Scenario: Search for trails nearby
        Given my location is "Rollinsville"
        And I'm willing to travel up to "10" miles
        When I search for nearby trails
        Then "Crater Lakes" is listed in the results

The key part here is the “given, when, then” section. This is what we will end up tying to an automated test. Above it, as you can see, is our user story in conventional format providing background and context.

You can imagine that we might have additional scenarios here related to finding trails that allow dogs, disallow mountain bikers and ATVs etc.

Despite the constraint of the specific structuring required here (and there is more richness available than this simple example) it seems to me that you could get a long way with this approach, and it’s not beyond the realms of possibility for these features to be directly authored by the Product Owner or business analyst.

The second portion of the “cost” of this approach is implementing the code to tie these scenarios to the system to test it. This is where regular expressions (regex) and my weakness with them come in to play.

If you’re not familiar with regular expressions, they basically provide a very succinct means of performing pattern matching operations on strings. See http://en.wikipedia.org/wiki/Regular_expression for more information.

To connect the scenarios up involves writing regular expressions that match the text in the “given, when, then” stanzas and pulls out the key inputs to the tests. In the example above this would be the location (Rollinsville) the distance the hiker is prepared to travel to a trailhead (10 miles) and the success criteria (Crater Lakes).

Those regular expressions, which are wrapped up in C# Cucumber attributes on methods to identify the given/when/then processing look like this:

[Given("^my location is \"(.*)\"$")]

[Given("^.*travel.*\"([0-9]*)\".*$")]

[When("^I search for.*$")]

[Then("\"(.*)\" is listed in the results")]

All of which may or may not read easily for you, depending upon your experience with regex. Mine amounts to little more than a fairly limited quantity. I’m pretty excited about the possibility of executable specifications, BDD and testing applications this way and plan on trying it out in anger over the coming months.

And this is why it suddenly matters that I suck at regular expressions.