Some stories are dependent by nature, for instance when a story has downstream or up stream effects on otehr teams.

The noteworthy exception is pattern #8. Pattern #8 splits an overarching CRUD type story along functional lines.

And I’d argue, by splitting the story along functional lines, the pattern often violates the INVEST guideline. Specifically, it often renders the fractured stories not valuable to customers in isolation.

For example, creating data in and of itself is usually not valuable; users want to do things with data. Same for updating and deleting data, and, in many cases, retrieving data. I don’t really want to add an entry to my checkbook; I’d rather it happen automatically. (Better yet, I’d like to know that my bank is tracking everything properly and that I am not overspending.)

As a general rule, I favor the other patterns you’ve mentioned for splitting stories. There are a lot of interesting issues surrounding splitting stories that I explored in this blog entry. I’m curious what you think.

How would you split a story which in essence is quite simple: just a search box that should display the results of what you typed in.

The thing is that behind the scenes, we have to configure the search engine and create the interface with it and configure the build server. This is the first story so we decided to work on the build server effort as part of this first story.

We prefer not to work on the so called story-less tasks since we prefer to track stories and not tasks, and don’t like the idea of “technical tasks” to setup an environment for example since I’m not confident in estimating those in terms of story points.

Could we split the search textbox and results story in some way? What do you think?

Thank you for your help! The problem isn’t so much the art department’s inability to estimate time required as the length of time they require for many pieces, which is just too long for the mandated two-week release cycle. We’re most likely going to have the art department work ahead.