I would like to improve in writing goal-oriented user stories/features

Question

I would like to improve my user stories writing abilities so I need your experience and guidance. I think that each variable part of a user story can be improved by following certain guidelines.

1. Role

Defining possible roles may be the easiest part. The only problem is that user stories usually just describe functional features that need development.

• Do you write non-functional stories? And I'm not thinking about technical stories that are related to other aspects of product planning like administrative things. I'm more thinking of additional supporting stories that support the same high-level goal. Like advertising related stories that are related to features?

2. Feature

Defining features seems to be easy but it turns out it's not. Because I can see stories that are heavily related so certain roles can't be developed until others are finished. Example: User registration is a pillar user story that needs to be done first in order to develop other user stories that are related to registered user roles (logged in users and/or admins etc.). This one is very obvious but sometimes relationships are much more subtle.

• How do you avoid relationships between user stories? Is there a technique to break related stories apart so we can have better development parallelism? Breaking relationships also helps better sprint cycles because one story can't stall the whole sprint.

3. Benefit

This one is the hardest part that I think I have least knowledge how to write good user stories with clear benefits.

• Do you actually write benefits per story or do you rather provide high level goals instead? Providing these instead of benefits makes it easy to see why certain user story is more important than the other? So it helps prioritisation.
• Is it wise to have shared benefits/goals between set of user stories?
• Do you write user stories without benefits part? Is that wise and what do you do instead?
• Do you write benefits in a way so they can be measurable? Can we do that and is it beneficial?

4. User stories as a whole

• Have you ever defined all user stories as epics? This would help filter out/prioritise those that give more to the common goals. Then split them into digestible chunks or per single feature user-stories.
• What additional metadata do you add to user stories? Also talking about user story grouping per higher feature or goal...

Answer 1

The user story format is pretty flexible.

“As a (type of user), I want (some feature), so that (some goal)”

I've seen this format used successfully at my workplace. For example:

"As a System Administrator, I want copies of the product catalog sent daily to our Sales Partners so that these partners always have the most current version of our product catalog"

In this example:

1. A feature is defined. The feature might take the name Partner Extract, for instance. It might be implemented as an ETL job that runs nightly to create data files that are made available to Sales Partners via SFTP.

2. The user story embeds the roles. The two roles identified are System Administrator and Sales Partner.

3. Incorporating non-functional requirements is easy. The above example includes one non-functional requirement: the product catalog updates must be daily. Requirements that address how much, how fast or how often are non-functional requirements. I like to refer to these requirements as "quality attributes". Here is another example of a user story that expresses a quality attribute:

As a Call Center Representative, I want customer search to return the result in 2 seconds or less (on average) so that customers are not left waiting on the phone.

Write user stories for reliability, security, capacity or any other quality that is deemed important.

Feature Dependencies

You have identified some legitimate limitations of user stories. They are unordered and there is no guarantee they will be independent. In fact, the might be interdependent-- a chicken-and-egg problem. I believe that all non-trivial projects require documentation to supplement the user stories. I watched the agile team here at work create activity diagrams (flow charts) of the business process. These diagrams were used to analyze the feature dependencies. Another approach might be to create PERT diagram in a big all-day session with the customer. In the end, some other artifacts will be necessary to support the user stories.

Epic!

A narrative that describes the scope of a project is a good idea. There should be something like a statement-of-work or a project charter. No serious project should be without one. These documents provide a starting place for identifying user stories. These document help answer tough questions like "What should be the priority of this feature?"

Metadata

After 15 years in the business, I have an opinion about meta-data. In general, it should be avoided. A few reasons include: after a month, no one knows if it is accurate; no one knows if it was updated; it is extra work to create it; you can't predict what metadata will be useful. Most meta-data is a distraction. I like to track owner, author, priority, estimate of effort, and date of last modification. Beyond that, I fight hard to keep meta-data out user stories and use cases.

Benefits (so that...)

I have an opinion about this as well. :-) Including the benefits is vital. Often, users will request a feature without having though about its value. No matter how good an agile team is, the project will fail if it implements unimportant stuff at the expense of more critical functionality. Also as a developer, I do a better job coding a feature if I know how it fits into the big picture. Here is a real-life example of a requirement without justification: "The system shall prevent transactions with EIP and a gift card from occurring.". Huh? What is EIP? Why do I care? Why does anyone care? I don't know. Understanding the context would have been helpful before I went to the business analyst for clarification.

Even worse is when no one remembers why the user story was written. Do we still need this one? Has the business process evolved to the point where this user story is invalid? Does anyone know? These conservations waste time. It gets suckier if the the author of the user story has left the company.

Measurement

Here is an example of user story that is not measurable:

As a Call Center Representative, I want the system to be fast so that customers are not left waiting on the phone.

How fast is fast? A millisecond? A tenth of a second? Ten seconds? Nobody knows. Nobody wants to be wrong so no one every even makes a guess.

Compare that user story to this one:

As a Call Center Representative, I want customer search to return the results in 2 seconds or less (for average daytime call volumes) so that customers are not left waiting on the phone.

This user story is testable. Average day time call volume can be determined from log files. Performance testing can be conducted to determine if the requirement has been met. Even better, the users and developers have agreed on the success criteria well in advance of the end of the project. Testable requirements are a beautiful thing.

Answer 2

I would like to say up front that I am no specialist in Agile development and have been using it with my team for just over a year. However, in this year I feel like I've grasped the core concepts of Agile. My answer below might be influenced by how we implemented Agile in our team but I feel we should not focus on adhering to the hardcore definition. I like the idea of "pick what you need" and we have certainly benefitted from this.

Also, you seem to have a misconception that a sprint is part of Agile; a sprint is part of SCRUM.

1. Role

Do you write non-functional stories? Those aren't technical stories to begin with. Technical stories define highly technical requirements. A good way in which technical stories are used is in "Eleven Lessons Learned about Agile Hardware Development".

A non-functional user story could be "As a colorblind person, I want an adapted GUI style so that I can do my color-sensitive work".

2. Feature

How do you avoid relationships between user stories? You don't. If you have no user registration in place, you simply can't develop things that require this functionality. You can however discuss functionality with the client, make a design or write tests.

Is there a technique to break related stories apart so we can have better development parallelism?

Not sure if this hits the nail on its head, but I was thinking that thinking in thin vertical slices might be useful for this.

Stories are the broken apart version of an epic. If you want even more granularity, you can write the classic functional requirements for them; but I feel that since in Agile teams are self-organizing, there should be no more granularity. If more is needed, commnicate with clients or developers.

Breaking relationships also helps better sprint cycles because one story can't stall the whole sprint.

If the sprint is meant to implement user registration, we won't add user stories that depend on user registration to the same sprint. I feel if you want to achieve better development parallelism then you shouldnt focus on developing many user stories in parallel, but rather the set of functional requirements that underpin them, whether they are explicitly specified or not.

3. Benefit

Do you actually write benefits per story or do you rather provide high level goals instead?

The implementation of a user story should be a benefit in itself. As ahoffer pointed out in his answer, the benefit is the "So that.." part of the user story. The epic the user story is part of is the shared goal of all the contained user stories.

Do you write benefits in a way so they can be measurable? Can we do that and is it beneficial?

It depends on the user story. "As a user I want X so that I can do Y faster." and "As a user I want X so that I can do Y in 12 seconds". Suppose that Y is something like saving a file, do we really need to quantifiy that to "12 seconds" instead of "faster"?

4. User stories as a whole

Have you ever defined all user stories as epics?

No, that's not how I feel you should treat user stories. An epic is a large piece of work, and a user stories defines smaller pieces of work within that epic.

What additional metadata do you add to user stories?

The epic they are part of, the sprint that they're part of (if they're the subject of a sprint) and the developers assigned to it. (Again, if the user stories are the subject of a sprint.