A 30-60-90 plan for your first Scrum Master role
ESTIMATED TIME
10
mins

Written by
Shikha Prasad
Published on
Somebody, somewhere, told you to write a 30-60-90 plan. Maybe a recruiter asked for one in the final round. Maybe your new manager wants to see it in week one. Maybe you read that strong candidates bring one and you want to look strong.
So you sat down and wrote a list of everything wrong with the team you have not met yet. Fix the standup. Clean up the backlog. Introduce a proper Definition of Done. Get the retros working. Improve velocity. It reads like a turnaround memo from someone who has already decided the team is broken.
Here is the uncomfortable truth. A first-role 30-60-90 plan is not a to-do list. It is a promise. And you are about to hand a room full of strangers a document full of promises you cannot possibly keep, made before you understand a single thing about how they actually work.
A plan full of fixes says you already judged them. A plan built to learn says you are worth trusting.
Why the eager version backfires
Think about what a new Scrum Master actually walks into. A team that has been running for months or years without you. Habits that exist for reasons you cannot see yet. A board that looks messy but is messy in a way everyone has silently agreed to. People who have watched process people come and go, each one arriving with a new template and a plan to fix them.
Now you show up on day one and reorganize the board. You add a meeting. You announce that retros are going to be run properly from now on. You have not cleared a single blocker or earned a single hour of anyone's trust, and you are already rearranging their furniture.
The team's read on you is instant and it is not kind. Another one who thinks the problem is us. They will nod in the meeting and change nothing the moment you leave the room. You will spend the next six months wondering why nobody adopts anything you suggest. The answer is that you spent your trust before you had any.

Same first month. One person is performing the role. The other is quietly doing it.
What actually goes in each box
A good first-role plan is boring on the surface and load-bearing underneath. It has three moves, one per month, and each one is smaller than the version in your head. Small enough that you will actually do it, and small enough that the team feels it.

The whole plan on one line: read, prove, stick. One promise per phase.
Days 1 to 30: read the system, promise nothing
The first month is not for fixing. It is for seeing. Your only job is to build an honest map of how work really moves, not how the org chart says it moves. Where does a ticket sit for four days doing nothing? Who actually makes the call when priorities collide? Which meeting is the one everyone quietly hates? What does this team think a Scrum Master is for, based on the last three they had?
Sit in the stand-ups and say almost nothing. Walk five finished tickets backward and see where the time actually went. Ask each person, one on one, what has been frustrating them lately. Write down what you find. You are not allowed to change anything this month, and that restraint is the whole point. The plan for month one is a single sentence: I will understand this team before I touch it.
Days 31 to 60: prove one thing
Now you have a map, and the map is pointing at something. Every team has a blocker that everyone can name and nobody has had the time or standing to remove. The environment that is always down before the demo. The approval that takes a week. The dependency on another team that never answers. Pick one. Just one.
Then clear it. Not propose a framework for clearing it. Clear it. Chase the approval yourself. Get the two teams in a room. Make the thing that has annoyed everyone for months quietly go away. When the team feels one real irritation disappear because you were there, you have done more for your credibility than any board redesign ever could. That is what earning the right looks like. It is not a speech. It is a result they can feel.
Days 61 to 90: make it stick, with a number
The trap in month three is treating your one win as finished. You cleared a blocker, everyone was happy, and now you go looking for the next fire. Do not. The senior move is to turn that single win into something the team keeps doing without you, and to attach one honest number to it so the improvement is visible to people above you too.
Cut the meeting that was wasting an hour? Track what the team does with that hour and whether the work still gets coordinated. Fixed the demo environment? Watch whether demos start on time now, and say so out loud. You are not chasing a dashboard. You are proving that one thing is measurably better than it was on your first day, and that it will stay better after you move your attention elsewhere. One kept improvement beats ten proposed ones.
The plan is also an interview asset
Here is the part most people miss. If a recruiter or hiring manager asks you to bring a 30-60-90 plan to the final round, they are not testing whether you can fill in a template. They are testing your judgment about power. A candidate who walks in with a plan to overhaul everything in month one has just told them they do not understand how new people build trust. A candidate who walks in with a plan to listen first, prove one thing, and make it stick has told them they have done this before, or at least they understand the room.
So the plan you would actually run and the plan you show in an interview are the same plan. That is the tell of someone who is ready. When they ask why month one has no wins in it, you say: because I have not earned the right to change anything yet, and a plan that pretends otherwise is a plan I would have to walk back. That answer lands harder than any list of improvements, because it is the answer of someone who has been the new person before and learned the hard way.
If this is your first role and you have never done it
You might be reading this before you have ever held the title, writing a 30-60-90 plan for a job you are still interviewing for. Good. You can still build the judgment this plan requires, and you can build it for real. Offer to help a nonprofit or a friend's small team run their work for a month. Go in with exactly this posture: read the system first, change nothing, then clear one real thing. You will feel, first-hand, how differently people treat the person who listens before they rearrange.
Do that once, honestly, and you will not be reciting a plan in the interview. You will be describing something you actually did, in the specific language of someone who has stood in the room and felt the difference between performing the role and doing it. That is the whole game. The certificate got you the conversation. This gets you the offer, and then it gets you the second month at the job you just won.
You do not need to arrive as the person who fixes everything. You need to arrive as the person worth keeping around long enough to fix the one thing that matters. Read first. Prove one thing. Make it stick. Then earn the next one.

Subscribe to the Newsletter
Join our growing community and get alerted first on our every article.
*By subscribing, you agree to send your information to our Company who agrees to use it according to their Terms and conditions and Privacy Policy
About the author
I believe the strongest tool and flex each of us has is our belief. When we truly believe in something, we align our mindset, energy, and actions with the right effort and guidance. That is when achieving almost anything becomes possible. This is how I help mentees at OAKKTREEUNII move into Software and Project Management careers for better pay, better confidence, and better work-life balance.
What should a Scrum Master do in the first 30 days?
Learn how work really flows, who decides, and where it jams. Do not change anything yet. The first month is for building an honest map, not for fixing.
Should I bring a 30-60-90 plan to a Scrum Master interview?
Yes, if asked. But make it a plan that listens first and proves one thing, not a list of everything you will overhaul in month one. It signals judgment about trust.
Comments


