Features: An Agile Introduction

The features in Figure 1 are basically a formalized version, wording wise at least, of traditional features. Another formalized approach is to write features as shall statements. For example “calculate the average mark on a transcript” would be worded “The system shall calculate the average mark on a transcript”. Although the wording changes slightly in the end features and shall statements are effectively the same thing in my experience.

Although one of the primary advantages of features is that their small size makes them easy to estimate and to implement their size also poses a problem in that one feature by itself rarely provides significant value to stakeholders. The solution is to organize features into groups called “feature sets”. Figure 2 depicts how the features of Figure 1 would be organized into three feature sets – Transcript, Enrollment, and Parking Passes. As you can see each feature set contains two or more related features.

Figure 2. Feature sets.

From a requirements point of view features are to FDD as user stories are to XP – they’re a primary source of requirements and the primary input into your planning efforts. However, from a size point of view feature sets are much closer conceptually to use cases. Features are estimated and prioritized in a similar manner to user stories. Because features are so simple to create it is common to use very simple tools – such as index cards or a spreadsheet – to capture them.

Source

This artifact description is excerpted from Chapter 7 of The Object Primer 3rd Edition: Agile Model Driven Development with UML 2.