1
Writing Great User Stories
User Story Formula
"As a [type of user], I want [to perform an action / achieve a goal], so that [I receive this benefit or value]."
✅ "As a returning customer, I want my cart to be saved when I close the browser, so that I can continue shopping later without losing my selections."
❌ "As a user, I want the cart to work better." — Too vague, not testable, no clear benefit.
Acceptance Criteria Template (Gherkin Format)
GIVEN [starting context or precondition]
WHEN [the user performs this action]
THEN [this is the expected result]
GIVEN I am a logged-in user on the checkout page
WHEN I click "Save Cart" and close the browser
THEN my cart items are still present when I return within 30 days
WHEN [the user performs this action]
THEN [this is the expected result]
GIVEN I am a logged-in user on the checkout page
WHEN I click "Save Cart" and close the browser
THEN my cart items are still present when I return within 30 days
2
INVEST Criteria — Is the Story Ready?
| Criterion | What it means | Refinement check question | |
|---|---|---|---|
| I | Independent | Can be developed and delivered without requiring other stories to be done first | "Does this story depend on another unfinished story? Can we reorder or split it?" |
| N | Negotiable | Details and implementation can change — only the user value is fixed | "Are we locked into a specific technical approach, or can the team find the best solution?" |
| V | Valuable | Delivers clear, meaningful value to a user or the business — not just technical work | "Who benefits from this? What changes for the user when this is done?" |
| E | Estimable | The team has enough information to estimate the effort involved | "Do developers feel confident estimating this? If not, what information is missing?" |
| S | Small | Can be completed within a single Sprint — if not, it needs to be split | "Could this fit in one Sprint? If a developer started Monday, would it be Done by Friday?" |
| T | Testable | Has clear acceptance criteria that can be verified — someone can test whether it is done | "How will we know this is done? Can QA write a test case against these criteria right now?" |
3
Story Point Estimation — Planning Poker
Planning Poker uses the Fibonacci sequence for relative estimation. Each developer picks a card privately, then all reveal simultaneously to prevent anchoring bias. When estimates differ widely, discuss and re-estimate.
½
Trivial
1
Very Small
2
Small
3
Medium
5
Medium-Large
8
Large
13
Very Large
?
Too Vague
⚡
If a story is estimated at 13 or more points — it is too large for a Sprint. Split it into smaller stories before it can enter Sprint Planning. A story estimated with "?" means the team needs more information from the PO before estimating.
4
Refinement Session Agenda
60–90 min session| Time | Activity | Owner | Output |
|---|---|---|---|
| 0:00–0:05 | Review previous refinement actions Check if any stories from last session have been clarified or updated based on feedback. | Scrum Master | Confirmed status of pending items |
| 0:05–0:15 | PO presents priorities PO walks through the top 5–8 upcoming stories and explains the business context and value of each. | Product Owner | Team understands the WHY |
| 0:15–0:50 | Story-by-story refinement For each story: PO reads it, team asks questions, acceptance criteria are agreed, team estimates using Planning Poker. | Team + PO | Estimated, refined stories |
| 0:50–1:05 | Story splitting (if needed) Stories that are too large (>8 points) or unclear are split into smaller, Sprint-sized stories. | PO + Developers | Smaller, sprint-ready stories |
| 1:05–1:15 | DoR check Apply the Definition of Ready checklist. Only stories meeting DoR are marked ready for Sprint Planning. | Scrum Master | Ready stories clearly marked |
5
Definition of Ready Checklist
Apply to every storyWritten in user story format. "As a [user], I want [goal] so that [benefit]." Technical tasks have a clear description of what needs to be done and why.
Acceptance criteria are written and agreed. At least 2–3 testable acceptance criteria exist and have been reviewed by the team and PO together.
Story is estimated. The Development Team has estimated the story using Planning Poker or an equivalent relative sizing method.
Story fits in one Sprint. No story estimated above 8 points should enter Sprint Planning without being split into smaller pieces.
Dependencies identified. Any dependencies on other stories, teams, or external systems are documented and are either resolved or have a clear plan.
UI/UX designs available (if required). If the story has a visual component, design mockups or wireframes are available for developers to reference.
Team has no blocking questions. All developer questions from refinement have been answered. The team feels confident they understand what to build.
6
Common Refinement Mistakes
❌ Poor Refinement Habits
- PO writes stories alone without developer input
- Acceptance criteria written after development starts
- Stories estimated without discussion — just averages
- 13-point stories pulled into Sprint Planning unchanged
- Refinement skipped when team is "too busy"
- Only the PO attends — developers absent
- Same stories discussed in every refinement with no progress
✅ Signs of Healthy Refinement
- Sprint Planning takes less than 90 minutes because stories are ready
- Developers rarely ask "what does this mean?" during a Sprint
- Stories rarely roll over to the next Sprint due to surprises
- Acceptance criteria are specific and testable
- The top 2 Sprints of backlog are always refined
- Team velocity is more predictable Sprint over Sprint
- Developers contribute to story writing — not just PO
MickyMarvels LLC
Practical Agile Mentoring · mickymarvels.info