Agile Product Owner

All agile artifacts are stored under doc/agile/:

• Current major version: v0
• Version-specific files: doc/agile/v0/
• Product backlog: doc/agile/product_backlog.org
• Major version manifest: doc/agile/v0/version_zero.org

Sprint backlogs are located at doc/agile/v0/sprint_backlog_NN.org where NN is the sprint number:

• Latest sprint backlog: Contains stories for the current sprint under active development. e.g., sprint_backlog_05.org.
• Older sprint backlogs: Contains completed work; consult occasionally when researching past decisions or completed features. e.g., sprint_backlog_01.org through sprint_backlog_04.org.

To identify the current sprint:

1. List files in doc/agile/v0/ matching the pattern sprint_backlog_*.org.
2. Find the file with the highest sprint number - e.g., sprint_backlog_05.org means sprint 5 is current.
3. Read the sprint mission at the top of the file to understand current focus.

Location: doc/agile/product_backlog.org.

The product backlog is organized into two sections:

Location: doc/agile/v0/version_zero.org.

Contains:

• Overall direction for the major version.
• Strategic goals and vision.
• Project planning and roadmap.
• Near-term milestones.
• Links to all sprint backlogs.

Create stories in the following situations:

1. New feature requests: User-facing functionality.
2. Bug fixes: Defects that need resolution.
3. Technical debt: Code quality improvements, refactoring.
4. Infrastructure work: Build system, CI/CD, tooling.
5. Cleanup tasks discovered during development: Technical improvements identified while working on other tasks
6. Research and analysis: Investigations, proof of concepts.
7. Documentation: User guides, developer documentation.

Stories in ORE Studio use org-mode format with specific structure:

Stories within the current sprint backlog should be ordered by:

1. Blockers first: Work that blocks other team members.
2. Sprint mission alignment: Work directly supporting sprint goals.
3. Dependencies: Work that other tasks depend on.
4. Value delivery: Work that delivers user value sooner.

When you identify cleanup work during implementation:

1. Assess urgency:
   • Can it be done now? → Do it immediately.
   • Needed for current sprint? → Add to current sprint backlog.
   • Can wait? → Add to product backlog.
2. Document context:
   • What needs cleaning up?
   • Why is it needed?
   • Where is the code located?
   • What is the impact if not done?
3. Tag appropriately:
   • Use :code: for refactoring
   • Use :infra: for build/tooling improvements
   • Use :analysis: if investigation needed first

When users or team members suggest enhancements:

1. Capture the idea in product backlog (Far section)
2. Document the value proposition
3. Note any dependencies or prerequisites
4. Add to appropriate section based on priority

When you need to investigate something:

1. Create a research story in appropriate backlog
2. Define clear research questions
3. Specify deliverables (report, proof of concept, decision)
4. Tag with :analysis:

• Significant feature completions
• Release candidates
• Integration points with external systems

• Major architectural decisions
• Technology choices
• Platform decisions
• User experience direction

• Ensure all sprint backlogs are linked in the manifest
• Keep descriptions up to date
• Note sprint completion status

1. Be specific – Clear, actionable descriptions
2. Include context – Why is this work needed?
3. Define acceptance criteria – How do we know it's done?
4. Link related work – Reference other stories, commits, or documentation
5. Use appropriate tags – Helps with reporting and filtering

1. Break down large stories – Keep stories small enough to complete in a few days
2. Create epics – Use parent stories for large features
3. Separate concerns – Split technical and user-facing work if it helps

1. Review regularly – Product backlog should be reviewed at least monthly
2. Archive completed work – Keep sprint backlogs but mark them as historical
3. Remove stale stories – Delete stories that are no longer relevant
4. Refine stories – Add detail to stories as they get closer to implementation
5. Move stories – Promote stories from Far to Near as priorities change

1. Respect the sprint mission – New stories should align with sprint goals
2. Limit work in progress – Focus on completing stories before starting new ones
3. Track time – Use org-mode clocking for time tracking
4. Update status – Keep story status current (STARTED, COMPLETED, etc.)
5. Document decisions – Add notes to stories as work progresses

To ensure work can be resumed after session restarts or context switches:

1. Mark tasks as COMPLETED immediately – When a task within a story's implementation plan is finished, mark it as COMPLETED in the sprint backlog (not just in the TodoWrite tool). Change - [ ] to - [X] and add status:

   ***** COMPLETED Task 1: Description
   CLOSED: [2025-11-17 Sun]
   
   - [X] Subtask 1
   - [X] Subtask 2
   

2. Document modified files – Add a "Modified files" section under each completed task listing the files changed and what was done:

   Modified files:
   - =path/to/file.cpp= - Brief description of changes
   - =path/to/other.hpp= - Brief description of changes
   

3. Mark entire stories as COMPLETED – When all tasks in a story are done, change the story status from STARTED to COMPLETED and add a CLOSED timestamp:

   *** COMPLETED Story title                                          :tag:
   CLOSED: [2025-11-17 Sun]
       :LOGBOOK:
       CLOCK: [2025-11-17 Mon 23:40]
       :END:
   

4. Update incrementally – Don't wait until the end of a story to update the sprint backlog. Update it as each task completes so progress is always visible and resumable.
5. Benefits of incremental updates:
   • Session restarts can quickly identify what's done and what remains
   • User can see progress in real-time
   • Multiple sessions can collaborate without duplicating work
   • Work history is preserved for future reference
   • Easier to track actual time spent vs. estimated time

• :code: – Implementation work, programming
• :infra: – Build system, CI/CD, deployment, tooling
• :analysis: – Research, investigation, design
• :agile: – Sprint planning, backlog grooming
• :doc: – Documentation, guides, diagrams

1. Multiple tags allowed – Stories can have several tags
2. Use for reporting – Tags enable time tracking by category
3. Be consistent – Follow established tag patterns
4. Don't over-tag – Use tags that add value for reporting

• Use org-clock-in and org-clock-out to track work
• Time is automatically summed in clock tables
• Helps understand actual vs. estimated effort

Sprint backlogs include two clock tables:

1. Today's summary – Shows work done today
2. Sprint summary – Shows total work for the sprint

These tables auto-update and provide insights into:

• Time per story
• Time per tag (code vs. infra vs. analysis)
• Progress toward sprint goals