Most teams don’t struggle because they can’t write user stories.
They struggle because they’re trying to use stories to do too many jobs at once—capture requirements, prevent misunderstandings, document edge cases, satisfy compliance, and (somehow) still fit everything into a sprint. The result is predictable: stories that are either so vague they force guessing, or so detailed they become miniature specifications.
The Story Critic skill, developed by Mountain Goat Trainer Cort Sharp, can be added to AI platforms like ChatGPT and Claude. You can try the Story Critic below, download a skill you can install, or use it through a free Mountain Goat Essentials account.
The skill is designed to help with the day-to-day reality for team-level practitioners—developers, testers, analysts, designers, and product owners—who have to refine, estimate, split, and deliver work. It helps create backlog items that are better conversation starters while still pushing you toward clarity on what “done” means.
User stories are supposed to shift the focus from writing requirements to talking about them, and the conversations matter more than the sentence on the card.
What The Skill Does (And Why It Makes Two Separate Judgments)
The Story Critic makes two different calls about every item:
- Headline Coaching Assessment: How strong is the item as written?
- Backlog Placement Guidance: Is this level of detail appropriate for near-term work or does it belong lower in the backlog?
That second judgment matters because a light story can be excellent if it’s intentionally lower in the backlog. And a detailed story can also be excellent—if you’re actually going to build it soon. That “just in time and just enough” mindset is a big part of how I think about writing and refining backlogs.
What The Story Critic Looks For In A Good Backlog Item
It’s not trying to turn your backlog into perfectly templated user stories. In fact, one of its best traits is what it doesn’t care about:
- It won’t scold you for writing “I can…” instead of “I want…”
- It won’t demand acceptance criteria on every item
- It won’t treat formatting as the point of the exercise
Instead, it focuses on the things that actually determine whether a team can refine and deliver:
- Outcome Clarity: What changes for the user (or system) if this is done?
- Scope Focus: Is it one idea, or several bundled together?
- Testability: Can the team answer, “What must be true for this item to be considered complete?”
- Backlog Fit: Is it the right amount of detail for where it sits?
In other words, it’s trying to help your team spend refinement effort where it creates the most value—keeping the top of the backlog sprint-sized and workable without turning refinement into paperwork.
The Headline Coaching Assessment Levels
The skill uses six levels. Think of these as “what kind of conversation do we need next?” rather than as grades:
- Ready for Implementation: clear, testable, small enough for near-term delivery.
- Ready for Refinement: focused, structured; estimate with minor clarification.
- Nearly There: strong intent/value; a few gaps will create friction.
- Good Start: meaningful idea; still too vague to estimate well or begin work on.
- Needs Significant Refinement: unclear, bundled, solution-heavy, or hard to test.
- Not Yet a Story: a task/fragment without a clear outcome.
A team can use these levels as a quick triage mechanism: Which items are close enough to estimate? Which need story splitting? Which should stay light for now?
Backlog Placement Guidance: How It Relates (Without Being The Same Thing)
After the headline assessment, the Story Critic adds one of four placement labels:
- Appropriate for lower backlog
- Appropriate for near-term work
- Too light for near-term work
- Too detailed for lower backlog
This is where teams often get tripped up. They assume “more detail” always means “better story.” But detail is only valuable when it’s timely. The whole point of writing stories is to preserve agility—so you can change direction and learn as you go—not to lock yourself into yesterday’s assumptions.
Practically, the relationship looks like this:
- A story can be Good Start and Appropriate for lower backlog (a perfectly fine placeholder).
- A story can be Ready for Refinement and Too detailed for lower backlog (overspecified far too early).
- A story can be Needs Significant Refinement and still be Appropriate for near-term work (because you’re about to do it, but you need to split and clarify first).
Multiple Output Formats (So You Can Match The Moment)
The skill supports multiple output styles, which is important because teams need different feedback at different times:
- Quick critique: headline + a few priorities (great right before refinement)
- Full critique: a structured, detailed coaching review (great when an item is stuck)
- Batch review: scan a set of items and identify patterns across the backlog
- Rewrite-only: when you mostly want a cleaner version (without the long diagnosis)
Examples (Zoom Product Backlog)
Below are three ways a team might use this skill.
Example 1: Submitting A Simple Story (Quick Critique)
Prompt
Give me a quick critique of:
When I schedule a Zoom meeting, I want to get a URL so that I can share it.
Example Output (Quick Critique)
When I schedule a Zoom meeting, I want to get a URL so that I can share it.
- Ready for Refinement - Clear outcome, but the team will immediately ask what “get a URL” includes (where shown, when available, and whether it’s copyable).
### Backlog Placement Guidance
Appropriate for near-term work
- **Top Coaching Priorities:**
- Clarify where the URL appears and when it’s generated (after save, on invite screen, in calendar integration, etc.).
- Make the completion signal observable: The team understands what must be true for this item to be considered complete.
- **One question to unlock the outcome:** Where in the scheduling flow does the user need the URL, and what’s the minimum UI that makes it shareable?
That’s the kind of feedback teams can act on immediately in refinement without turning a small story into a dissertation.
Example 2: Submitting A Story With Acceptance Criteria (Full Format)
This one is intentionally realistic: a story with a lot of acceptance criteria. That’s common when teams are trying to reduce risk or prevent rework—especially on UI-heavy features.
Prompt (Acceptance Criteria Shown In Part For Readability)
Critique this story:
As a Zoom meeting participant, I want to be able to chat via text with others in the meeting so that I can ask questions and such without interrupting the meeting.
Acceptance criteria (not all shown):
- Chat is available to all authenticated meeting participants while the meeting is in progress.
- A participant can send a text message to everyone in the meeting.
- A participant can send a 1:1 direct message to another participant.
- Incoming messages appear in near real time without requiring a page refresh.
- Unread message indicator is shown when the chat panel is closed/minimized.
- If message delivery fails, the sender is notified and can retry.
- Only meeting participants can view messages for that meeting.
- Messages persist for the duration of the meeting so participants can scroll back.
Example Output (Full Format)
As a Zoom meeting participant, I want to be able to chat via text with others in the meeting so that I can ask questions and such without interrupting the meeting.
### Headline Coaching Assessment
- Needs Significant Refinement
- Strong user outcome, but the acceptance criteria bundle multiple message types and UX behaviors into what is likely an epic that will be hard to estimate without story splitting.
### Backlog Placement Guidance
Appropriate for near-term work
### Coaching Snapshot
- **Item Type:** User Story
This is a user-facing capability with a clear benefit: ask questions without interrupting.
- **Structure:** Clear
Who + capability + why are present; the criteria add useful detail.
- **Outcome or Result Clarity:** Concrete and Observable
“Participants can send and receive chat messages during a meeting” is demonstrably true.
- **Focus:** Multiple Objectives
The criteria cover several distinct slices (everyone chat, 1:1, delivery behavior, indicators, persistence, permissions).
- **Testability:** Needs Clarification
Many parts are testable, but “near real time” and “authenticated participants” need a shared interpretation for verification.
- **Acceptance Criteria:** Present but Needs Refinement
Helpful and mostly aligned, but large enough that it risks becoming a mini-spec instead of supporting refinement.
### Strengths
- The core outcome is clear and valuable during meetings.
- The criteria include a strong completion signal around permissions (participants only).
- The criteria acknowledge failure cases (delivery fails, retry), which teams often discover late.
### Top Coaching Priorities
1. **Split this into a smallest viable slice** (start with “message everyone” before adding 1:1 and ad-hoc group messaging).
2. **Keep the criteria that define ‘done’ and move optional enhancements into follow-on items** (emoji, advanced indicators, performance targets, etc.).
3. **Clarify the few terms that will block estimation** (what “authenticated participant” means and what “near real time” means in testable terms).
### Split Guidance (Optional)
- Split by message target: everyone-first, then 1:1, then ad-hoc group messages.
- Split by experience: send/receive messages first, then unread indicator, then persistence/scrollback enhancements.
### Questions to Ask During Refinement (Optional)
- Are guests included, or is chat restricted to signed-in participants only?
- Is persistence strictly “during the meeting,” or should there be any after-meeting access?
- What’s the minimum acceptable “real time” behavior we can verify in tests?
### Improved Version(s)
- **Rewrite #1 - Same Template, Improved Clarity**
As a Zoom meeting participant, I can send and read text messages during a meeting so I can ask questions without interrupting.
- **Rewrite #2 - Alternative Template (Optional)**
When I’m in a Zoom meeting, I want to message other participants in text so I can participate without speaking over the meeting.
Notice what the critique is doing: it’s not rewriting everything. It’s trying to get the team to the point where they can estimate and deliver by splitting the work, which is often the real lever in refinement.
Example 3: Submitting A Product Backlog With Multiple Items (Batch Review)
In practice, teams often want a fast scan across a backlog. They’re trying to decide, “What’s close? What’s risky? Where should we spend refinement time?”
Prompt (One Product Backlog, One Item With Acceptance Criteria)
Batch review these backlog items for Zoom:
1) As a Zoom meeting participant, I want to be able to chat via text with others in the meeting so that I can ask questions and such without interrupting the meeting.
(Includes acceptance criteria)
2) When a Zoom meeting ends, I want Zoom to close so that I stop sending audio and video.
3) When I schedule a Zoom meeting, I want to get a URL so that I can share it.
4) When my mic volume is too low or too high, I want Zoom to adjust it so I always sound awesome.
Example Output (Batch Review)
1) As a Zoom meeting participant, I want to be able to chat via text with others in the meeting so that I can ask questions and such without interrupting the meeting.
- Needs Significant Refinement — Great outcome, but bundled scope across multiple message types and UX behaviors.
### Backlog Placement Guidance
Appropriate for near-term work
2) When a Zoom meeting ends, I want Zoom to close so that I stop sending audio and video.
- Ready for Refinement — Clear safety outcome; the team will just need to clarify what “close” means across platforms and edge cases.
### Backlog Placement Guidance
Appropriate for near-term work
3) When I schedule a Zoom meeting, I want to get a URL so that I can share it.
- Ready for Refinement — Clear value; needs minor clarification about where/when the URL appears.
### Backlog Placement Guidance
Appropriate for near-term work
4) When my mic volume is too low or too high, I want Zoom to adjust it so I always sound awesome.
- Good Start — Intent is clear, but “adjust it” hides important questions (how, when, and what constraints).
### Backlog Placement Guidance
Too light for near-term work
Patterns Across The Set
- The strongest items have an observable outcome and a clear completion signal.
- The weakest items are “clear in spirit” but hide the key decisions the team needs to estimate.
Rewrite (Weakest Item)
- When my mic volume is outside an acceptable range, Zoom can automatically adjust input gain so my volume stays within that range.
This is the kind of output teams can use to choose a short refinement agenda: split chat, clarify “close,” clarify where the URL appears, and pull the mic story forward with a better outcome definition.
How I Recommend Teams Use This
If you try this skill once and treat the output as a verdict, you’ll be disappointed. That’s not what it’s for.
Where it helps is as a lightweight coach in three places teams already spend time:
- Before refinement: run quick critiques to surface the top 1–2 questions you’ll need to answer anyway.
- During story splitting: use it to confirm you actually reduced scope rather than just rearranged words.
- Before sprint planning: batch review the top of the backlog to spot “too light” items before the meeting starts.
Refinement is hard enough when the backlog is good. When it isn’t, refinement becomes a recurring meeting where everyone feels busy and nobody feels confident. A tool that nudges items toward better conversation—and clearer “done”—can save teams from a lot of avoidable pain.
Install
You can download a zip file containing the skill and then install it within ChatGPT or Claude.
You can also sign up for a free MGS Essentials account, which gives you access to the Story Critic as well as other AI tools developed specifically for agile teams.
Make The Skill Your Own (By Editing A Few Files)
If you like what the Story Critic does, you can make it even more valuable when you tune it to match your team.
You don’t have to rewrite the whole skill. Small, targeted edits change the coaching in useful ways:
- Update the rubric to match what your team actually values in refinement. If you care most about “what must be true when we’re done,” make that explicit. If you want the coach to push harder on story splitting, say so.
- Add examples that look like your backlog. The fastest way to steer the coach is to give it a handful of “good” and “needs work” stories from your product domain—same vocabulary, same kinds of constraints, same level of detail you consider healthy.
- Keep a few regression test examples—stories you can re-run after edits to confirm the skill still behaves the way you want. Think of these as unit tests for your coaching style.
A practical starting point is to tune three things:
- Vocabulary: product terms, roles, and common nouns the skill should preserve in rewrites.
- Strictness: what “near-term work” requires on your team (for example, a clearer completion signal).
- Splitting: state which of the SPIDR splitting patterns you prefer or tell it to use a different splitting approach
The goal isn’t to turn the Story Critic into a rulebook. It’s to turn it into a coach that speaks your team’s language and helps you get to better refinement conversations faster.
Last update:
April 28th, 2026
