Multiple Projects | Portfolio Views, Prioritization
Manage multiple concurrent projects with portfolio views, resource allocation, and WSJF prioritization. Reduce context switching and burnout.
13 min read
Managing multiple projects simultaneously creates coordination overhead: resources split attention, dependencies cross project boundaries, and context switching destroys productivity. GitScrum's portfolio management features—cross-project views, shared resources, and centralized reporting—help teams maintain focus while balancing competing priorities. The key is establishing clear boundaries, reducing context switches, and making project health visible at a glance.
Multi-Project Challenges
Common Problems
MULTI-PROJECT DYSFUNCTION:
┌─────────────────────────────────────────────────────────────┐
│ WHAT GOES WRONG │
├─────────────────────────────────────────────────────────────┤
│ │
│ RESOURCE FRAGMENTATION: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Developer Alex: ││
│ │ Monday: Project A standup, work on A tasks ││
│ │ Tuesday: Project B urgent fix, A blocked ││
│ │ Wednesday: Project C review, back to A ││
│ │ Thursday: B escalation, C testing ││
│ │ Friday: "Where was I on Project A again?" ││
│ │ ││
│ │ Result: 5 context switches = 60% productivity loss ││
│ │ Nothing gets done well ││
│ │ Burnout in 2-3 months ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PRIORITY CONFUSION: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Project A PM: "This is our highest priority" ││
│ │ Project B PM: "This is our highest priority" ││
│ │ Project C PM: "This is our highest priority" ││
│ │ ││
│ │ Developer: "...so which one do I work on?" ││
│ │ ││
│ │ Result: Developer picks easiest, not most important ││
│ │ Critical deadlines missed ││
│ │ No one owns the trade-off decision ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ HIDDEN DEPENDENCIES: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Project A needs API from Project B ││
│ │ Project B didn't know this ││
│ │ Project A blocks for 2 sprints waiting ││
│ │ ││
│ │ Result: Cascading delays across projects ││
│ │ Last-minute scope cuts ││
│ │ Unhappy stakeholders everywhere ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Context Switching Cost
MEASURING PRODUCTIVITY LOSS:
┌─────────────────────────────────────────────────────────────┐
│ CONTEXT SWITCHING IMPACT │
├─────────────────────────────────────────────────────────────┤
│ │
│ RESEARCH ON TASK SWITCHING: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Projects │ Context Switches │ Time Lost │ Effective ││
│ │ ─────────┼──────────────────┼───────────┼─────────── ││
│ │ 1 │ 0 │ 0% │ 100% ││
│ │ 2 │ 1/day │ 20% │ 80% ││
│ │ 3 │ 3/day │ 40% │ 60% ││
│ │ 4 │ 6/day │ 55% │ 45% ││
│ │ 5+ │ Many │ 75% │ 25% ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ WHY IT'S SO EXPENSIVE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Mental state reload: ~15-25 minutes ││
│ │ "What was I doing? Where's the code? What's blocked?"││
│ │ ││
│ │ 2. Attention residue: Previous task stays in mind ││
│ │ "I wonder if that PR got merged..." ││
│ │ ││
│ │ 3. Cognitive overhead: Keeping multiple contexts ││
│ │ Memory full, errors increase ││
│ │ ││
│ │ 4. Shallow work trap: Never reach deep focus ││
│ │ Complex problems don't get solved ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Resource Allocation Strategies
Dedicated vs Shared Resources
ALLOCATION MODELS:
┌─────────────────────────────────────────────────────────────┐
│ CHOOSING THE RIGHT MODEL │
├─────────────────────────────────────────────────────────────┤
│ │
│ MODEL 1: DEDICATED RESOURCES │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ││
│ │ │ Project A │ │ Project B │ │ Project C │ ││
│ │ │ │ │ │ │ │ ││
│ │ │ 👤 Dev 1 │ │ 👤 Dev 3 │ │ 👤 Dev 5 │ ││
│ │ │ 👤 Dev 2 │ │ 👤 Dev 4 │ │ 👤 Dev 6 │ ││
│ │ └─────────────┘ └─────────────┘ └─────────────┘ ││
│ │ ││
│ │ ✅ Maximum focus, no context switching ││
│ │ ✅ Clear ownership and accountability ││
│ │ ❌ Resource underutilization during slow periods ││
│ │ ❌ Knowledge silos between projects ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MODEL 2: TIME-BOXED ALLOCATION │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Week 1-2: Project A (full team) ││
│ │ Week 3: Project B (full team) ││
│ │ Week 4: Project C (full team) ││
│ │ Repeat... ││
│ │ ││
│ │ ✅ Deep focus for extended periods ││
│ │ ✅ Clear boundaries on when switching happens ││
│ │ ❌ Projects wait weeks for attention ││
│ │ ❌ Urgent issues can't be addressed immediately ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ MODEL 3: PRIMARY + SECONDARY ASSIGNMENT │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 👤 Dev 1: Primary: A (80%), Secondary: B (20%) ││
│ │ 👤 Dev 2: Primary: A (80%), Secondary: C (20%) ││
│ │ 👤 Dev 3: Primary: B (80%), Secondary: A (20%) ││
│ │ ││
│ │ Rules: ││
│ │ • Work on primary 4 days, secondary 1 day ││
│ │ • Secondary work is scheduled, not interrupt-driven ││
│ │ • Cross-training ensures backup coverage ││
│ │ ││
│ │ ✅ Balance between focus and flexibility ││
│ │ ✅ Built-in knowledge sharing ││
│ │ ⚠️ Requires discipline to maintain boundaries ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Capacity Planning
REALISTIC CAPACITY:
┌─────────────────────────────────────────────────────────────┐
│ PLANNING ACROSS PROJECTS │
├─────────────────────────────────────────────────────────────┤
│ │
│ AVAILABLE CAPACITY CALCULATION: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Total hours in sprint: 80 hrs (2 weeks) ││
│ │ ││
│ │ Subtract: ││
│ │ Meetings & ceremonies: -10 hrs ││
│ │ Email, Slack, admin: -8 hrs ││
│ │ Context switch overhead: -8 hrs (if multi-proj) ││
│ │ Unexpected interrupts: -4 hrs ││
│ │ ───────────────────────────── ││
│ │ Available for focused work: 50 hrs ││
│ │ ││
│ │ That's 62% of "full time" actually productive ││
│ │ ││
│ │ If working on 2 projects: ││
│ │ Project A (60%): 30 hours ││
│ │ Project B (40%): 20 hours ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ IN GITSCRUM: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Track time per project using Time Tracking ││
│ │ Compare planned vs actual allocation ││
│ │ Adjust future sprints based on real data ││
│ │ ││
│ │ Time Tracking → Charts → Filter by project ││
│ │ See: Where did time actually go? ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Portfolio Management
Cross-Project Visibility
UNIFIED VIEW IN GITSCRUM:
┌─────────────────────────────────────────────────────────────┐
│ PORTFOLIO DASHBOARD │
├─────────────────────────────────────────────────────────────┤
│ │
│ All Projects Overview: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ PROJECT │ SPRINT │ HEALTH │ TASKS │ BLOCKERS ││
│ │ ─────────────┼─────────┼────────┼───────┼──────────── ││
│ │ Mobile App │ 14/20 │ 🟢 │ 23/32 │ 1 ││
│ │ Web Portal │ 8/15 │ 🟡 │ 12/28 │ 3 ││
│ │ API Platform │ 12/15 │ 🟢 │ 45/52 │ 0 ││
│ │ Data Pipeline│ 3/10 │ 🔴 │ 5/18 │ 5 ││
│ │ ││
│ │ Summary: ││
│ │ • 4 active projects ││
│ │ • 2 healthy, 1 at risk, 1 critical ││
│ │ • 9 total blockers requiring attention ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Filter views: │
│ • All projects │
│ • My assignments only │
│ • Critical/blocked only │
│ • By client/team │
│ │
└─────────────────────────────────────────────────────────────┘
Dependency Tracking
CROSS-PROJECT DEPENDENCIES:
┌─────────────────────────────────────────────────────────────┐
│ VISUALIZING DEPENDENCIES │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ DEPENDENCY MAP: ││
│ │ ││
│ │ Mobile App ────depends on────▶ API Platform ││
│ │ │ │ ││
│ │ │ │ ││
│ │ └───depends on───▶ Auth Service ││
│ │ │ ││
│ │ ▼ ││
│ │ Web Portal ────depends on────▶ Data Pipeline ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ TRACKING IN GITSCRUM: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ For cross-project dependencies: ││
│ │ ││
│ │ Option 1: Link tasks between projects ││
│ │ Task MOBILE-45 "User login flow" ││
│ │ → Blocked by: API-102 "Auth endpoint" ││
│ │ ││
│ │ Option 2: Use Discussions for coordination ││
│ │ Discussion: "API v2 migration impact" ││
│ │ @mobile-team @web-team "When do you need this?" ││
│ │ ││
│ │ Option 3: Create coordination tasks ││
│ │ Task: "[Coord] API v2 rollout sequence" ││
│ │ Checklist: ││
│ │ ☐ API team deploys v2 ││
│ │ ☐ Mobile team updates client ││
│ │ ☐ Web team updates client ││
│ │ ☐ Monitor for issues ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Prioritization Frameworks
Stacking Rank Across Projects
UNIFIED PRIORITY LIST:
┌─────────────────────────────────────────────────────────────┐
│ SINGLE SOURCE OF PRIORITY │
├─────────────────────────────────────────────────────────────┤
│ │
│ PROBLEM: Each PM says their project is highest priority │
│ SOLUTION: Executive-level stack ranking │
│ │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ PORTFOLIO PRIORITY (set by leadership): ││
│ │ ││
│ │ Rank │ Project │ Rationale ││
│ │ ─────┼───────────────┼───────────────────────────────── ││
│ │ 1 │ Mobile App │ Q4 launch commitment to client ││
│ │ 2 │ API Platform │ Enables Mobile + Web ││
│ │ 3 │ Web Portal │ Internal, can slip 2 weeks ││
│ │ 4 │ Data Pipeline │ Nice-to-have optimizations ││
│ │ ││
│ │ RULE: When conflicts arise, higher rank wins ││
│ │ (unless explicitly overridden) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ CONFLICT RESOLUTION: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Scenario: API team has 1 dev available ││
│ │ Mobile needs feature X ││
│ │ Web needs feature Y ││
│ │ ││
│ │ Resolution: Mobile is higher priority → feature X ││
│ │ ││
│ │ No negotiation, no politics, just the ranking. ││
│ │ If Web PM disagrees, escalate to change ranking. ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
WSJF for Cross-Project Prioritization
WEIGHTED SHORTEST JOB FIRST:
┌─────────────────────────────────────────────────────────────┐
│ OBJECTIVE PRIORITIZATION │
├─────────────────────────────────────────────────────────────┤
│ │
│ WSJF = (Business Value + Time Criticality + Risk Reduction) │
│ ────────────────────────────────────────────────────│
│ Job Size │
│ │
│ SCORING (1-10 scale): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ITEM │ Value│ Time │ Risk │ Size│ WSJF ││
│ │ ──────────────────┼──────┼──────┼──────┼─────┼─────── ││
│ │ Mobile: User Auth │ 10 │ 10 │ 5 │ 3 │ 8.3 ││
│ │ Web: Dashboard │ 7 │ 5 │ 3 │ 8 │ 1.9 ││
│ │ API: Rate Limiting│ 5 │ 8 │ 9 │ 2 │ 11.0 ★ ││
│ │ Data: ETL Refactor│ 4 │ 2 │ 2 │ 10 │ 0.8 ││
│ │ ││
│ │ Priority order: API Rate Limiting → Mobile Auth → ││
│ │ Web Dashboard → Data ETL ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ Use WSJF when: │
│ • Multiple high-priority requests competing │
│ • Need objective, defensible prioritization │
│ • Stakeholders disagree on importance │
│ │
└─────────────────────────────────────────────────────────────┘
Team Practices
Reducing Context Switches
PRACTICAL STRATEGIES:
┌─────────────────────────────────────────────────────────────┐
│ MINIMIZING CONTEXT SWITCHING │
├─────────────────────────────────────────────────────────────┤
│ │
│ STRATEGY 1: PROJECT DAYS │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Mon-Wed: Project A work only ││
│ │ Thu-Fri: Project B work only ││
│ │ ││
│ │ NO switching mid-day except emergencies ││
│ │ Define "emergency" criteria clearly ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ STRATEGY 2: BATCH COMMUNICATION │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Project A standup: 9:00 AM ││
│ │ Project A questions: 9:00-9:30 AM only ││
│ │ ││
│ │ Project B standup: 9:30 AM ││
│ │ Project B questions: 9:30-10:00 AM only ││
│ │ ││
│ │ Rest of day: Focus time, async only ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ STRATEGY 3: TASK COMPLETION BEFORE SWITCHING │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Rule: Finish current task before switching projects ││
│ │ ││
│ │ ❌ Don't: Jump to Project B while A task half-done ││
│ │ ✅ Do: Complete A task, then context switch once ││
│ │ ││
│ │ Smaller tasks = easier to complete before switching ││
│ │ Break large tasks into <4 hour chunks ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ STRATEGY 4: PROTECTED FOCUS TIME │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Block 2-3 hour chunks for deep work ││
│ │ No meetings, no Slack, no email ││
│ │ Put in calendar so PMs respect it ││
│ │ ││
│ │ "If it's not an outage, it can wait 3 hours" ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Reporting
Cross-Project Status Updates
UNIFIED REPORTING:
┌─────────────────────────────────────────────────────────────┐
│ PORTFOLIO STATUS REPORT │
├─────────────────────────────────────────────────────────────┤
│ │
│ Weekly portfolio update (to leadership): │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ PORTFOLIO HEALTH: 🟡 At Risk ││
│ │ ││
│ │ PROJECT SUMMARIES: ││
│ │ ││
│ │ 🟢 Mobile App ││
│ │ Sprint 14 complete, on track for Q4 launch ││
│ │ No blockers ││
│ │ ││
│ │ 🟢 API Platform ││
│ │ Rate limiting deployed, auth next ││
│ │ Dependency: Mobile needs auth by Sprint 16 ││
│ │ ││
│ │ 🟡 Web Portal ││
│ │ Behind 1 week, resource constraint ││
│ │ Need: 1 additional frontend dev ││
│ │ ││
│ │ 🔴 Data Pipeline ││
│ │ Blocked on infrastructure decision ││
│ │ Need: Executive decision on cloud provider ││
│ │ ││
│ │ CROSS-PROJECT RISKS: ││
│ │ • Mobile launch depends on API auth (due Sprint 16) ││
│ │ • Web waiting on Data pipeline for analytics ││
│ │ ││
│ │ DECISIONS NEEDED: ││
│ │ 1. Cloud provider for Data Pipeline ││
│ │ 2. Approve Web Portal resource increase ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘