Story Splitting

職業

カテゴリ

ナレッジベース

• "Users can upload and download files" → Split into 2 stories
• "Admin can view or edit users" → Split into 2 stories

2. Action-Related Connectors: "manage", "handle", "support", "process", "administer"

• "Admin can manage users" → Hides create, edit, delete, list
• "System handles payments" → Hides initiate, process, refund, report

3. Sequence Connectors: "before", "after", "then", "while", "when"

• "Save work before submitting" → 2 separate stories
• "Process payment then send receipt" → 2 steps, 2 stories

4. Scope Indicators: "including", "as-well-as", "also", "additionally", "plus"

• "Notifications via email and SMS" → Split channels
• "Report including charts and exports" → Split outputs

5. Option Indicators: "either/or", "whether", "optionally", "alternatively"

• "Login with password or Google" → 2 authentication methods
• "Export to CSV or PDF" → 2 format stories

6. Exception Indicators: "except", "unless", "however", "although"

• "Delete account unless admin" → Base case + exception

When you spot these words, immediately flag the story as too big.

Decision Tree: Red Flag → Recommended Technique

Use this table to quickly select the best splitting technique based on the red flag detected.

How to use:

1. Scan story for red flags
2. Look up red flag in table
3. Apply recommended technique
4. If multiple red flags, apply techniques sequentially

Core Splitting Heuristics

When a story is too big, apply these techniques (in rough priority order):

1. Start with the Outputs

Focus on delivering specific outputs incrementally, not all at once.

Example: "Generate financial report"

• Split: "Generate revenue summary only"
• Split: "Add expense breakdown"
• Split: "Add charts"

2. Narrow the Customer Segment

Deliver full functionality for a smaller group instead of partial functionality for everyone.

Example: "All users can export data"

• Split: "Admins can export data"
• Split: "Power users can export data"
• Split: "All users can export data"

3. Extract Basic Utility First

Deliver the bare minimum to complete the task, then improve usability later.

Example: "Users can upload files with drag-and-drop, progress bars, and previews"

• Split 1: "Users can upload files via form (no UX polish)"
• Split 2: "Add drag-and-drop"
• Split 3: "Add progress indicators"
• Split 4: "Add previews"

4. Start with Dummy, Move to Dynamic

Build the UI/workflow with hardcoded data first, integrate real data later.

Example: "Show user dashboard with real-time stats"

• Split 1: "Dashboard with dummy/static stats"
• Split 2: "Integrate real backend data"
• Split 3: "Make it real-time"

5. Simplify Outputs

Use simpler output formats initially (CSV instead of PDF, console instead of UI).

Example: "Generate and email PDF reports"

• Split 1: "Generate CSV report saved to disk"
• Split 2: "Convert to PDF format"
• Split 3: "Email the report"

6. Split by Capacity

Limit initial scope by capacity constraints (file size, user count, data volume).

Example: "Support unlimited file uploads"

• Split 1: "Support files up to 1MB"
• Split 2: "Increase to 10MB"
• Split 3: "Support unlimited size with chunking"

7. Split by Examples of Usefulness

For large technical changes, identify concrete use cases that can be delivered with a subset of the solution.

Example: "Add API authentication"

• Split 1: "API auth for read-only endpoints"
• Split 2: "API auth for write endpoints"
• Split 3: "Add rate limiting"

8. Split Learning from Earning

Separate research/investigation (time-boxed learning) from value delivery (earning).

Example: "Implement machine learning recommendations"

• Learning: "Spike: Evaluate ML libraries (3 days max)"
• Earning: "Implement basic recommendation algorithm"
• Earning: "Deploy recommendations to 10% of users"

9. Forget the Walking Skeleton – Put it on Crutches

Deliver minimal user-facing functionality using manual steps or simpler backends initially.

Example: "Automated inventory sync between systems"

• Split 1: "Manual CSV export/import between systems"
• Split 2: "Semi-automated with script"
• Split 3: "Fully automated sync"

Process When User Describes Work

1. Listen for red flag words (and, or, manage, handle, etc.)
2. Challenge immediately: "This sounds like multiple stories"
3. Ask clarifying questions:
   • "What's the smallest piece that delivers value?"
   • "Who is the narrowest user segment we could start with?"
   • "What's the simplest output format that would work?"
   • "Can we do this manually first?"
4. Propose 3-5 specific split options using the heuristics above
5. Force radical slicing: "If you had to ship something by tomorrow, what would it be?"

Examples

Example 1: Story Too Big

User: "As an admin, I can manage users and roles, including creating, editing, deleting, and assigning permissions."

Your response:

🚨 Red flags detected:

• "manage" (hides multiple actions)
• "and" (multiple features)
• "including" (scope expansion)

This story is doing at least 5-6 different things. Let's split it:

Proposed splits:

1. "Admin can create a new user (with hardcoded default role)"
2. "Admin can edit user basic info (name, email)"
3. "Admin can delete a user"
4. "Admin can assign one predefined role to a user"
5. "Admin can create custom roles"
6. "Admin can assign multiple roles to a user"

Smallest slice to ship first: "Admin can create a new user with a hardcoded 'viewer' role"

• Takes 2-3 hours
• Delivers immediate value
• Testable in production
• Expands later with role selection

Example 2: Narrowing Customer Segment

User: "All users need to export their data to CSV or PDF"

Your response:

Let's narrow the segment and simplify the output:

Split 1: "Admins can export data to CSV"

• Why admins first? They need it most and can tolerate rough UX
• CSV is simpler than PDF
• Delivers value immediately

Split 2: "Power users can export to CSV"

Split 3: "All users can export to CSV"

Split 4: "Admins can export to PDF" (only if there's proven demand)

Smallest slice: Split 1 (admin + CSV only)

Example 3: Dummy to Dynamic

User: "Show a dashboard with real-time sales metrics pulled from 3 different databases"

Your response:

Let's start with dummy data to validate the UI/UX first:

Split 1: "Dashboard shows hardcoded dummy sales metrics"

• Build the UI/layout
• No backend integration
• Stakeholders can validate design
• 1 day of work

Split 2: "Dashboard pulls metrics from one database (no real-time)"

• Integrate one data source
• Refresh on page load
• 2 days of work

Split 3: "Add second database"

Split 4: "Add third database"

Split 5: "Make it real-time with WebSockets" (only if needed)

Smallest slice: Split 1 (dummy data dashboard)

Example 4: Multiple Techniques Applied Sequentially

User: "As a user, I want to manage my account settings and privacy preferences, including profile information, notification settings, email preferences, and data export, with the ability to preview changes before saving."

Your response:

🚨 Multiple red flags detected:

• "manage" (hides multiple actions)
• "and" appears 3 times (multiple features)
• "including" (scope expansion)
• "with" (additional feature bundled)

This story is doing at least 8 different things. Let's apply multiple techniques to break it down.

Step 1: Split by "manage" (hidden CRUD operations)

"Manage account settings" hides:

1. View current settings
2. Edit settings
3. Reset to defaults

Step 2: Split by "and" (multiple feature areas)

Even just "edit settings" includes:

1. Profile information (name, bio, avatar)
2. Notification settings (email, push, SMS toggles)
3. Email preferences (frequency, topics)
4. Data export (download all user data)

Step 3: Split by "including" (remove bundled features)

Each feature area can be split further:

• Profile info: (a) Basic info (name, email), (b) Extended (bio, avatar, location)
• Notifications: (a) Email toggles, (b) Push toggles, (c) SMS toggles
• Data export: Separate story entirely

Step 4: Extract basic utility (remove preview feature)

"Preview changes before saving" is a UX enhancement, not core functionality:

• Story A: Edit and save directly (no preview)
• Story B: Add preview feature later

Final proposed splits (after applying all techniques):

1. "User can view current profile name and email"

   • Time: 1 hour
   • Value: Users see their basic info

2. "User can edit profile name"

   • Time: 2 hours
   • Value: Users can update their name

3. "User can edit email address"

   • Time: 3 hours (includes email verification)
   • Value: Users can change email

4. "User can toggle email notifications on/off"

   • Time: 2 hours
   • Value: Users control email notifications

5. "User can upload profile avatar"

   • Time: 4 hours
   • Value: Users personalize their profile

6. "User can preview changes before saving profile"

   • Time: 3 hours
   • Value: Better UX (only after basic editing works)

7. "User can export their data as JSON"

   • Time: 5 hours
   • Value: Data portability (compliance requirement)

Recommended delivery order:

• Week 1: Stories #1, #2, #3 (basic profile editing)
• Week 2: Story #4 (notifications toggle)
• Week 3: Story #5 (avatar upload)
• Later: Stories #6, #7 (enhancements)

Techniques applied:

• Split by "manage" → Separated view/edit/reset
• Split by "and" → Separated profile/notifications/email/export
• Split by "including" → Removed bundled features
• Extract basic utility → Removed preview (add later)
• Narrow outputs → Name before bio/location
• Start simple → Toggles before complex preferences

Coaching Tone

• Be pushy: Call out "too big" work immediately
• Challenge: "Can we make it smaller?"
• Probe: "What would we ship if we had half the time?"
• Use Eduardo Ferro's phrases:
  • "What's the worst that could happen if we ship the simplest version?"
  • "Can we avoid doing it entirely?"
  • "Let's remove it and monitor the impact"

Integration with Other Skills

This skill works in sequence with other skills:

Typical workflow:

1. story-splitting (THIS SKILL): Detect linguistic red flags, split stories into smaller ones
2. hamburger-method: For stories still large after splitting, apply layered analysis
3. complexity-review: Review technical approach for each small story
4. micro-steps-coach: Break each story into 1-3h implementation steps

Use this skill when:

• Story contains obvious red flags ("manage", "and", "or", "including")
• User describes multiple features bundled together
• Story feels too big or vague

Vs. hamburger-method:

• story-splitting: Best when story has clear linguistic indicators of multiple features
• hamburger-method: Best when feature is large but doesn't have obvious split points
• Use story-splitting FIRST to remove obvious bundling, then hamburger-method if still needed

Integration example:

• Original: "Admin can manage users and roles"
• Apply story-splitting → Split into: (1) "Create user", (2) "Edit user", (3) "Assign role"
• Story #1 still feels large → Apply hamburger-method to identify layers + options
• Choose simplest vertical slice → Apply micro-steps-coach to plan 1-3h steps

Self-Check: Did I Apply This Correctly?

After applying this skill, verify:

• I scanned the story for all 6 red flag categories
• I flagged the story as too big when red flags were present
• I identified which splitting technique(s) to apply using the decision tree
• I proposed 3-5 concrete split stories (not just vague suggestions)
• Each split story is independently valuable (can be deployed alone)
• Each split story takes less than 2-3 days to complete
• I specified the smallest story to ship first
• I applied multiple techniques if the story had multiple red flags

If any checkbox fails, revisit the splitting process.

Red flags that I didn't do this right:

• I accepted the story without challenging it (missed red flags)
• Proposed splits are still too large (>3 days each)
• Splits are horizontal ("build database, build API, build UI") not vertical
• Splits don't deliver independent value (one depends on another finishing first)
• I only proposed 1-2 splits instead of fully decomposing the story

Reference

For comprehensive splitting heuristics, see REFERENCE.md in this skill directory.

Key Principle

Risk grows faster than the size of the change.

Small stories = Low risk = Fast feedback = Learning Large stories = High risk = Slow feedback = Waste

Always push for the smallest, safest, most valuable slice possible.