Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Agile Development and Executable Requirements: Towards Team Maturity

Learn how to introduce executable requirements into your Agile development process, a sure technique for making your Agile team more effective.


advertisement

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

Role

Amount Spent

Points Before Stay

Points After Stay

Frequent Traveler Member

500

10000

11500

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:

Role

Login name

Password

Display Registration?

Frequent Traveler Non-Member

   

Yes

Frequent Traveler Member

John

123

No

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.



Click here for larger image

Figure 1. Sample C# code of what a class would look like for implementing FitNesse with our story



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap