How many stories do you typically rewrite?

It depends on the backlog size and how much needs rework, but a typical engagement covers 30-50 stories. I focus on the stories closest to development, the ones your team will pick up in the next 2-3 sprints, rather than trying to rewrite everything at once.

What story format do you use?

I adapt to what your team already uses, but I default to a structure that includes user context (who and why), acceptance criteria (what "done" looks like), and scope notes (what's explicitly out). I avoid rigid "As a user, I want..." templates when they don't add clarity.

Will you prioritize the backlog too?

I'll recommend a prioritization approach, but final priority decisions stay with your product team. What I do is make the stories clear enough that prioritization conversations become productive instead of circular. If you need help with prioritization frameworks, that's part of [Product Leadership Coaching](/services/product-leadership-coaching/).

What if our team uses Jira / Linear / Shortcut?

I work in whatever tool your team uses. The principles are the same regardless of platform. I'll set up within your existing workflow rather than asking you to adopt something new.

User Storywriting & Backlog Review

Overview

Your backlog shouldn't feel like a junk drawer. But for most teams, it does. A mix of half-written stories, feature requests from six months ago, bugs no one can reproduce, and "placeholder" tickets that became permanent residents.

The problem isn't laziness. It's that nobody taught the team what a good story looks like, what "ready for dev" actually means, or how to keep the backlog from becoming a dumping ground. I've taught story writing to 150+ PMs and coached 50+ engineers on what "done" means before a line of code gets written. A clean backlog is the foundation of predictable delivery, and most teams are one good audit away from a healthier rhythm.

I'll rewrite your stories, clean up the clutter, and set up a structure your team can maintain without you hovering over every ticket.

Who this is for

This works well when you're:

A PM who inherited a backlog with 200+ tickets and no idea what's still relevant
A team where engineers regularly ask "what does this story actually mean?" in standup
A product leader noticing that sprint commitments keep slipping because stories aren't scoped well
A startup that grew past the "just talk about it" phase and needs real story discipline
An engineering manager frustrated by vague acceptance criteria and unclear priorities

If you need ongoing product leadership including backlog ownership, Fractional Product Leadership or a Sprint Engagement might be the right next step. This engagement is about building the foundation.

What you get

Backlog audit. I review your existing backlog, flag what's stale, identify stories that are too big or too vague, and categorize everything by status and readiness. You'll know exactly what you have and what's missing.
Rewritten stories. I rewrite your top-priority stories with clear structure: user context, acceptance criteria, scope boundaries, and anything engineering needs to start without a follow-up conversation.
Story writing playbook. A lightweight guide tailored to your team's tools and workflow so the backlog stays healthy after I leave. Includes templates, examples, and a definition of "ready for dev."

Typical engagement

Duration: 1-3 weeks
Commitment: 8-15 hours total (audit, rewriting, team walkthrough)
Format: Remote, async review with one team walkthrough session

User Storywriting & Backlog Review

Overview

Who this is for

What you get

Typical engagement

Frequently asked questions

What clients say

From the playbook

Related writing

You might also need

Interested in user storywriting & backlog review?