Building a reference story library for your team
We're growing the team from 5 to 10 developers. New people keep asking "what does a 5-point story look like?" during planning poker.
I want to create a reference library of actual stories we've completed at different point values. How do you build and maintain something like this? What information should be included for each reference story?
Structure for Reference Stories:
For each point value (1, 2, 3, 5, 8, 13), document 3-5 real completed stories with:
- Story title and link to Jira/ticket
- Brief description (1-2 sentences)
- What made it this size (complexity factors)
- Actual time taken (for calibration)
- Link to PR/commit (optional but helpful)
Example Entry (5 points):
User Profile Edit Feature
Allow users to update name, email, avatar. Includes frontend form, backend API, validation, email confirmation.
Why 5 points: 2 new API endpoints, frontend components, database migration, email integration.
Actual time: 1.5 days
PR: #234
Categorize by Type:
- UI work (forms, pages, components)
- API development (endpoints, integrations)
- Database work (migrations, queries)
- Bug fixes (simple, complex, production)
This helps people find relevant examples: "I'm estimating a database migration - what have we done before?"
Maintenance:
- Review quarterly - codebase changes over time
- Add exceptional stories (outliers teach lessons)
- Remove outdated examples (deprecated tech)
Tool Options:
- Confluence wiki (searchable, version-controlled)
- Notion database (taggable, easy to filter)
- GitHub wiki (dev-friendly, near the code)
We created a Notion database with tags: #frontend, #backend, #database, #integration. New devs can filter by technology stack to find relevant examples.
Also added a "Lessons Learned" field for stories that were mis-estimated initially.
Love the categorization by type! I'll set up a Notion database with these fields and start populating it with our last 3 sprints worth of stories.
Pro tip: Include screenshots or GIFs of the completed feature. Visual examples help non-technical stakeholders understand why something was 8 points vs 3 points.