One of the most overlooked parts of user stories is the content that follows those two little words, “so that.” I’ve found that we (those of us working on agile projects) tend to do a good job of writing user stories until it gets to those two little words. For example, let’s say the iPhone team has a backlog and one of the stories is:
As an iPhone 3G user I want to be able to make VoIP calls over the 3G network in addition to wi-fi.
Sounds pretty good in terms of a user story. It’s likely more an “epic”, but I won’t get into the size of user stories. Let’s start the conversation with the product owner and the team and estimate this story. Not so fast. Notice that we have no idea why the user would want to make voice over IP (VoIP) calls over the 3g network. I think the assumption is often made by whoever is writing the user stories that the team and others already understand the value of the story. That is not a safe assumption to make. Not only is it not a safe assumption to make but the focus of the team will turn to “how” to make the user story a reality. I think we’d all rather discuss the value of the user story before we start jumping into questions about how it might be implemented. But when the value isn’t present in the story it’s easy for everyone to overlook. Let’s see what that story might look like with the value statement added to it:
As an iPhone 3G user I want to be able to make VoIP calls over the 3G network in addition to wi-fi so that I can save money by not using my crazy expensive voice minutes.
Now we understand why the user wants this functionality. Before we could’ve assumed it was for any number of reasons. The cost savings is the driver for this story. The team and anyone else reading this user story can now better understand what the real drive for the desired functionality is.
I read a while back an InfoQ article about changing the format of user stories. The traditional format is what we’ve already used in the example above:
As a <type of user> I want <some functionality> so that <some benefit>.
The new format suggested by the Elizabeth Keogh, the author the InfoQ article points to as the one suggesting the new format, looks like this:
In order to <achieve some value>, as a <type of user>, I want <some functionality>.
I think the new format is worth considering in light of how many user stories lack value statements. T
he only thing holding me back from this new format is that it reads too much like Yoda speak. Yoda was always known for putting those awesome sentences together, like: “Named must your fear be before banish it you can.”
I think whether we change the format of user stories or simply use the existing format, the important thing to remember is to communicate the value driving the user story. As Yoda might say: Focus we must on business value lest we lose reason why user story exists.