---
sourceDocument: Zurich Strategic Portfolio Management
sourceDocumentLink: https://www.servicenow.com/docs/r/zurich/it-business-management

 Release :

    - zurich

ft:locale :

    - en-US

ft:publication_title :

    - Zurich Strategic Portfolio Management

ft:clusterId :

    - itbm

bundleId :

    - itbm

workflow :

    - Technology


---

# Writing effective stories in Agile Development 2.0

# Writing effective stories in Agile Development 2.0 {#ariaid-title1}

* Release version: Zurich
* 
* Updated July 31, 2025
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read

Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of Writing effective stories in Agile Development 2.0

Well-written user stories in Agile Development 2.0 are crucial for clear communication among developers and team members, including Testing and Documentation.
Effective stories enable accurate effort estimation aligned with the agreeddefinition of done, which specifies exit criteria for story completion.
Each story must have a clear description tied to a user persona and measurable, testable acceptance criteria.
Show full answer Show less  

## Key Features

* **Story Description:** Should identify the user persona's role, their need or goal, and the benefit to stakeholders. The recommended format is: *"As a \<role\>, I want \<goal or need\>, so that \<benefit\>"*.
* **Acceptance Criteria:** Define the boundaries of the story and confirm when software behavior meets expectations. They are vital to the definition of done.
* **Good Acceptance Criteria Characteristics:**
  * **Usability:** Include quantifiable measures of ease of use.
  * **Functionality:** Specify user tasks, business processes, or functions to be completed.
  * **Error Handling:** List error cases and expected software responses.
  * **Performance:** Test system responsiveness from a user perspective.
  * **Stress Tests:** Define acceptable thresholds under load (e.g., concurrent users).

## Practical Guidance for ServiceNow Customers

* Write story descriptions that clearly identify who benefits and why---for example, specifying the exact user role and expected outcome.
* Ensure acceptance criteria are detailed and testable, avoiding vague terms like "appropriate people" without defining who that includes.
* Use examples of good stories and acceptance criteria as templates to improve communication and ensure alignment with business value and technical requirements.

## Key Outcomes

By following these guidelines, ServiceNow customers can create user stories that are:

* Clear and easily understood by all team members.
* Aligned with business value and technical needs.
* Testable and measurable, enabling accurate verification of completion.
* Better estimated in terms of effort and aligned with the agreed definition of done.  
Well-written stories are easy to understand by all developers and members of team
members, such as Testing or Documentation.

Stories enable the assignment group to accurately estimate the effort required to implement
the work according to the definition of done. Definition of done is the exit criteria agreed to
by the group, that determines when a story is complete.  
A story has the following basic conditions:

* Description: The story description relates to a user persona, such as administrator, and either describes a business value or addresses a technical debt.
* Acceptance criteria: The story acceptance criteria are measurable and testable.
{#how-to-write-stories__ul_jhr_1mg_dp}

## Story descriptions

A good user story description identifies the following for meeting the stated requirement:

* the role of the user persona in the system
* the need expressed by the user persona
* the benefit to all stakeholders such as developers, users, and others
{#how-to-write-stories__ul_c3y_mmw_d1b}

Typically, a story description is expressed as: "As a \<role\>, I want \<goal or need\>, so that \<benefit\>".

Examples of good story description
:
    * Description: As a developer, I want to publish the current state of my application to an update set, so that I can deploy it to a production system.
    * Description: As a customer, I want to receive notifications when comments are entered for an incident so that I am updated on the status.
    * Description: As a change manager, I want to enable the assessment of risk for any given change by establishing a list of questions with multiple choice answers.
    {#how-to-write-stories__ul_dhg_wmg_dp}

Example of bad story description

:   Description: Notifications are sent when incidents are created.

    This description is poor because:

    * The description does not state who or what is sending the notifications, not in what form the notification takes, such as email.
    * The description does not include any benefit information, so the business value is not clear.
    {#how-to-write-stories__ul_ukd_bng_dp}

    It could be better written as:

    Description: As an incident creator, I want email notifications to be sent to a predefined
    set of interested parties when I create an incident. This way, they are informed when an
    incident affecting them is created.

## Story acceptance criteria

Acceptance criteria define the boundaries of a user story, and are used to confirm when the
software is working as intended, which means the story is completed. Acceptance criteria are an
essential part of the 'Definition of Done' for a story.

Good acceptance criteria

:   Good acceptance criteria should include the following, where relevant:

    * Usability: Be sure to include measures of usability in the acceptance criteria. Indicate how to answer the question: Is it easy to use? The key is to identify the right measurements and make sure each is quantifiable.
    * Functionality: Identify specific user tasks, business processes, or functions that must be in place at the end of the project. A functional requirement might be: The user can choose from multiple sizes.
    * Error handling: Enumerate error cases and how each should be handled. For example, if a user performs the steps in the wrong order, how will the software handle it?
    * Performance: Test system performance from the perspective of an individual user. For example: Is the UI responsive?
    * Stress tests: Describe how the system responds when it is under stress because there are many users, transactions, or queries. Acceptance criteria should define acceptable thresholds for stress testing. For example: Does the system respond within a 250-millisecond threshold when 100 users submit queries simultaneously?
    {#how-to-write-stories__ul_ebt_nkq_pz}

Example of Good Acceptance Criteria

:   Description: As a customer, I want to order and pay for the book via a secure web-based
    form, so that my credit card information is safe.

    Acceptance Criteria:

    * All mandatory fields must be completed before a customer can submit a form.
    * Information from the form is stored in the customer orders database.
    * Payment can be made via Amex, Master Card, or Visa credit card.
    * The system shall accurately calculate and apply sales tax.
    * The system shall accurately calculate and apply shipping charges.
    * The customer shall be able to verify the accuracy of the order.
    * An acknowledgment email is sent to the customer submitting the form.
    * Protection against spam is working.
    {#how-to-write-stories__ul_fd5_h4g_dp}

Example of Bad Acceptance Criteria

:   Description: As a customer, I want to receive notifications when an incident is commented,
    so that I am updated on the status.

    Acceptance Criteria: The appropriate people are notified when incidents are commented.

    The acceptance criteria are poor because they do not give enough detail to test, for
    example, it is not clear who the appropriate people are.  
    The acceptance criteria could be better written as:

    1. As an ESS user, create an incident.
    2. Select Notify interested parties.
    3. Save the incident.
    4. Log in as an interested party.
    5. Check that you have received an email for the logged incident.
    {#how-to-write-stories__ol_fgl_s4g_dp}