Agile development processes can help teams to plan and make the process transparent to management. Planning sessions, release plans and other techniques that help Agile development teams keep their work transparent are helpful. Those techniques should help all development teams deliver software at higher quality with more predictable timing. Teams that want to be highly productive need to focus on their engineering techniques as well. This article focuses on the practice of executable requirements. Agile development teams that utilize executable requirements, maintaining them consistently and well, can be considered mature.

What Is a “Highly Productive” Agile Development Team?

Clinton Keith described highly productive teams or hyper-productive teams as “… teams that have achieved a state of ownership, commitment and collaboration that allows them to be far more productive in creating ‘product value’ on a regular basis.”

For our purposes, hyper-productive teams are performing at a significantly higher level than previously. I would categorize this as two to three times more than previously measured productivity. A team that is completing an average of 7 stories per iteration or release cycle would achieve 14 ? 21 stories per iteration or release cycle. This velocity is achieved without impact to quality. These should be high-quality releases.

Executable requirements assist teams to be highly productive by clearly defining what done means. This is achieved through encouraging the conversations that need to take place between product owner and teams.

Defining Executable Requirements in Agile Development

Executable requirements are requirements defined by business that can be hooked up to the software code. This can be done using different tools, including custom code. The most common tools include FitNesse, Cucumber and other tools we will mention later.

If the code cannot be hooked up to the requirements and shown to stakeholders, then these are not executable requirements for the purposes of this article. For instance, unit tests created by developers are executable, but they are not executable requirements. Business members of the team are not going to view and work on unit tests, which are tests exclusively for developers.

Using executable requirements helps in the following ways: Immediately, during the sprint, it allows the team to understand when they are done with the story easily. In the future, as these requirements are run consistently against the code base when code is checked in, they help to ensure that those requirements are tested against in the future.

Getting Your Agile Development Team Started with Executable Requirements

To get started with executable requirements, your team must first decide how to write those requirements. You may choose to use a format utilizing columns and rows. This would be a great fit for the tool FitNesse. Let’s say your story has something like the following as an acceptance criteria: If a frequent traveler stayed at our five-star hotel for a cost of $500, they will have 1500 points credited to their account. Below is how you could show that AC in a column and row fashion.

Table 1: Column and Row Requirements Example

Placing the acceptance criteria in a spreadsheet-like format works well for the above story. This technique has drawbacks for non-technical people or those not comfortable with spreadsheets. Most product managers I have worked with are able to understand written acceptance criteria easier than those presented in a spreadsheet manner. Keep that product manager in mind when choosing how to write your acceptance criteria.

Another option is to use behavior driven development (BDD) style acceptance criteria. BDD is known as a more language-driven option. BDD is detailed in a later section.

Using FitNesse

As mentioned above, FitNesse can be utilized by the team. To get your team started using FitNesse as your executable acceptance criteria, the team needs to start by formatting the AC for a story in a spreadsheet-like manner.

To begin this task, create executable requirements when verifying your acceptance criteria with the product owners. When someone from the team picks a story to work on, they need to work on the acceptance criteria with all team members, before development starts. This could mean QA, Dev and product owners or any other members that make up your team. During this time, discuss any other testing that needs to take place that involves verification by the business.

Fitnesse Example

In the instance of our frequent traveler application, let’s use this story to work with:

As a non-frequent traveler member visitor to our website, I want the non-member to be able to browse the hotel properties and be able reserve them in order to capture sales from non-members.

Now let’s work on the acceptance criteria. Since Agile methodology recommends conversations over contracts, the importance of the team working together on this AC is in the conversations. The executable requirements just document what went into those conversations. In this case the discussion uncovers that the person on the website who is not a member should see a link to sign up for the frequent traveler program. In a spreadsheet format, this would be set up like so:

As you can see, we added two scenarios as the acceptance criteria. The first row is the main path that shows what the story asks for explicitly. The second row takes another option and asks what happens when a frequent traveler logs in. In this case, we do not want the registration link to display. Expect the teams to continue working on scenarios.

The team can then transfer these criteria to the FitNesse server. FitNesse is a server-based product that is a central repository for the AC. To hook the above example into a FitNesse server, you need to create fixtures. Below is a quick overview of how you might create fixture code to hook the above test into FitNesse. This is not a primer on how to do this, but a quick start reference. For more details on how to utilize FitNesse, it is recommended that you view the Fitnesse website. Image 1 below shows how C# code might look for implementing this.

• Given
• When
• Then

There are many tools your team can use to implement the executable part of this acceptance criteria. These tools include, but are not limited to Cucumber, rSpec and SpecFlow. These tools allow you to take that cadence mentioned above and hook that scenario into your code.

Once again, the actual acceptance criteria can be written in collaboration with other team members. The story is pulled to be worked on. The team then gets together, developers, QA, product managers, etc., and they collaborate on the scenarios that are needed to ensure the story is done. In other words, when these criteria are met, the team is confident that the story is done.

Just a note to exercise a little caution here not to be too inflexible with this definition of done. There have been times when a product owner sees the story completed according to this specification, and the story meets acceptance criteria. The product owner sees a demo of the “done” story, and the result is not what she expected, but is considered “done” by those criteria. At this point, if the team has shown this prior to the end of a sprint, the product owner may ask to tweak the story a little. If the team is okay with that tweak, they can just fix it and the acceptance criteria along with it. This feedback loop helps the team deliver a more valuable product to the customer.

Remember these acceptance criteria are helping us to have conversations within the team. How the above scenario is handled should be up to the team.

BDD Example

In BDD, the user story starts with the business reason first. This is the main difference between our story shown in the FitNesse example and this story. BDD asks for this, since the business reason should inform us why we are doing this story.

• In order to capture sales from nonmembers.
• As a non-frequent traveler member visitor to our website,
• I want the non-member to be able to browse the hotel properties and be able reserve them.

The Acceptance Criteria in BDD style for this story could be something like this:

Scenario 1

• Given a first-time visitor to Eric Hotels website
• When I access the reservations page
• Then I see a “Frequent Traveler Registration” button.

Scenario 2

• Given I am a visitor to Eric Hotels website
• And I am a member of the frequent traveler program,
• When I login as Eric
• And my Password is 123
• And I click login
• And I access the reservations page,
• Then I cannot see a “Frequent Traveler Registration” button.

These scenarios could be placed on the back of story cards or entered into your tracking tool. Most importantly they can now be placed into your code, ensuring the executable part of this article! In a tool like Specflow, the above scenarios could be copied and pasted as a test, and hooked up to code to test.

One of the benefits of the BDD tools is that they are clients that run along with the development environment. This makes it easy for developers to run the tests right away on their computers. With a server tool like FitNesse, developers need to compile code, copy to a server, run it there, make changes back on the developer computer. The BDD tools are a little more convenient for developers.

Figure 2 shows a screenshot of how the Acceptance Criteria looks in the tool SpecFlow.