The Scrum Master market has tightened considerably. A wave of hiring during large agile transformations was followed by a wave of consolidation, and many organisations that once ran one Scrum Master per team now expect the role to be combined with delivery management, product ownership or engineering management. The practical effect is that CVs which describe the role as running ceremonies compete poorly, because ceremony facilitation is precisely the part organisations decided they could absorb.
What is still hired, and hired well, is someone who demonstrably makes teams deliver better. The CV has to show that.
The fault: describing the framework instead of the results
The typical Scrum Master CV reads as a description of Scrum. "Facilitated daily stand-ups, sprint planning, sprint reviews and retrospectives." "Maintained the sprint backlog." "Removed impediments." "Shielded the team from external distractions."
Everyone with the title did all of these. They are the job description, not the contribution. A reviewer reading twenty such CVs cannot distinguish between them, and picks on certification and industry instead, which is not a competition you want to be in.
The alternative is to write about what changed on the teams you worked with.
Metrics that hold up
Agile metrics are easy to game and experienced hiring managers know which ones are hollow.
Velocity increases are the weakest claim available. "Increased team velocity by 40%" invites the obvious response that story points are relative and locally defined, and inflating them requires no improvement at all. Avoid it, or explain the measurement carefully.
What actually lands:
- Cycle time and lead time. Time from work started to delivered, or from request to delivered. Objective, comparable, and directly meaningful to a business. "Reduced median cycle time from 11 days to 4 by breaking down stories and capping work in progress."
- Predictability. The proportion of sprint commitments met, or forecast accuracy. Often more valuable to stakeholders than raw speed, and rarely claimed.
- Quality. Escaped defects, production incidents, change failure rate, rework percentage. A team that got faster and buggier did not improve.
- Deployment frequency and change lead time. Where you influenced them, they are strong evidence because they are hard to fake.
- Flow. Work in progress reduced, blocked time reduced, queue length.
- Team health, with the instrument named: retrospective sentiment, team health checks, attrition on the team.
Bullet rewrites
Weak: "Facilitated all Scrum ceremonies for a team of eight."
Better: "Ran delivery for an eight-person platform team; introduced explicit WIP limits and story slicing that took median cycle time from 11 days to 4 over two quarters, with sprint commitment accuracy rising from around 60% to over 85%."
Weak: "Removed impediments and shielded the team from distractions."
Better: "Identified that roughly a third of sprint capacity was going to unplanned support work; negotiated a rotating support role with the product owner so the remaining capacity became forecastable, which ended three consecutive quarters of missed commitments."
Weak: "Coached the team on agile best practices."
Better: "Coached two teams through the shift from six-week releases to weekly; ran the first eight releases as mob sessions until the team was confident, then handed the process over entirely."
The pattern in every rewrite is the same: name the specific problem, name the specific intervention, name what changed. The intervention is the part that shows judgment, and it is the part generic CVs omit.
Be honest about scope and context
Reviewers want to know what you were actually operating in, and it varies enormously:
- How many teams, and how many people
- Whether teams were co-located, distributed, or across time zones
- Framework in practice (Scrum, Kanban, Scrumban, SAFe, LeSS), and honestly, since "we called it Scrum and ran two-week waterfalls" is a real and common situation you can describe as a starting point you improved
- Organisational maturity when you arrived and when you left
- Whether the role also carried delivery management, release management, RTE or product responsibilities
- Technical context: the domain, and whether you could engage with the engineering substance
That last one is increasingly a differentiator. Scrum Masters who understand the technical work well enough to have useful conversations about architecture, testing strategy and technical debt are markedly more valuable than those who can only manage process, and this is worth evidencing.
Certifications: necessary, not sufficient
CSM, PSM I–III, SAFe SA or SPC, ICAgile, PMI-ACP. List them with the awarding body and year, near the top.
They are frequently a hard filter, so having the relevant one matters. But they no longer distinguish candidates, because most applicants hold at least one: a two-day CSM course and a passed exam is a low bar and everyone knows it. PSM II and III carry more weight because they are harder. Treat certification as the entry ticket and let the outcomes section do the actual persuading.
Position for how the role is being hired now
Given the consolidation described above, it is worth being explicit about the adjacent capability you bring. Delivery management, release coordination, programme-level work, product ownership experience, people management, or engineering background all widen the set of roles your CV fits, and many current postings are looking for exactly that combination.
If you have it, put it in the summary line rather than leaving it to be discovered in the third bullet of your second role.
Format
One page under about ten years, two beyond it. Single column, standard headings, contact details in the body of the page rather than a document header, consistent month-and-year dates. Certifications high on the page, outcomes in the experience section, and the framework vocabulary present but not doing the heavy lifting.
You can check how yours parses and scores with the free ATS checker.
