Summary: Avoid the temptation to deem features "in scope" because of the illusion that they are free.

Its very common for customers, when asked if they want a story to include option x, to reply: "well, I'll take it if it doesn't cost anything" -- i.e. if it doesn't change the estimate.

While its tempting (especially if its small) to give in to this, its a mistake. Here's why:

First, if the option in question is needed, then its needed whether cheap or expsensive (we'll get to ROI in a minute), so this is a dead giveaway that the value of the feature has not been established (IOW, its likely something "cool" but not something valuable). Second, nothing is ever free, its either already there, or someone will spend time adding it -- time that could be used for something that is considered valuable.

Yes, there are features where if cheap enough, they could be included. Such marginal ROI features however are not generally when this situation arises (those usually float near the bottom-middle of the story stack). In such cases though, they should still have some point value attached (even if you have to throw a couple together to make a one point story).

So, why is this so common? I think the answer is due in part to the fact that many development efforts have slack -- hidden slack -- built in because of the all-to-common practice of negotiated estimation. Negotiated Estimation is where the software creator guesses at the time it will take (usually padding the result in anticipation of pushback), and the software customer (or a representative project manager) pushes back on the estimates to coerce the result into alignment with expectations. At the extreme this becomes not a negotiation, but a one-way edict: The software will be completed within this time. The result is a strange compromise (strange in that both compromises are known to the creator, not the customer): The schedule is sandbagged, and quality is sacrificied.

Many customers are experienced with this mode of development, and so push the creators to add features (assuming their estimates are conservative). The most pressure is brought by former programmers who padded their estimates and assume that others do too. This also produces another wasteful side-effect: Vague areas are filled in by the programmer; ambiguous business rules are guessed at, speculative features that seem to add completeness are included, and non-functional eye candy are lovingly tweaked -- all without the customer's involvement. This is an awful lot of inefficiency, for free.

However, if you subscribe to the principle (you may not) that the person who is going to use and pay for the software should be the one -- the only one -- to decide (suggestion and advice are something else) what functionality is included, then you can see how such reliance on the programmer to make the decision whether speculative "free" features are added is counter to this goal. Instead, I subscribe to the notion that its better to have slack visible (it should exist regardless), get all effort quantified (not negotiated!), and assume all features are out, unless explicitly included (with the inevitable ambiguities resolved via regular customer discusion). It makes for better expectations all around, it builds trust, it puts decidable changes (i.e. changing scope instead of trying to change estimates) in the hands of the decision makers, and -- at its best -- results in better quality software, with better work environments.

But that's just me.