The velocity trap

When three juniors perform less than one senior

‘We need more developers to meet our deadline!’ This sentence comes up regularly in planning meetings. The seemingly simple solution is to hire three juniors instead of one expensive senior. On paper, the calculation seems convincing: three juniors often cost only slightly more than one senior and theoretically contribute three times as many working hours.

But this logic is deceptive. Practical experience shows that juniors only achieve about 60 per cent of the productivity of a senior and that the hidden costs of coordination, mentoring and quality quickly exceed the supposed savings. The result is overworked teams, delayed projects and frustrated stakeholders. The real problem lies in simplified velocity mathematics. It only considers capacities superficially, without taking into account the complex dependencies of modern software development.

The problem: Simplified velocity mathematics leads to costly misjudgements

Two factors are at the heart of many planning errors: the deceptive simplicity of story points and an often overlooked loss of productivity.

Story points are a common measure of effort and productivity in agile teams. But they are anything but objective. A senior developer might rate a task at two story points, while a junior developer might rate the same task at five points. This difference is no coincidence, but rather a reflection of fundamental differences in experience, routine and problem-solving skills. Those who view story points as a purely mathematical quantity ignore these differences and create false expectations of team performance.

The hidden loss of productivity has an even more serious impact. Studies show that 55 per cent of teams invest between five and fifteen hours per week per developer in unproductive work. [1] Juniors are particularly affected by this: they need significantly more time for code reviews, get lost in technical dead ends more often, spend longer cycles debugging and need additional support in architectural decisions. What looks like full capacity on paper shrinks considerably in reality.

A look at the actual velocity figures confirms this picture. Juniors with up to two years of experience achieve only around 60 per cent of the productivity of a senior on standard tasks and fall back to as little as 30 to 40 per cent on complex architecture issues. Mid-level developers with three to five years of experience are at around 80 per cent, can solve most tasks independently and thus relieve the seniors. Only senior developers themselves form the basis with full productivity, make sound architectural decisions and act as multipliers for the entire team.

Practical example: The start-up that almost fell into the velocity trap

TechFlow GmbH, a young FinTech start-up, was facing a crucial project deadline. At first glance, the solution seemed simple: instead of hiring another senior developer for £75,000, they decided to hire three juniors for £40,000 each.

On paper, this decision promised 120 developer hours per week instead of 40, representing an additional capacity increase of 200 per cent.

The reality after six months painted a different picture.

Planned vs. actual velocity

• Planned: 45 story points per sprint (3 juniors at 15 points each)
• Actual: 22 story points per sprint
• Comparison: A senior developer would have achieved an estimated 28 to 32 story points.

Hidden costs

• Mentoring overhead: The existing senior developer spent 40 per cent of his time on code reviews and architecture issues.
• Quality issues: 35 per cent more bugs in production
• Rework cycles: An average of 2.3 iterations per feature instead of 1.2
• Communication effort: Daily stand-ups took 50 per cent longer

After six months, TechFlow pulled the emergency brake. Two juniors left the team and another senior was hired to replace them. The effect was evident after just three sprints: velocity increased by 68 per cent, the bug rate fell by 45 per cent and time to market was reduced by three weeks. The assumption that three juniors would be more productive than one senior turned out to be a misconception that could only be corrected through a strategic realignment.

The real costs of velocity mathematics: A calculation example

At first glance, three juniors seem like a better deal than one senior. But only a realistic calculation shows how strongly productivity is actually influenced by experience, coordination and quality.

Scenario A: Three juniors

• Base productivity: 3 × 15 story points × 0.6 = 27 points
• Mentoring overhead: –6 points (20% reduction)
• Coordination losses: –4 points (15% reduction)
• Rework cycles: –5 points (additional iterations)

= Net velocity: 12 points per sprint

Hidden costs per year

• Delayed market launch: approx. £200,000
• Additional QA cycles: approx. £35,000
• Increased infrastructure costs: approx. £15,000

= Total hidden costs: approx. £250,000

Scenario B: A senior

• Base productivity: 30 points
• Architecture bonus: +3 points (better technical decisions)
• Less rework: +2 points (higher initial quality)

= Net velocity: 35 points per sprint

Real ROI comparison

• Three juniors: £135,000 + £250,000 hidden costs = £385,000 for 12 points per sprint
• One senior: £85,000 for 35 points per sprint

Cost per story point

• Junior team: £32,083
• Senior: £2,429

The result is clear: three juniors not only deliver less, but also cost many times more in total.

Implementing the right velocity mathematics

How can project managers and CTOs avoid falling into the velocity trap? The key is to assess capacities realistically and design the team composition strategically. A five-step approach is recommended here:

1. Introduce realistic productivity factors

Not every developer works at the same speed or to the same standard. Correction factors should therefore be taken into account in capacity planning.

Developer level multipliers:

• Junior (0–2 years): 0.6 × planned capacity
• Mid-level (3–5 years): 0.8 × planned capacity
• Senior (5+ years): 1.0 × planned capacity
• Lead (8+ years): 1.2 × planned capacity (team multiplier)

Coordination overhead by team size:

• 2–3 people: –5% velocity loss
• 4–6 people: –10%
• 7–9 people: –20%
• 10+ people: –35%

2. Calculate the optimal team composition

A balanced mix is more effective than a one-sided team. The so-called ‘pizza team’ formula recommends a ratio of 1 senior : 2 mid-level : 1 junior.

Sample calculation:

• 1 senior × 1.0 = 30 points
• 2 mid-level × 0.8 = 48 points
• 1 junior × 0.6 = 15 points
• Mentoring bonus: +10% (senior provides effective support)

= 102 points gross, minus 5% coordination effort = 97 points net

3. Introduce quality-weighted velocity

Traditional velocity ignores differences in quality. A weighted metric takes bug rate and rework rate into account:

Formula:

Weighted velocity = story points × (1 – bug rate/100) × (1 – rework rate/100)

Sample calculation:

• Junior team: 45 points × (1 – 0.35) × (1 – 0.40) = 17.5 weighted points
• Senior team: 30 points × (1 – 0.12) × (1 – 0.15) = 22.4 weighted points

4. Develop a long-term growth strategy

A team is not a static entity, but grows with its members. That is why it is worthwhile to pursue a clear development strategy from the outset. In the first phase (‘Foundation’), the focus is on building a strong senior core, defining standards and architecture, and mentoring programmes. In the second phase (‘Scaling’), mid-level developers are specifically added, while juniors are carefully trained in niche areas and continuous training is established. In the third phase (‘Optimisation’), juniors develop into mid-level developers, seniors increasingly take on lead roles, and the multiplier effects in the team are fully exploited. In this way, sustainable growth in competence and productivity is achieved step by step.

5. Implement measurement and monitoring systems

Planning and team building alone are not enough; without transparent measurement, actual progress remains unclear. A set of meaningful metrics provides clarity. These include

• an adjusted velocity that takes quality factors into account,
• cycle time as a measure of the lead time from development to release,
• the defect escape rate as an indicator of errors that make it into production,
• and the mentoring coefficient, which shows the proportion of senior time spent on team support.
• In addition, it is also worth recording the technical debt velocity, i.e. the capacity planned for reducing technical debt.

Those who collect these key figures regularly and make them transparent within the team can recognise bottlenecks at an early stage and take targeted countermeasures.

Conclusion: Velocity excellence through intelligent team composition

The calculations clearly show that the supposedly simple equation ‘more heads = more productivity’ does not add up. Three juniors cannot achieve what one senior can in the same amount of time. In practice, the ratio is closer to 0.4 to 1. Added to this are hidden costs for mentoring, coordination and rework, which quickly exceed the supposed savings many times over.

Sustainable productivity can only be achieved through intelligent team composition. Mixed teams with a balanced ratio of senior, mid-level and junior developers achieve higher net velocity, better quality and thus significantly higher added value. Quality multiplies speed because less rework and fewer bugs stabilise and accelerate development.

Tip: Analyse the composition of your teams using the formulas and metrics presented. Calculate the actual cost per story point and identify where there is potential for improvement. Investing in the right balance between senior expertise and junior talent not only pays off in higher velocity, but also lays the foundation for long-term growth.

Notes (partly in German):

[1] See, for example, appinio: Productivity in the workplace or manage it: The more academics, the less productive? or Personalwirtschaft: Wasting time at work

Would you like to know how productive your current setup is? Merlin Mechler will work with you to analyse your team composition and calculate where productivity can be increased and costs reduced. The service is free, practical and delivers clear results. This gives you a sound basis for decision-making for your next projects. Here you can make an appointment.

Here you can find more information about story points.

And here you can find more information about velocity and developer velocity.

What do you think of the approach presented? Feel free to share the article in your network and discuss it.