Stating what the User 'Really' Wants

In my previous post I stated my opinion that the "biggest problem" in software engineering is "bridging the 'gap' between understanding what the user truly wants to accomplish and how to best leverage technology to help accomplish that." For some reason, I seem to be wired to perform this particular task intuitively. What is missing for me is a way to communicate my discoveries and understandings. When I have successfully discovered what the user "truly wants" I have failed to accurately communicate that anyone else.


This article contains some of my thoughts on how I intend to address that failure moving forward. Let me forewarn the (unlikely) reader that I have not yet successfully validated this approach. It is simply my intent to test its validity.


User Stories


User stories are intended to be a tool used to capture "what the user wants to achieve." If you look at examples you will find they provide real promise in accomplishing that objective. One of the common structures recommended is in the form: "As a <role>, I want <goal/desire> so that <benefit>."  The benefit portion is sometimes considered optional.


There is an aspect of what the user wants that is missing in user stories. User stories don't talk about what the user doesn't want. I propos to add a special category of user story. I will call this a 'User Gripe'. In a user grip, we address what the user doesn't want to have happen, what the user hates about the current system or what activity the user wants to avoid. If we use the same format to describe a user gripe it may look like this: "As a <role>, I don't want < obstacle/undesired behavior> because <pain caused>." 


I like user stories. I think they have value, especially if we add the concept of a user gripe. There is something I don't like about user stories however. Who's story is it? If we use the recommended format we find ourselves having to record the same story for different roles with potentially different benefits. I could just say "As a <role> or a <role>, I want ..." but that can get really ugly.


I think I want to use a connection to associate actors to user stories. If I define the benefit on the connection then I can associate multiple actors to the same story and define the benefit the actor gets from the story. The definition of the benefit could still be optional but the connection is not.


Related User Stories


What should be done with two different stories that are simply two ways to accomplish the same thing? If each individual piece of functionality needs to be developed they both must be documented.


Some people would advocate making a generic user story and defining the details in the design phase of the sprint. In many cases this will work. However there are times when you want one method to be developed in one sprint and another method in another sprint. In these cases a single story will not allow you to plan your sprints appropriately.


Another issue is related to 'epics'. If you start with an epic and then refine the epic to multiple user stories, is there any value in keeping the epic? If so, how do you establish (track) the relationship between the epic and the story?


These and other scenarios drive me to the concept of modeling relationships between user stories. It appears to me there are two relationships:

• Aggregation or containment - One story includes others. This is the case with epics. 
• Specialization or inheritance - One story may be a specific means of accomplishing a more general story.

As an example, take the scenario with which I am currently working. Imagine a help desk system that helps manage support incidents for a machinery manufacturing company. A service technician and a service administrator are interviewed and they both want to create a customer interaction and relate it to a specific incident and a specific piece of machinery. Since they often interact with the customer via e-mail, they also want to create an interaction using e-mail.


With a traditional approach of creating user stories on a 3x5 card you would likely end up with about 8 cards. Four would start with "As a service technician" and four with "As a service administrator." All the stories would be about creating a customer interaction but two (two copies) would have the same content about a specific way to create an interaction, while four (two copies of two) would be about some information that may optionally be included during the creation of an interaction. With a modeling technique you could have four stories with their relationship to each other and their actors. Here is what it may look like.

By putting information on the connections I can describe the benefit portion of the user story from each actor's perspective. If I have the ability to generate document text from the diagram, I could assemble user stories for review with the user. Because of the connections I can focus on all stories for a specific user or all stories related to a specific story. If I can search text associated with the connections I can find all stories that provide a certain benefit.


I wanted to cover more ground but this post is long enough already. I will pick it up in another post with the relationship between user stories and use cases.


Tory