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: Read more »
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.”
I’ve been reading a great book called What I Talk About When I Talk About Running by Haruki Murakami. It’s not a book about business, agile, marketing, scrum, branding or anything else that I usually write about. Instead, it’s a memoir written by a great novelist about running and training for marathons. But, there was an interesting passage that I think really applies to agile teams (or anyone for that matter). It’s about finding and setting the right pace for sustainability. Here’s Murakami on sustainable pace:
