Initial commit
This commit is contained in:
Zhongwei Li
422
skills/requirements-feedback/references/feedback-checklist.md
Normal file
422
skills/requirements-feedback/references/feedback-checklist.md
Normal file
@@ -0,0 +1,422 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user