Stories are Placeholders not Buckets

Agile methodologies often use stories as requirement documents. Stories are placeholders that signify conversations that will need to occur between the customer and the developers before features are implemented. A story gives a high level idea of the required functionality; however, the details of the functionality live in the mind of the customer until they are expressed to the development team.

Stories are generally concise and purposefully vague; however, they do contain enough detail for the developers to estimate the level of effort required to implement the feature(s). Accurate estimates are crucial because they are used to plan what is in and out of scope for a release. Clearly, inaccurate estimates create volatile scope.

The importance of estimates has the following implication: Stories cannot be used as Buckets.

An example of a bucket would be:

"Create Reports" or "Deploy the application to a production environment."

If the 'production environment' is known this is a perfectly valid story. However, the story cannot be accurately estimated if the 'production environment' is a box that will be ordered later in the project and the platform is still undetermined. A story in which the details are unknown at this point is nothing more than a bucket.

The largest problem with buckets is that they generally end up being far too small. Traditionally, buckets represent the more complicated parts of the system because they aren't yet understood or defined. Since they aren't fully understood, often buckets are pushed off until near the end of the project. Because buckets are generally addressed at the end you are generally already working with a mostly written system that hasn't taken in to account the effects of the bucket. While everyone should be striving to write systems that are flexible and maintainable, having any system at all often makes things more complicated than when the bucket was originally envisioned and estimated (which is another reason buckets are often underestimated). Another problem with buckets is that they often end up with things that don't belong in them. This is also a product of defining a bucket toward the end of a release. Since the release is nearing it only makes sense that the business would like to put as much in a bucket as possible. Of course, overfilling buckets doesn't work either. As Martin already noted:

You can't put ten pounds of shit into a five pound bag.
--Anyone who has tried

Unfortunately, over-estimating buckets is also problematic for the planning process because it breeds distrust between the developers and the business.

This does not mean that buckets do not have their place in agile projects. It is always important to capture required functionality whether or not it is well defined at this point. However, buckets simply cannot be stories or the planning process will break down. Any bucket that must be in the current release likely represents the largest risk for the current release. Therefore, the current release should be limited to stories and buckets should live only in subsequent releases.