Take a minute and think about your current backlog. Close your eyes and get a good mental picture of it. OK, got an image? Now open your eyes. Does it look something like this cluttered garage?
Or, maybe you think it’s a little more organized and looks like this garage:
In agile software development, we create user stories as a way to communicate the requirements of our users in an easy to understand format. Usually, they take the following form:
“As a <user type>, I want to <function> so that I can <business value>.”
An example of a real user story looks like this:
“As a frequent traveler, I want to rebook a past trip so that I can save time booking trips.”
As I’ve been looking through backlogs from various organizations and teams, I’ve started to notice a trend. Well, less of a trend than finding numerous similarities. The similarities I’m seeing are in the user stories in the backlogs. Many of the backlogs I’ve seen have user stories that say something like “Get smart on the dojo toolkit” or “Find out more about the ASP.NET MVC“. I call them the “Get Smart” stories. The Get Smart stories are stereotyped stories that contain little or no detail. Storyotypes. It’s not that I don’t believe in stories for research spikes. What I don’t like is that these stories don’t follow the simple INVEST rule of user stories. If you’ve never heard of the INVEST rule, it basically says that user stories should be:
Building software is complex. Every time you think have something nailed down, the requirements change. In fact, it reminds me of a quote from Al Gore’s “An Inconvenient Truth“:
“It’s like beach combing. Every time the tide comes in and out, you find some more shells.”
