The use of feature stories in agile software development

Jon Swope and I were recently discussing the appropriate use of feature stories in agile software development and reached the conclusion that we’re not convinced we have the best solution for back-end type tasks.

To provide some background, our company makes use of Pivotal Tracker for agile development.  We track new features, bugs, and chores using the following rules:

Feature: Any development that extends the functionality of the application in such a way that produces a new product deliverable.  These stories receive a point estimate and are the sole driver of velocity.  Feature stories may track both consumer facing functionality and back-end functionality that is only consumed by developers.

Bug: This story type is used to record defects against existing functionality that was delivered via a previous feature story.  Bugs do not receive a point estimate because they are a flaw in a previously worked feature story for which points were already earned.

Chore: A chore is any effort that supports development of the application but that does not produce a product deliverable.  Examples include configuration of a development environment and ‘spike’ which is an exploration of new technologies and techniques that may benefit development of features.

Returning to our discussion on the proper story type for back-end functionality let’s cover the pro-con for both feature and chore:

Pro Feature: When written as a feature, all back-end functionality can be estimated and is represented in project velocity.  Tracking with a point value is appropriate because this story results in a product deliverable.

Con Feature: This story cannot be directly consumed by the end user.  This results in confusion for product managers who contribute stories from the perspective of an end consumer because they are unable to sign-off on non consumer facing functionality.

Pro Chore: The chore requires no sign-off which frees the product manager from confusion and uncertainty of the story’s status.

Con Chore: The chore carries no point value yet produces a deliverable that is not reflected in velocity.  This story requires no sign-off and will not receive the same attention as features when reviewed by QA and product management.

While I recognize the shortcomings of the feature story type for back-end functionality I’m not convinced that chore is the appropriate container for these stories.  I believe back-end should affect velocity because its’ development effort produces product functionality that can be consumed (a deliverable).  I would like to eliminate the confusion of QA and product who have a difficult time verifying back-end functionality as they cannot directly consume it.

The use of categorization for feature stories might allow for more accurate tracking of back-end product development but may do little more than writing the stories from a developer’s persona as we do currently.  I’m looking for suggestions on this one, if you’ve encountered the same concern and have a solution please share in the comments below.