Some of my readers may already know that I like to challenge every practice that is accepted as norm in software development. I always ask a few questions:
- What is the value of the norm?
- How can we get the same value in other ways?
- Is one of the above ways better (or at least worth mentioning)?
I’ve recently realized that one of these norms in agile software development is user stories, and I will especially discuss the way we write user stories.
If you’ve never heard of user stories, that’s what they are:
One or more sentences in the everyday or business language of the end user that captures what the user wants to achieve
A user story has to express a few things:
- Who wants to use that part of the software
- What is the user trying to do
- Why is it valuable
The way we typically express user stories is this:
As a “role”, I want “goal/desire” so that “benefit”
and some examples are:
As a customer representative, I want to search for my customers by their first and last names so that I can see their information.
As a non-administrative user, I want to modify my own schedules but not the schedules of other users so that I can maintain my schedule.
It so happens that I don’t like this way of expressing stories at all. First, it’s too long. Second, it sounds too formal. Third, it feels unnatural (at least to me).
But how could we express the same idea?
My first thought was this:
The “role” needs to/has to “goal/desire” so that “benefit”
which makes the stories shorter and more natural (again, for me), like this:
The customer representative searches for customers by their first and last names so that he can see their information.
Any non-administrative user can modify his schedules but not the schedules of other users so that he can maintain his own schedule.
It sounds better, but it’s still not as good as I’d like it to be. How about thinking of a person instead of a role?
Jack the Customer Representative searches for customers by their first and last names so that he can see their information.
John the User can modify his schedules but not the schedules of other users so that he can maintain his schedule.
That’s much better. We can now discuss about what Jack might want to do in the application and learn more about our users in the process.
Some of you may recognize this technique; it’s called “personas”, at least once you add to each person an identity: a photo, a short description and so on. However, what’s different here is that I’m advocating the incremental creation of personas and the usage of “persona slicing” (no, we’re not gonna slice people, even though I love the Dexter series).
Once we know we’re talking about Jack and John, we can add more details: a photo or a drawing, age, sex, familiarity with IT systems and so on. It may turn out at some point that we need to discuss about more kinds of non-administrative users, and that’s when we decide to “slice” John based on a specific information like age:
John Sr. needs large fonts in his schedule because he’s short sighted.
John Jr. would love a touch screen interface because he loves the new technologies.
I admit, it can be a little bit trickier and certainly funnier with other types of persona slicing (maybe create Joan and Jackie?), but it doesn’t have to be serious all the time. Actually, it must be fun at least some of the time.
So, that’s another way of writing stories which in my view is more valuable because it adds a human touch and more context. What do you think?
It’s definitely better the more you think about users as real people with specific needs. Being funny is good, too.
But any kind of user stories are better than none. Too often customers — and developers — think in terms of how the application is going to work, instead of what it’s supposed to achieve. Hence the oft-heard exchange: “It does exactly what you asked for!” “I know what I asked for! But it’s not what I need!”