30-60-90 Day Plan for a Scrum Master: Example, Metrics and First Week

10 min read ยท 2026-10-25

A 30 60 90 day plan for scrum master roles splits your first three months into three goals: learn how the team really works in the first 30 days, fix the one or two problems that hurt delivery most by day 60, and show measurable progress with a plan for the next quarter by day 90. It tells your manager what to expect and keeps you from changing everything in week one.

Most onboarding plans miss what makes this job different. A scrum master owns neither the backlog nor the code. Your results show up in the team's flow, its predictability and how fast impediments get cleared. The plan below is built around that: the events you sit in, the people who shape your team's work, quick wins that fit the role and metrics you can actually report.

It works whether you join a new company, move into the role from development or QA, or take over a team that already has habits. Adjust the weeks to your sprint length, but keep the order.

The roadmap at a glance

Goal: By day 90, the team runs every Scrum event with a clear purpose, the top impediments are owned and tracked, and your manager has a baseline and a trend for flow and predictability. Duration: 13 weeks (90 days)

  1. Listen and map the team (Weeks 1-2)

    Understand how the team works today before you suggest any change.

    • Hold 30-minute one-on-ones with every developer, the product owner and your manager, and ask what slows them down and what they would keep.
    • Attend every event as an observer and note timeboxes, who speaks, and whether each one ends with a decision.
    • Read the notes from the last few Sprint Reviews and retrospectives, plus any open impediment list.
    • Get access to the board in Jira or Azure DevOps and trace how a work item moves from backlog to done.

    Milestone: A one-page team map: people, events, working agreements, the Definition of Done as written and as practiced, and the top five pains you heard.

  2. Diagnose and agree on priorities (Weeks 3-4)

    Turn what you observed into two or three improvement goals the team and product owner support.

    • Pull a baseline from recent sprints: items committed versus completed, cycle time, carry-over and escaped defects.
    • Share your observations in a retrospective and let the team vote on what to tackle first.
    • Agree with the product owner on how refinement works and how many sprints of backlog should be ready.
    • Start a visible impediment log with an owner and a target date for each item.

    Milestone: Day-30 check-in with your manager: baseline metrics, the impediment log and two or three agreed improvement goals.

  3. Fix the events and the flow (Weeks 5-8)

    Make the Scrum events and the board serve the team instead of running as rituals.

    • Refocus the Daily Scrum on progress toward the Sprint Goal and move problem solving to right after it.
    • Coach the product owner to bring a draft Sprint Goal to Sprint Planning.
    • Add a work-in-progress limit to the In Progress column and track blocked items every day.
    • Rewrite the Definition of Done with the team so testing and code review are part of it.
    • Vary the retrospective format and end each one with a single action that has an owner.

    Milestone: Two sprints in a row with a Sprint Goal set at planning and inspected at the Sprint Review, and every retro action closed or deliberately carried over.

  4. Clear systemic impediments (Weeks 7-10)

    Take on the blockers the team cannot fix alone because they sit between teams or in the wider organization.

    • Split the impediment log into team-level issues and organization-level issues.
    • Meet the leads who own the organization-level ones, such as test environment access, release approvals or a shared API.
    • Join the cross-team sync and raise dependencies at least two sprints before they bite.
    • Make the Sprint Review useful to stakeholders by inviting the right people and showing working software, not slides.

    Milestone: At least one organization-level impediment removed, with the before and after written down (for example, days waiting for a test environment).

  5. Measure and plan the next quarter (Weeks 11-13)

    Show progress against your baseline and set the agenda for the next 90 days.

    • Compare the last three sprints with your day-30 baseline on Sprint Goal success, cycle time and carry-over.
    • Run a short team health check and share the results with the team before anyone else.
    • Coach a team member to facilitate a retrospective so the events do not depend on you.
    • Write a one-page review for your manager with results, open impediments and next quarter's goals.

    Milestone: Day-90 review held with your manager: metric trends, impediments closed, team health results and an agreed plan for the next quarter.

Your first-week checklist

Week one is about access and relationships, not improvements. If you walk into your first Sprint Planning with a list of fixes, the team will hear criticism from someone who has not yet seen a full sprint.

Use this list to make sure nothing basic is missing by Friday. Each item gives you either context or a relationship you will need in month two.

  • Accounts for the board, the wiki (Confluence or similar), the team chat and the build pipeline dashboard.
  • A copy of the current Definition of Done, working agreements and team calendar of events.
  • One-on-ones booked with every team member and the product owner within the first two weeks.
  • A 30-minute meeting with your manager to agree on what success at day 90 looks like and how often you will check in.
  • A list of the products, services and other teams your team depends on, built from the board and your conversations.
  • A personal notes file where you log observations with dates, so your day-30 summary is based on facts.

People to meet in the first 30 days

A scrum master serves the developers, the product owner and the organization around them. Many of the impediments you will face are owned by people outside the team, so meet them before you need a favor.

Ask each person the same three questions: what is going well with this team, what frustrates you about working with it, and what would you change first. Comparing the answers tells you more than any single interview.

  • Product owner: how the backlog is built, who their stakeholders are, and how they decide what goes into a sprint.
  • Developers and testers: one-on-one, not as a group, so quieter people speak freely.
  • Engineering manager: performance concerns, hiring plans and technical debt they worry about.
  • Other scrum masters or agile coaches: shared practices, the cross-team sync and what has been tried before.
  • Key stakeholders: the two or three people who attend the Sprint Review or should, and what they need from it.
  • Release, operations or platform leads: how code reaches production and where it usually waits.

Quick wins that fit the role

A quick win for a scrum master is a visible improvement the team asked for, delivered in a sprint or two, that makes their week easier. It should not be a new process you invented. The best quick wins come straight from your one-on-ones.

Pick one or two from the list below only if your observations point to them. Announce them as experiments with a review date, so the team can drop them if they do not help.

  • Cutting a 40-minute Daily Scrum back to 15 minutes by moving detailed problem solving to a follow-up with only the people involved.
  • Cleaning up the board: closing stale tickets, merging duplicate columns, and making blocked work visible with a flag.
  • Adding a backlog refinement session mid-sprint so Sprint Planning stops running long.
  • Putting the Sprint Goal at the top of the board where everyone sees it every day.
  • Fixing one recurring delay, such as waiting for code review, with a simple team rule the team writes itself.

Metrics to track and how to measure them

Pick metrics that show flow and predictability, take your baseline in month one, and report the trend at day 60 and day 90. Never use velocity to compare teams or to judge people. Once story points become a target, estimates stop being honest.

Most of these come from your board's built-in reports or a simple export to Excel. Keep the list short. Four metrics you track every sprint beat ten you forget.

  • Sprint Goal success: in how many of the last sprints the team met its goal. Count it at each Sprint Review.
  • Committed versus completed: items planned at Sprint Planning against items done at the end. Track the trend, not single sprints.
  • Cycle time: days from In Progress to Done for each item. Look at the spread as well as the average.
  • Impediment age: days each impediment stays open, from your impediment log.
  • Escaped defects: bugs found after release that trace back to the sprint's work.
  • Team health: a short anonymous survey on clarity, workload and collaboration, run in month one and again in month three.

Example: a filled-in plan for a mobile app team

Picture a scrum master joining a seven-person team that builds a banking app, with two-week sprints, a product owner shared with another team, and releases that wait on a central QA group. Here is how the plan could look.

Notice that each block has an owner and a milestone you can check. The scrum master owns the process work, but the product owner and the QA lead own key parts of the outcome.

  • Days 1-30, learn (owner: scrum master): one-on-ones done, two sprints observed, baseline shows the team completes about half of what it commits and items wait several days for QA. Milestone: team map and baseline reviewed with the manager.
  • Days 31-60, improve (owners: scrum master and product owner): Sprint Goal written at every planning, refinement moved to mid-sprint, work-in-progress limit of three items on the board. Milestone: two sprints with a met Sprint Goal.
  • Days 61-90, scale (owners: scrum master and QA lead): a developer pairs with QA so testing starts inside the sprint, and the release checklist moves into the Definition of Done. Milestone: QA wait time down against the baseline, day-90 review approved.

How to present it to your manager or in an interview

For your manager, use one slide with three columns (days 1-30, 31-60, 61-90). Each column gets a goal, three actions and one measurable milestone. Below the columns, list the support you need, such as access to the release manager or budget for a team workshop. Leave out the full list of events you will attend; your manager knows them.

In an interview, the plan proves you know the job is about outcomes, not ceremonies. Say clearly that the first month is mostly listening, then name the metrics you would baseline and one example of an organizational impediment you have removed before. Ask the interviewer what the team's biggest pain is today and adjust your 60-day goals on the spot. That shows you would do the same with the real team.

Common mistakes to avoid

  • Changing the events in week one breaks trust before you understand why the team works the way it does, so observe for two sprints and change only what the team agrees to.
  • Using velocity to push or compare the team turns estimates into a target, so report Sprint Goal success and cycle time instead.
  • Acting as the team's assistant by booking meetings and updating tickets hides the coaching work, so teach the team to own its board and rotate facilitation.
  • Solving every impediment yourself makes the team depend on you, so ask who should own each one and take only those that need organizational reach.
  • Leaving the product owner out of your plan means you keep fixing symptoms of an unready backlog, so hold a weekly working session with them from week two.
  • Listing activities without outcomes makes the day-90 review impossible to judge, so attach a baseline and a target to every goal.

Frequently asked questions

What should a scrum master do in the first 30 days?

Listen and observe. Meet every team member and the product owner one-on-one, attend every event without changing it, and take a baseline of how work flows. End the month with a short summary and two or three improvement goals the team agrees with.

How do I write a 30 60 90 day plan for a scrum master interview?

Keep it to one page or three slides, one per 30-day block. Give each block a goal, a few actions and a measurable milestone, and make it clear that month one is about learning. Use what you know about the company to name likely priorities, and say you would confirm them with the team.

What metrics should a new scrum master track?

Start with Sprint Goal success, committed versus completed items, cycle time, impediment age and a team health survey. Take a baseline in the first month and report the trend at day 60 and day 90. Avoid using velocity as a performance measure.

How is a scrum master 30-60-90 plan different from a project manager's?

A project manager's plan centers on scope, schedule and budget for a project. A scrum master's plan centers on how the team works: events, flow, impediments and team health. The scrum master does not assign tasks, so the milestones measure the team's improvement rather than delivery dates.

What if I am the scrum master for two teams?

Run the first 30 days for both teams in parallel, but pick improvement goals per team, because their problems will differ. Stagger the events so you can attend all of them. Look for shared impediments, since fixing one often helps both teams at once.

Generate this roadmap with AI