User stories are short descriptions of features or capabilities that provide value to end users. They follow a standard format of "As a <role>, I want <feature> so that <benefit>" to clearly define the who, what and why. Additional details like acceptance criteria, scenarios, and assumptions help ensure user stories are independent, negotiable, valuable, estimable, small, and testable. Best practices include writing stories from the perspective of a specific user role, defining scenarios using a "Given/When/Then" structure, and using stories to guide automated testing and prevent regressions across the entire project.

1. USER STORIES
What are they?
Who are they for?
What benefit do they bring?
What are the best practices?

2. User Story origin

From XP's use cases to the 3Cs
− Card: token representing requirements
− Conversation: grooming/pre-planning/prioritisation
− Confirmation: define how we know it's done

user stories are an artefact of team negotiation
on scope commitment, a medium to add
certainty to what the team is building, obtain
early feedback ('fail' and learn early) and
improve as part of incremental software
delivery

3. Story journey from Design Thinking
to Scrum

4. Story mapping via user activities

5. Build/measure/improve minimum
viable product
http://www.slideshare.net/chassa/2013-0603specification-byexamplewithgherkinchristianhassa

6. Characteristics of a good story

I Independent The user story should be self-contained, in a
way that there is no inherent dependency on another user story.

N Negotiable User stories, up until they are part of an iteration,
can always be changed and rewritten.

V Valuable A user story must deliver value to the end user.

E Estimatable You must always be able to estimate the size of a
user story.

S Scalable (small sized) User stories should not be so big
as to become impossible to plan/task/prioritize with a certain level of
certainty.

T Testable The user story or its related description must provide the
necessary information to make test development possible.

7. Story formatting: best practices
1. As a… I want… so that…: role, feature and
business case (V in INVEST)
2. Assumptions: are captured to avoid
misunderstandings: system availability,
excluded story scope, dependencies… (S & I
in INVEST)
3. Scenarios + given/when/then: T in INVEST.
Acceptance Criteria are a set of statements,
each with a clear pass/fail result, that specify
both functional (e.g., minimal marketable
functionality) and non-functional (e.g., minimal
quality) requirements.

8. 1.a. Defining the role: “As a....”

This is the WHO? Something or someone that
sends a stimulus into the system boundary

Keeping the story valuable and user centric

Use role and personae to help define most
adequate features

As a... designer/dev? Effort vs. value (Customers
only value tasks instrumentally, as required steps on the way to getting
what they really want)

Developer? Technical stories should only be used when the
product is constrained to a single subsystem or component & there is no
obvious external user/device/system

Read more:
https://www.scrumalliance.org/community/articles/2011/august/5-common-mistakes-we-make-writing-user-stories

9. What is a valid role?
• Real stories go from outside the system
boundary to inside the system, or vice versa.
• If we see a story focused only on things happening inside the system, it's a
sign that this is an implementation detail, not something the user regards
as a system behavior.
http://www.industriallogic.com/blog/as-a-developer-is-not-a-user-story/

10. Can spikes be user stories?

Definitions

“A Spike is a technical [or functional] investigation to produce an answer in
regards to some acceptance criteria on a story prioritized in upcoming
Sprints” http://agileatlas.org/articles/item/spikes-in-scrum-the-exception-not-the-rule

“"a story that cannot be estimated until a team runs a timeboxed
investigation. The output of a spike story is an estimate for the original
story.” http://underlap.blogspot.co.uk/2013/02/why-i-hate-spikes.html

Characteristics
Does not fit INVEST or ‘user’ in ‘user story https/
://davenicolette.wordpress.com/2014/09/25/is-a-spike-a-type-of-story

Team collaboration should happen *within* the user story container (as tasks)
and spikes are exceptions to the rule because of the size/dependency of the
task.

Spikes tend to be ‘specialist’ owned whereas Stories are cross-functional

Prototypes, Proof of Concepts (PoC), and Wireframes all fall into the
classification of Spikes

11. Can spikes be user stories?(continued)

Estimates

Like tasks, spikes should be estimated in time & further framed with a timebox.
XP has used the ‘Gold star card’ concept to ensure management of spikes

Team velocity is a metrics used to calculate value rather than effort
http://guide.agilealliance.org/guide/velocity.html

Velocity is used as a predictive measurement and analytics tool shared with
stakeholders, so they know when they are likely to receive working software. If
effort is written into it, the metric loses reliability.
http://johnharo.net/agile-should-you-estimate-spikes-with-story-p

12. 1.b. Defining the feature “I want...”

Define the feature/series of events. How the
role triggers the stimulus; usually verb+object

Englobes the set of criterion (WHAT vs.
HOW)

Is unique to both the 'role' and the 'benefit'

Example: “I want to collect books in my
shopping basket”

13. 1.c. Defining the benefit “so that...”

This is the WHY?

Helps the PO prioritise. This section is sometimes fleshed
out to include the business case, or recap on pain points/opportunities
identified in Design Thinking

Helps guarantee value specific to the 'role'

Example: “so that I can purchase multiple
books at once”

14. 2. Acceptance criteria in practice:
specification by example

Define a scenario: acceptance criterion
headline

Use the Triple A of Given/When/Then
− Given=Arrange: Context, initial state of the system
− When=Act: Execution of the feature/event
− Then=Assert: Assertion of observable behaviour

Example:
scenario: Books can be added to the shopping basket
Given my shopping basket is empty
When I add the book “Harry Potter” to my shopping basket
Then my shopping basket should contain 1 copy of “Harry Potter”

15. Advantages of specification by
example

Scenario gives quick ‘in’ into the aim(s) of the
feature

Going through given/when/then helps drive
reflection, detection of borderline cases,
negative testing, which will uncover more work
(ex: content/UX/design on error messages)

Language is simple and can be used by both
business and systems (Cucumber/Java style of
Behaviour Driven Development)

16. Specification by example extended
to deployment automation (CI)

17. Specifications used to detect code
regression across full project
(not just latest feature)