MARTYHAUGHT

Obie Fernandez just posted a nice entry on a limitation he’s felt recently with large stories. I have thought about this exact thing several times over the past couple of years and my teams have tried a few different approaches. Bill de hÓra and Geoffrey Wiseman posted two great follow-ups that share some of my same conclusions.

For me it comes down to a couple points. We’ll assume that the requested feature is too large for the team to complete in a single iteration. Thus you’ll need to deal with a story spanning multiple iterations or having to break it down further.

Though making a single story may be convenient, I strongly dislike keeping large stories that I know cannot be done in a single iteration. As Geoffrey suggested, I look for ways of breaking down the stories as much as possible while still delivering value. I think in Obie’s case this could be done. The documentation and installation instructions could wait for a following iteration. Perhaps only part of the photo plugin’s features would be ported on the first take. It’s almost like the first story is to spike the generator plugin approach to eliminate the riskier parts of the story. In follow-up iterations the rest of the features and documentation could follow.

Instead of considering “Adding Photos” as a story, I consider this more of a feature, or an epic as Mike Cohn might describe (via his book, Agile Estimating and Planning). I personally like feature over epic as nomenclature as that makes more sense and feels more natural to the business/consumer side of things. A feature is usually how I like to consider very high level business functionality that you define in a project release plan. Almost always a feature will have multiple stories, each with their own acceptance tests. Usually these stories can be done at separate times. While these stories are useful on their own the entire feature will not be complete until all are finished. As Bill mentions, this can be a slippery slope as it leads to the feature forever being 80% done given the pieces spread over several iterations. While I’d agree this can be a pitfall, I’m not sure how you can get around that since there is too much work to complete in a single iteration. I’d also consider that more an issue with how you organize the stories in your iterations and not with how you breakdown the feature.

Another interesting question to explore is do you release small parts that are useful over iterations or keep the entire feature under wraps until it’s all done. In Obie’s case, he would not likely release this plugin to the public until the feature was complete. Internally, they could be using it on a current project or dummy project to see how the integration goes until all stories of the feature were complete.

As with almost everything in agile projects, context is king. The client needs, business culture and intent with the feature is going to drive how you answer these questions and where you compromise.

blog comments powered by Disqus