Creating Feature Cards

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.

• A Team Approach to Creating Feature Cards
• Feature Cards Compared to…
• Copyright

A Team Approach to Creating Feature Cards

One of our favorite Agile practices is the team creation of feature cards. The exercise lets the team discover features together. The project team uses an organized brainstorm to refine product highlights and convert them into feature cards. At the conclusion of this exercise, the feature cards contain enough information to be prioritized, sequenced, grouped, and estimated. You’ll use this information to create your release plan.

You can expect the following things to happen during the exercise:

• Feature scope will become clearer.

• Additional feature dependencies will be identified.

• Many feature cards will be split into more granular features.

Team members grab blank index cards and enter the information from the Feature Description Document and additional information gathered from the customer.

At this point, your feature cards are born, but they aren’t complete. Figure 12.2 displays a feature card for the Auctionator after the initial conversation with the customer.

Acme needs to complete the following fields on the card:

• Usage frequency

• Requirements uncertainty

• Technical uncertainty

• Dependencies

Let’s join the Acme Media team as they complete their feature cards.

Figure 12.2 A feature card after Acme’s first discussion with the customer. You need to complete the question areas before you can prioritize this feature.

Creating a Feature Card at Acme Media

You complete the feature-card fields by discussing the cards as a team. As each team member creates a feature card, they act as an investigator and speak to other team members and the customer. To see this in practice, let’s watch a team member at Acme Media complete the additional fields.

Gina Wallace is the tester assigned to the pilot project. Gina grabs the feature card for ability to bid on an item (shown in Figure 12.2) and considers the four empty fields. Based on the information Jay, the customer, provided during the feature introduction, Gina knows this feature is at the core of the application and will be used frequently. Gina writes high in the category for Usage frequency.

Gina also remembers that Jay said a user must be registered to place a bid on an item. Gina records feature 4, require user registration, as a dependency for this feature.

Continuing to think about dependencies, Gina also realizes that a user can’t bid on an item unless the item is posted. Gina records feature 10, place an item up for bid, as another dependency.

Next, Gina considers the requirements uncertainty for the feature. How well did Jay describe the feature when the team asked him questions about it? Did Jay have a good feel for the feature’s scope? After spending a few minutes thinking about the card by herself, Gina realizes she still has some open questions, so she asks Jay for more information:

• Will we have a way to refresh the bidding screen so the bidder can keep track of how much time is left to bid, or will the bidder have to refresh their browser on their own?

• Will a bidder have an option to buy it now, meaning can they place a bid so large that the auction automatically ends and they win the item?

• Will a bidder be able to view the bid history for an item up for bid?

Jay considers Gina’s questions within the overall vision for the project. The main vision is to get live quickly with a minimal feature set so Acme Media can stop the competition from eroding the company’s customer base. With that vision in mind, Jay tells Gina that the bidding screen won’t refresh automatically. Jay also feels the buy it now functionality will make a great future feature, but they won’t pursue it in the current release. Jay adds the buy it now feature to the product backlog.

Jay also thinks about the ability to view bidding history. He considers his own experiences when buying items on eBay: he cares about seeing the highest bid but not about seeing the entire bidding history. Jay decides that the ability to view the bidding history will also go into the product backlog, but it won’t be considered for this release.

Gina records the additional information on the feature card and then revisits the question of requirements uncertainty. To her, it seems that the customer has a good feel for this feature and that the basic requirements are well defined. Gina writes low for Requirements uncertainty on the card.

Next, Gina considers the last field: Technical uncertainty. The customer can’t help her a lot here, but she knows Matt, the developer, was involved in the feasibility investigation and can assist. Gina walks across the room and speaks with Matt.

Matt shares the information he’s collected from his feasibility work. He tells Gina that a level of concern exists because the team has never created auction functionality before, but he’s researched competing sites and found free auction source code on the internet. Matt has also looked at the existing merchandise application code and feels the auction functionality can be added to it without much technical concern.

Speaking to the ability to place an item up for bid specifically, Matt feels this feature isn’t technically complex. Matt tells Gina that he’ll mark the feature as having low technical uncertainty. Gina records the information on the card.

Gina needs to complete only one more field. How will she describe an acceptance test for this feature? She goes back to Jay to ask what he will consider a successful deployment of this feature. Jay and Gina identify two acceptance tests for the feature: a bidder’s auction will be successfully recorded into the system, and the bidder will receive a bid-confirmation notice. Gina records the tests onto the card.

She has now completed all the fields she can; see Figure 12.3.

As Gina has been completing her card, other team members have been doing the same thing. The room has been abuzz with conversations. When all the feature cards are complete, each team member will describe the feature they documented to the group for feedback and thoughts.

Figure 12.3 A feature card after completion of the feature-card exercise. For now we won’t address the fields for estimated effort and planned iteration. This will come after you perform prioritization and estimation work.

Note

Why Not Design the Feature Right Now?

As you create feature cards, you’ll begin to imagine potential design options and constraints. It may be tempting to turn the feature-card meeting into a full-blown design session. Don’t do it.

What if you discover that a feature has a low priority, or the customer decides the feature isn’t needed after all? If this happens, you’ll have wasted precious time designing a feature that will never be delivered.You must also consider the time needed to design each feature. The feature-card exercise is time-boxed and is usually completed in one day. You’re gathering just enough information to prioritize the work, not complete it. Designing every feature in detail could take several days. You have urgency to evaluate and prioritize the work before engaging in detailed design. You’ll go deeper into the features before and during the development iterations.

Reviewing the Feature Cards as a Team

To complete the feature-card creation process, each team member presents their card to the team at large for feedback. When the whole team reviews the cards, additional issues are discovered, additional assumptions are added, and you give everyone on the team a voice. It’s also common for team members to challenge the customer on the value of some features.

When Gina reviews the ability to bid on an item, various members of the team ask questions:

• Keith from architecture wants to know the feature’s service-level requirements. How much time will the system have to record a bid and then allow all bidders to see the increase? Gina defers the question to Jay, the customer, who says the system needs to reflect a new bid after five seconds. Gina records this assumption on the card.

• Ryan, the designer, wants to know about the user interface. He asks Jay if they can use the existing site-navigation theme, or if the team will need to create a new look and feel for the Auctionator. Jay responds that he wants to keep the project as simple as possible and use the existing navigation if possible.

• Tom from operations asks how long a bid must be stored after an auction is closed. Also, will they need to store all bids or just the winning bid? Jay replies that he wants all bids for an auction to be stored for one month. Jay also tells the team that he’s working on legal disclaimers for the site, to protect Acme Media from any issues associated with disgruntled bidders.

Acme Media continues the feature-card exercise by reviewing and discussing all the other features. As the end of the day, they have enough information to prioritize and sequence the work.

Feature Cards Compared to…

Feature cards are at the heart of the Agile case study we’re using. You may wonder how they compare and contrast to other requirement and planning tools frequently used for software development. Let’s take a moment to compare feature cards to three popular tools.

User Stories

Some of the people we’ve worked with refer to feature cards as user stories on steroids. We believe this is an accurate description.

Feature cards share the same goals as user stories. You aren’t looking for requirements; you want information to help you plan. You aren’t looking for formal requirements to review; you want to interact with the customer verbally to better understand their needs. You also want to gather just enough information to understand the scope of the system. User stories and feature cards collect conversations with customers. Feature cards also aim to represent a piece of work that can be completed within an iteration. And feature cards and user stories both collect the tests needed to verify a feature is complete.

The main thing that makes feature cards different is the additional fields for uncertainty, dependencies, and frequency of use. By adding these fields, you make it easier for the team to prioritize and sequence features after the initial customer conversations.

Use Cases

Use cases have been an essential requirements-gathering tool for many years. We’ve used them on many projects, and they can provide a good process for documenting a system’s detailed requirements. But if use cases are used too early, they can create issues for a project:

• A use case can imply technical-design details and bias the team toward implementation. You can easily lose sight of what the customer needs and begin rushing down the path to building the application.

• A use case can define a large scope of functionality. You want to see all your features defined as pieces of work that can be completed within an iteration. Many times, a use case exceeds this timeframe.

Let’s look at the first issue and how design can creep into the discussion with use cases. A few years ago, Greg worked on a project that let employees update their personal benefits information online. Greg and a developer worked with the customer and quickly documented the main use case (see Figure 12.4).

In this example, the use case didn’t have an extreme bias toward design details, but hints were starting to surface. Greg’s team was already thinking about using PeopleSoft and a SQL database. This team also assumed there would be separate screens for each benefits area and that the customer would receive a change confirmation via email. Such assumptions may end up being correct, but they steer the customer away from a conversation about their needs and into a discussion of implementation details.

Figure 12.4 A use case can create issues for a project when it’s used too early. The format can bias the team toward implementation planning versus trying to understand the true user or business need.

It’s important to note that there are two types of use cases: essential and real. An essential use case is closer to a feature card; the interaction listed is at a high level and isn’t implementation specific. A real use case describes the detailed interaction with the system, naming screens, databases, triggers, and other system artifacts.

Returning to the second issue with use cases, let’s see how scope could become large for an Auctionator feature (see Figure 12.5).

The Acme Media team could probably complete the main use case for place a bid within 10 days, but other use cases that could come from the exceptions probably wouldn’t be completed within the same 10 days. Frequently, it takes more time to create an exception feature than it does to support the main, perfect world flow.

Figure 12.5 Alternate flows and exceptions can make a use case large and hard to consume within one iteration.

In conclusion, we think use cases are a great requirements-gathering tool, but they should be used in conjunction with feature cards or after feature cards are complete.

Functional Specifications

In our experience, a functional specification is a deep, detailed document that speaks to how a requirement will be delivered. Functional specifications frequently include use cases, wireframes, interaction diagrams, formal business requirements, and entity-relationship diagrams.

Functional specifications are common in a waterfall environment. We usually see the following flow around a functional specification:

1. A business-requirements or marketing-requirement document is created.

2. A functional specification is created from the business-requirement document.

3. A technical design document is created from the functional specification.

4. A test plan is created from the functional specification.

The process can be formal, and each document is created in series. In some cases, the customer may not be consulted as the documents are being created; this process is common with fixed-bid work.

The team is trying to deliver to a requirement document and to use statements such as “The system shall….” If the customer did not detail their requirements correctly, you don’t care—you get paid as long as you deliver to their specifications. This approach is different from the Agile mentality of learning as you go and engaging in frequent customer interaction.

If you contrast a feature card to a functional specification (FSP), you’ll notice the following differences:

• A feature card starts a requirements conversation. An FSP tries to cover all requirements immediately.

• A feature card is used to record conversations. An FSP doesn’t include conversations but focuses on documenting how a documented business requirement will be met.

• A feature card focuses on verbal communication, common understanding, and synchronizing the team on the customer goals. An FSP focuses on documenting the functional details and having team members read the FSP to understand what they should do.

• A feature card focuses on gathering just enough information to prioritize, sequence, and estimate the work.

Note that we don’t see an issue with creating functional specifications, but we do see issues with the process that usually surrounds them. In our experience, we’ve witnessed four weaknesses with the processes typically used with a formal FSP:

• A functional specification focuses on delivering what was requested at the beginning. In our experience, what the customer wants changes as they see the product demonstrated. Feature cards begin the process of identifying what is needed at the end, not the beginning.

• A functional specification can position the customer as an enemy, with definitive statements such as the system shall. The customer is also somewhat inhuman when their needs are presented on paper versus via a face-to-face conversation.

• The process around functional specifications can delay the ability to get early estimates for the project. An FSP may take weeks or months to complete, and then it’s passed to developers for technical design and ultimately development estimates. It may take months to get an estimate for project duration.

• When estimates do come in, you may realize that you’ve completed functional specifications for features that you won’t have time to complete. This FSP work will be wasted effort.

There is value in FSPs when you work with offshore resources, or to help you support traceability requirements. It’s also great to have a document that holds all the information about a feature in one place, especially if you don’t have a dedicated team room or a place to hold your whiteboard diagrams and flow. We’ve seen some teams take pictures from their whiteboard-modeling discussions and store them in the FSP. This is a great idea because team members usually understand diagrams better than requirements statements. The main point is that you don’t want to start your initial planning process by creating detailed functional specifications.

Previous article: Feature Cards: A Tool for "Just Enough" Planning

Continue on to the next article: Constraints and Considerations in Using 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.