What a Scrum Master Actually Does in the First 30 Days
A practical, week-by-week guide to the first month as a Scrum Master — what to observe, who to talk to, and which habits to build before you start changing anything.
The first 30 days as a Scrum Master are less about fixing things and more about earning the right to suggest changes. New Scrum Masters often arrive eager to reorganize the board, rewrite the working agreements, and overhaul the retrospective on day one. Resist that urge. Your first month is for listening, observing, and building trust.
Week 1 — Observe without judgment
Spend your first week understanding how the team actually works, not how the process documents say it should. Attend every event quietly. Watch the Daily Scrum: is it a status report to a manager, or a real planning conversation among developers? Notice who speaks, who stays silent, and where energy drops.
Map the people. Meet your Product Owner one-on-one and understand how they order the Product Backlog. Talk to each developer about what slows them down. Identify the stakeholders who show up at Sprint Review and the ones who quietly influence priorities from the sidelines.
Week 2 — Understand the flow of work
Now look at the system. How does a Product Backlog item travel from idea to "Done"? Where does it wait? Pull up the last three or four sprints and look for patterns: items rolling over repeatedly, scope added mid-sprint, or a Definition of Done that everyone interprets differently.
This is also the time to confirm the basics are real. Is there a single, visible Product Backlog? Does the team have a shared Sprint Goal each sprint, or just a pile of tickets? These gaps tell you where your coaching will matter most.
Week 3 — Make small, safe interventions
By the third week you have earned enough context to nudge gently. Pick one improvement that the team already feels the pain of, and facilitate a conversation about it rather than mandating a fix. If the Daily Scrum has become a status meeting, ask the developers how they would like to use those fifteen minutes. Let the solution be theirs.
Strengthen the retrospective. A strong retro is the engine of continuous improvement, so invest in making it safe, focused, and action-oriented. End every retro with at most one or two concrete experiments the team commits to trying.
Week 4 — Establish your rhythm
In the final week, settle into the cadence that will define your role: protecting the team from disruption, helping the Product Owner keep the backlog healthy, removing impediments quickly, and coaching the organization toward greater agility over time.
Write down what you have learned and share a short, honest summary with the team. Name the strengths you see and the one or two areas you want to explore together next. You are not there to be the hero who fixes everything. You are there to help a self-managing team get better at solving its own problems — and the first 30 days are how you set that tone.