Friday, July 20, 2007

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.


  1. I'm so glad you blogged about stories -- it's perfect timing.

    One of our projects is facing a similar problem: the release-level estimates being done on stories is off by 30-40% of the iteration-level estimates done on the engineering tasks broken down from the stories... this sends the project plan into a toss and updating the plan so often is not feasable.

    From your blog entry I now recognize that the stories we are getting are in fact mostly "buckets". I guess there is a thin line between the two and we're having a tough time determining which is which.

    Any suggestions on how to deal with customers who are providing buckets instead of stories? Do you think we could do some amount of breakdown for 3 to 4 iterations in advance and estimate on those? (But we'll lose a bit on the agility, won't we?) It seems the team is better at estimating broken-down tasks rather than stories.

    A blog entry from you on "estimating" and how you go about it (for various types of stories/buckets) would be a big help. :-)


  2. Aman,

    Getting only stories (and not buckets) in your current iteration is a tough (if not impossible) task.

    I think the first step is identifying what is a bucket and what isn't. I agree that the line is gray; however, I tend to think of a story as something that the business can elaborate fully on. Conversely, if the business has a rough idea, but the details aren't nailed down, that's probably a bucket.

    The best thing to do with buckets is to push them in to the spotlight. Throughout the life of the project you should highlight any buckets that "must be in the current release" as the largest risks on the project. Also, reiterate to the business that you cannot have any faith in the estimates and therefore the delivery schedule as long as your release contains any buckets.

    Best of luck, Jay

  3. I agree with you Jay, that a story that the cleint ca nnot fully elaborat on is definitely a bucket, and not a truly estimatable story, by definition.
    However, what is not mentioned, and is equally as troubling about your given example, is the existing dependency in that the forst story is awaiting a yet to be introduced or developed 'production environment'. This dependency cannot exisit and have the story remain estimatable, as ithsi goes against the "I" of the INVEST principle. That is to say, the story is not independent...
    Just my observations! 8-)


Note: Only a member of this blog may post a comment.