Practice: Feature Cards

Practice Feature Cards

Objective

The purpose of feature cards is to provide a simple medium for gathering basic information about features, recording high-level requirements, and developing work estimates.

Discussion

Feature-based development is intended to be customer- facing development. Feature cards are used to identify, but not to define, features. Feature cards [2] act as agreements between customers and project team members to discuss (and document, to the extent necessary) detail requirements during an iteration. Discussion is critical to understanding, which in turn is critical to estimating. Feature cards identify features that the customer wants in the product. For large products, hardware component or business activity "group" cards (from the feature breakdown structure, or FBS) can be used to organize and plan individual feature lists. A group card may encompass 10, 15, or even 20 detail features.

[2] In Extreme Programming these are called story cards. Other agile software development methods may use similar termscomponents, use cases, backlog itemsalthough they are not identical concepts.

Feature cards, as illustrated in Figure 6.2, are 4x6-inch index cards on which the project and customer team members record the information gathered in their requirements discussions. The critical piece is the discussion. As in other agile practices, the entire team, not the project manager alone, is responsible for interacting and producing the feature cards. The project manager facilitates the discussion and monitors action items, but agile planning is a team sport.

Figure 6.2. Sample Feature Card (Requirements Uncertainty Scale refers to the exploration factor categories; E=Erratic, F=Fluctuating, R=Routine, S=Stable)

The cards themselves are important. They provide a mobile, tactile medium that team members can write on, shuffle about on the table, and have conversations around. Once data gets entered into a formal medium people are less likely to change it. The information on the cards becomes the product of the team's collaborative effort and a focal point for mutual understanding of the product at a detail level.

A few key items of information should be recorded on feature cards. Supplementary documents can be used for detailed requirements information. Typical items on feature cards are:

• Feature identifier and name
• Feature description: a sentence or two that describes the feature in customer terms
• Feature type (C=customer domain, T=technology domain)
• Estimated work effort: the estimated work effort needed to deliver the feature, including time for requirements gathering, design, coding, testing, and documentation [3]

  [3] Many project managers and team members are accustomed to estimating activities or tasks , not features. When estimating features, it is important to cover all the activities involved.

• Requirements uncertainty (erratic, fluctuating, routine, stable): an "exploration factor" for a specific feature
• Feature dependencies: dependencies that could influence implementation sequencing
• Acceptance tests: criteria the customer team will use to accept or reject the feature [4]

  [4] These criteria could be implemented in specific test cases or included in a customer focus group review. Figuring out acceptance criteria compels the customer team to define what "done" means.

Often customer-recognizable features and technical activities provide orthogonal views of the same problem space. In planning the next iteration for a project (as I discuss later in this chapter), the team first turns the feature cards over and lists the technical activities required to specify, design, build, test, and document the feature. To progress from a customer-recognizable unit of work to a reasonable technical unit of work, there will probably be a reaggregation of that work. Technical activities from several customer features (e.g., multiple features displayed on a control panel) may be aggregated into a single technical work package. Design and technical architectures will influence this reaggregation.

For larger projectsthose with 1,000 features, for examplethe feature cards will probably require some form of automation for sharing among feature teams. While each individual team may use cards for its own planning sessions, sharing across multiple teams would prove difficult. Distributed teams and teams working under formal contracts may need to automate the cardsor more correctly, the information on the cardseven for smaller projects. As with other agile practices, the team should let the need dictate the use and formality of the documentation.

The level of requirements uncertainty and the technology risk factors will influence not only feature scheduling, but also the team's approach to implementing a feature. Generally, high-risk features (erratic or fluctuating) will be scheduled in early iterations so that the team can determine first, if the feature can be implemented at all, and second, if it can be implemented, if it will take more time or money than anticipated to implement it. If the requirements are difficult to gather or pin down, a series of discovery prototypes may be required. If the best design option isn't clear, a series of design experiments (simulations, quick throw-away implementations ) may need to be conducted . Highly uncertain features may require additional research work before they can be planned at all. Even within a product there will be technology areas or features that run the gamut from low to high risk. Treating each with an approach geared to the level of risk will improve both effectiveness and productivity.