User stories are the most important aspect of delivering a successful agile project that meets (or even exceeds) the expectations of the client. The story can serve as the vehicle for determining scope, sprint planning, requirements gathering, specification documentation, as well as test script creation and training documentation. So great care must be taken to elicit, document, and gain consensus on and approval of the client’s needs before executing.

Once Upon a Time… a.k.a. The Exposition

The exposition of a good book typically sets the stage for what’s to come. The same is true of the user story. Take time to plan the methods by which you’ll elicit requirements from your client. Proper planning could make or break the level of information you are able to collect during this time. Will you use traditional  interviews, questionnaires, or observation sessions? Will you embrace collaborative methods like focus groups or workshops that engage a cast of characters from all levels of the organization?

Rising Action… Due Diligence To Prepare For Execution

FullSizeRenderOnce the client has shared the current state (to include pain points) as well as the future vision (which likely has a multitude of wishes); it’s time to determine what will or will not be included in the scope. This can be accomplished by a variety of methods. C5 Insight likes to ensure all levels of the organization are represented when this activity occurs, so that individuals and teams feel like they participated in prioritizing the plan for the future.

After the scope has been defined, the stories can be crafted with the deliverable design in mind. An example of a very basic user story outline is shown below:

  1. Account User Story
    1. Story: As a <user type>, I want to <function> so that <benefit>.
      1. Ex: As a sales rep, I want to be able to have access to detailed information on an account so that I can review, create or update information that will better prepare me to assist the customer.
    2. Acceptance Criteria: (What is required for the business and product owner/sponsor to accept the story.)
      1. Ex: Ability to create or edit an account
    3. Definition of Done: (What is required before sending out for User Acceptance Testing. Here’s where the design aspects come to mind.)
      1. Ex:
        1. Ability to create new Account
        2. User Account Detail Story - Summary Section
          1. Account Name
          2. Phone (auto formatted to (111) 111-1111)
          3. Fax (auto formatted to (111) 111-1111)
          4. Website
          5. Parent Account - may be blank
          6. Relationship Type
            1. Default value new accounts = Other
            2. Available values = Customer - Key, Customer - Other, Distributor, Prospect - Other, Prospect - target, Other
    4. Estimated Hours:
      1. Ex: 12
    5. Priority
      1. Ex: High/Med/Low
    6. Dependencies:
      1. Ex: Connections, Single view, Contacts

Once the stories have been drafted, it is of the utmost importance to gain client approval. The stories will serve as the scope against which all change requests are measured for that particular sprint, or the larger project, should the client choose to forego some originally scoped work in lieu of newly identified requests.   

Climax… Execution of the Deliverable

It’s time to bring the stories to life! At this point, the project team is actively engaged in configuration, customization, and development modes dependent upon the needs of the story at hand. If you’re operating in an agile environment, this should include a demo and refinement loop(s) before the team is ready for user acceptance testing.

Falling Action… Testing to Eliminate Conflicts/Defects

The same user story crafted to guide the development of the deliverable can, and should be used, to craft the test script for user acceptance testing. After all, user acceptance is all about ensuring the request has been delivered. An example of a very basic test script outline is shown below:

  1. Account Test Script
    1. Test Script: As a <user type>, does <function> perform <benefit>?
      1. Ex:
        1. As a sales rep, do I have access to detailed information on an account so that I can review, create or update information that will better prepare me to assist the customer?


Again, be sure to gain final acceptance of the deliverables from the client. If there are any open items remaining from user acceptance testing, ensure they are documented and the remediation plan is in place and agreed to.

The End… a.k.a The Resolution

And here the user story comes to an end. It’s time to push the deliverable to production and train the audience. The story comes full circle as you transform it from a “want or need” to a “how to”. An example of a very basic training tip sheet is shown below:

  1. Account Training Tip Sheet
    1. Tip Sheet: As a <user type>, access <function> to perform <benefit>.


Do you have some great user story tips? Feel free to share your story, we’d love to hear from you! For more information about this blog or C5 Insight contact us here