Internal Tool Development | Prioritization, Stakeholders
Manage internal tool projects with GitScrum. Balance feature requests, prioritize with scoring models, and communicate roadmaps to stakeholders transparently.
8 min read
Internal tools require special management approaches to balance diverse stakeholder needs, technical debt, and innovation. GitScrum helps coordinate internal tool development with request tracking, prioritization workflows, and stakeholder communication features.
Internal Tools Challenges
Unique Dynamics
INTERNAL TOOL CHARACTERISTICS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ INTERNAL TOOLS VS PRODUCTS: │
│ │
│ Aspect │ Product │ Internal Tool │
│─────────────────────┼─────────────┼──────────────────────│
│ Users │ External │ Colleagues │
│ Feedback │ Indirect │ Very direct (loud) │
│ Prioritization │ Data-driven │ Politics-influenced │
│ Budget │ Revenue-tied│ Cost center │
│ UX Resources │ Dedicated │ Often limited │
│ Scope creep │ Managed │ Constant pressure │
│ Tech debt tolerance │ Lower │ Higher (ship fast) │
│ │
│ COMMON CHALLENGES: │
│ • Every team thinks their request is top priority │
│ • "Can you just add..." requests never stop │
│ • Limited resources for proper design │
│ • Pressure to ship quickly, clean up later (never) │
│ • Unclear ownership between features │
│ • Hard to measure success (no revenue) │
└─────────────────────────────────────────────────────────────┘
Request Management
FEATURE REQUEST PROCESS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ INTAKE FORM: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Feature Request ││
│ │ ││
│ │ Requester: _________ Department: _________ ││
│ │ ││
│ │ What do you need? ││
│ │ [Description of desired functionality] ││
│ │ ││
│ │ Why do you need it? ││
│ │ [Business problem being solved] ││
│ │ ││
│ │ How many people would use this? ││
│ │ [Number of users affected] ││
│ │ ││
│ │ What happens if we don't build it? ││
│ │ [Impact of not doing this] ││
│ │ ││
│ │ When do you need it? ││
│ │ [Timeline and urgency] ││
│ │ ││
│ │ Sponsor: _________ (VP+ approval required) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ WHY THESE QUESTIONS: │
│ • Forces requester to think through need │
│ • Provides prioritization data │
│ • Creates paper trail │
│ • Reduces "just add this quick" requests │
└─────────────────────────────────────────────────────────────┘
Prioritization
Scoring Framework
PRIORITIZATION SCORING:
┌─────────────────────────────────────────────────────────────┐
│ │
│ WEIGHTED SCORING MODEL: │
│ │
│ Factor │ Weight │ Score (1-5) │ Weighted │
│───────────────────────┼────────┼─────────────┼─────────────│
│ Business impact │ 35% │ 4 │ 1.4 │
│ Users affected │ 25% │ 3 │ 0.75 │
│ Strategic alignment │ 20% │ 5 │ 1.0 │
│ Technical effort (inv)│ 15% │ 2 (high) │ 0.3 │
│ Urgency │ 5% │ 3 │ 0.15 │
│───────────────────────┼────────┼─────────────┼─────────────│
│ TOTAL SCORE │ 100% │ │ 3.6 │
│ │
│ PRIORITY BANDS: │
│ • 4.0+ = High (next quarter) │
│ • 3.0-3.9 = Medium (this year) │
│ • 2.0-2.9 = Low (backlog) │
│ • <2.0 = Decline with explanation │
│ │
│ TRANSPARENCY: │
│ Share scoring with requesters so they understand │
│ why their request ranked where it did. │
└─────────────────────────────────────────────────────────────┘
Capacity Planning
CAPACITY ALLOCATION:
┌─────────────────────────────────────────────────────────────┐
│ │
│ QUARTERLY CAPACITY SPLIT: │
│ │
│ [█████████████████████░░░░░░░░░░] 100% │
│ │ │ │ │
│ │ New Features 50% │ Maint. │ Tech │
│ │ │ 25% │ Debt │
│ │ │ │ 25% │
│ │
│ WHY THIS SPLIT: │
│ • New Features (50%): Deliver value to stakeholders │
│ • Maintenance (25%): Keep existing tools running │
│ • Tech Debt (25%): Invest in long-term health │
│ │
│ ADJUSTMENTS: │
│ • Critical production issues take from New Features │
│ • Tech debt can flex down for urgent requests │
│ • Maintenance is non-negotiable baseline │
│ │
│ VISIBILITY: │
│ "We have 50% capacity for new features. │
│ Current queue fills 200% of that capacity. │
│ Something must give - let's prioritize together." │
│ │
│ This makes tradeoffs visible to stakeholders │
└─────────────────────────────────────────────────────────────┘
Stakeholder Management
Communication Cadence
STAKEHOLDER COMMUNICATION:
┌─────────────────────────────────────────────────────────────┐
│ │
│ WEEKLY: Status Update (Async) │
│ • What shipped this week │
│ • What's in progress │
│ • Blockers/risks │
│ Audience: All stakeholders │
│ │
│ MONTHLY: Roadmap Review (30 min meeting) │
│ • Progress on quarterly goals │
│ • Upcoming priorities │
│ • New request intake │
│ Audience: Department leads │
│ │
│ QUARTERLY: Planning Session (2 hours) │
│ • Review capacity │
│ • Prioritize major initiatives │
│ • Set quarterly goals │
│ Audience: VPs + Product Owner │
│ │
│ AD-HOC: Request Updates │
│ • Status change notifications │
│ • Questions/clarifications │
│ Audience: Individual requesters │
│ │
│ KEY PRINCIPLE: │
│ "No surprises" - stakeholders should never be │
│ surprised by priority decisions or delays. │
└─────────────────────────────────────────────────────────────┘
Managing Expectations
SAYING NO GRACEFULLY:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SCENARIO: Request doesn't make priority cut │
│ │
│ ❌ BAD RESPONSE: │
│ "We can't do that right now." │
│ "It's not a priority." │
│ → Feels dismissive, creates frustration │
│ │
│ ✅ GOOD RESPONSE: │
│ "Thanks for the request. Based on our scoring model, │
│ this scored 2.8 out of 5, which places it in the │
│ backlog tier. The main factors were: │
│ │
│ • Lower user count (affects 5 people) │
│ • High technical effort (3 weeks) │
│ • Similar manual workaround exists │
│ │
│ Currently, items scoring 3.5+ are being worked on. │
│ │
│ Options: │
│ 1. It stays in backlog, re-evaluated next quarter │
│ 2. If urgency changes, sponsor can escalate to VP │
│ 3. If scope reduces, score may change │
│ │
│ Want to discuss further?" │
│ │
│ → Transparent, data-driven, offers path forward │
└─────────────────────────────────────────────────────────────┘
Quality & Maintenance
Technical Health
INTERNAL TOOL HEALTH:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TECH DEBT REALITIES: │
│ • Internal tools accumulate debt faster │
│ • "Ship fast, fix later" pressure │
│ • Users tolerate more jank than customers │
│ • Debt eventually slows all development │
│ │
│ HEALTH INDICATORS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Metric │ Current │ Target │ Status ││
│ │─────────────────────┼─────────┼────────┼───────────────││
│ │ Deploy frequency │ Weekly │ Daily │ ⚠️ Slow ││
│ │ Mean time to fix │ 4 hours │ 2 hours│ ⚠️ Slow ││
│ │ Test coverage │ 45% │ 70% │ ⚠️ Low ││
│ │ Dependency age │ 8 months│ 3 months│ ⚠️ Old ││
│ │ Uptime │ 99.5% │ 99.9% │ ⚠️ Low ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MAINTENANCE TASKS: │
│ • Dependency updates (monthly) │
│ • Security patches (immediate) │
│ • Performance monitoring │
│ • Error rate tracking │
│ • Backup verification │
└─────────────────────────────────────────────────────────────┘
User Support
SUPPORT MODEL:
┌─────────────────────────────────────────────────────────────┐
│ │
│ SUPPORT CHANNELS: │
│ │
│ #internal-tools-help (Slack) │
│ • First line for questions │
│ • Team monitors during business hours │
│ • Response time: <2 hours │
│ │
│ Self-Service: │
│ • FAQ documentation │
│ • Common workflows │
│ • Video tutorials │
│ │
│ Bug Reports: │
│ • GitScrum ticket submission │
│ • Triaged within 24 hours │
│ • Critical = same day fix │
│ │
│ SUPPORT TIME BUDGET: │
│ 10% of team capacity reserved for support │
│ • Rotate support duty weekly │
│ • Keeps one person available │
│ • Others can focus on development │
│ │
│ FEEDBACK LOOP: │
│ Common support questions → Improve docs or UX │
│ Track support volume per feature → Identify problem areas │
└─────────────────────────────────────────────────────────────┘