gh-sjnims-requirements-expert-plugins-requirements-expert/skills/requirements-feedback/references/feedback-checklist.md

Requirements Feedback Checklist

Use this checklist to ensure comprehensive feedback collection and incorporation at each level of the requirements hierarchy.

---

Vision-Level Feedback Review

Timing: After creating/updating vision, quarterly reviews

Preparation

• Vision issue is complete and current in GitHub Projects
• Key stakeholders identified and available
• Supporting research/data gathered (market analysis, user research)
• Review meeting scheduled with adequate time (60-90 minutes)

Feedback Questions

Problem Validation:

• Do target users resonate with the problem statement?
• Is the problem significant enough to solve?
• Are there other more pressing problems to address first?

User Validation:

• Are target user descriptions accurate?
• Have we identified all key user types?
• Do we understand their context and constraints?

Solution Validation:

• Does the solution vision make sense to stakeholders?
• Is the value proposition compelling?
• Are there alternative approaches we should consider?

Strategic Alignment:

• Does this align with business goals and strategy?
• Is timing right for this initiative?
• Do we have resources and commitment?

Success Metrics:

• Are success metrics measurable and realistic?
• Do metrics align with business objectives?
• Can we actually track these metrics?

Scope & Boundaries:

• Are boundaries clear and appropriate?
• Is anything missing from scope?
• Is anything included that shouldn't be?

Actions

• Document feedback received (in issue comments)
• Update vision based on validated learnings
• Communicate changes to stakeholders
• Schedule next vision review (quarterly or as needed)

---

Epic-Level Feedback Review

Timing: After identifying epics, before story creation, monthly reviews

Preparation

• All epic issues created in GitHub Projects
• Epics linked to vision as children
• Initial prioritization complete
• Product team and technical leads available

Feedback Questions

Completeness:

• Do these epics collectively deliver the full vision?
• Are there gaps in user journeys?
• Are all target user types covered?
• Do epics address all success metrics?

Scope & Boundaries:

• Is each epic appropriately scoped (not too big/small)?
• Are epic boundaries clear and distinct?
• Is there overlap between epics that should be resolved?

Technical Feasibility:

• Are all epics technically feasible?
• Are there technical risks or unknowns to investigate?
• Are architectural foundations identified?

Dependencies:

• Have all inter-epic dependencies been identified?
• Is sequencing logical given dependencies?
• Are there external dependencies to consider?

Prioritization:

• Does priority order make sense?
• Are "Must Haves" truly essential?
• Are "Won't Haves" clearly documented?

Actions

• Add missing epics discovered during review
• Split or combine epics as needed
• Update epic scope and descriptions
• Adjust priorities based on feedback
• Update dependency mapping
• Document changes in epic issue comments

---

Story-Level Feedback Review

Timing: During backlog refinement, before sprint planning

Preparation

• Stories created for epic being reviewed
• Stories linked to epic as children
• Development team, UX, and QA available
• User research findings available (if applicable)

Feedback Questions

INVEST Criteria:

• Are stories independent enough?
• Are details negotiable (not over-specified)?
• Does each story deliver clear value?
• Can team estimate each story?
• Are stories small enough (1-5 days)?
• Are stories testable with clear acceptance criteria?

Completeness:

• Do stories cover all epic scope?
• Are edge cases and error scenarios covered?
• Are all user types' needs addressed?

Clarity:

• Is the user goal clear in each story?
• Are acceptance criteria specific and testable?
• Are assumptions and constraints documented?

Value:

• Does each story deliver user-facing value?
• Are priorities appropriate?
• Can we explain "why" for each story?

Actions

• Split stories that are too large
• Combine stories that are too granular
• Add missing stories
• Clarify vague acceptance criteria
• Update story descriptions and estimates
• Adjust priorities based on team feedback

---

Task-Level Feedback Review

Timing: During sprint, daily standups, code reviews

Preparation

• Tasks created for story being implemented
• Tasks linked to story as children
• Implementers identified and assigned
• Story acceptance criteria reviewed

Feedback Questions

Clarity:

• Is it clear what needs to be done?
• Are acceptance criteria specific enough?
• Are technical notes helpful?

Completeness:

• Are all necessary tasks identified?
• Are testing tasks included?
• Are documentation tasks included?

Dependencies:

• Is task sequencing correct?
• Have blockers been identified?
• Can tasks be parallelized?

Implementation Feedback:

• Are actual results matching expected outcomes?
• Have we discovered missing tasks?
• Are estimates accurate?
• Have we learned anything that should update the story?

Actions

• Add tasks discovered during implementation
• Update task acceptance criteria if incomplete
• Update story acceptance criteria if tasks reveal gaps
• Document implementation learnings
• Adjust future task breakdown based on learnings

---

Post-Implementation Feedback Review

Timing: After feature launch, ongoing

Preparation

• Feature deployed and available to users
• Analytics/metrics collection in place
• User feedback channels established
• Stakeholders identified for review

Feedback Questions

Value Delivery:

• Are users actually using this feature?
• Is it delivering expected value?
• Are success metrics being achieved?
• What's working well?

Problems & Pain Points:

• What issues are users encountering?
• What's confusing or difficult?
• What's missing that users need?
• What feedback are we getting from support?

Opportunities:

• What enhancements would increase value?
• What related needs have been discovered?
• What should we build next?

Validation:

• Were our assumptions correct?
• What did we get wrong?
• What did we learn?

Actions

• Update requirements based on usage data
• Create new stories for enhancements
• Deprioritize or remove unused features
• Document lessons learned
• Update vision/epics if major insights emerged
• Plan iteration or follow-up work

---

Feedback Collection Methods Checklist

User Research Methods

• User Interviews: One-on-one conversations about needs and experiences
• Surveys: Structured questions to larger user groups
• Usability Testing: Observe users attempting tasks
• Analytics Review: Examine actual usage patterns and behaviors
• Support Ticket Analysis: Identify common issues and requests

Stakeholder Feedback Methods

• Review Meetings: Formal reviews with stakeholders
• Async Reviews: GitHub issue (in a GitHub Project) comments and discussions
• Roadmap Planning: Strategic alignment sessions
• Demos: Show working software for feedback

Team Feedback Methods

• Backlog Refinement: Regular story review with team
• Daily Standups: Quick updates and blockers
• Retrospectives: Reflect on what worked and what didn't
• Code Reviews: Technical feedback during implementation

Automated Feedback Methods

• Usage Analytics: Track feature adoption and usage
• Error Monitoring: Identify bugs and issues
• Performance Metrics: Measure speed and reliability
• A/B Testing: Compare alternatives empirically

---

Feedback Incorporation Workflow

1. Collect

• Gather feedback from various sources
• Document in GitHub issue comments - in GitHub Projects
• Tag relevant people and issues
• Categorize by type and severity

2. Analyze

• Look for patterns across feedback sources
• Validate with data when possible
• Distinguish opinions from facts
• Prioritize based on impact and confidence

3. Decide

• Determine what changes to make
• Assess scope of changes (minor vs major)
• Get buy-in from stakeholders if needed
• Plan communication of changes

4. Update

• Modify GitHub issues (vision/epics/stories/tasks) - issues in GitHub Projects
• Add comments explaining changes
• Update priority, scope, or acceptance criteria
• Link to feedback sources

5. Communicate

• Notify people who provided feedback
• Explain how feedback was used
• Update team on requirement changes
• Thank contributors

6. Validate

• Verify changes address the feedback
• Confirm with feedback providers if possible
• Test new requirements with users if significant
• Monitor impact of changes

7. Document Learnings

• What did we learn?
• How can we improve future requirements?
• What patterns are emerging?
• Update processes based on learnings

---

Red Flags to Watch For

Feedback That Suggests Problems

• Confusion: People don't understand what's being built → Requirements unclear
• Misalignment: Stakeholders disagree on priorities → Need alignment session
• Feasibility Concerns: Team says it's much harder than expected → Scope or approach issue
• Low Engagement: Users don't care about feature → Value hypothesis wrong
• Frequent Changes: Requirements changing constantly → Unstable vision or poor research
• No Feedback: Nobody commenting or engaging → Not enough collaboration

When to Escalate

• Fundamental vision questions (scope, viability)
• Major technical feasibility issues
• Significant stakeholder disagreement
• Resources or timeline at risk
• User feedback contradicts assumptions

---

Feedback Review Cadences

Continuous (Daily/Weekly)

• Task-level feedback during standups
• Code review feedback
• Bug/issue reports

Regular (Weekly/Bi-weekly)

• Story refinement sessions
• Sprint retrospectives
• User testing sessions

Periodic (Monthly)

• Epic priority review
• Roadmap adjustment
• Stakeholder check-ins

Strategic (Quarterly)

• Vision validation
• Success metrics review
• Strategic alignment

---

Template: Feedback Review Meeting

Meeting: [Vision/Epic/Story] Feedback Review Date: [YYYY-MM-DD] Attendees: [Names and roles] Duration: [60-90 minutes]

Agenda:

1. Review Current State (10 min)

   • Present current requirements
   • Highlight recent changes
   • Share context

2. Collect Feedback (30 min)

   • Go through feedback questions for this level
   • Capture all input (no debate yet)
   • Use checklist above

3. Discussion (20 min)

   • Discuss key themes and patterns
   • Validate or invalidate assumptions
   • Identify areas of disagreement

4. Decisions (15 min)

   • Determine what changes to make
   • Assign action items
   • Set next review date

5. Wrap-up (5 min)

   • Summarize decisions
   • Confirm action items and owners
   • Thank participants

Follow-up:

• Update GitHub issues within 48 hours - in GitHub Projects
• Communicate changes to broader team
• Schedule next review

---

Use this checklist to establish regular, effective feedback loops that keep your requirements aligned with user needs and stakeholder goals throughout the product lifecycle.