0% found this document useful (0 votes)
8 views

Software Engineering Lecture4 2

The document discusses user stories and acceptance criteria for agile software development. It provides examples and best practices for writing user stories and outlines elements that should be included in acceptance criteria, such as scenarios, preconditions, and expected outcomes. The document also discusses traits of effective acceptance criteria and examples of formatting acceptance criteria.
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
8 views

Software Engineering Lecture4 2

The document discusses user stories and acceptance criteria for agile software development. It provides examples and best practices for writing user stories and outlines elements that should be included in acceptance criteria, such as scenarios, preconditions, and expected outcomes. The document also discusses traits of effective acceptance criteria and examples of formatting acceptance criteria.
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 42

User Stories

How to Document Requirements ?


Too Much vs. Too Little
Think… for User Stories
User Stories
Product Backlog
• A prioritized list of work for the development team that is
derived from the roadmap and its requirements.
• The most important items are shown at the top of the product
backlog, so the team knows what to deliver first.

• Product backlog is divided into N number of Epics.


• Each Epics can be divided into Y number of Stories (User Stories).
User Stories
Basics
User Stories
Be wary of
details
Points considered for User Stories

Step 01: Think of the “WHO” Step 02: Think of the “WHAT” Step 03: Think of the “WHY”

One action per story It should either improve the UX,


Define natural intention, not the feature increase retention rates, shorten users’
journey to the issue solution or
Keep it short whatever.
Don’t include UI information Each Story should contribute
something to the general goal of
product.
If not, may be something wrong.
How many stories needed ?
Acceptance Criteria

CONDITIONS THAT A SOFTWARE PRODUCT UNIQUE FOR EACH USER STORY AND TO BE DEFINED BEFORE THE DEVELOPMENT
MUST MEET TO BE ACCEPTED BY A USER, A DEFINE THE FEATURE BEHAVIOR FROM THE TEAM STARTS WORKING ON A PARTICULAR
CUSTOMER, OR OTHER SYSTEMS. END-USER’S PERSPECTIVE. USER STORY.
Traits of effective acceptance criteria

Everyone must Acceptance criteria


Acceptance criteria Criteria should be
understand your should provide user
should be testable. clear and concise.
acceptance criteria. perspective.
• Results must leave • Don’t write • Useless if your • Should be written in
no room for comprehensive developers can’t the context of a real
interpretation. documentation. understand it user’s experience.
• It should reveal • Keep your criteria as
straightforward simple and
yes/no or pass/fail straightforward as
results. possible.
How to Format User Story Acceptance Criteria?
Scenario/Given/When/Then/And Format

User acceptance criteria


User story follows the template:
template:
• As a (intended user), • Scenario (Name of the
• I want to (intended action), behavior)
• so that (goal/outcome of • Given (how things begin),
action). • when (action taken),
• then (outcome of taking action)
• And (continue any of the
previous)
How to Format User Story
Acceptance Criteria?

Verification List

• The team makes a verification checklist.


• Defining a list of pass/fail or yes/no statements
that will mark the functionality as complete.
• Whatever format is chosen, the team should be
comfortable to work with.
Acceptance Criteria: Example

User story: Acceptance criteria:


As a product manager. Scenario: The product manager adds potential ideas
I want to score potential ideas. and ranks the best ideas based on benefit versus cost.
So that I can decide what to include on my Given that I have added two or more ideas and scored
product roadmap. them using the Benefit vs Cost scoring model
When I click the Rank button
Then ideas are sorted with the top-scoring ideas at the
top.
Example
Acceptance Criteria: Example
User Stories:

Acceptance criteria:

On clicking ‘checkout’
On clicking ‘view Numbers of each item
Total invoice amount tab, you can select
cart’, the cart opens in are displayed and can
is displayed. delivery time and
a new tab. be changed.
address.
As an online shopper,
I want to view my cart,
so that I can make the On clicking ‘place
payment. On clicking ‘proceed order and pay’, you
Choose between Set the chosen option
to payment’, various can enter account
various payment as default option, if
payment options are details, and are taken
options. required.
displayed. to the bank website for
making the payment.
Acceptance Criteria: Example
Acceptance criteria:
User Stories:

Display the student’s Pick the option


Choose the scores that
assessment scores for to Share the report
must be shared with
each of the tests (other options can be
the employer.
completed. Print or Save).
As a trainer,
I want to print an
assessment report,
So that I can share Choose the person with If there is an incorrect
response, Share the document
student’s whom the report
display an error through email.
performance details should be shared.
message.
to the employer
Acceptance
Criteria:
Example
User Story:
As a user,
I want to be able to request the cash from my account at an ATM
so that I will be able to receive the money from my account quickly and in different places

Acceptance Criteria:

Acceptance
Criteria:
Example
More examples
https://www.parabol.co/blog/user-story-examples/#user-stories-in-agile-general-examples
Make the feature scope more detailed

Explaining Negative cases


Aim of
Acceptance Setting Communication
Criteria
Aligning with Acceptance Testing

Feature Evaluation
What to avoid in acceptance criteria

Avoid writing “NOT”

USER STORY
Don’t: As a user, I don’t want to have to enter my payment method every time I want to
request a refund.
Do: As a user, I want my payment method to be saved and automatically suggested so
that I can easily choose it.

ACCEPTANCE CRITERIA:
Don’t: The system must not fail.
Do: The system should have an availability of no less than 90%.
What to avoid in acceptance
criteria
Avoid passive voice:

Indication of a subject should be clear to know who should be able to perform the action.

USER STORY

Don’t: As a user, I want buttons for the refund to be shown.


Do: As a user, I want to be able to click the courses and then see the refund button.

ACCEPTANCE CRITERIA:
Don’t: The identification of purchased courses should be confirmed.
Do: The Accounting System should confirm the Customer Courses.

Avoid undefined pronouns :


Might cause ambiguity
Stories Smell: Anti
patterns of User
Stories
Everything in a Sprint should be
Stories Smell: Anti patterns of User Stories written as a user story
Specifying what the user wants is
Stories Smell: Anti patterns of User Stories enough!
Stories Smell:
Anti patterns
of User Stories
User Stories should be incredibly
detailed
Stories Smell: Anti
patterns of User
Stories
User stories can depend on other
stories in the Sprint
Stories Smell:
Anti patterns
of User
Stories
Stories should be very small
Stories smell:
Anti patterns of
User Stories
The product owner is a user
Stories Smell:
Anti patterns of
User Stories
Skipping the acceptance criteria
Stories Smell:
Anti patterns of Confusing the acceptance criteria with the Definition of Done

User Stories
References
• https://www.linkedin.com/pulse/user-story-smells-ryan-thomas-hewitt-
csm-cspo-itil
• https://jadealm.com/blog/difference-between-acceptance-criteria-and-
defintion-of-done/
• https://www.altexsoft.com/blog/acceptance-criteria-purposes-formats-
and-best-practices/
• https://www.productplan.com/glossary/acceptance-criteria/
• https://www.knowledgehut.com/blog/agile/what-are-acceptance-
criteria

You might also like