Backlog Refinement Language | Agile & Scrum Exercises

1 / 5

During backlog refinement, the Product Owner presents four candidate user stories. The team needs to identify which one follows the correct user story format — describing a user goal rather than a technical implementation.

Which story is correctly written in the standard user story format?

The standard user story format is: "As a [role], I want [goal] so that [benefit]" — it describes what the user wants to achieve and why, not how the system or developer should build it.

Option	Problem
B — collaborative filtering, 90% precision	Technical implementation detail — not negotiable, no user role or business value
C — "The system shall…"	System requirement format, not a user story — missing the human perspective and the "so that" benefit
D — "As a developer, I want…"	Developer role with a technical goal — not delivering user value; should be a tech task or spike

Using the correct format matters: it keeps the team focused on outcomes for users, not outputs for engineers, and makes the story easier to slice and prioritise by business value.

2 / 5

The team is writing acceptance criteria for a session-expiry feature. The tech lead says: "Acceptance criteria must be in BDD format — Given, When, Then."

Which of the following is a correctly written BDD acceptance criterion?

BDD acceptance criteria use the Given / When / Then structure to describe behaviour from the user's perspective in a testable, unambiguous format:

Clause	Role	Example
Given	Context / precondition	User has been inactive for 30 minutes
When	User action or system event	They navigate to a protected page
Then	Observable, verifiable outcome	Redirected to /login with a specific message

Options A and B are test descriptions or requirements, not BDD criteria. Option C is informal notes — it lacks the structured format that allows direct automation and removes ambiguity for both developers and QA.

3 / 5

During a refinement session, the team applies the INVEST checklist to evaluate candidate stories. INVEST stands for: Independent, Negotiable, Valuable, Estimable, Small, Testable.

Which story satisfies all six INVEST criteria?

Option C — saving a delivery address — passes all six INVEST criteria:

Criterion	Option A	Option B	Option C ✓	Option D
Small	❌ Entire UI redesign	✓	✓	❌ Too vague
Negotiable	✓	❌ Specifies OAuth 2.0 + JWT	✓	✓
Testable	❌ No measurable criteria	✓	✓	❌ "Good experience" not testable

The key failures: A is too large (entire UI redesign = epic, not story), B pre-decides the technical implementation (violates Negotiable), and D is too vague to be Estimable or Testable.

4 / 5

During refinement, the tech lead says about a checkout story:

"This story is too large for one sprint. I suggest we split it into the happy path — where the payment goes through successfully — and separate stories for each error case: payment declined, address validation failure, and timeout."

Which story-splitting strategy is the tech lead describing?

Splitting by workflow scenarios (happy path + error cases) is one of the most valuable story-splitting strategies because each slice delivers independently testable user value:

Splitting strategy	Value per slice	Recommended?
By workflow scenario (happy/error paths)	High — each slice is usable	✓ Yes
By technical layer (UI / API / DB)	None — no layer works alone	✗ Anti-pattern
By team member (component ownership)	None — creates integration risk	✗ Anti-pattern
Cross-sprint (one large story)	None until fully done	✗ Violates sprint goal clarity

Technical layer splitting (Option A) is the most common anti-pattern — it creates component tasks that cannot independently deliver value to a user, which defeats the purpose of user stories.

5 / 5

During sprint planning, the Scrum Master adds a new item to the sprint backlog:

"Before we can estimate the payment gateway integration story, the team needs to investigate whether the vendor's API supports idempotent requests. I'm adding a spike to this sprint for that."

Which statement correctly defines a spike in Agile?

A spike is a time-boxed investigation task whose output is knowledge, not a shippable feature. Spikes reduce uncertainty and enable better estimation:

Spike attribute	Description
Time-boxed	Has a fixed time limit (e.g. 4 hours, 1 day) to prevent unbounded research
Output is knowledge	Ends with a decision, recommendation, or updated estimate — not production code
Enables estimation	Run when a story cannot be estimated because of technical unknowns
Not a user story	Spikes do not follow the "As a user…" format; they are team-internal tasks

Options B (urgent bug), C (performance test), and D (refactoring) describe different types of unplanned or technical work — none of them fits the definition of a spike.