Feature Cards: A Tool for "Just Enough" Planning

Applies to: Agile

Authors: Greg Smith and Ahmed Sidky

Get this book in Print, PDF, ePub and Kindle at manning.com. Use code “MSDN37a” to save 37%.

This topic contains the following sections.

• The Structure of a Feature Card
• Copyright

When we plan an Agile project, we try to do so in a lean fashion. We want to gather the minimal information needed to prioritize, sequence, and estimate a feature, so we can deliver high-value features as soon as possible. We can do this without creating detailed functional specifications and without guessing at all the tasks that we may need to complete, by creating feature cards.

Feature cards start the discussion between the customer and the project team and support reaching common agreement on what a feature entails. In this chapter we will show you how much information to place in a feature card and how to involve your team in the creation of the cards; we will also discuss the limitations in using cards.

To help you better understand feature cards and the feature-card exercise, let’s look at the structure of a card.

The Structure of a Feature Card

Feature cards are similar to the user stories used in Extreme Programming (XP) development. We also often use the term feature shell to describe a feature card. The card provides enough information to plan a feature and discuss it quickly. The size of the card also makes it easy to track a feature and re-plan when necessary.

Let’s look at a completed feature card (see Figure 12.1).

Figure 12.1 A completed feature card for the Auctionator. A feature card provides just enough information to prioritize a feature. Additional dialogue or documentation is usually needed to support coding.

The following are the feature card’s fields:

• Feature ID. A unique number assigned to the feature. Numbering becomes more important in large projects, when features can have similar names.

• Feature name. A high-level description of the feature. It should describe the value of the feature to the customer.

• Description. A deeper description of the functionality.

• Feature type. Whether the feature is for the customer or for the system itself (a technical feature type). An example of a customer feature is the ability to bid on an item. An example of a technical feature is “create an email web service.”

• Estimated work effort (ideal days). Total labor estimated to be needed for the feature. It’s a summary of the task estimates on the back side of the card. This field is used only for the first iteration of a project.

• Story points. A measure of the relative size of the feature, not an estimate. Story points will be your main metric for determining capacity as the project proceeds.

• Planned iteration. The iteration in which you plan to build the feature.

• Customer value (C,H,M,L). Critical, high, medium, or low. The customer’s or user’s perspective of the value this feature provides. Critical means the customer doesn’t see the value of the project if this feature can’t be completed. Customer priorities frequently change after the team discusses all possible options for supporting the requirement outlined in the feature.

• User. Similar to an actor in a use case. For a pilot project, the most common users are buyers and sellers.

• Usage frequency (daily, weekly, monthly, other). Another way to help you determine the value of the feature. Frequent use often implies high value to the customer.

• Requirements uncertainty (H,M,L). High, medium, low. How comfortable the project team is with the customer’s awareness of their need. After the customer described the feature, were you confident they truly understood their need, or was the customer still trying to clearly state the need? If a feature has high uncertainty, it’s difficult to outline a design and the potential code needed. Conversely, if the uncertainty is low, the team should be able to outline a design and build the feature.

• Technical uncertainty (H,M,L). High, medium, low. Tied to the technical risk associated with the feature. Does the project team have a vision for the technology that is needed to support this feature? Do you have experience with this technology? High technical risk means you don’t have experience with the technology, or the technology itself isn’t stable.

• Dependencies w/other features. Do you need any other features in place, or designed, before you can build this feature? For example, your project has a feature that lets you view a seller’s feedback from their previous transactions. Before you create this feature, you need to create a feature that lets you record buyer feedback onto the seller’s record.

• Acceptance. An outline of a high-level user acceptance test. What tests will this feature have to pass before it’s deemed complete?

We frequently hear project teams ask how they can go from a feature card to working code. Many teams are used to receiving a detailed functional specification. A feature card doesn’t have the detailed information they have received historically.

The answer is that feature cards aren’t supposed to replace functional specifications. The feature-card exercise helps your team assess the level of documentation or information that is needed to build the feature. This documentation may include use cases, wireframes, mockups, usability studies, or other requirement artifacts.

Note

How Much Documentation for Requirements?

We’ve seen teams build simple features from the information on the feature cards. As features become more complex, teams bring in additional tools such as use cases, workflow diagrams, wireframes, screen mockups, prototypes, and information-flow diagrams. This is where agility and team knowledge come into play. The methodology doesn’t dictate the documentation needed for each feature: the team does.

The Right Amount and Type of Information

Teams also want to know when a feature card is too big and when it should it be split into separate features. The best way to determine this is to walk through the steps needed to support the feature.

Project-team members grab a feature card during the feature-card exercise and walk through it on a whiteboard. They review potential workflows to support the feature and the steps needed. This workflow discussion usually identifies hidden features, and the team can create additional feature cards. You’ll see an example of this process when Acme Media performs its feature-card exercise.

You can also use these guidelines to determine whether your feature cards contain the correct amount and type of information:

• The functionality described is understandable to users.

• The card describes functionality, not an implementation task.

• There is enough information to estimate the implementation effort.

• The card generally represents 1–10 days’ worth of effort, or it fits in your story point scale.

• Each card is as independent of the others as possible.

• The card is testable.

With experience, you and your team will develop a good feel for when the information is sufficient.

Additional Feature-card Benefits

In addition to providing the correct amount of information to initiate planning, feature cards also provide these benefits:

• Customer focus. Many requirement-gathering processes can quickly turn into task meetings. When this happens, the focus becomes how to build a feature, not what the customer needs. Feature-card titles focus on the customer. You provide the “ability to” for the customer. Your titles are user centric, and so are your acceptance tests.

• Identifying risks early. Feature cards have two fields that ask the team how uncertain they are about requirements and about the technology that will be needed. fications were complete and the team started working on detailed design. In an Agile world, the developers and other team members are involved early in the process to identify risk. This gives you more time to work through the risks, or an opportunity to cancel risky, noncritical features.

• Common understanding. We’ve worked on many projects that had highly documented requirements, but whose team was still confused about the feature. This frequently happens when one person writes the detailed specifications and then tries to explain a 30-page requirement document to the team. The feature card starts the requirements process by letting the entire team see the direction the feature is taking. This common understanding leads to quicker delivery and quicker decisions, because the team doesn’t have to constantly reference and interpret requirements documentation.

Now that you have a feel for the structure and benefits of feature cards, let’s look at the process you use to create them.

Previous article: Agile Management

Continue on to the next article: Creating Feature Cards

Copyright

©2009 by Manning Publications Co. All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by means electronic, mechanical, photocopying, or otherwise, without prior written permission of the publisher.