5.0 KiB
Story Generation Plan — CMS Frontend
Approach
Persona-Based + Feature-Based Hybrid: Stories are organized by persona (who) and grouped under the feature/page they relate to (what). This gives clear ownership per role while keeping related stories together for implementation.
Planning Checklist
- User Stories Assessment completed
- Story approach chosen: Persona-Based + Feature-Based Hybrid
- Clarification questions generated (see below)
- Clarification questions answered
- Stories generated (stories.md)
- Personas generated (personas.md)
- Acceptance criteria verified (INVEST-compliant)
- Personas mapped to stories
Generation Steps
Step 1: Generate personas.md
Create aidlc-docs/features/cms-frontend/inception/user-stories/personas.md with:
- Persona: System Owner
- Persona: CMS Administrator
- Persona: CMS User
- Persona: New Invited User (completing setup)
- Persona: Anonymous Visitor (unauthenticated, e.g. invite link recipient)
Step 2: Generate stories.md
Create aidlc-docs/features/cms-frontend/inception/user-stories/stories.md with stories for:
Epic: Authentication & Session
- US-01 Login with email and password
- US-02 Stay logged in across tab switches (session persistence via refresh token)
- US-03 Logout and end session
- US-04 Access denied redirect when not authenticated
- US-05 Auto token refresh on expiry
Epic: System Initialization
- US-06 Initialize system as first Owner (setup flow)
- US-07 Redirect to setup when system is not initialized
Epic: Dashboard
- US-08 View dashboard after login
- US-09 View system availability status on dashboard
Epic: User Management
- US-10 View list of users (Owner/Admin)
- US-11 Invite a new user by email with role selection (Owner/Admin)
- US-12 Share invite link after invitation is created
- US-13 Complete account setup via invitation link (New Invited User)
- US-14 Handle expired/invalid invitation token gracefully
Epic: Profile
- US-15 View own profile information
Epic: System Settings
- US-16 View system availability status in settings (Owner)
- US-17 Access denied to System Settings for non-Owners
Epic: Navigation & Layout
- US-18 See role-appropriate navigation items in sidebar
- US-19 Toggle dark/light theme
Epic: CMS Management (Placeholder)
- US-20 View CMS management placeholder page
Step 3: Validate INVEST criteria
- Each story is Independent (can be implemented standalone)
- Each story is Negotiable (not a contract)
- Each story is Valuable (delivers user benefit)
- Each story is Estimable (dev can size it)
- Each story is Small (fits in one sprint iteration)
- Each story is Testable (acceptance criteria are verifiable)
Step 4: Map personas to stories
- Add persona references to each story in stories.md
Clarification Questions
Please answer the following questions to improve story quality.
Question 1: Story format preference
Which format should be used for user stories?
A) Standard narrative: "As a [persona], I want to [action], so that [benefit]" B) Job-story format: "When [situation], I want to [motivation], so I can [outcome]" C) Other (please describe after Answer: tag below)
Question 2: Acceptance criteria format
How detailed should acceptance criteria be?
A) Concise bullet points (3–5 bullets per story, focus on happy path + key error states) B) Gherkin-style (Given/When/Then scenarios for each story) C) Detailed checklist covering happy path, error states, edge cases, and security constraints X) Other (please describe after Answer: tag below)
Question 3: Story granularity for auth flows
The authentication flow has several sub-steps (login, token refresh, logout, 401 handling). Should these be:
A) Separate stories — one story per interaction type (login, refresh, logout, redirect) B) One story per user goal — login is one story, "stay logged in" is one story, logout is one story C) A single epic story with sub-tasks broken out in acceptance criteria X) Other (please describe after Answer: tag below)
Question 4: Role names in stories
How should roles be referred to in story personas?
A) Use technical role names from the backend: Owner, Admin, User B) Use business-friendly names: System Owner, CMS Administrator, CMS User C) Use both — technical name + friendly alias (e.g. "Owner (System Owner)") X) Other (please describe after Answer: tag below)
Question 5: Out-of-scope stories
Should the stories document include placeholder/future stories for features that are explicitly out of scope in v1 (e.g. profile editing, availability status management, CMS content)?
A) Yes — include them as clearly marked "Future / Out of Scope" stories B) No — only include stories that are in scope for v1 C) Include brief notes only (no full story format) for future features X) Other (please describe after Answer: tag below)