Agile User Stories – Getting It “Write”

By Karen Fischer

“I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant.” ― Robert McCloskey

The success of any project depends upon clear communication and customer involvement throughout the entirety of the Agile Software Development Life Cycle. Poor communication between team members and the customer/product owner often results in a number of pitfalls which leads to lost productivity and reduction of quality in the delivered product. Writing User Stories correctly helps bridge many communication issues, brings clarity, and leads to high-quality results.


User Stories are NOT Requirements

Many teams find it difficult to transition from Waterfall to an Agile development method simply because they are accustomed to referencing a complex list of software requirement specifications. While the objective of User Stories for all intents and purposes is to achieve the same end result as software requirements specifications, they differ in a number of ways. User Stories:

  • Are not as detailed as requirements since they describe functionality from the users’ perspectives and not the system's perspective
  • Are short and easy to read, enabling them to be easily understood by developers, product owners, stakeholders, and users
  • Represent small increments of valued functionality that can be developed and tested in a short period of time (days to weeks)
  • Usually start out as Epics (some large, vague idea of how the software should function), which are then broken down into simple, more manageable, testable pieces that are easier to build, test, and deploy
  • Are easy to estimate, helping the agile development team understand complexity, plan for iterations, and gauge velocity
  • Are organized in lists that can be more easily re-organized and prioritized as the functionality evolves and as additional information becomes available; they are not outlined in a complicated document, spreadsheet, or project software involving substantial maintenance efforts
  • Provide input to support documenting the changes made during development and test phases (Note: updating project documentation should always be part of every sprint cycle as it is easier to make updates concurrent with any software changes)
  • Identify the intended business value to communicate the purpose of the functionality amongst the team

Additionally, User Stories should provide a Definition of Done, which is a list of criteria agreed upon by the Agile Team. These must be met before the User Stories are considered "done." Failure to meet these criteria at the end of a sprint normally implies that the work should not be counted toward that sprint's velocity. A Definition of Ready should also be agreed upon by the team. In short, “ready” can be defined as a list of input criteria for accepting a user story in a sprint. This list reflects where the product owner and the team agree to the prerequisites needed for starting a sprint. The list also helps signal to the team that they can begin working on specific items in the product backlog. For more details on Agile definitions, refer to the following website”

User Stories are a forward-looking activity. There is no real benefit or added value in creating User Stories for legacy requirements that have been previously implemented and tested successfully. Development efforts on defining and refining User Stories are best spent on new/changing functionality.


What User Stories Should Be

The format of an Agile User Story consists of the following: As a <role> I can <activity> so that <business value> + Acceptance Criteria

  • Role – represents who is performing the action or the one who is receiving the value from the activity.
  • Activity – represents the action to be performed.
  • Business Value – represents the value to the business.
  • Acceptance Criteria – outlines the conditions of satisfaction being placed on the system which is approved by the customer/product owner.

Using the 3’’x5” Index Card example template below in Image1, a User Story can be best described as a short description of the customer’s need. Whenever possible, a User Story should be written by the customer (product owner) or someone the customer delegates to act as a business representative. A User Story should be kept short and fit on a 3"×5" index card during working sprint sessions. The text on the card should cover the role of the user in the system <As a>, the need expressed by user <I want or I can>, and the benefit from implementing described feature <So that>.

The main purpose of a User Story is to convey the user’s need and estimate the effort needed to implement a new software feature or change and provide a Definition of Done for the team. These estimates are generally referred to as “Size” or “Story Points.”  “Story Types” reference the origination of the User Story. Types of User Stories can be used to create a collection or to group similar types of User Stories such as Defects, Customer, Technical, New Functionality, etc. within the Product Backlog or on a Story Board.

User Stories enable conversation that leads to extracting business and technical requirements and eliminating hidden assumptions. Sometimes they are mistaken with Use Cases and Use Scenarios, but the biggest difference is that they are much shorter and do not describe the application interface, steps, or flows in the application. The success of a User Story is confirmed by Acceptance Test as derived from the Acceptance Criteria, sometimes referred to as Conditions of Satisfaction. All of these elements are important and play a role in expressing and understanding the captured requirement.

Image1 - User Story Template Using A 3’’x5” Index Card:

User Stories should be kept simple and the titles should be kept to just a few words in order for the team to recognize and remember easily (also used so the team can refer to it in their stand-ups and daily activities). Complex User Stories, referred to as Epics, should be decomposed into smaller User Stories. These Epics/User Stories will serve as the basis for the Product Backlog content.

After the sprint is completed and sign-off acceptance is received, the 3”x5” cards can be discarded. Any historical information and associated documentation for the User Story implementation should be stored in an Agile Configuration Management (CM) repository. It is important to note that there are many Agile teams that don’t use physical 3’’x5’’ cards but implement the same concept using software tools. Often, Agile teams use a combination of both to track User Story progress until delivery, store historical documentation/artifacts, and outline details of a specific change made to the software. 


Facilitating the Process by Using Available Tools or Software*

Using visuals and commercial Agile software products help facilitate the understanding of desired functionality. Not involving the developers (aka designers) sooner, to create a visual for the customer, is a critical mistake often made.The key is to involve both early in the conception phase. While a User Story leverages words, the visuals help translate ideas into concepts. Whereas 3”x5” cards are best used as working sessions/drafting Users Stories; it is better to use tools in the long-term. Utilizing the right software will help facilitate and improve all Software Development within the Agile Framework.

The right Agile software can help categorize similar child/parent dependencies among User Stories, by facilitating and enabling the Agile Team members to search via key words or “like” concepts. Although cliché, choosing the right tools for your project helps facilitate the current process or can be used to improve the sprint process. Tools should never drive the process.  As most vendors enable you to try a product for 30-60 days before buying and committing to it, I would recommend going this route. Define your Sprint process, timelines, and enter User Stories data to determine which tool is best for your project. Just because tools come packaged as a “suite” doesn’t mean the tools can be customized to fit your process. Tools should not be rigid. If you find these software tools difficult to use or if they take too much time to update/maintain, you have chosen the wrong tool. An Agile tool should be able to help product owners create User Stories and enable developers/team members to understand the work for which they are responsible, when it is clearly prioritized and tracked.

Features to look for in an Agile User Story/Product Backlog Tool include the following:

  1. Reports outlining tracking and metrics are built in and can be downloaded as a spreadsheet or graphic
  2. Provision of historical information defining who is making the changes (how each change was implemented; what the specific change was; who made the change, etc.)
  3. Links to relevant documentation or source code (potential impacts to training materials, user guides, software design documents, etc.)

In Image2 below, is an example of a Software User Story template using a Details tab to convey the user, goal, and value of the User Story. The other tabs could be used to implement the change; outline associated test cases; and link to related files, documents, and/or other attachments that should be linked to a specific User Story.

 Image2 – SW Which Capture Detail of User Story/Product Backlog 

*Intent is not to recommend specific software to buy but rather to conduct your due diligence and research what is available before you purchase. Many companies offer trial versions of their software so you can determine if it fits your needs before making a final commitment.


Customer Involvement/Buy In Should NOT Be Optional

The success of any project depends upon clear communication and customer involvement. Poor communication between team members and the customer/product owner can be the more significant pitfall for many Agile development projects. It is important to emphasize that understanding what the customer wants and the business processes surrounding implementation of a specific functionality is paramount to overall success.

Many projects fail because the customer is not involved or has initial buy-in/approval but later changes his/her mind once something is implemented. Development should not begin if the customer has not approved the User Stories and if the team has not agreed upon the Definition of Readiness and the Definition of Done criteria. If things change, the customer should be notified as soon as possible, if impediments cannot be overcome. Informing the customer too late is never a good practice. It is important to note there are differences between the Definition of READY and the Definition of DONE. 

As mentioned, communication is paramount in order for Agile to be successful. Involving the designers/developers to create visuals can significantly help overcome instances where the customer fails to understand what will be implemented as well as any new functionality concepts. Many times, customers communicate what they want and then leave it up to the contractor to define User Stories. Even in this situation, the customer still needs to sign off on User Stories prior to development, or the customer needs to designate someone (not a contracting employee) with the authority to do so. It is critical to make sure any time losses or schedule delays are noted as applicable. Many times, the customer is often not aware of how much time is lost, simply because s/he has not made decisions to move forward.


Summary: Practice, Practice, Practice Makes Perfect (or Nearly Perfect)

Generating User Stories will become easier the more you do them. An Agile Team consisting of project personnel new to writing User Stories may often be initially frustrated by the duration of this process to derive the User Story details, estimate hours, define a Definition of Readiness and a Definition of Done, and identify potential impacts/risks. However, customer buy-in and involvement from the start of this process can help reduce wasted time. Although it may be an idealistic perception that Agile will “fix” communication issues, understanding what User Stories “are” and what they “are not” is key to successfully building high-quality products. Though trials and errors will definitely be encountered during the implementation of Agile, following a clearly defined Agile User Story development process is worth the effort in the long run.