The Director Wants Per-Person Velocity

This is not a velocity problem; it is a shared-responsibility problem that velocity is masking. Flat velocity plus rising escaped defects plus two people doing the design is the signature of knowledge concentration: the team is fast at writing code and slow at learning, and the defect trend is the interest payment.

The retrospective actions were 'marked done but nothing changed', which is the strongest signal here. The likely cause is not laziness - it is that pairing and rotating reviews would slow the two seniors down and put the 30-34 point streak at risk, so under delivery pressure the team reverts. An agreement that competes with the number the team is measured on will always lose.

First interventions:

• Talk to individuals privately before changing anything in the room; the juniors' silence needs a safe channel.
• Reframe the goal publicly: make defects and review turnaround visible alongside velocity, so the team sees the trade it is making.
• Run one small, time-boxed experiment rather than a policy: e.g. every story touched by at least two people for three sprints, measured by review participation and escaped defects.
• Reserve capacity for it explicitly in the sprint so it is not the first thing sacrificed.

The Scrum Master does not diagnose in a blame session, does not mandate pairing as a rule, and does not treat the two seniors as the problem - they are carrying a system that rewards them for it.

Decline, explain the mechanism, and offer a substitute.

Story points are a relative, team-calibrated estimate of size, not a measure of output. Attributing them to individuals breaks the estimating basis in three ways: points are not comparable across people; whoever splits stories smallest accumulates the most points; and the moment points are used for ranking, the team's incentive is to inflate estimates and avoid sharing work - precisely the behaviour already showing up here.

So the answer is not a flat refusal. Bring alternatives:

• Team-level trends the director can legitimately use: throughput, cycle time, escaped defect rate, review turnaround, predictability against forecast.
• Individual development signals that actually measure what he wants: a skills matrix, peer feedback, contribution to reviews and pairing, and 360 input - not apportioned estimates.
• The consequence, stated plainly: a ranking built on points will make the knowledge concentration worse, because the two seniors will rationally stop investing in the juniors.

The Scrum Master's job here is to protect the team's ability to estimate honestly, and to coach upward rather than simply comply. If the director insists on individual metrics for HR purposes, that is a management decision to escalate to the agile coach or delivery leadership - not something the Scrum Master implements quietly at team level.

Reduce the number of actions and attach evidence to each one.

The retrospective is generating intentions, not experiments. Three changes:

1. Start with the previous actions. Spend the first ten minutes of every retrospective on what was agreed, what happened, and what got in the way. Unfinished actions are data about the system, not a failure to be skipped past.
2. One or two experiments, not a list. Each carries an owner, a date, and an explicit 'how will we know it worked' - for this team, something like 'escaped defects below 6 per sprint' or 'review turnaround under one day'. A statement like 'pair on every story' with no measure is why the board said done while nothing changed.
3. The Scrum Master stops owning the actions. Writing and chasing them is exactly what removes team ownership. The Scrum Master owns the follow-up ritual; the team owns the actions.

Make the improvement work visible on the same board as the sprint work, and cap it at two items in flight. Twenty-seven open actions is a work-in-progress problem dressed up as continuous improvement.