User stories ready to estimate
Three worked examples to uncover scope, tests and dependencies before choosing a card.
Preparation does not mean knowing every detail
A story ready for discussion has an understandable outcome, boundaries and visible questions, not an exhaustive specification. Refinement clarifies and breaks down work as you learn.
These fictional exercises have no preset points. Size depends on product, dependencies, quality practices and team references. Start by explaining the intended delivery.
This preparation aid is not an official Scrum rule or a barrier to discussing uncertainty. A better question is useful even when you cannot estimate yet.
Example 1: find orders by reference
A support person finds an order by full reference. The API and reusable search field exist. Partial matches and new filters are excluded.
Acceptance: valid reference shows an authorised order; unknown reference shows an empty state; network error permits retry without losing text. Search has a clear label and works by keyboard.
Ask about permission checks, pasted spaces and API tests covering the screen's contract. If the API does not exist, the original scope has changed.
Compare with a similar completed search. Make new permission models explicit; visual similarity does not imply equal size.
Example 2: turn off a summary email
An account holder can disable weekly summaries in preferences. Recovery emails remain enabled. Custom frequency is excluded.
Acceptance: settings persist across sign-ins, sending respects changes and save errors restore the previous state. Decide what happens to already queued summaries.
Uncertainty may be in sending, not the switch. Consult someone familiar with it; investigate unknown queue behaviour before estimating.
Start with a binary setting and leave extra frequencies for later. Each part must work end to end. A screen without sending changes only appears functional.
Example 3: export report results
An authorised user downloads filtered results as CSV, with agreed columns and readable headers. This fictional product story is not an announced StoryFlop feature.
Clarify volume, dates, special characters and permissions. Visible page or all filtered results? What appears while waiting? Answers may require different solutions.
Acceptance: matching filters, preserved accents, compatibility with the target tool and no unauthorised rows. Include security and safe handling of formula-like values.
Investigate uncertain volumes using representative authorised data. An explicitly limited useful export may be a first step rather than a full export with unknown cost.
The shared check before voting
Ask two people to explain the story. Clarify differing outcomes. Include tests, review, permissions and dependencies in the work to finish.
Record exclusions to prevent recurring assumptions. Assign an owner and review time for questions that can change the solution substantially.
Keep answers in the template and bring the story's title and description to StoryFlop. Transfer the agreement to your backlog to preserve context for implementation.
- We can explain the expected outcome
- We know how to verify it
- Dependencies, boundaries and questions are visible
Put it into practice
Sources and further reading
The examples and StoryFlop instructions were written for this section. These sources provide context for the method and refinement: