Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

What Are User Stories, and Who Should Write Them?

DZone's Guide to

What Are User Stories, and Who Should Write Them?

User stories make it easier to understand exactly what you are building, why, and who it's for. Read on for more on who captures them and how.

· Agile Zone ·
Free Resource

Adopting a DevOps practice starts with understanding where you are in the implementation journey. Download the DevOps Transformation Roadmap. Brought to you in partnership with Techtown.

If you are engaged in software development, you must have heard of user stories. Perhaps you even write them as a manager. Or maybe you're a client and your software developer wants you to frame feature requests as user stories.

In this post, you'll find everything you ever wanted to know about user stories.

What's a User Story in Software Development?

A user story is a format for framing software features and/or requirements. As the "user" part suggests, user stories are written in first-person singular and describe a feature as it is perceived by the app's user.

A typical user story follows this structure (if we're talking about the Agile development process):

As a [user role],
I want [this-and-this feature],
So that [this-and-this effect is achieved].


The first part (as a...) specifies the user's role in the application, which is normally associated with what one is allowed to do there.

The second part (the feature) points to the piece of functionality that is used in this case.

The third part (the desired outcome) is the value the user wants to get out of the feature. Here are some examples.

Example 1

As a registered user,
I want to be notified when a friend is going to an event nearby
So that I can react to the news or join them in the event.

Example 2

As a rider,
I want to get a 10% discount on every 10th trip
So that I get rewarded for consistently spending money on the service.

There are sound reasons for this kind of structure. When product/project managers deal with software requirements that come from a variety of sources, it is sometimes difficult for them to attain uniformity. Which category of users the feature covers or where the business value lies may also be unclear. The user story format helps capture these critical details.

Approaches to Composing User Stories

User stories can be written in a variety of ways, depending on who's going to work with them.

The Gherkin Way

Gherkin is a plain-text language that describes behavior without specifying its implementation. Here is a simple example of the Gherkin syntax:

Feature: Guest contributor functionality
    In order to contribute to blog XXY
    As a guest author
    I want to be able to publish articles on the website


Scenario: I edit my own article
    Given I am a contributor
    And I am logged in to my account
    When I am on a separate article page
    And I am the author of this article
    Then I can see the "edit" button
    And I can click it
    And I can use a popup interface for editing my article



Scenario: I edit somebody else's article
    Given I am a contributor
    And I am logged in to my account
    When I am on a separate article page
    And I am NOT the author of this article
    Then I CANNOT see the "edit" button


As you may have noticed, indent defines structure in Gherkin. The basic parameters are Given/When/Then, and these can be appended by multiple And's if necessary. The syntax goes beyond these basic parameters, though. If you're really determined to master Gherkin, here's a nice tutorial.

While Gherkin may not be the best choice when you're gathering initial requirements for the project, it can be beneficial (especially for the QA team) when further developing user stories. User stories written in Gherkin are easy to convert to test cases.

The Agile Way

Many Agile project management applications offer a functionality for entering user stories. For example, we've used the Taiga app on some of our internal projects. It helps you organize work around user stories that can be broken down into individual tasks in the backlog.

Source: Taiga.io interface

If you think about it, it makes perfect sense to have user stories as backlog items and then add multiple tasks to one user story. Why? Because, let's say, you have one feature (=user story) and three people working on it; you'll need separate tasks for those people. You'll need a designer to design the interface, an HTML/JavaScript programmer to program the interface, and the DevOps to release the interface into production.

Other tools like Pivotal Tracker (that introduces the concept of "epics" to group related stories together) also let you create stories that can be of different types: Features, Chores, Bugs or Releases.

Source: PivotalTracker.com

Apart from the various approaches used by various companies, remember that there's a simple and straightforward way to word user stories — examples of which you saw at the beginning of this post.

Who Should Write User Stories?

So, whose responsibility is it to write user stories? Well, it depends. If your team has agreed to capture features in the form of user stories, it is most likely that they'll come from the shareholders through the Product Owner. So, it may be the PO who actually pens them down.

It could also be a Project Manager or a QA who may also work with the client to discuss features and requirements. Or, maybe you're a 15-person startup and you are the CEO, CTO, and CMO? In this case, you could set an example and start using user stories to document features.

Many in IT also talk about "user story development," which is the process of registering high-level details first (e.g. starting with a simple list of features) and then developing them into more detailed stories by adding tasks, scenarios, etc.

In Conclusion

At the end of the day, formulating features in the shape of user stories helps you stay focused on the business objectives. It also helps you make the requirements complete. And, as was said, the exact template/fields you use could be different, depending on the situation.

Take Agile to the next level with DevOps. Learn practical tools and techniques in the three-day DevOps Implementation Boot Camp. Brought to you in partnership with Techtown.

Topics:
agile ,user story ,agile manager

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}