Agile User Stories Contrasted to Formal Requirements

The Computer Society of the Institute of Electrical and Electronics Engineers (IEEE) has published a set of guidelines on how to write software requirements specifications. The IEEE recommendations cover such topics as how to organize the requirements specification document, the role of prototyping, and the characteristics of good requirements. The most distinguishing characteristic of an IEEE 830—style software requirements specification is the use of the phrase “The system shall…,” which is the IEEE’s recommended way to write functional requirements.

From an agile development point of view, developing well-defined requirements prior to coding has some major flaws. It implies that the software was at some point sufficiently well known for its scope to have been fully defined. This is usually not the case. The waterfall approach assumes that software is complete when it fulfills a list of requirements, rather than when it fulfills the goals of the intended user.

What Is a User Story?

A user story is an informal statement of the requirement. With agile development, a user story is a software system requirement formulated as one or two sentences in the everyday language of the user. User stories are used for the specification of requirements (together with acceptance tests). Each story is written on a small 3 × 5 inch paper note card to ensure that it is not lengthy.

An example of a user story might be, “When a user attempts to use an expired credit card, the system prompts him to use a different credit card.”

The process of breaking down a user story is important because it helps one think about how to develop and test the functionality. Many people disaggregate a user story into tasks and then estimate them because they are smaller units of work and can be estimated with less inaccuracy. The goal is to track the number of running tested features. I want to know how many user stories are passing.

Agile Planning

In agile planning, we usually have to estimate how much work a story will take. When developers write functional tests before design and coding, they are more confident the user story is complete. This also aids in user story estimation. That will make the release planning easier.

The following are some useful agile planning tips:

1. Schedule short-term: As agile planning is an evolutionary process, it is difficult to plan long-term.

2. Do not overemphasize Gantt charts: As the requirements and activities are rapidly changing and evolving, you may find yourself spending all your time updating Gantt charts

3. Involve the team with scheduling: The team should be active participants in the project to gain “buy-in.”

4. Define short iterations: Limit the development iterations to 2 to 3 weeks, which will also limit “scope-creep.”

5. Train the team: The team may not have worked on agile projects in the past and will not understand the process unless they are exposed to training and facilitation workshops.

As part of the planning process, it is imperative to prioritize user stories (as with any requirements). This can be achieved with a User Story Prioritization Model, as shown in Figure 31.1.

The following are the basic elements of the model:

1. ■ The relative benefits of focusing on a user story

2. ■ The relative penalty for not focusing on a user story

3. ■ The relative cost to implement a user story

4. ■ The relative risk to implement a user story

Each of these elements are input to the model for each user story and weighted. The result is a score displayed on the last column, which can be sorted in descending order to show their relative priority. (The Prioritization Model is located in the CD that came with this book.)

Types of Agile Testing

Test-Driven Development (TDD) is a software development technique consisting of short iterations where new test cases covering the new functionality are written first, then the production code necessary to pass the tests is implemented. The availability of tests before actual development ensures rapid feedback after any change.

Practitioners emphasize that test-driven development is a method of designing software, not merely a method of testing. The first step is to turn acceptance criteria into tests, so one of the most important factors for us is to find tools that support us in achieving that goal. Functional testing tools are actually a very important part of the testing process. Given that there are already many unit testing tools available for nearly every programming language, a suitable functional testing tool seems more important for testers.

For Web applications, functional testing tools such as Selenium, Watir (Watin, Watij), and Sahi are available. Abbot is useful for Java GUI applications, NUnitForm for Windows Form applications, and Microsoft UIAutomation Framework for a wide range of Windows applications. More “heavy” tools such as HP’s Quick Test Professional (QTP) could also be used.

When a user story is to be implemented, a more formal acceptance test must be written by the customer to ensure that it is later possible to determine whether the goals of the story have been fulfilled.

Acceptance tests are created from user stories. During an iteration, the user stories selected during the iteration planning meeting will be translated into acceptance tests. The customer specifies scenarios to test when a user story has been correctly implemented. A story can have one or many acceptance tests, whatever it takes to ensure the functionality works.

An example of an acceptance test for the foregoing credit card story might be:

1. Test with Diner’s Club, Visa, MasterCard, and American Express (pass)

2. Test with Visa Club (fail)

   

   Figure 31.2   User story versus test cases.

3. Test with good, bad, and missing card ID numbers

4. Test with expired cards

5. Test with different purchase amounts (including one over the card’s limit)

Acceptance tests are black-box system tests. Each acceptance test represents some expected result from the system. Customers are responsible for verifying the correctness of the acceptance tests and reviewing test scores to decide which failed tests are of highest priority.

Acceptance tests are also used as regression tests. A user story is not considered complete until it has passed its acceptance tests. This means that new acceptance tests must be created with each iteration or the development team will report zero progress.

The matrix shown in Figure 31.2 is a useful way of documenting the relationship between user stories and acceptance tests.

Compliance Testing

Compliance testing determines that a product implementation of a particular implementation specification fulfills all mandatory elements as specified and that these elements are operable.

Compliance testing may become more stringent over time, especially as a particular implementation specification matures. Regardless of how a software audit is initiated, the process is rarely anticipated and often results in valuable resource loss. Beyond the resource strain, software audits require additional expenses to deploy asset management services to prevent future compliance breaches. This chapter presents a risk assessment survey to help determine if your organization can adhere to a software compliance audit and what level of risk it faces.

The following are six basic steps for enabling software management to ensure it has the documentation to satisfy an audit:

1. Review existing software licensing agreements.

2. Take an inventory of existing IT assets.

3. Compare inventory to purchasing records to determine problematic areas.

4. Uninstall noncompliant software.

5. Implement management policies for use and license compliance.

6. Maintain new standards and processes.