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:
Thinking back to the Get Smart stories, I think they are independent and valuable, but they fall short of being negotiable, estimable, sized appropriately, and especially testable. Now, I know that these stories generally are used to define research spikes and therefore are used to give better estimates for other user stories in the backlog. So, I can even let go of estimable, negotiable and small. What I want to focus on is the “T”: Testable. If all your story says is “Get smart on the dojo toolkit“, how does your team test if you “Got smart“? There are no specifics in the story about why your team needs to get smart. What is the reason for the research? As my colleague Ben Carey has described it, the testable attribute ensures that our acceptance criteria are not ambiguous. To make something testable – we need to make it measurable and specific. And I believe this has to apply to the Get Smart stories as well.
So, instead of “Get smart on the dojo toolkit“, try to rewrite the story to maybe say something like “In order to send complex data between the client and server as json, as a delivery team we want to research the dojo toolkit and the ASP.NET MVC.” And, if you want to go with the traditional user story format, you could write it as “As a delivery team, we want to research the dojo toolkit and the ASP.NET MVC so that we could figure out a way to send complex data between the client and server as json“. These stories are much more testable because they’re specific and measurable. When the team completes one of these stories, they should be able to describe how to send complex data between the client and server as json using either or both the dojo toolkit and the ASP.NET MVC. In fact, they would probably be able to demo a prototype of the functionality based on the stories. And, because these stories are specific, they prevent the team from wandering through documentation, tutorials, and code samples without any aim or goal. The research in this story is confined only to understanding how to send data as json. Nothing else. So, be specific and avoid storyotypes….do that and you and your team will get smart!