Feature thinning guidelines

These feature thinning guidelines are based on Gerard Meszaros Storyotype approach for splitting bloated XP stories.

Whether you're using eXtreme Programming and user stories or not, the four categories identified by Gerard offer a simple way to thin features or stories. Looking at a proposed product feature, these guidelines offer a simple way to divide up characteristics of the feature. These characteristics identify perforations in the feature that make it easy to divide up. I've taken liberty with the names of the characteristics so that I could more easily remember and apply them. Hopefully you can to.

Imagine you're making choices about scale on each particular feature of a car. The characteristics of the feature we'll look at are:

• Necessity: what minimal characteristics are necessary for this feature? For our car a minimal engine and transmission are necessary - along with a number of other features.
• Flexibility: what would make this feature more useful in more situations? For our car, optional all wheel drive would make it more useful for me to take on camping trips. A hatchback might make it easier for me to load bigger stuff into the back.
• Safety: what would make this feature safer for me to use? For our car making the brakes anti-locking would make the car safer.
• Comfort, Luxury, and Performance: what would make this feature more desirable to use? I'd really like automatic climate control, the seats to be leather, and a bigger V6 engine.

If we were buying and using a car, we all need the necessities. However, we all may have different opinions on what's more important between flexibility, safety, and comfort, luxury, or performance. We want varying degrees of all those things up to what we can afford. We expect each feature of the car to have at least the necessities and some of all the other categories.

Some characteristics don't easily fit into one category. Is all-wheel drive a safety characteristic or a flexibility characteristic? I guess it depends if it's raining hard outside, or if I choose to drive the car off road to go camping.

Now let's look at a high level software feature and apply some thinning guidelines. Let's choose a feature in software we likely all use. We'll express the need for this feature as a user task - since the feature we build needs to support that user task.

We'll look at how these four guidelines might apply to the feature or features that support this task, and how these guidelines might apply while planning and estimating a release, and while iteratively designing and building the software.

Necessity

To identify what's necessary look at the user of the software and the simplest possible use. Start by looking at the task the user intends to perform. Write a simple user scenario or task case to understand the steps of usage. Identify only the absolutely necessary steps that allow the task to be considered successful. A feature that supports necessity supports only those necessary steps.

Using our "send an email message" task, success for me is to get a message sent.

The steps I as a user might likely follow would be to:

1. Indicate I'd like to send a message
2. Indicate who I'd like to send the message to
3. Write the message
4. Indicate I'd like the message sent now.

I've really cut back here. Notice I didn't enter a subject line, send it to multiple people, carbon copy anyone, or add any attachments. It's likely I wouldn't choose to buy a product that did only those things. But, if the product couldn't do those basic things, well, that would just be silly.

If we described a "send an email message" feature as having just those things, it would have only the necessities.

For any given software feature, we can thin it to include only its necessities.

Flexibility

To identify specific options that make the feature more flexible look back at the user and possible use of the feature. For the task the user is performing, write a simple user scenario or task case. For each step in that task, ask what your user might alternatively do, or do in addition to the actions performed in that step. In use case writing these might be considered our alternative steps. A feature that supports some degree of flexibility supports some or all of these alternative uses.

Using our "send an email message" task, I might optionally type a subject line - actually I usually do that, but I guess if you press me, it's not really a necessity. I might optionally send the message to many people. I might optionally carbon copy or blind copy others. I might send an attachment, save it to my sent folder, or forward someone else's message.

Adding support for some or all these "might dos" adds flexibility to the feature.

Safety

To identify specific options that make the feature more safe look again to the user and use. For the task the user is performing write a simple user scenario or task case. For each step consider things that could go wrong. How might our user enter data incorrectly and cause trouble downstream? What does the business paying for the software want to make sure the user doesn't do? Characteristics that help the user by validating or correcting input, or by applying business rules that restrict or block some actions are considered safety features. A feature that contains this sort of input validation, correction, or business rule applications has some amount of safety built in.

Using our "send an email message" task, if I typed in an improperly formatted email address, sending the message would fail. I might appreciate it if the email address were validated. In some corporations large attachments are considered unacceptable because they bloat email storage, and consume lots of bandwidth. If the system were to stop me from attaching a large file, the business paying for this software might appreciate that. Adding these sorts of characteristics to the "send an email message" feature adds safety. Features in our software often have some number of safety characteristics.

Comfort, Performance, and Luxury

To identify specific options that make the feature more pleasant to use look again to the user and use. For the task the user is performing write a simple user scenario or task case. For each step consider things that make the step easier to accomplish, faster to accomplish, or more fun to accomplish. You may have to base your decisions on what's easier, faster, or more fun based on what the feature already looks like, or what's considered the bare necessity feature. It helps to look at similar or competitive products to identify these areas for improvement.

Using our "send an email message" task, I really hate typing the same email addresses over and over. It would be nice if the system auto-completed addresses I'd used before. I'm a rotten speller, and my grammar aint so good. Could the system check my spelling and grammar in the email message and subject line? Can I insert amusing smiley icons into the message? Adding these sorts of characteristics to the "send an email message" feature adds comfort, performance, and luxury. I'll like this product much better if it has some of these things.

Estimates at the release level become budgets

The estimates given against prospective features to support tasks will serve as development time budgets during iterative design and development. For now, use these estimates to size and plan releases that will be successful in the eyes of their target users and the business paying for the development. As you begin to make specific design decisions for the features to support users' tasks, let the budget set limits for the amount of flexibility, safety, and comfort, performance, or luxury you add.