Every career has juniors, intermediates, seniors, gurus, and whatnot. I'm looking for what separates the different levels so I know how to structure a career path within a company.

Ideally I'd like to have definitions that distinguishes between different levels applied to Scrum Master and Agile Coach roles as guidance. This short answer to a currently-closed question "What's the difference between Entry Level/Jr/Sr developers?" explains the differences as:

Entry Level - must give them explicit instructions, check everything they do, little or no design responsibility, no analysis responsibility

Junior - less explicit instructions, less checking, some minor design and analysis responsibility; helps the entry-level people find the compiler and use the repository

Senior - major design and analysis responsibility, is expected to correct oversights on his/her own, little/no checking, little/no instructions; helps the junior-level people learn/improve analysis and design skills

The currently-accepted answer on Software Engineering Stack Exchange is much longer, but makes similar distinctions.

  • 1
    The training and certification of scrum masters is such that all they bring to the table is process knowledge, unless they acquired coaching skills by a different path. Unfortunately, as a result of the training's focus on processes, many scrum masters remain stuck. Only the ones with an agile mindset of their own will seek to improve their coaching skills. It is those coaching skills, that separates the juniors from the mediors and seniors. So maybe you could look for "career levels" for coaches to help you out. Especially as even the scrum guide doesn't distinguish levels of scrum mastery. Commented Nov 8, 2016 at 11:34
  • That is an interesting insight. So far, in my mind I never distinguished between scrum masters' process knowledge and coaching functions, but I will definitely look into it and keep it in mind.
    – CMW
    Commented Nov 8, 2016 at 11:51
  • Personally, I think it is one of the main reasons for so many agile transitions not delivering what Agile promises. There are more reasons of course, but the total lack of attention for coaching skills in the training of people expected to coach the development team and the organization in their Scrum adoption (see scrum guide's scrum master description), certainly doesn't help. Recently published an article on it. Commented Nov 8, 2016 at 11:57
  • Second the coaching aspect. I would also add that it can have to do with business involvement. I junior scrum master is only focusing on his team. A more senior scrum master also coaches the business as a whole.
    – Majaii
    Commented Nov 8, 2016 at 15:38

5 Answers 5


I think the different levels can relate to the Agile Onion as described by Simon Powers.

enter image description here

Entry level: Can implement the tools and processes, but doesn't have a good understanding why the processes, practises, principles and values exist. Could lead to cargo-cult Agile.

Intermediate: Can work on a team level, but does not yet have the experience to change organizations. Understands principles and values, but might not yet be the best to teach other Scrum Masters. But should coach teams on Agile practices like technical excellence.

Senior: Assists management to create structural and cultural changes in the organisation to become more Agile. Leads the path through Agile Fluency.

Guru: Leads (larger) successful Agile transformations, writes books, etc..

  • +1 This is what I was alluding to with "It is those coaching skills, that separates the juniors from the mediors and seniors." in my comment to the question. Like how you gave the various (coaching) levels explicit skills and scope. Commented Nov 9, 2016 at 8:51
  • Lysa Adkins describes a growth path for Agile coaches in her book coachingagileteams.com , but I am not sure that a Senior Agile coach and a Senior Scrum Master are the same. Commented Nov 9, 2016 at 9:00
  • Personally, I think that the way you describe senior scrum masters may effectively be a junior agile coach level? (Haven't read the growth path yet). Maybe the levels you describe here have more to do with Agile Coaches? Scrum master being the entry level job, with intermediate level the start of the Agile Coach levels? From all the job postings I have seen, scrum master does seem the way in to Agile Coaching. Also think that Agile Coaching distinguishes itself from process change management (business redesign) mainly in coaching/people skills level of experience with "higher" management? Commented Nov 9, 2016 at 9:18
  • I think you are right it could be a junior agile coach. After reading this post: agile-ux.com/2010/03/30/the-scrummaster-is-not-an-agile-coach I guess not everyone agrees with the fact that Scrum states: "Leading and coaching the organization in its Scrum adoption;" or it does not include anything other then what the Scrum guide describes. Commented Nov 9, 2016 at 12:18
  • Interesting. Will go through it in more detail later. Mind you, there are also many interpretations of the word 'coach'. A coach in the sense of the training I am in at the moment (personal or team coach focused on what s/he/they want to accomplish) is entirely different from a coach hired for there subject matter expertise, where it becomes more of a 'consultancy' approach - sort of like sports coaches? Agile coaches seem expected to combine the two. Commented Nov 9, 2016 at 15:58

In our organization, junior SMs facilitate the cadence of the project. They make sure the meetings happen, make sure the right people are there, help the team members self organize, and also track things like story point burndown, etc. They provide summaries of team work at internal sprint reviews, and bring up issues the team has to management. As with the classic definition of agile scrum, they are always looking out for impediments and seeking to remove them.

Mid level SMs are generally obvious because of their people skills. Mid level SMs are leaders (not in a traditional manager sense, but they are someone the team tends to look to and rely on). Mid level SMs are great at generating team cohesion and team morale tends to be high. At this level, the Sm tends to become much more comfortable using their experience to look at past sprints and be able to make projections about future work that make them very useful to PMO types. A SM at mid level can not only help facilitate a planning meeting, but has experience with the team and can contribute estimates of what might or might not be too big of an item to take on based on past performance. This tends to help the tech leads and BAs a lot.

Senior SMs tend to get sucked up into the management functions that are (in my opinion) the weak area of agile scrum. Senior SMs are often involved in organizing project-wide initiatives, keeping SQA efforts on track (organizationally), making sure that teams are covering needed areas when it comes to release issues, defect prioritization, etc. For a larger project, they tend to fill the void left where "self organize" basically fails (anything larger than 40 people or so) and step into a lot of roles traditionally covered by a PM or PMO staff. Unfortunately this means that senior SMs are often spread too thin between way too many responsibilities.

  • Are they technical or not? I do a lot of what a mid level SM does, but don't actually write code.
    – bobo2000
    Commented Jan 13, 2017 at 17:40
  • @bobo2000 None of our SMs write code. I am pretty sure that the classical agile-scrum methodology does NOT have SMs write code. They are facilitators who keep things on track and "remove roadblocks".
    – JBiggs
    Commented Jan 13, 2017 at 19:30
  • that's good to know, I was confused about whether they needed to code or not. Read some answers on here, where they say that SMs need to be extremely technical.
    – bobo2000
    Commented Jan 13, 2017 at 20:42


A junior scrum master should understand and be able to explain the fundamental principles and founding ideas behind agile. They should be able to explain to the more reluctant members of a team why they are doing Agile.

JSM's (if I can shorten it that way) should be able to facilitate and mediate all of the basic Agile ceremonies at a very informal, casual level. This would include daily standups, sprint planning, backlog refinement, sprint review, and retrospective meetings. They should understand the basic purpose of each meeting and provide the team some level of direction, as well as steer the meeting without meddling. Allow the right conversations to happen naturally, but also steer them away from going off on a tangent.


At this level, the scrum master needs to get better at understanding the team's work, and explain it or provide updates on things if required. ISM's should start helping with work intake. They should be able to have basic discussions with the team's business analyst and other stakeholders to help define and break down requirements and document work, and to make sure the requirements and the work intake capacity are in agreement with team goals and previous sprint capacities. They should be able to work with the product owner to understand priorities and should then ensure the team's sprint plans agree with those priorities, and help the team communicate to the PO any delays, roadblocks, or unexpected work coming in.

The scrum master should also act as a roadblock-mover. They should be able to help get things escalated and resolved so that the team can work more efficiently, and they should start to look at inter-team dynamics. For example, during retrospectives, they should begin to see if certain team members are causing trouble for others, and look at ways to remedy that. They should feel more comfortable having difficult discussions when necessary ("your behavior is hurting your team, what ideas do you have to fix that?"). Not taking on the role of manager, but they do have to manage certain things day to day and make sure the team is meeting their commitments. The scrum master should feel like an integral part of the team and should celebrate their team's successes and feel badly about things that slow their team down.

ISM's should help the team manage their backlog in terms of the grunt work of making cards and filling requirement details in and prioritizing work from discussions with stakeholders; they should be able to take a few notes as to what needs done and go do it later, without taking valuable time during the Agile meetings that could be used for team collaboration and discussion.

Meetings should become more structured and formalized. The team backlog should be well documented, either digitally or physically, and some effort should be made to ensure that cards are moved at each standup, and team members should be held accountable for providing an update. If they are not able to be physically present at the meeting, they should provide an update through email or some other means, having someone else fill in for them. The team should feel like they are in sync. There should be a working agreements document posted somewhere and the entire team should be aware of it and have voted it into practice.

ISM's should begin helping their team to become more self-organizing and to rely on the scrum master less and less. The greater their skill, the less they should be required, sort of shrinking into the background and being less of an active participant and more of an enabler and an observer.


At the senior level, scrum masters should build up a refined sense of their team's weaknesses and strengths and should develop a plan to specifically address those findings. They should feel comfortable addressing the team as a whole and with a certain amount of authority, only to motivate and enable them to do their best work. They should be able to address infractions and encourage the team to further adopt Agile practices. At this level the shift from "doing Agile" to "being Agile" should be complete. They should understand when their team feels uncomfortable with or resistant to being Agile, even when those concerns are not voiced out loud.

They should be able to get ahead of the game and help the team react to disruptors, getting resolution quickly or at least helping the team communicate the roadblocks effectively and work out what to do with the appropriate stakeholders. They should be experts at getting feedback and improving, not just the team but also themselves and how they facilitate the Agile ceremonies. They should use each meeting well, digging into the depths of the team's workload, publishing each triumph, and when issues occur, getting to the crux of what went wrong, and how to fix it going forward.

They should hold their team accountable to their working agreements and not be afraid to challenge team members and get tough when required. This should still be done in an Agile frame of mind, being willing to adapt if the team decides as a whole that things should change. Getting a feel for where the team is at and what they are thinking should be easy at this point. The working agreement document should be further refined and capture team policies for Agile meetings and learnings from past mistakes. The senior scrum master should be able to mediate and resolve conflicts between team members and to keep team meetings focused and productive.

At this stage they should ensure that all work is broken down into sprint size tasks prior to the beginning of a sprint, and that during the sprint the work is broken down further into day-size work or smaller, so that cards can be moved during the daily standup. Standups should be mandatory at this point, though the schedule would be somewhat flexible.

The retrospective in particular should be quite detailed and should really get the team thinking. Senior scrum masters know how to finesse every last detail from their team without having to beg for it, and how to help each person participate and enjoy doing so.

The SSM should become the "man behind the curtain" - helping the team along in their Agile maturity without interfering and teaching the team to run the scrum processes on their own more and more.


Scrum master gurus should be able to teach what they know and mentor new scrum masters. They should know Agile inside and out and be able to explain and defend its core tenets easily. They should be able to tailor their approach to an individual team and should be experts at reading people and understanding the team's interactions.

They should have a great enthusiasm for Agile and be able to relate any situation to its corresponding Agile principle. They should be able to perform the scrum ceremonies admirably for any team, whether brand new to Agile or quite mature. They should have multiple plans and ideas for every aspect of being Agile, and be able to quickly select the best one that applies to each scenario or to each team or even individual. They should be able to quickly build a deep technical knowledge of their team's workload that enables their team to be far more productive and efficient. They should be able to explain the work the team does in detail, and make minor decisions related to work intake, and should push back on attempts to overfill the team backlog or to hold the team to a previous velocity.

They should be able to teach the team to self-organize and manage their own backlog, and handle the Agile meetings and ceremonies smoothly and without intervention or moderation. They should exemplify Agile practices and be able to take criticism from the team, even requesting it, and use it to improve themselves. They should be able to help the team improve but to do so while being basically invisible.

  • 1
    Scrum Master should not manage backlogs, that is something Product owners do. Daily Scrums (standups) should be mandatory on Junior level, not just on Senior level. But the worst is that your saying the Scrum Master should speak for the team, the SM should teach the team to self-organize and speak for them selves, not the other way around. In that aspect I also do not understand why SM masters should work with BA's and Stakeholders to work on requirements. The SM should facilitate that the developers and the PO do this in a productive way. You have some stuff right, but so much wrong. Commented Nov 8, 2016 at 18:20
  • "but so much wrong" - Indeed, find me an organization that does everything right. Every company is going to do things differently. I was relating what my experience is in my company. This is the path we have actually taken, right or not. Feel free to answer it yourself.
    – Tim
    Commented Nov 8, 2016 at 18:31
  • 1
    By "speak for the team" I meant be able to stand up in organizational PI meetings and explain what the team is working on in detail. I didn't necessarily mean make decisions. Manage backlog is the same thing. They should be able to work with BA's and provide input and help take care of roadblocks, do a lot of the grunt work of making cards and filling out details provided by the BA or PO, not so much making the decisions or setting priorities.
    – Tim
    Commented Nov 8, 2016 at 18:51
  • 1
    I expect a Scrum Master to teach self-organisation and not do the work for them. The Scrum team should create the cards and the Product Owner should update the organisation on which value the team is currently working. Ofcourse no organisation does every thing right, but we can aim high and continuously improve to get there. My team does not need me anymore to facilitate Scrum, they can perfectly execute a Sprint without me, but they do need me to help them to grow even further and become even more high-productive. Commented Nov 8, 2016 at 19:57
  • Ok that makes sense. More of a work yourself out of a job mindset. I don't think we have that as our goal. One difference is my org is struggling with resources. My team has no BA right now and our product owner is way too busy to provide updates, so it ends up being the scrum master who does that stuff. Good info for the future. Looks like we have a ways to go yet as a company in our agile maturity.
    – Tim
    Commented Nov 8, 2016 at 20:08


You are trying to apply a legacy hierarchy to a framework that explicitly rejects the notion of a team hierarchy. This makes the question itself an anti-pattern within Scrum.

While HR departments and line managers often need to make these sorts of distinctions for organizational or political reasons having nothing to do with the Scrum framework or the values and principles of the agile manifesto—especially in high power-distance cultures or organizations—the only correct answer within the Scrum framework is to not make these distinctions at all. The Scrum Team is collectively responsible for the success or failure of its processes and delivery, and external definitions of seniority are not relevant to that that responsibility.

Analysis and Recommendations

The 2020 Scrum Guide makes no such distinctions. There are only three defined roles/accountabilities within the framework, and there's no provision for time-in-grade or experience levels for role titles.

With that said, there are certainly mature teams and (in the CMMI sense) immature teams. There are also people who are new to the framework or their role within it. However, while this distinction might be helpful in determining how to help the team adopt the framework or successfully adapt to it, it's important to understand that the Scrum framework doesn't recognize such distinctions:

Within a Scrum Team, there are no sub-teams or hierarchies.

Furthermore, seniority is not intrinsically relevant to the Scrum Team's internal processes. While a Scrum Team is ideally cross-functional, meaning the team collectively has all the necessary skills to deliver value each Sprint, the individuals within the team often have different skill sets and levels of experience. That means it's up to the team to determine how to share the collective responsibility of delivery because:

[A Scrum Team is] self-managing, meaning they internally decide who does what, when, and how.

Since there are no formal hierarchies, and all the Developers are simply "Developers," such decisions are generally based on who is best-suited for a given task. In this case, "best suited" is often an assessment the team collectively makes based on everyone's individual skills, the composition of the team, and each person's available capacity to take on work within the current Sprint. This should always be true, regardless of a person's external rank or title outside the Scrum Team. Ultimately, the whole Scrum Team is accountable for delivery of the Sprint Goal and the Product Increment for the Sprint, and the distinctions your trying to make don't change that.

If your organization chooses to make such distinctions outside the Scrum Framework, that's likely to be for financial or cultural reasons. This is within senior leadership's scope of authority. However, I'd consider it the role of the Product Owner, Scrum Master, and (to a lesser extent) the Scrum Team as a whole to help educate the organization on why this works against agility, and to try to help senior leadership come up with a better way to evaluate the effectiveness of its Scrum Teams and to hire/fire/reward people based on individual performance if they choose to do that in spite of the clear industry evidence that this is an agility anti-pattern.

Senior leadership is always ultimately accountable for "tone at the top." If they break the Scrum process, deliberately or not, then they get to keep both halves. Q.E.D.

End Note: Definitions are Relative

It's also worth pointing out that differences in experience—and the monetary or political value of those differences—are often relative. While many IT organizations often develop their own lexicon or time-in-grade for experience levels (e.g. many companies use 5 years as an arbitrary cut-off point, while others use the frequently-debunked 10,000 hours method), the reality is that the distinctions are typically idiosyncratic and company-specific, and are often formulated based on a combination of existing company culture, specific problem domain, and the current experience levels (however defined) of existing staff.

As an example, assume I have over 20 years of experience in certain programming languages. If you have only 10, but are better than me at that language, which one of us is "senior?" If I've been a professional subject matter expert (SME) at something for a decade, but you've got master of the same subject with five years of experience, does that make you a "journeyman SME" or are we peers with perhaps some different career experiences?

Also consider this counter-example. What if I've been working my rear end off for three years to be the best I can be at something, while you've been coasting in a comfortable sinecure for five? Which one of us is likely to be more experienced or better suited for a given project? Which of us is more deserving of a raise or bonus?

I'd argue that these distinctions are both relativistic and largely immaterial to how much value a given person can bring to a role, a team, or a project. This is where outcome-based assessments for the whole Scrum Team are often more valuable than trying to assign intrinsic value to arbitrary titles or to individual time-in-grade. Your organizational values will certainly vary, but the underlying truth of the proposition will not.


As a Scrum Master, you'll find that you have plenty of career options. The more experience you have with Scrum, you will find that you could take on the mantle of an Agile coach, a mentor, and guide, a Product Manager or Product Owner, or much more. A Scrum Master can become an organizational transformation expert by helping not just one team but several teams and departments in the organization. They can coach management teams, customer organizations, other Scrum teams, etc. to eventually play a crucial role in organizational development and transformation.

  • 1
    This post is attracting flags and downvotes because it doesn't the OP's central question of how to distinguish between different levels of Scrum mastery within a common lexicon (but there isn't one). While your question attempts to help with the career path part, it is really only a partial answer, but could be expanded or revised to improve it. [Note to flaggers: There are valid reasons to flag this answer, but "not an answer" isn't one of them. If you don't understand why, please raise the issue in meta. It would also be better to advise new users about how to improve when possible.]
    – Todd A. Jacobs
    Commented Apr 23, 2022 at 16:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.