2. Topis
• 1. Requirements in Agile -
introduction
• 2. Characteristics of a
good user story
• 3. Quality Assurance for
requirements
Agile
Requirements
Quality
3. Cyrille BABIN
SEBASTIEN DIARD
Xavier Houot
Nicolas SONNIER
RIM FALEH
Vinh-Quang NGUYEN
LIDIA VALENTE
TERRY LENGRAND
JEAN-MARC MAIER
Francois ROBERT
aurélie Bacle-Lewandowski
Participants
4. Requirements in Agile
IREB Certified Professional for Requirements Engineering - RE@Agile Primer -
Syllabus and Study Guide
Version 1.0, 15.03.2017
6. Requirements in Agile
User story
As a <type of user>, I want <some goal> so that
<some reason>
Card
Conversation
Confirmation
Persona Acceptance
criteria
UI specification
Quality criteria
7. Characteristics of a good user story
INVEST
I (Independent)
The PBI should be self-contained and it should be possible to
bring it into progress without a dependency upon another
PBI or an external resource.
N (Negotiable)
A good PBI should leave room for discussion regarding its
optimal implementation.
V (Valuable)
The value a PBI delivers to stakeholders should be clear.
E (Estimable)
A PBI must have a size relative to other PBIs.
S (Small)
PBIs should be small enough to estimate with reasonable
accuracy and to plan into a time-box such as a Sprint.
T (Testable)
Each PBI should have clear acceptance criteria which allow
its satisfaction to be tested.
As a <type of user>, I want <some goal> so that <some reason>
8. Characteristics of a good user story
Practice
Please check the following stories against
INVEST criteria.
US01
As a System
I should be able to manage roles.
US02
As a System
I should change status from ‘Inactive’ to
‘Active’ when customer successfully set
the password for the first time.
US03
As a User
I should be able to collect and update
Customer ID for every user profile.
US04
As a User
I would like to log in to security
application using my username and
password
so that I will be able to interact with
application on a security level predefined
to me by administrator.
US05
As a User, I want to be able to run your
product on all versions of Windows from
Windows 7 on.
9. Characteristics of a good user story
Acceptance
scenarios
As a <type of user>, I want <some goal> so that <some reason>
Acceptance scenarios
Boundaries
Limitations
Test basis
Exception
Error handling
Undestanding and
consensus
Accurate
planning and
estimation
Better
verification
and coverage
10. Characteristics of a good user story
As a X student
I can see my fee for the semester
so that I know the remaining balance
Acceptance Criteria
1. The semester fee balance is displayed.
2. The semester fee balance is calculated.
3. The fee balance is displayed for that semester duration.
4. The balance is not displayed if an unknown student
identity is applied.
Acceptance
scenarios
https://dzone.com/articles/acceptance-criteria-in-software-explanation-exampl
11. Characteristics of a good user story
Acceptance
scenarios
Given
• A set of key
pre-
conditions
for a
scenario
When
• The key
action a
user will
take and
that leads
to an
outcome
Then
• Observable
outcome –
what
happens
after the
user makes
that action
Scenario
• Title,
description
of the
scenario
Business-oriented
language allowing
to express
the product
behavior
Gherkin Scenario, Given, When, Then
12. Characteristics of a good user story
Acceptance
scenarios
https://rthewitt.com/2017/06/30/gherkin-for-business-analysts/
13. Characteristics of a good user story
Practice
For the following US, please write
acceptance scenarios.
US01
As a User
I want the ability to reset my password
So I don't need to go to local security officer to do so.
US02
As a User
I would like to log in to security application using my
username and password
So that I will be able to interact with application on a
security level predefined to me by administrator
14. Characteristics of a good user story
Additional
elements
Epic User story
Acceptance
criteria
UI layout
Glossary
definition
Data
specification
Messages
15. Quality Assurance for requirements
Quality
management
Project
management
Communication
Business
analysis
Testing and QA
activities
Development
Deployment
Quality
strategy
Roles and responsibilities
Communication plan
Artifacts and deliverables
Tasks and activities
Outputs and results
Quality goals and metrics
Checklists and quality gates
17. Quality Assurance for requirements
Quality
gates
Definition of Done
Code reviewed and documented
according to rules
Unit tests passed
Acceptance criteria met
Functional tests passed
Performance requirements met
Story accepted by Product Owner
Definition of Ready
Story written in a given format
Story met INVEST criteria
Story estimated by the team
Acceptance criteria defined and
understood by team
UI mockups provided and understood by
team
Performance criteria defined and
understood by team
19. Quality Assurance for requirements
Review
meetings
Primary
perspectives to
examine an
increment of
work before,
during, and
after
development
Three
amigos
3
amigos
Business
•What problem are
we trying to solve?
Development
•How might we
build a solution to
solve that problem?
Testing
•What about this,
what could possibly
happen?
What to do
How to do it
How to know when it is done correctly
https://www.agilealliance.org/glossary/three-amigos
20. Quality Assurance for requirements
Review
meetings
Review of PBIs by
PO and (some of)
the team to
ensure correctness
and completness
of the backlog
Backlog
Grooming
Removing invalid/not relevant user stories
Creating new user stories
Updating priorities of stories
Correcting estimates
Splitting too „big” user stories
22. Thank you for your attention!
Stowarzyszenie Jakości Systemów Informatycznych
ul. Poznańska 16 lok. 4
00-680 Warszawa
Karolina Zmitrowicz k.zmitrowicz@sjsi.org