The daily standup has a blind spot: it captures what individuals say they're working on, but not the actual pattern of work across the team.
Developer A says "I'm working on the payment feature." Developer B says the same. Sounds like the team is focused.
But what if Developer A spent 2 hours on payments, got pulled into a bug fix, did a code review for another team, answered Slack questions, and then briefly touched payments again? That's not focus—that's fragmentation.
Heatmaps make these patterns visible.
What Scattered Work Looks Like
Open Velocinator's Work Activity view for a team. The heatmap shows each developer's activity across repositories and issues over time.
The Focused Pattern
A developer working with focus shows:
- Sustained activity on one or two repositories
- Commits clustered together (not scattered across the day)
- PR activity aligned with commit activity
- One primary issue/ticket receiving most attention
This is what good looks like. Deep work. Maker schedule.
The Scattered Pattern
A developer struggling with fragmentation shows:
- Activity jumping between 5+ repositories in a single day
- Long gaps between commits (context switching overhead)
- PR reviews interspersed randomly through coding work
- Multiple tickets touched, none receiving sustained attention
This developer isn't lazy—they're overloaded. Every context switch costs 15-30 minutes of ramp-up time. With 8 switches per day, they might lose 2-4 hours to transition overhead alone.
Common Causes of Scattered Work
Too Many Projects
When a developer is assigned to three initiatives simultaneously, they can't give any of them sustained attention. The math doesn't work:
- 3 projects × 2 hours "minimum viable context" = 6 hours
- Actual focused work: 2 hours
- Context switch overhead: 1.5 hours
Net result: each project gets 40 minutes of productive work per day.
Support Rotation Without Protection
The developer is officially working on Feature X, but they're also answering questions about System Y (because they built it) and triaging bugs in System Z (because they're on "support rotation").
Each interruption fragments the primary work.
"Quick Questions" Culture
Slack messages, shoulder taps, "do you have 5 minutes?" None of these take 5 minutes when you account for the context switch cost.
A developer who answers 10 "quick questions" per day loses 2-4 hours of productivity to the interruptions, even if each answer only took 3 minutes.
Review Thrash
PRs need review. Reviewers are asked to respond quickly. But every time a developer stops coding to review, they lose focus on their own work.
If review requests come randomly throughout the day, the developer never gets a sustained block for deep work.
Using Heatmaps for Diagnosis
Team-Level View
Look at the whole team's activity pattern for the past sprint:
Healthy signals:
- Each developer has one or two primary activity areas
- Activity is clustered in sustained blocks
- Work aligns with sprint commitments
Warning signals:
- Everyone's activity is spread across many areas
- Patterns show constant switching
- No clear alignment between people and priorities
Individual Conversations
When you see a scattered pattern for a specific developer, have a conversation:
"I noticed your activity was spread across six different areas this week. Is that intentional? Are you getting pulled in too many directions?"
The heatmap starts the conversation. The developer's context completes it. Maybe they were covering for someone on PTO. Maybe they're being asked to do too much. Maybe they need help saying no.
Spotting Organizational Issues
If everyone's heatmaps are scattered, the problem is systemic:
- Too many parallel priorities
- Understaffing for the work committed
- Poor protection of maker time
- Cultural acceptance of interruption
One scattered developer is a coaching opportunity. All scattered developers is a management problem.
The Swarming Alternative
The opposite of scattered work is swarming: the entire team focusing on one priority until it's done.
When a team swarms, heatmaps show:
- Multiple developers active in the same repository
- Overlapping timeframes (pair programming shows as synchronized activity)
- Quick PR cycles (reviews happen immediately because everyone's in context)
- Rapid progress on the target initiative
Swarming feels inefficient ("why have 4 people on one thing when they could each work on different things?"), but it often delivers faster:
- Faster decisions (everyone's in context)
- Faster reviews (reviewers understand the work)
- Fewer bugs (more eyes, more knowledge sharing)
- Lower coordination overhead
Implementing Focus
WIP Limits
Set explicit limits on work in progress:
- Per developer: "No one works on more than 2 initiatives"
- Per team: "We focus on 3 priorities per sprint, max"
When something new comes in, something current has to pause.
Dedicated Support Role
Instead of everyone being partially on support, assign one person per sprint as the "shield." They handle all support requests, questions, and interruptions. Everyone else gets protected maker time.
Rotate the role so no one burns out.
Batched Review Time
Instead of reviewing whenever requests come in, establish review blocks:
- 9-10 AM: Morning review session
- 2-3 PM: Afternoon review session
Outside those windows, developers can focus without review obligations.
Async Communication Default
"Quick questions" should be Slack messages that the recipient answers when they have a natural break—not interruptions that demand immediate attention.
Model this from leadership. If the manager asks questions and expects immediate replies, the team will too.
Measuring Improvement
Track heatmap patterns over time:
Focus Score: What percentage of each developer's activity is concentrated on their primary project?
- Below 50%: Highly scattered
- 50-70%: Moderately focused
- Above 70%: Well focused
Repository Spread: How many repositories does each developer touch per week?
- 1-3: Focused
- 4-6: Starting to scatter
- 7+: Fragmented
Commit Clustering: Are commits clustered together (focused sessions) or spread throughout the day (interrupted work)?
As you implement focus improvements, these metrics should improve.
The Standup Upgrade
Instead of going around the room with status updates, use the heatmap:
"Looking at this week's activity, I see we're spread across 8 different initiatives as a team. Let's discuss: are these all equally important, or should we swarm on our top 3?"
The visual makes the conversation concrete. It's not about feeling busy—it's about whether the activity pattern matches the priorities.
Your team's heatmap tells a story. Make sure it's the story you want.
