Scoping the first version of a new feature - how big of a bite?

Well, the umbrella drinks are gone, so it must be time to get back to work.  On the flight home, I started thinking about some new features going into one of our products. 

One of the interesting challenges with a new feature is knowing how "rich" the feature needs to be before it is released.  In XP (Extreme Programming), the idea is that the customer is sitting with the developer and can say when a feature actually solves the problem.  But usually I act as the proxy for several customers, and new features can be intended for situations the customer has never actually seen.

My general philosophy is to try to solve the key user stories and get the feature to customers to get feedback.  So the trick is separating the critical user stories from the "nice to haves".  A lot of judgement comes into play here, but these are some of the questions to consider when trying to separate the stories:

• How likely is a situation going to be?  How many customers?  How frequently?
• Is there a workaround for it?  How hard is the workaround?
• How far away is the next release of this software?  How likely is it that customers will upgrade?  How much effort will it be to upgrade?

So here's an example that happens with basically every enterprise product - reporting.  One school of thought would be to put no reports into a product and ask customers to query the database.  But if we look at the criteria, the need for reports is very common and the workaround can be a big barrier.  Plus, you give up a big chance to get feedback from customers, and if you change the database, they can be pretty unhappy about the work they've lost.

At the other end, you could put in every reporting bell and whistle on the planet with nifty OLAP functions, extracts, alerts, etc.  But it will take a while to deliver, and most likely, the customers will still need some things that are not included and probably never use some of the bells or whistles.

The agile compromise that I like is to start with some basic reports and listen to what customers like and don't like.  Then iterate quickly to meet their most critical needs.  In the end, smaller bites are much better if you can make sure they are easy to chew and have the tastiness that comes from getting their requests as directly to the chefs as possible.