4 User Story and AC

Agile Software Development
(ASD) Lect-5 User Stories –

Testable onwards
Prof. Daiwat Vyas
B.TECH SEMESTER 6TH CSE

User Stories
• Testable
• A good user story should be testable.

• Tester must be able to verify the story.
• Should be possible to automate tests.
• Possible candidates for untestable story.
• Stories covering non function requirements
• Stories dependent on other stories.
• User Story : As an engineer, I should be able to learn to use the product easily
so that my productivity improve.
• Revised Story : As an engineer, I should be able to produce the five monthly
report in a day without needing to use the help manual.
User Stories
• In the Software Development industry, the word ‘Requirement’ defines
what our goal is, what the customers exactly need and what will make our
company to increase its business.
• Be it a product company which makes software products or a service

company which offers services in various software fields, the prime base
for all of them is the requirement and the success is defined by how well
the requirements are met.
• The term ‘requirement’ has different names in different project

development methodologies or frameworks.
User Stories
• Lets take few more examples of User-Stories first;
• A user story is a requirement for any functionality or feature which is
written down in one or two lines and max up to 5 lines.
• A user story is usually the simplest possible requirement and is about
one and only one functionality (or one feature).
• Example:
• As a WhatsApp user, I want a camera icon in the chat box to capture
and send pictures so that I can click and share my pictures
simultaneously with all my friends via WhatsApp.
User Stories- Acceptance Criteria
• What is an Acceptance Criteria?
• An acceptance criterion is a set of accepted conditions or business
rules which the functionality or feature should satisfy and meet, in
order to be accepted by the Product Owner/Stakeholders.
• This is a very important part of user story completion and it should

be studied by the Product Owner and Business Analyst very
meticulously because missing a single criterion can cost a lot.
• This is a simple numbered or bulleted list.

• Its format is as follows:
• “Given some precondition when I do some action then I expect the
result”.
• Example (w.r.t to WhatsApp user story as mentioned previously):

• Let’s consider that I’m chatting with a friend and I should be able to
capture a picture.
• When I click on a picture, I should be able to add a caption to the image
before sending it.
• If there is some problem with starting my phone camera, an error message
like ‘Camera could not be started’. etc., should be shown accordingly.
• What are Acceptance Criteria Used For?
• 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.
• What are Acceptance Criteria Used For?
• 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.
• Who Writes Acceptance Criteria and When?
• Either a client or a development team writes acceptance criteria.
• As a rule, criteria written by a product owner (the client) are reviewed

by a member of the development team to make sure that the criteria
are clearly specified and that there are no technical constraints or
inconsistencies from the development perspective.
• Such flow is an excellent way to collaborate if a product owner has
some experience in software development and is aware of how to
write project documentation.
• Who Writes Acceptance Criteria and When?
• If you prefer to assign writing acceptance criteria to the development
team:
• then a requirements analyst, project manager or QA specialist should

deal with this task, since they know the technology stack and the
feasibility of features.
• How to Write Acceptance Criteria?
• There are several types of acceptance criteria. The most popular are
rules-oriented (in the form of a list) and scenario-oriented (in the
form of scenarios that illustrate each criterion).
• The scenario-oriented type is popular among Agile teams since it

helps with getting across requirements, envisaging various use cases,
and further using scenarios for manual and automated acceptance
tests.
• There are several types of acceptance criteria. The most popular are
rules-oriented (in the form of a list) and scenario-oriented (in the
form of scenarios that illustrate each criterion).
• The scenario-oriented type is popular among Agile teams since it

helps with getting across requirements, envisaging various use cases,
and further using scenarios for manual and automated acceptance
tests.
• Eg. 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
• Eg. User-Story- Acceptance Criteria
• Scenario: System user signs in with valid credentials
“Given I’m a logged-out system user
and I’m on the Sign-In page
When I fill in the “Username” and “Password” fields with my
authentication credentials
and I click the Sign-In button
Then the system signs me in”
• The Given/When/Then template helps you reduce the time spent on
writing test cases since you describe the system’s behaviour upfront.
• Prefer writing acceptance criteria with the first-person “I” since it

helps us talk from a user’s perspective and keep a user’s needs in
mind.
• Example-2 User-Story
• Our first user story describes the webpage search feature:
• As a website user
I want to able to search on the webpage
So that I can find necessary information
• Example-2- Acceptance Criteria
• Scenario: User searches for an item by its name
“Given that I’m in a role of registered or guest user
When I open the “Products” page
Then the system shows me the list of all products
And the system shows the “Search” section in the right top corner of the
screen
When I fill in the “Search” field with the name of existing item in the
product list
And I click the “Apply” button OR press the Enter key on keyboard
Then the system shows products in the Search Results section with product
names matching entered product name
And the system shows the number of search results in the top of the Search
Results section”
• Hence, the User story defines the requirement for any
functionality or feature
• while the
• Acceptance Criteria defines the ‘Definition of done’ for the user

story or the requirement.
• Let’s understand why it is extremely important to dig ‘deep’ in user
stories and acceptance criteria.
• To start with, let us first understand the importance of an ‘in-depth’

study of a basic and fundamental thing i.e. User Stories.
User Stories- Digging Deep into User-Stories & Acceptance Criteria
• Example Case-1
• Assume that you and your team are working on a Mobile Application
and the product was an application that was designed for the delivery
people like courier services etc.
• You would have seen a delivery person coming to your place for
delivery.
• And they have a mobile phone on which they ask you to give your
signature after delivery.
• This signature reflects on the portal of the courier service providers
like DTDC, FedEx etc.
• Example Case-1
• Assume that you and your team are working on a Mobile Application
and the product was an application that was designed for the delivery
people like courier services etc.
• You would have seen a delivery person coming to your place for
delivery.
• And they have a mobile phone on which they ask you to give your
signature after delivery.
• This signature reflects on the portal of the courier service providers
like DTDC, FedEx etc.
• Example Case-1
• Let’s assume that the mobile app is just launched and their
portals are already existing and up & working.
• Problem: For a Sprint your Product owner has a user story for this
mobile app that “As a Portal Admin, I should be able to view the
signature taken by the delivery person at the time of delivery”.
• Here the portal (web app) is changed and updated accordingly to

reflect the signature.
• Example Case-1
• As a QA & Testing team you have to verify if the signature captured in
the mobile app is reflecting as expected in the portal.
• If you look at this user story, it looks simple but there is a hidden
requirement here that “For historical deliveries, there was no
signature reflection functionality, so what should happen if the
portal guys view historical deliveries?”
• Should historical data be wiped out? Should we allow crashes or

errors for such data?
till CT-1
• Example Case-1
• What should be a solution of handling such cases?
• Solution: When the respective DB tables are updated to add a new
column for the Signature location, the old data should have a NULL
or 0 value which should be checked and a message stating ‘No
signature exists’ should be shown.
• This can be called as a miss from the Product Owner or Business
Analyst, but this has to be done. Implementing one feature
successfully but breaking something along with it is not desirable by
the customers. This needs to be done along with the same user story
and in the same sprint.
• Understanding the acceptance criteria and all the other conditions&
rules exhaustively is even more important than understating a user
story.
• If a requirement is incomplete or vague, it can be taken up in the next

sprint but if an acceptance criterion is missed, then the user story
itself can’t be released.
• All of you would have used net banking at some point and most of
you use it every day and download their respective historical
statements a lot.
• If you observe it carefully, there are certain specific options available

for downloading them.
• There is an option to select the type of file for downloading your

statement. There is an option to choose if you want to download only
the Credits/Debit /both.
• Now imagine that the Product Owner gives you this User story “As a
customer, I want to download my account statement so that I
can view all my transactions done for a specific period”.
• With the following Acceptance Criteria:
• Considering that I am on the Download Historical Statement Page, I
should select the period for which I want to download the statement.
should select the account for which I want to download the
statement.
should not be allowed to download the statement for future ‘To’ date.
• Now imagine that the Product Owner gives you this User story “As a
customer, I want to download my account statement so that I
can view all my transactions done for a specific period”.
• With the following Acceptance Criteria:
should not be allowed to select ‘From’ date 10 years beyond in the
past.
• Considering that I download my statement, I should be able to view
the downloaded file.
should be able to download my statement in doc, excel and pdf
formats.
• Referring the above mentioned acceptance criteria’s for the
mentioned user-story, do you find anything that is missing in the
acceptance criteria’s mentioned?
• If you go through those acceptance criteria’s, there are 3 things
missing here:
• Name and format of the file name that will be downloaded.
• What information (Column names) is to be displayed in the file.
• The options list to select what kind of a transaction the customer

wants i.e. only debits or only credits or both.
• Such cases may happen once in a while, however still study well
about each acceptance criteria and try to visualize it with reference to
the user story.
• The more you study deeply about the conditions and business rules
the more will be your knowledge about the feature.
• Bugs found in the initial stage cost nothing compared to what it may
cost in the ‘testing’ stage.
• A
• Importance of finding Discrepancies in User Story/Acceptance
Criteria
• It is always important to do a deep dive in the user stories and
acceptance criteria at an early stage even before the development or
testing commences.
• The following slides, have details about why of finding

Discrepancies in User Story/Acceptance Criteria is necessary
and important.
• Wastage of Time:
• If the discrepancies or mistakes in the user story/acceptance criteria
are found when development is going on or testing is going on, then a
lot of rework may need to be done in the remaining sprint time.
• It doesn’t happen that even if the Product Owner missed few things,
they will move the user story to the coming sprint. Higher chances
are that they ask the team to do the necessary implementation and
release it in the same sprint.
• Hence it becomes a nightmare for the team as they have to spend
extra time, come on weekends or work late night. This can be avoided
by studying and discussing the user story/acceptance criteria at the
earliest possible stage.
• Wastage of Efforts:
• The developers and QA have to revisit the implemented code and test
cases again.
• Updating, adding and removing as the per requirement is not an easy

task. It becomes too painful as there is already a pressure to deliver on
time.
• In such a situation, there are chances of mistakes in the development
or testing stage.
• Deep understanding of User Story and acceptance criteria can only be
achieved by spending immense time on studying it.
• There is no specific tool or course available in the market to do
this for you as this is all about logical thinking, experience, and
knowledge about the product.
• Participating in Pre-plan meeting actively, talking to the BA, studying
on your own can only help you to achieve this. The more efforts you
put, the more you learn and grow.

4 User Story and AC

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

4 User Story and AC

Uploaded by

Copyright:

Available Formats

Agile Software Development

(ASD) Lect-5 User Stories –

B.TECH SEMESTER 6TH CSE

• A good user story should be testable.

• Be it a product company which makes software products or a service

• The term ‘requirement’ has different names in different project

• This is a very important part of user story completion and it should

• This is a simple numbered or bulleted list.

• Example (w.r.t to WhatsApp user story as mentioned previously):

• To reach consensus: Having acceptance criteria synchronizes the

• To allow for accurate planning and estimation: Acceptance

• As a rule, criteria written by a product owner (the client) are reviewed

• then a requirements analyst, project manager or QA specialist should

• The scenario-oriented type is popular among Agile teams since it

• The scenario-oriented type is popular among Agile teams since it

• Prefer writing acceptance criteria with the first-person “I” since it

• Acceptance Criteria defines the ‘Definition of done’ for the user

• To start with, let us first understand the importance of an ‘in-depth’

• Here the portal (web app) is changed and updated accordingly to

• Should historical data be wiped out? Should we allow crashes or

• If a requirement is incomplete or vague, it can be taken up in the next

• If you observe it carefully, there are certain specific options available

• There is an option to select the type of file for downloading your

• Name and format of the file name that will be downloaded.

• What information (Column names) is to be displayed in the file.

• The options list to select what kind of a transaction the customer

• The following slides, have details about why of finding

• Updating, adding and removing as the per requirement is not an easy

You might also like