Constraints and Considerations in Using 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.

• Limitations in Using Feature Cards
• Hard-copy Cards vs. Electronic Cards
• Key Points
• Copyright

Limitations in Using Feature Cards

Switching to a feature-card-based planning process can be a big cultural change. You may have constraints that make it difficult for you to make the conversion. Let’s look at some of the most common constraints.

Project Complexity

We once worked on a huge project to deliver an online real estate site. The project was estimated to have four major phases and take a year to complete. In addition, we were outsourcing most of the functionality to a real-estate site service provider. The provider wanted us to provide complete functional specifications for all our requirements before they would provide a cost estimate. Our team had Agile experience, but we didn’t see how we could use feature cards for a vendor who didn’t want to work in an Agile fashion.

Since this time, we’ve learned that the best way to deal with large projects is to focus on identifying the critical features first and then use the feature-card process for the critical work. When we need to estimate all the work, we discuss themes for future phases and provide high-level estimates to stakeholders, but we don’t try to estimate a huge project in detail. This approach has worked well for us because we often find that once phase 1 critical features are delivered, the customer may change their mind about what is needed next and may cancel subsequent phases. You’ll also find that the world isn’t static during your project, and a change in the business climate can make a customer redirect you to a new need.

The Customer Isn’t Available

An integral part of creating feature cards is dialogue with the customer or product owner. On occasion, we’ve worked with teams that were able to complete the feature-card exercise with minimal customer interaction during the exercise. Here’s an example.

Once we worked on an intranet platform that had multiple customers per release. Some customers were available for the feature-card exercise, and others had only an hour or two to give. Some customers were totally unavailable due to vacation or illness. If a customer had only an hour or two, we interviewed them intensely for the time they were available and then used a proxy to continue the process. The proxy was frequently a business analyst who spent time with the customer before the feature card meeting. As the feature-card discussions continued without the customer, the analyst provided feature requirements and decisions; later, they reviewed the discussion with the real customer.

In cases where the customer wasn’t available at all, we debriefed them before the session and had someone on our team named as a proxy in advance of the meeting.

Ultimately, you want high customer involvement in your development process. Assuming your customer was highly involved in the creation of business-requirement documents in the past, your customer should have time for the feature-card exercise now that you won’t require detailed business requirements to initiate the project.

Compliance and Traceability

In many environments, you must provide requirements traceability and support compliance programs such as Sarbanes-Oxley (SOX). Let’s discuss traceability first.

If you use feature cards, you may find it difficult to go through them for an auditor to prove you supported a requirement. In these instances, you may want to have an electronic version of the card with a unique ID that can be referenced to show support for the original requirement. In our experience, we’ve gone a step further and created an electronics requirement package that auditors can reference. These packages contain customer discussions, wireframes, interactions diagrams, workflow diagrams, and sometimes use cases. We’ve also stored a record of test results and customer approval. The good news is that our feature cards, and everything we do in an Agile environment, are focused around acceptance testing. Other than documenting results in a place they can be referenced, you shouldn’t need to make any process changes.

Agile is also good for compliance environments because projects (releases or iterations) are small and make results easier to view and comprehend. An Agile process also lends itself to transparency, which most regulatory bodies desire.

Perhaps the biggest thing to address with Agile and compliance is how you document your process. We’ve found that companies often harm themselves by documenting a process they don’t follow. In these examples, teams rush to create artifacts that support compliance but provide no value to the project.

We’ve also worked in ISO environments; one of the famous quotes from ISO auditors is “document what you do, and do what you document.” Many large companies have teams dedicated to corporate methodology, and these teams document what they think you do or should do. You need to work with these teams so they document the true Agile process that you use, so you’re always in compliance.

Hard-copy Cards vs. Electronic Cards

The spirit of feature cards is to increase verbal communication with the customer and enhance the team’s understanding of features. Using physical cards encourages face-to face communication and also helps the team better remember what a feature is about, because a team member writes the conversation notes on the card in their unique handwriting (see Figure 12.6).

Figure 12.6 Features are easier to remember when they’re created by hand and always on the wall for team members to reference and edit.

You should make it easy to discuss, reference, and modify feature cards if needed. A physical card simplifies this process. Physical cards also work well when you begin prioritizing and sequencing the features for a release: you can move the cards around and view them as the team discusses sequencing.

But sometimes you may also want an electronic representation of your card. For example, if you’re working with distributed employees, you may want to show them the features via a wiki or collaboration website, as in Figure 12.7. You may also have a queue for customer requests, where your customers complete an electronic form that populates your backlog. You can print these cards for the feature-card exercise and update them online after the exercise if necessary.

Some teams don’t have a dedicated team room, and an electronic tool lets the team view feature information at their desks or other remote locations.

Figure 12.7 Tools such as SharePoint let you create feature cards electronically. Electronic cards can be used to supplement the use of physical cards and make it easier to distribute feature information to offshore teams or across a large enterprise.

Note

A Case Study from a Real Project Manager Using Both Physical and Electronic Cards

When I was initially trained on Agile processes, I was told to always use index cards or paper for the feature cards. The team could quickly create, edit, view, and move index cards. The physical paper was also conducive to collaboration and conversation. I totally support this approach, and I can attest that paper works great for the feature-card exercise.

On occasion, though, I’ve had issues with paper after the feature-card exercise. I’ve worked in several environments where we couldn’t get a dedicated team room, so we couldn’t leave our artifacts on the wall. In those instances, we brought a computer and a digital camera with us to the team room. We created the feature cards in Microsoft Word and used a digital camera to take a picture of any sequencing work. We then posted the information on a team website that all team members could go to whenever they wanted—they didn’t have to find the physical feature cards. When necessary, we printed out the feature cards and went back to work passing them around physically and writing on them.

Going electronic has also helped me with capacity planning. I’ve used tools such as SharePoint, VersionOne, and Rally to enter features into an electronic list. This list lets me aggregate team capacity and story-point estimates for a quick comparison. This helps me assign features to iterations during release planning.

I’ve also created a feature-card template in Microsoft Word. I print a stack of these blank cards before the feature-card exercise and hand them out to the team when we start breaking down the features. The template contains all the fields in which to record feature information. This also helps people remember what data they should collect.

I suggest that you experiment with paper and electronic methods and then outline a custom process that works for your team.

Do all you can to use physical cards that are viewable at all times, preferably in a dedicated team room. Physical cards are extremely important for the feature-card exercise and later for release and iteration planning. Use electronic cards to supplement physical cards if you have constraints that limit the availability of physical cards to team members.

Key Points

The key points from this chapter are as follows:

• Feature cards let you plan a project without creating detailed functional and technical specifications.

• Feature cards help you prioritize your work and avoid wasting time on features that may never be needed.

• Feature cards aren’t meant to be the only source of requirements information.

• After initial planning, you may want to supplement the cards with additional artifacts to support feature development.

• Features need to be broken down into a size that allows delivery of working code within 10 days. If you pursue large features that take weeks or months to complete, you may fall back into a waterfall process and lose your ability to evaluate project status.

• Feature cards are all about the customer. The cards should describe the value that will be delivered to the customer.

• A completed feature card holds initial estimates, but you don’t perform estimation until you determined priorities and sequence.

• Involve your entire project team in the feature-card exercise, unless the team is too large. If your team has more than 12 people, you may need to have representatives by area.

• Involving the entire team ensures consistent understanding and buy-in. If anyone has doubts about feature value, they can share their concerns directly with the customer.

• A feature card is similar to a user story. The main difference is that a feature card has fields to remind team members about information to collect related to risk and value.

• Use cases can assist you during the feature-card creation process, but you need to make sure the use case speaks to the business need and not a specific implementation of the need.

• If at all possible, use physical feature cards for the feature-card exercise. Physical cards encourage you to interact with the customer and place a focus on verbal communications, which helps you understand the customer’s need. Try to limit the use of electronic cards to supporting the physical cards or passing the information to distributed groups.

Previous article: Creating Feature Cards

Continue on to the next article: Prioritizing the Backlog

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.