Tuesday, April 1, 2008

Story Containers

We follow the XP development process.*

One of the things that we're having a bit of a time with is reconciling two goals:
  • stories should be of manageable (small) size
  • stories should have clear user benefit
Sometimes this is easy. 

For example, a story like this:
"Customer can email support from within the support page in the application"
has clear customer benefit and is pretty small.

Sometimes this is not so easy. 

For example, a story like this:
"System automatically logs a bug in the event of a crash (or updates an existing bug)."

This story is quite large, so ideally we'd break it down into smaller stories. However, doing that puts us at risk of losing the customer focus. One of the smaller stories in our example might be "System can log in to the defect tracking system." Fun, sure, but not directly helpful to the customer.

The best way I know of to handle this is to have multiple stories that are grouped into a story container of some type. This way we can keep our stories small but still say that they are helping provide benefit to the customer. The problem is then differentiating story containers from stories in the queue. I've tended to keep them separate, but this is far from a solved problem.

Anyone in the ether have ideas?

* Mostly, sort of, etc. Don't email me with process rants, please!

No comments:

Post a Comment