8 min read • Guide 713 of 877
Managing Feature Requests from Multiple Stakeholders
Multiple stakeholders with competing priorities is normal - chaos doesn't have to be. GitScrum helps manage feature requests with intake forms, scoring systems, and transparent roadmaps that align stakeholders around shared priorities.
Request Management Challenges
Common Problems
STAKEHOLDER REQUEST CHAOS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SYMPTOMS: │
│ • Every stakeholder thinks their request is top priority │
│ • Requests come through multiple channels │
│ • No clear criteria for what gets built │
│ • "Squeaky wheel" gets prioritized │
│ • Constant scope changes │
│ • Team frustrated by shifting priorities │
│ • Stakeholders frustrated by lack of progress │
│ │
│ ROOT CAUSES: │
│ • No formal intake process │
│ • Unclear prioritization criteria │
│ • Lack of visibility into constraints │
│ • No shared understanding of capacity │
│ • Political pressure overriding process │
│ │
│ IMPACT: │
│ • Team works on wrong things │
│ • Business value not maximized │
│ • Relationships strained │
│ • Productivity lost to context switching │
│ │
│ SOLUTION: Transparent, consistent process │
│ that treats all stakeholders fairly │
└─────────────────────────────────────────────────────────────┘
Intake Process
Request Form
FEATURE REQUEST INTAKE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ FEATURE REQUEST FORM │
│ │
│ Requester: ___________ Department: ___________ │
│ Date: ___________ Priority requested: ___________ │
│ │
│ 1. WHAT DO YOU NEED? │
│ [Brief description of desired feature] │
│ ________________________________________________ │
│ │
│ 2. WHY DO YOU NEED IT? │
│ [Business problem being solved] │
│ ________________________________________________ │
│ │
│ 3. WHO BENEFITS? │
│ [Number of users/customers affected] │
│ ________________________________________________ │
│ │
│ 4. WHAT HAPPENS WITHOUT IT? │
│ [Impact of not doing this] │
│ ________________________________________________ │
│ │
│ 5. HOW URGENT IS IT? │
│ ☐ Critical (business impact now) │
│ ☐ High (needed this quarter) │
│ ☐ Medium (would be helpful) │
│ ☐ Low (nice to have) │
│ │
│ 6. ARE THERE ALTERNATIVES? │
│ [Workarounds currently being used] │
│ ________________________________________________ │
│ │
│ 7. HOW WILL WE MEASURE SUCCESS? │
│ [Metrics that would improve] │
│ ________________________________________________ │
│ │
│ [Submit Request] │
└─────────────────────────────────────────────────────────────┘
Single Channel
REQUEST CHANNEL DISCIPLINE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ❌ BEFORE: Requests Come From Everywhere │
│ │
│ • Email to individual developers │
│ • Slack messages │
│ • Hallway conversations │
│ • Meeting side-notes │
│ • "Can you just..." │
│ │
│ RESULT: Things get lost, unfair prioritization │
│ │
│ ───────────────────────────────────────────────── │
│ │
│ ✅ AFTER: Single Intake Channel │
│ │
│ All requests → Feature Request Form → GitScrum Backlog │
│ │
│ RESPONSES TO OFF-CHANNEL REQUESTS: │
│ │
│ "Great idea! Please submit it through the feature │
│ request form so it can be properly evaluated and │
│ prioritized alongside other requests." │
│ │
│ "I hear you - to make sure this doesn't get lost, │
│ can you add it to the request backlog?" │
│ │
│ BENEFIT: Everything tracked, nothing lost, │
│ fair evaluation for all requests │
└─────────────────────────────────────────────────────────────┘
Prioritization
Scoring System
WEIGHTED SCORING MODEL:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SCORING CRITERIA: │
│ │
│ Business Impact (35%): │
│ 5 = Major revenue/cost impact │
│ 4 = Significant business improvement │
│ 3 = Moderate improvement │
│ 2 = Minor improvement │
│ 1 = Minimal impact │
│ │
│ Users Affected (25%): │
│ 5 = All users/customers │
│ 4 = Majority of users │
│ 3 = Many users │
│ 2 = Some users │
│ 1 = Few users │
│ │
│ Strategic Alignment (20%): │
│ 5 = Core to company strategy │
│ 4 = Supports key initiative │
│ 3 = Aligned with goals │
│ 2 = Loosely related │
│ 1 = Not aligned │
│ │
│ Effort (inverse) (15%): │
│ 5 = Very small (days) │
│ 4 = Small (week) │
│ 3 = Medium (2-4 weeks) │
│ 2 = Large (1-2 months) │
│ 1 = Very large (quarter+) │
│ │
│ Urgency (5%): │
│ 5 = Critical deadline │
│ 3 = Important timeline │
│ 1 = No specific deadline │
└─────────────────────────────────────────────────────────────┘
Priority Meeting
PRIORITIZATION SESSION:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CADENCE: Monthly (or as needed) │
│ DURATION: 60-90 minutes │
│ ATTENDEES: Product, key stakeholders, tech lead │
│ │
│ AGENDA: │
│ │
│ 1. CAPACITY REVIEW (10 min) │
│ • Available capacity next period │
│ • Commitments already made │
│ • Realistic throughput │
│ │
│ 2. REQUEST REVIEW (40 min) │
│ • Walk through new requests │
│ • Requester presents (briefly) │
│ • Score each criterion │
│ • Calculate total score │
│ │
│ 3. STACK RANK (20 min) │
│ • Sort by score │
│ • Discuss any adjustments │
│ • Draw "the line" based on capacity │
│ │
│ 4. COMMITMENTS (10 min) │
│ • Items above line = committed │
│ • Items below line = acknowledged, not now │
│ • Communicate decisions │
│ │
│ GROUND RULES: │
│ • Scores are debatable, process is not │
│ • No HiPPO (Highest Paid Person's Opinion) │
│ • Capacity is a constraint, not a negotiation │
└─────────────────────────────────────────────────────────────┘
Communication
Saying No
DECLINING REQUESTS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ❌ BAD WAY: │
│ "We can't do that." │
│ "It's not a priority." │
│ "Maybe later." │
│ │
│ ✅ GOOD WAY: │
│ │
│ "Thank you for submitting the [Feature] request. │
│ │
│ After evaluation, it scored 2.6 out of 5, which places │
│ it in our backlog tier. Here's the breakdown: │
│ │
│ Business Impact: 3/5 - Moderate improvement │
│ Users Affected: 2/5 - Affects ~50 users │
│ Strategic Alignment: 3/5 - Supports goals │
│ Effort: 2/5 - Large (6+ weeks) │
│ Urgency: 2/5 - No hard deadline │
│ │
│ Currently, items scoring 3.5+ are being prioritized. │
│ │
│ Options: │
│ 1. Stays in backlog, re-evaluated next quarter │
│ 2. If urgency changes, we can re-score │
│ 3. If scope reduces, score might improve │
│ 4. VP escalation available if business-critical │
│ │
│ Happy to discuss further." │
│ │
│ WHY THIS WORKS: │
│ • Transparent criteria │
│ • Not personal │
│ • Path forward exists │
└─────────────────────────────────────────────────────────────┘
Roadmap Visibility
STAKEHOLDER ROADMAP:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PUBLIC ROADMAP (Updated Monthly) │
│ │
│ Q1 2024: COMMITTED │
│ ──────────────────── │
│ ✅ Checkout Redesign (Retail) [In Progress] │
│ ✅ API v2 Launch (Platform) [Planned Feb] │
│ ✅ Mobile App Improvements (Product) [Planned Mar] │
│ │
│ Q2 2024: PLANNED │
│ ──────────────────── │
│ ◯ Dashboard Analytics (Sales) │
│ ◯ SSO Integration (IT) │
│ ◯ Bulk Import Feature (Ops) │
│ │
│ BACKLOG: EVALUATING │
│ ──────────────────── │
│ ◯ Dark Mode (Community) Score: 2.8 │
│ ◯ Custom Fields (Sales) Score: 2.5 │
│ ◯ Email Templates (Marketing) Score: 2.3 │
│ │
│ VIEW YOUR REQUESTS: │
│ [Filter by department: ____] │
│ │
│ SUBMIT NEW REQUEST: │
│ [Feature Request Form] │
│ │
│ BENEFIT: Stakeholders can self-serve status updates │
└─────────────────────────────────────────────────────────────┘