Advanced Guide to the Agile Method: User Stories

The Agile Method is a project management technique that enables rapid development of a working product, allowing for transparency and flexibility in design and modifications so that the customer is ultimately satisfied with a working product. User stories are what define the functionality of a project, written in bite-sized pieces so that a team can produce functional deliverables that can be presented to the Product Owner as soon as possible.

In our Beginner’s Guide to the Agile Method, we talked about the basic terminology, structure, and philosophy behind working in Agile. Now, we’re going to go in depth and look at how creating great user stories can lay the foundation for an exceptional project.

A Closer Look at User Stories

User stories are at the core of Agile projects. Without stories, developers would be floundering for direction to create functional deliverables. The shortest form of the user story is a simple sentence:

For a retail website, you might see a story such as “As a website customer, I want to change my address so that I may receive my purchases.” Obviously, this user story would be based on other stories that define the Epic, but it can give you an idea how a story might look.

Avoiding Scope Creep

Let’s say you were going to create a retail site. You have the job of putting together the next part of the story, and you’ve come up with, “As a customer, I want to change my address so that I may receive my purchases,” but is this a good story? It can be, if you take the following steps into consideration:

1. How much has already been done so that you don’t have to further define your user, your goal, or the benefit? It makes the scope of the work much bigger if you don’t already have the user login, address, and web page designed.
2. Is this a single story or is this closer to an Epic? Do you have to define multiple stories to get to this story, or have they already been done?
3. If you believe this is a single story, will your team be able to create a functional product, or will you make the task bigger than the sprint time allows?

It’s very easy to be swayed by the siren song of scope creep.

As a developer, it’s very easy to be swayed by the siren song of scope creep, and allow your task to become too big to be reasonably completed in an average sprint. While the features may indeed be needed for your user story to work, it shows that you haven’t reduced your user story down to the simplest component.

In our case, “As a website customer, I want to change my address so that I may receive my purchases” may be too big. Instead, you may want to break it up into multiple user stories such as:

• As a website customer, I want to create an account, so I can purchase something.
• As a website customer, I want to enter in my contact information, so I don’t have to contact customer support with that information.
• As a website customer, I want to enter in multiple shipping addresses, so I may send my purchases to different places.
• As a website customer, I want to select from different payment options, so that I can pay for my purchases conveniently.

Using INVEST When Creating a User Story

Bill Wake, an Agile Method guru, developed the mnemonic “INVEST” to describe what is necessary for creating good user stories.

• I – Independent — The user story should not overlap with any other user story and should be able to be implemented at any time. This may or may not be able to be accomplished, depending on the task.
• N – Negotiable — The user story should not be set in stone. They should be able to be changed and rewritten up until delivery.
• V – Valuable — The user story needs to provide some value to the user or the customer. If it provides no value, then it is not useful.
• E – Estimatable — The user story’s scope should be able to be estimated. Maybe not to the hour or to the line of code, but you should have a pretty good idea how much work it entails.
• S – Small — The user story needs to be small. Preferably able to design and implement in a day.
• T – Testable — The user story should provide the framework for testing. The code should be able to be tested successfully to the user story.

Formal Versus Informal User Stories

When considering the type of user stories you’re writing, following the above description on constructing a user story will create a formal user story. An informal user story would look more like a basic requirement, such as “Ability for customers to change their address.” Both formal and informal user stories should have estimates and priorities assigned to them. The estimates should entail the portion of the sprint needed to accomplish the task; the priorities can be ranked by whatever is most meaningful to your team.

Formal user stories can further be defined through confirmations. Confirmations are details that flesh out the story. In the case of the retail website, “As a website customer, I want to change my address so that I may receive my purchases,” you might see the following confirmations:

• The address must be a valid address.
• The address must be a physical address for private parcel carriers such as FedEx or UPS.
• The address must be a mailing address for USPS.
• The address must have a valid city, state, and zip code if in the United States.

While they may be useful to some teams, we do not recommend informal stories for someone new to Agile. They often provide too much leeway to properly identify what needs to be done, and should only be used sparingly.

Although the Agile method isn’t for everyone, its ability to empower teams to quickly produce functional deliverables is unmatched. If you’d like to learn more about the benefits of Agile, stay tuned for our next entry in our Advanced Guide to Agile series.