Outcome

You will convert vague backlog items into clear, testable user stories with acceptance criteria that drive implementation and reduce rework.

Speed matters. But clarity matters more. The goal is fast precision, not fast guessing.

2.1 Why Fuzzy Requirements Create Rework

Common failure patterns:

• Undefined actors (“user” means who?)

• Hidden business rules

• Missing constraints

• No edge case thinking

• Acceptance criteria that describe intent, not behavior

If a developer cannot write a test from it, the story is not ready.

2.2 Rewrite Using a Structured Format

Story Template

Title
Clear, outcome-focused.

User Story
As a
I want
So that

Acceptance Criteria (Given / When / Then)
Behavioral. Observable. Testable.

Edge Cases
At least three. Always.

2.3 Exercise

Original “Confusing” Backlog Item

“Improve login so it’s more secure and user friendly.”

This is ambiguous:

• What does “secure” mean?

• What does “user friendly” mean?

• Who is the user?

• What behavior changes?

Rewritten Version (Testable)

Title

Add account lockout after failed login attempts

User Story

As a registered user
I want my account protected from brute-force login attempts
So that unauthorized users cannot gain access

Acceptance Criteria

Scenario 1 – Lock after repeated failures

Given a registered user with a valid account
When the user enters an incorrect password 5 consecutive times within 15 minutes
Then the account is locked
And the user cannot log in
And a lockout message is displayed

Scenario 2 – Successful login resets counter

Given a registered user
When the user enters correct credentials
Then the failed login counter resets to zero
 

Scenario 3 – Lockout duration

Given a locked account
When 30 minutes have passed
Then the account is automatically unlocked

Edge Cases

1. Failed attempts spread across more than 15 minutes (should not trigger lockout).

2. Attempted login while already locked (must not increment counter).

3. Simultaneous login attempts from multiple devices (counter must remain consistent).

2.4 Definition of “Ready”

A story is ready when:

• The role is explicit

• Business value is clear

• Acceptance criteria are behavior-based

• Edge cases are identified

• A developer could write tests immediately

If you cannot derive tests, it is not ready.

 

Your Exercise

Take one confusing backlog item from your current board and:

1. Rewrite the user story using the structured format.

2. Create at least 3 Given/When/Then acceptance criteria.

3. Identify 3 meaningful edge cases.