10 June 2014
Features Matter to Users More Than Stories
by Doug Alcorn
We’ve been in the software development world so long, we often don’t even know when we’re using jargon. The “user story” is one of those jargon terms that new customers often don’t understand. By contrast, what they do understand is features. The more I work with clients, the less I want to make things up for them to care about. User stories are a sacred cow we can afford to sacrifice.
User stories were one of the fundamental tenets of Extreme Programming. They were an alternative to other computer science concepts like “use cases”, “scenarios”, or “requirements”. User stories were meant to be simpler and more focused. There’s piles of literature on how to write them. I’m not sure where all that literature leads us.
Here’s an experience I think most of us can sympathize with. You have an app on your phone that you use every day. For me, it’s Evernote. I love Evernote. I use it all the time. I recommend it to everyone I meet. I’m constantly saying, “You could use Evernote for that.” When there’s a new release, I read the release notes. I don’t have hard numbers on this, but I suspect most of you reading this have an app you read the release notes for.
What goes in those release notes? Sometimes it’s lame. They will say something like “Bug fixes”. But good app writers will summarize the new features in the app in such a way that I’m excited to learn what I’m getting. “Guys! Check this out. I can <…….> in Evernote now!” The benefit to me, the user, is clear and concise. It’s something I can tweet in 140 characters.
These are the features I want to track as we build software. Not everything is exciting like that. But we want to focus on “minimum marketable features”. These are features as small as we can define them but still have value to the end user and the organization that produces it. Too often in the past, our clients have asked for some feature that we’ve broken into multiple user stories. Often these smaller user stories don’t individually have value to the client or end user. That’s why we should focus on features. The feature is the whole that provides the complete value statement.
Of course, the danger is these features will be too big. The scope of the features can grow and grow. The danger is the feature will stay “in progress” for too long. All of these are issues we have to manage as agile developers. Segmenting work by the value they define doesn’t change any of that. The focus is on what the client and the end user sees. Segment your work into sized units that they care about.
