Since the adoption of user stories, we have noticed huge benefits in our development workflow. We don’t expect to plan everything upfront anymore, don’t waste time analyzing things which will never turn into software, and can deliver value to our customers much quicker and more efficiently.

Many other companies have experienced the same benefits and it’s for this reason that user stories are becoming a standard way to collect software requirements. If you’re not familiar with them, you can learn more reading here or getting this book. For now let’s just think of them as simple sketches on Post It notes, in the following form:

The good about User Stories

User stories don’t mention software features, focusing on user interactions and user benefits instead. Since they need to fit on a Post It sheet, they need to be short. Therefore, rather than being a list of detailed requirements, they end up being simple “reminders” of what will need to be discussed later on in the project life-cycle. Maybe. Yes maybe, because after having developed several stories, you might realize that several others do not need to be implemented at all. They are scratched from the project road-map altogether, before requiring significant design and development effort.

Stories are developed and delivered incrementally, in order of business priority. At each iteration (development phase) a batch of stories is selected, analyzed and turned into working software. Value is delivered to customers at regular intervals, much earlier than with traditional development processes.

 

Are User Stories a Silver Bullet?

I’m sure the above sounds great. And indeed it is. But let me tell you a story: several years ago I got to work with some folks from an Italian company, which is famous for its adoption of agile methodologies. I’ve learned a lot from that experience. They quickly explained everyone involved in the project what user stories were, then assigned each of the developers and customer representatives (around 15 people) a set of post it sheets, and finally said: “ok everybody, let’s now start writing user stories together”. Everyone started to think about some stories and gave his contribution. By the end of the day, we had collected several dozen Post It sheets.

All good, right? Well, not really. Sure we had put together a lot of stories. Problem is that later on, after we had developed them, we found out that many provided little or no value towards the project goals. And I’m sure we had missed out several others which would have. Don’t get me wrong. I’m not saying that stories are not the way to go, and that you shouldn’t measure things in retrospective. But development has a cost. And if you can avoid developing the wrong things from principle, well, I think that’s even better.

A problem of perspective

I’m now confident the problem we faced is a perspective one. Let’s consider user stories in the form we have seen above again. By starting our statements in the form

we are focusing on ourselves. And, in this example, if I think about myself shopping for some gifts, I think about as many filtering options as I can. And so – I’m sure – will do many other geeks, who just love to evaluate all possible available options. The problem is that intended system users will probably be different. They won’t know or care about Pareto optimals or multidimensional optimization. They’d probably just pick the best looking item, for the peace of their mind. System users more often than not have a different background, different expectations, and most likely different needs from ours. Which we need to take into account, and which we did not in the situation I’ve mentioned above.

Introducing Personas

In order to avoid this kind of issues, we introduced personas (for a good quick introduction see this book) into our requirements gathering process. We wanted to make sure we delivered software which satisfied intended users needs, not just our customers or ourselves. So, we started to create stereotyped characters of our intended users (whose characteristics were gathered either through interviews, observation or both) and then writing stories in the following form:

Now imaging implementing, or just estimating this story. At this point, you might be wondering who the heck Josie Black is. And that’s a good question. Let’s describe her as follows:

 ”Josie’s a 28 years old busy lawyer from Los Angeles, California. She’s always in a hurry, obsessed by her job and tends to forget about her friends’ birthdays. Therefore she looks for presents on the Internet, always at the very last moment. She has a budget in mind and doesn’t care much about making the perfect gift. A good one will be enough. She just wants to get the purchase job done as quickly as possible, so to get back to work. She’s annoyed by systems who do make a lot of questions and offer too many options.”

Now, what if Jodie’s profile was more similar to the following:

 “Josie’s a 68 years old retired business woman, who now lives in a small town in New England. When she was living in New York city, she loved to go shopping in malls and spending a lot of time looking for the perfect present for her friends and family members. Nowadays she enjoys the countryside, but misses shopping a lot. Luckily there’s the Internet, and that’s where she still does spend a lot of time searching for the best gifts. Before making a purchase she literally compares dozens or even hundreds of items.”

Now try to read the same user story above again. Do you feel the same way? If you need to make an estimate on development effort, do you think it’s going to take the same amount of time? Do you still think the story above is the best you could write? From our experience, the answer to these questions is almost always no. And that’s a good thing already, since the use of personas helps us being more accurate when writing stories and making initial estimates. What’s even more important, though, is the fact that when you properly consider the people who’ll use the system, you can easily ditch those stories which do not make sense at all. The process is no different from the traditional one, and everyone in the team can suggest a story. The point is that suggestions do not start from our perspective, but rather from that of our personas. And we’ve found this to be a significant switch. After all stories are collected, moreover, we review them and ask ourselves: “would this guy/gal, or anyone else of these folks here find this story useful”? If the answer is no, we simple drop the story.

Conclusion

The majority of our customers come to us with a set of requirements that they expect us to transform into software. When they accept to follow the process introduced above, interesting things emerge. The most significant one is surely the 50% of features they were requesting being cut off.  With personas it’s immediate for eveyone to find out about features which would be of no use for anyone. This is a fundamental point, which much improved our process and efficiency. But that’s only part of the game. As JJ Garrett points out, there are 2 things you need to address for an application to be successfull: user needs and business goals. The technique described above proved to be much helpful for better understanding user needs. A forthcoming post on this blog will talk about other techniques we do use in order to make sure business goals are also met.

Photo Credits: flickr.com/photos/eschipul/4160817135,
flickr.com/photos/coalitionforicc/6521548779, flickr.com/photos/judybaxter/4272568538