4. User Stories and User Roles

Question 1

Requirement Risks (5)

Answer 1

1. lack of understanding of the business or social context
2. uncertainty on what the system should do
3. cultural differences between
4. ambiguous or vague requirements specifications
5. ambiguities over domain elements

Question 2

Managing requirement risks (2)

Answer 2

User stories
Prototyping

Question 3

Requirement gathering (define)

Answer 3

an iterative process of elicitation, specification, and validation.
* Avoid early commitments to particular design solutions
* Requirement gathering is an ongoing process

Question 4

Why do requirements evolve (3)

Answer 4

1. problem domain changes
2. customer’s own understanding of the problem increases
3. progress on system design and implementation uncovers new risks and opportunities

Question 5

Elicitation Steps (6)

Answer 5

1. identify - project stakeholders
2. elaborate - full user requirement
3. draw - system boundary
4. understand - organisational context and culture
5. make - hidden assumptions explicit
6. define - other goals

Question 6

System boundary ( define)

Answer 6

what a system should and should not do

Question 7

elicitation techniques (9)

Answer 7

Questionnaires
Observations
Interviews
Brain Storming
Data Mining
Estimation
Document Analysis
Mind mapping
Risk Analysis

Question 8

how to conduct interviews (5)

Answer 8

1. prepare user stories from initial problem
2. structure questions to identify new user stories and resolve uncertainties
3. coordinate the questions selected with other interview teams
4. be prepared to vary the discussion if unexpected, but important, topics emerge
5. practice the interview to avoid running over time. Make sure everyone know their roles

Question 9

Why do we use Observation as a requirements gathering technique (4)

Answer 9

1. documented workflows of an organisation are often very different from how tasks are actually carried out.
2. work practice continues to evolve over time
3. stakeholders, users and beneficiaries revealed after observing real work practices
4. observations reveal assumptions that prospective users have about the features of the proposed system

Question 10

Refining user stories With MSCoW (Define)

Answer 10

1. adding more details
2. refined into implementation tasks (stories may share tasks)
3. story prioritisation (MOSCOW)
   - must have
   - should have
   - could have
   - would be nice to have

Question 11

Scenarios are useful for

Answer 11

describing workflow and specifying acceptance criteria

Question 12

Acceptance Criteria/ scenario template

Answer 12

given a [fixture]
and [another fixture]

when [an action is performed on a feature]
and [another action is performed on another feature]

then [a condition holds]

eg. 
given a mocked database of properties
and a property search API
when a text search is preformed for 29 acacia road
then Banana property is returned

Question 13

User Story mapping (Define)

Answer 13

User-story mapping is a lean UX-mapping method, often practiced by Agile teams, that uses sticky notes and sketches to outline the interactions that the team expects users to go through to complete their goals in a digital product

Also known as user-story maps, story maps, and story mapping

Question 14

Use case (Define)

Answer 14

A uses case is a set of interactions occurring between a system and 1 or more actors. An actor is either a user or 1 or more systems.

Similar to a user role or system role.

More detailed then user story templates

Question 15

Key information in the use case (3)

Answer 15

Use Case Title: Pay for reservation
Primary actor: Dog Renter
Secondary actor:
Preconditions ( things to be true before we begin, eg - A user has logged in), Dog Renter has selected dog(s) and date(s) to reserve
Success Guarantees: Conditions that will be true if the use case finishes successfully. Dog has been rented and user’s credit card has been charged
Main Success Scenario: The main path through a use case. The most common path.
1) Dog renter submits credit card details
2) System validated credit card
3) System charges the credit card
4) Dog renter is given a unique confirmation number
5) Dog(s) are marked as unavailable on selected dates(s)

Extensions:* Variations of the main success scenario. ( Each one is an alternative scenario) *
2a) Card is not a type accepted by the system
@a1) The system notified the user to use a different card
2b) The card is expired
2b1) The system notifies the user to use a different card
3a: The card is declined.
3a1) the user is notified why the card is declined.

Question 16

Differences between user stories and use cases (4)

Answer 16

• Scope - User stories are smaller. Team puts constrains on their size.
• Completeness - Use cases tend to not get updated and User stories are added as needed.
• Longevity - Use cases are part of permanent project record. User stories are disposed of.
• Purpose- Use case documents an agreement of what the customer wants. Custom signs off. User Storis are place holders for condersation to facilitate release and planning.

Question 17

What is a user story and its format.

Answer 17

A User Story is an informal, natural language description of features of a software system. They are written from the perspective of an end user or user of a system, and may be recorded on index cards.
As a [type of user]
I [want/can/am required to]
So that [some goal]: What do you want to do?
Becuase [some reason]: What’s your underlying motivation?

Confirmation - How will I know when I am done.

Question 18

List the 3 criteria that go in a user role: ( 3 Cs)

Answer 18

Context **
(e.g., physical and social environment in which a user plays the role, domain
knowledge, level of proficiency, how users will access the system)
User logs in on their mobile device to get a ride home from a night out, has an established
account.
Characteristics (e.g., when the user interacts with the system, and with what regularity;
volume of work, mental state of the role while interacting with the system)
User requests a ride a few times a month when traffic is heavy and it’s easier to call a car service than drive and park someplace.
Criteria (what needs to be in place for this role to consider their user experience a success?)
Safe, reliable driver appears within 10 minutes of request. System notifies user of driver’sname and license plate number. Payment is automatically debited from the user’s account, so
no money changes hands.

Question 19

When Defining a Persona Type what are 5 example attributes to use?

Answer 19

Here are some suggested attributes to define:
* Demographics
* Psychographics
* Personal attributes
* Goals in the system
* Physical, social or technical environment

Question 20

Why is Collaborative User Story Creation important?

Answer 20

Poor specifications are often a major reason for project failure.

Specification problems can result from the users’ lack of insight into their true needs, absence of a global vision for the system, redundant or contradictory features, and other miscommunications.

In Agile development, user stories are written to capture requirements from the perspectives of developers, testers, and business representatives.

In sequential development, this shared vision of a feature is accomplished through formal reviews after requirements are written; in Agile development, this shared vision is accomplished through frequent informal reviews while the requirements are being written.

Question 21

What do user stories addres

Answer 21

The user stories must address both functional and non-functional characteristics.

Each story includes acceptance criteria for these characteristics.

These criteria should be defined in collaboration between business representatives, developers, and testers.

They provide developers and testers with an extended vision of the feature that business representatives will validate.

An Agile team considers a task finished when a set of acceptance criteria have been satisfied.

Question 22

What is the testers role in Collaborative User Story Creation?

Answer 22

Typically, the tester’s unique perspective will improve the user story by identifying missing details or non-functional requirements.

A tester can contribute by asking business representatives open-ended questions about the user story, proposing ways to test the user story, and confirming the acceptance criteria.

Question 23

What is the INVEST technique?

Answer 23

The collaborative authorship of the user story can use techniques such as brainstorming and mind mapping. The tester may use the INVEST technique [INVEST]:
 Independent
 Negotiable
 Valuable
 Estimable
 Small
 Testable

Question 24

What is the the 3Cs of User Stories?

Answer 24

According to the 3C concept [Jeffries00], a user story is the conjunction of three elements:

 Card: The card is the physical media describing a user story. It identifies the requirement, its criticality, expected development and test duration, and the acceptance criteria for that story. The description has to be accurate, as it will be used in the product backlog.

 Conversation: The conversation explains how the software will be used. The conversation can be documented or verbal. Testers, having a different point of view than developers and business representatives [ISTQB_FL_SYL], bring valuable input to the exchange of thoughts, opinions, and experiences. Conversation begins during the release-planning phase and continues when the story is scheduled.

 Confirmation: The acceptance criteria, discussed in the conversation, are used to confirm that the story is done. These acceptance criteria may span multiple user stories. Both positive and negative tests should be used to cover the criteria. During confirmation, various participants play the role of a tester. These can include developers as well as specialists focused on performance, security, interoperability, and other quality characteristics. To confirm a story as done, the defined acceptance criteria should be tested and shown to be satisfied.

Agile teams vary in terms of how they document user stories. Regardless of the approach taken to document user stories, documentation should be concise, sufficient, and necessary.