As developers when we release code we almost always classify it as n amount of features:

Announcing Release v4:

Auto Login
User Profiles
Reporting
When product management comes to engineering they usually have a list a features they want in the application. Those features may or may not make it into the final release, but they begin their life a feature request.

If you ask your CEO the following question:

"Does the business benefit from adding features or adding value?"

What do you think the answer will be? Unless your CEO is incompetent the answer should always be "adding value".

If we improve our business by adding value then why do we structure development around features instead of value add? Why don't we ask and get the information on what the value add is?

When I was at Staples we had a "quick" project that was to implement real-time credit card authorization. This was some years ago before this type of thing was well known. Development had a lot of concerns about performance, uptime, and what to do when the authorization didn't work because of technical issues. It seemed that we were jeopardizing our lifeblood (purchasing) by adding this feature.

As the lead I asked the question about the value of this project. The answer was that we were loosing something like 13 million a day/week/month (I forget the time frame) to mostly Nigerian fraud and this would put an end to that. Suddenly we had a value add request and not a feature request. It was one of the few times when I felt like I knew exactly the reason for a feature that extended beyond "so and so wants it so we are building it". The value add also went a long way to answering the what if questions that we had.

This post on BDD got me thinking along these lines.

I'll quote the above post:

“That’s the problem,” says Chris. “You’re putting the role first. It’s the value that’s most important. Try this: In order to <deliver some value>, as a <role>, I want <some feature>. Instead of working out why people want a feature, and whether it contributes to the value, now we’re working out who needs a feature, then assigning the story. So our stories are much more focused. If all the stories that contribute to a value are ready, we release.”

Next time you get a feature request convert it to a value and then prioritize it:

"In order to <achieve some value>
As a <role>
I want <some feature>."