Why this matters
As a Business Analyst, you help teams plan, estimate, and deliver. Inconsistent granularity (mixing epics, stories, and subtasks) ruins estimates, hides dependencies, and slows sprints. Keeping a steady "zoom level" across user stories and acceptance criteria makes grooming faster, forecasts clearer, and delivery smoother.
- Backlog refinement: split or merge items so they are similar size and ready.
- Estimation: compare apples-to-apples stories for reliable sizing.
- Release planning: group consistently sized stories into sprints with fewer surprises.
- Quality: acceptance criteria at the same depth help QA create consistent test cases.
Concept explained simply
Granularity is the level of detail and size of a work item. "Consistent granularity" means most stories in a sprint are roughly the same size and depth of acceptance criteria.
Target rule of thumb (adjust for your team):
- Each story is a vertical slice that a developer can complete in 1–3 days.
- Each story has 3–7 clear acceptance criteria using Given/When/Then.
- Avoid mixing epics (too big) and subtasks (too small) into the story list.
Mental model: camera zoom
Think of a product as a landscape. Epics are wide-angle shots (too broad), subtasks are extreme close-ups (too detailed). Stories should be like a standard portrait: consistent framing so you can compare them easily.
Quick rules and checklist
- Same zoom: Stories belong to the same level (no epics or subtasks mixed in).
- Fits a sprint: Each story typically fits in 1–3 dev days (team-specific).
- Vertical slice: Delivers user-visible value end-to-end.
- INVEST: Independent, Negotiable, Valuable, Estimable, Small, Testable.
- 3–7 ACs: Acceptance criteria are concise, outcome-focused, and testable.
- Use Gherkin style: Given/When/Then to reduce ambiguity.
- Split by SPIDR if too big: Spike, Paths, Interfaces, Data, Rules.
- Merge if too small: Combine closely related slivers that can’t deliver value alone.
Worked examples
Example 1: Payments (normalize size)
Original item (too big): "As a shopper, I can pay with card, see saved cards, refunds, and invoices."
Normalized set (vertical slices, 1–3 days each):
- Story A: "As a shopper, I can pay with a new credit card."
AC (sample):
- Given a valid Visa, When I submit payment, Then the order is confirmed and a receipt is shown.
- Given an invalid card, When I submit, Then I see a validation error and no charge occurs. - Story B: "As a shopper, I can save a card for future use."
- Given I check "Save card", When payment succeeds, Then the card is saved and listed in my wallet. - Story C: "As a shopper, I can use a saved card."
- Given I have a saved card, When I select it, Then payment uses that card without retyping details.
Example 2: Notifications (avoid subtasks-as-stories)
Original items:
- "Create DB column for sms_opt_in" (subtask)
- "As a user, I can set notification preferences" (story)
Normalized stories:
- Story: "As a user, I can enable or disable SMS notifications."
AC:
- Given I am on Preferences, When I toggle SMS, Then my choice is saved and reflected on reload.
- Given SMS is disabled, When an SMS-triggering event occurs, Then no SMS is sent.
Technical tasks (like DB column) remain subtasks under the story, not separate stories.
Example 3: Reporting (split by Rules/Data)
Original item (mixed scope): "Add advanced filters and export to CSV with scheduling."
Normalized using SPIDR:
- Story 1 (Rules): "Filter by date range and status."
- Story 2 (Data): "Export current filtered results to CSV."
- Story 3 (Paths): "Schedule a daily export at a set time."
Steps to normalize granularity in grooming
- Scan for outliers: Identify items that look like epics (too many outcomes) or subtasks (implementation-only).
- Define the target size: Agree as a team on the 1–3 day story benchmark and 3–7 ACs.
- Vertical slice first: Ensure each story delivers user-visible value end-to-end.
- Split with SPIDR: Break big stories by Paths, Interfaces, Data, Rules, or use a Spike when learning is needed.
- Merge tiny slivers: Combine small, related items that don’t deliver value alone.
- Align AC depth: Rewrite acceptance criteria to the same level of detail across stories.
- Re-estimate: After normalization, re-check estimates to confirm consistency.
Exercises
Match these with the exercises below. You can do them here, then compare against the solutions.
Exercise 1: Rewrite a mixed backlog to a consistent level
Given items:
- Item A: "As a customer, I can manage my subscription and see invoices and change plan and add vouchers."
- Item B: "Implement endpoint /v1/subscription/update"
- Item C: "As a customer, I can pause my subscription until a chosen date."
Task: Produce 2–5 user stories, each fitting 1–3 dev days, each with 3–5 Gherkin-style acceptance criteria. Ensure technical tasks are subtasks, not separate stories.
Checklist:
- Each story is user-facing and valuable.
- 3–7 concise ACs per story.
- No mixed epic/subtask levels in the story list.
Exercise 2: Split, keep, or merge?
Given these items with rough dev-day estimates (from the team):
- D1: "New filter: by region" (0.5 day)
- D2: "Advanced segment builder with nested rules" (5 days)
- D3: "Add tooltip text to 8 fields" (0.5 day)
- D4: "Export to Excel with formatting options" (3 days)
- D5: "Schedule weekly Excel export" (2 days)
- D6: "Refactor export module" (unknown)
Task: For each item, choose one action: Split, Keep, or Merge. If Split, say how (e.g., by Rules/Data/Paths). If Merge, state what to merge with. Add a short reason.
Tip: Use the 1–3 day target and 3–7 ACs guideline.
Common mistakes and self-check
- Mixing technical tasks as stories: Keep implementation tasks as subtasks under a user-facing story.
- Stories too big (epics): If it exceeds 3 days or has >7 ACs, split by SPIDR.
- Stories too small: If no user-visible value alone, merge with a sibling story.
- ACs are steps, not outcomes: Write ACs as outcomes (Given/When/Then), not developer to-do lists.
- No vertical slice: UI-only or back-end-only work rarely delivers value alone; find an end-to-end slice.
Self-check prompts
- Can this story be demoed to a stakeholder in under 5 minutes?
- Would QA know when to pass/fail using the ACs alone?
- If we dropped this story from the sprint, would user value decrease? If not, it might be a subtask.
Practical projects
- Create a mini story map for a simple feature (e.g., profile management). Normalize 6–10 stories to the same granularity and write ACs.
- Run a mock grooming session with a friend: one plays PO, one plays BA. Practice splitting with SPIDR and aligning AC depth.
- Take an old project’s backlog and normalize the top 15 items. Track how estimates change after normalization.
Mini challenge
Pick any single oversized story from your work or a sample backlog. In 15 minutes, produce 2–4 normalized stories with ACs using SPIDR. Aim for 1–3 days each and 3–7 ACs. Demo-ready is the goal.
Who this is for
- Business Analysts, Product Owners, and Scrum Masters refining backlogs.
- New BAs learning to prepare stories for predictable delivery.
Prerequisites
- Basic understanding of user stories and acceptance criteria.
- Familiarity with sprints and backlog grooming.
Learning path
- Write clear user stories (INVEST)
- Craft acceptance criteria (Given/When/Then)
- Maintain consistent granularity (this lesson)
- Prioritization and story mapping
- Refinement and estimation techniques
Next steps
- Apply the checklist in your next refinement session.
- Use SPIDR to split any story exceeding 3 dev days.
- Standardize AC templates across your team.
Quick Test
Everyone can take the test for free. If you are logged in, your progress will be saved automatically.