Article

Definition of a Feature (Given … When … Then)

Alice Toth

Published on: March 19th, 2009

This post was previously on the Pathfinder Software site. Pathfinder Software changed its name to Orthogonal in 2016. Read more.

At some point in their career, most everyone in software development has encountered the client who paints a very eloquent picture about their fantabulous idea that’s going to revolutionize the [insert industry vertical here]. However, as time goes on you realize the client is staying at the 60,000-foot level, and while that may make for great conversation, it’s less than ideal for actually developing something. The trick, then, is to get them to climb down into the trenches and define the details before you have to start writing the code.

At Orthogonal, we’ve been involving clients in creating business-driven scenarios to define a feature, i.e., what does ‘create accounts’ really mean. These scenarios walk through the different tasks of a feature and identify the expected behavior and outcome based on the user’s actions. Although they follow a specific format (context, events and outcomes), they are written in plain English that can be understood by all team members.

Given that something has already happened (e.g., user logged in) [context]
When the user does something (e.g., clicks on a button) [event]
Then this is what should happen [outcome]

Very straightforward. Very understandable. And once written, the client must review and sign-off on the scenarios before we begin to code.

The benefit of this process is that we’re not asking the client to do the impossible (write the nitty gritty details); we’ll take the first pass at bringing the 60,000-foot idea down to the nitty gritty. But, we are asking that the client read the scenarios and approve them as the definition for the feature … or get back to us with improvements/additions and then approve the scenarios. Once approved, though, the scope of the feature is now defined and understood by both the business stakeholder and the development team.

Because writing scenarios is an iterative process and one that must involve the client directly, it does add a bit of up-front time to a project. However, the cost is worth it because the project’s features are fully defined and agreed-upon prior to coding, thereby reducing ambiguity to the developers and allowing the project manager to better manage scope creep. Plus, we now have our acceptance tests for what defines the feature as complete.

Even better, though, is that we’ve found involving the client in creating the details of a feature definition reduces, if not eliminates, the “oh that’s not what I was thinking of” comments come demo time.