When building applications, it is imperative to think like the user. That's where user stories are valuable! A user story isn't just a task or action item; it's a tool that helps development teams incrementally build user-centric products that provide value to users and customers alike. User story requirements are derived from all sectors of the application development ecosystem, including user, customer, and stakeholder desires, as well as business and technical constraints and needs. In short, user stories drive the incremental delivery of value that characterizes agile development, and work best when they are actionable, specific, measurable, and goal oriented. Below I'll answer some basic questions about user stories that will help you create well-crafted user stories and ensure the success of your agile projects.

What is a user story?

User stories are the most common agile method for describing the desired functionality from the perspective of the user or customer of an application who wants a particular capability. User stories shift the focus from the traditional process of writing requirements to talking about them by inspiring conversations about features and functionality in a single sentence or two. While user stories reduce the time spent on writing exhaustive requirements documentation such as "shall" statements, they more importantly provide a placeholder for future user- and customer-centric dialogue.

When should I write user stories?

There is no specific time frame for writing user stories; in fact, they should be written throughout your agile project. However, a good rule of thumb is to start each of your projects with story-writing sessions. We have found that these sessions will not only help ensure participation of all our team members and establish some ground rules around formulating user stories, but also facilitate the creation of product backlog items that describe the functionality that can be added over the next few sprints within a release cycle. Remember, in many cases, some of these user stories will be epics that will need to be decomposed into smaller stories that better fit into future sprints; but more on that later.

How do I write a good user story?

There are two practical methods that can help you write good user stories. The first method, the Three Cs model, coined by Ron Jeffries in 2001, encapsulates the components of a user story: "Card, Conversation, and Confirmation." According to Agile Alliance, Jeffries proposed this model to distinguish "social" user stories from "documentary" requirements practices, such as use cases. Jeffries explains each component as:

• A "Card" is a written description of the story used for planning and as a reminder.
• A "Conversation" takes place at different times and places during a project between various people concerned by a given feature of a software product: customers, users, developers, and testers. This conversation is largely verbal but most often supplemented by documentation.
• The "Confirmation" implies that the objectives the conversation revolved around have been reached, or tests that are used to determine when a story is "done".

The second method, the INVEST model, was defined in an article by Bill Wake in 2003. This model serves as a checklist to evaluate the quality of user stories. The purpose of the INVEST model is to ensure that user stories are clear, actionable, and contribute to the overall success of a project. Here is how each letter in the method breaks down:

• Independent: User stories should be self-contained and not dependent on other stories.
• Negotiable: Requirements should be open to discussion and refinement.
• Valuable: Each user story should provide value to the end users or customers.
• Estimable: Teams must be able to estimate the effort required to complete a user story.
• Small: User stories should be small and focused, addressing a single piece of functionality.
• Testable: A user story should have clear acceptance criteria that define when it is “done.”

Regardless of the model you decide to use, writing good user stories requires three important things: (1) an understanding of the basic user story template; (2) a focus on the user or customer; and (3) a clear picture of the desired functionality. That said, when writing your user stories, follow this standard format:

As a <Role/Persona>, I want <Goal/Objective> so that <Benefit/Result/Some Reason?>

This format allows you to capture the essential elements of a requirement: who it is for, what it expects from the software, and why it is important or valuable. Here are some general rules when using this format:

• Role/Persona – Should be an actual user, or group of users, who interacts with the application. This should be as specific as possible, and remember, the development team is NOT a user.
• Goal/Objective – Should represent the behavior of the software and written as an action. This is typically unique for each user story, and should be written in active voice, not passive voice.
• Benefit/Result/Some Reason – Should be a real-world result that is non-functional or external to the software. Many stories may share the same benefit/result/some reason statement, and may also be for other users or customers, not just for the actual user of the user story,

User stories can also be written at varying levels of detail covering large amounts of functionality, or only a small discrete piece of functionality. Like we discussed earlier, many of the larger user stories, or epics, that you develop at the beginning of a project will contain less detail. Since these user stories are likely too large for your team to complete in a single sprint, they will need to decompose them into multiple smaller user stories, each properly sized to be completed within a single sprint and each containing clear and measurable acceptance criteria. While epics can provide the bigger picture to your team, decomposing them into smaller user stories will not only allow your team to divide the task items to work more efficiently, but also help them more easily complete and show their work to users, customers, and stakeholders at the end of a sprint.

Who should write user stories?

This is often a source of contention in many environments; however, most agile professionals agree that there is a clear delineation between the responsibilities of the product owner and the development team. While it is the product owner's responsibility to ensure a product backlog of agile user stories exists, that doesn't mean that the product owner is the one who responsible for writing them. Over the course of a good agile project, you should expect user stories to be written by each team member. However, keep in mind that who writes a user story is far less important than who is involved in the discussions to create it. That is why it is imperative that you ensure the right people are in the room when having the conversations that drive the creation and confirmation of a user story.

Can you provide some examples?

Glad you ask, because one of the best ways to learn how to write good user stories is to see examples. Below are a few real-world user story examples from our web site.

As a…	I want…	So that…
…site visitor	…access old blogs available from the Insights page	…I can retrieve subject matter that I remember from the past, or others recommend to me.
…employee	…securely access the Costpoint timekeeping application	…I can retrieve and enter my daily timesheet information.
…partner	…see a list of contract vehicles and descriptions	…I can review them and evaluate partnering options.

What are the benefits of user stories?

In conclusion, good user stories can provide several benefits to your agile projects. First, they can help your teams deliver high value by focusing on small and immediate user and customer needs, often allowing your teams to implement and deliver small features in just a few hours or a few days. Second, since the development of user stories relies on user- and customer-centric dialogue and collaboration, these discussions allow participants to reveal diverse business and technical perspectives and provide the flexibility for creative and innovative ways of solving user and customer needs. Additionally, these discussions will allow your team members to directly connect with users to understand their perspective, challenges, pain points, and opportunities.