Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

User

...

Stories

  • A

...

  • short description of something that your user will do when he or she

...

  • comes to your website or uses your software

...

  • Written from the point of view of a person using your website or application

...

  • Written in the language that your customers would use

...

  • Similar to usage scenarios, except that they are not limited to describing a user interface

...

  • Format of about three sentences of text written by the stakeholder in the stakeholder's terminology without techno-syntax

...


Each user story is composed of three aspects:

...

An initial user story may be very brief, containing just enough information for planning. However, because Acumos is used and developed by people all over the world, it is extremely important that a user story, once accepted, is updated to include as much detail as possible.

Who Creates a User Story

A user story is created by the stakeholder (the person who requested the functionality). Stakeholders!

Stakeholders, end users, clients... these are the people who create user stories and acceptance criteria. The person who created the user story writes the acceptance criteria.

Format

As an [type of user] I want [some goal or action] so that [some reason].

So, for example: As a Flickr member, I want to set different privacy levels on my photos, so I can control who sees which of my photos.

Acceptance Criteria

...

  • A vital part of a User Story

...

  • Define the boundaries of a user story

...

  • Are used to confirm when a story is completed and working as intended

...

Writing the acceptance criteria is the first step of fleshing out the details of your user story.

...

  • Are a formalized list of requirements that ensure that all

...

  • scenarios are taken into

...

  • account 
  • Specify conditions under which a user story is fulfilled

...


Writing the acceptance criteria is the first step of fleshing out the details of your user story. Concisely written criteria help development teams avoid ambiguity about a client’s demands and prevent miscommunication. Creating acceptance criteria is very similar to creating a use case. Both developers and testers rely on clearly defined acceptance criteria.

Who Creates Acceptance Criteria

...

  • To define boundaries. Acceptance criteria help development teams define the boundaries of a user story. In other words, acceptance criteria help you confirm when the application functions as desired, meaning that a user story is completed.
  • To reach consensus. Having acceptance criteria synchronizes the development team with the client. The team knows exactly what conditions should be met, just as the client knows what to expect from the app.
  • To serve as a basis for tests. Last but not least, acceptance criteria are a cornerstone of positive and negative testing aimed at checking if a system works as expected.
  • To allow for accurate planning and estimation. Acceptance criteria scenarios allow for the correct division of user stories into tasks so user stories are correctly estimated and planned. 

Format

Given an initial condition, when something happens, then this is the result


Examples

User Story: As a conference attendee, I want to be able to register online, so I can register quickly and cut down on paperwork

Acceptance criteria could include:

  • A user cannot submit a form without completing all the mandatory fields.
  • Information from the form is stored in the registrations database.
  • Protection against spam is working.
  • Payment can be made via credit card.
  • An acknowledgment email is sent to the user after submitting the form.

User Story

As a logged-out user
I want to be able to sign in to a website
So that I can find access my personal profile

...

https://rubygarage.org/blog/clear-acceptance-criteria-and-why-its-important

https://www.visual-paradigm.com/guide/agile-software-development/user-story-vs-use-case/

https://www.boost.co.nz/blog/2012/01/use-cases-or-user-stories

http://www.agile-process.org/

http://agilemanifesto.org/principles.html