30-60-90 day plan for scrum masters

A 30-60-90 day plan for a new scrum master should observe every Scrum event and the team's flow without changing them in the first 30 days; take over facilitation, the impediment list and the team's working agreements in days 31-60; and by day 90 show one improvement from the retrospectives measured in the team's own flow data, plus at least one impediment removed from outside the team. The accountabilities come from the Scrum Guide (November 2020 version, current as of November 2026): the Scrum Master is accountable for establishing Scrum as the guide defines it and for the Scrum Team's effectiveness, which is a different job from assigning work or reporting status.

This page is for the engineering manager, head of delivery, agile coach or product leader hiring a scrum master for one or more Scrum teams. Product Backlog ordering and the Product Goal belong to the role in the 30-60-90 day plan for product owners; people management, hiring and performance to the 30-60-90 day plan for engineering managers; schedule, budget and RAID logs to the 30-60-90 day plan for project managers.

What does the Scrum Guide make the scrum master accountable for?

The guide on scrumguides.org describes the Scrum Master serving three groups. The table pairs each with what it means in the first 90 days.

Two details from the guide shape the first month. The Daily Scrum is a 15-minute event for the Developers, so the scrum master makes sure it happens rather than running it as a status meeting. And the Sprint Backlog is a plan by and for the Developers, so the scrum master coaches the team to own it instead of assigning work.

Which events does the scrum master keep in their timeboxes?

Shorter Sprints usually get shorter events. Timeboxes are maximums, not targets; a team that plans a two-week Sprint well in two hours does not need eight.

What does the 30-60-90 day plan look like?

30-60-90 day plan — [Name], Scrum Master, [team(s)]
Reports to: [engineering manager / head of delivery / agile lead]
Start date: [date]    Teams: [N]    Developers: [N]
Product Owner: [name]    Sprint length: [weeks]
Tools: [board / tracker, wiki, CI dashboard]

DAYS 1-30 — Observe, listen and gather evidence
Goals:
- Attend every event for [2] Sprints without changing the format
- One-to-one with each developer, the Product Owner and the
  main stakeholders: what helps, what slows the team down
- Read the Definition of Done and working agreements; check
  whether recent Increments met the Definition of Done
- Pull [3] months of flow data: work in progress, cycle time,
  work item age, throughput; Sprint Goals met
- Start a visible impediment list with dates and owners
Deliverables by day 30:
- A short "how this team works" note with evidence
- Impediment list, split into inside and outside the team

DAYS 31-60 — Take over facilitation and the impediment list
Goals:
- Facilitate the events, keeping each within its timebox and
  ending with its purpose met (a Sprint Goal, a plan, adaptations)
- Run retrospectives that end with one or two owned actions
- Work the impediment list; take the top external impediment to
  the person who can remove it
- Agree a WIP limit or other working agreement with the team,
  if the data supports it
Deliverables by day 60:
- Retrospective actions logged and reviewed at the next retro
- One external impediment escalated with an owner and a date

DAYS 61-90 — Show the team getting more effective
Goals:
- Measure the first retrospective improvement against the day-30
  flow baseline
- Help the Product Owner with refinement techniques so the next
  [2] Sprints' items are ready
- Hold a session with stakeholders on how to work with the team
  (Sprint Review, requests, priorities)
Deliverables by day 90:
- One improvement shown in the team's flow data
- One impediment outside the team removed

Check-ins: weekly with [manager]; reviews at day 30, 60 and 90.

Numbers in brackets are examples; adjust them to the Sprint length and the number of teams.

Which numbers should a new scrum master track?

The Kanban Guide for Scrum Teams (January 2021) defines four basic flow measures: work in progress, "the number of work items started but not finished"; cycle time, the elapsed time between when a work item starts and finishes; work item age, the time since an unfinished item started; and throughput, "the number of work items finished per unit of time." They are useful because the team can see them move when it changes how it works. The standards below are examples only.

Leave velocity and story points out of the scrum master's own evaluation. They are the Developers' planning tools, and using them as a score teaches teams to inflate estimates.

What does "on track" look like at day 30, 60 and 90?

A filled example

How should the hiring manager use this plan in the final interview?

Give every finalist the same brief: the team, the Sprint length, a screenshot of the board and three months of flow data or a Sprint report. Score the plans with the rubric in how to evaluate a 30-60-90 day plan in an interview. A strong scrum master plan observes and measures before it changes the process, and names impediments outside the team as part of the job. Questions that test it:

• "The team has missed its Sprint Goal four times in a row. What do you look at first?"
• "A senior manager joins the Daily Scrum and starts assigning work. What do you do, then and afterwards?"
• "The retrospective keeps producing the same complaint about another team. How do you get it fixed?"
• "Our director wants to compare velocity across teams. What do you tell them?"

The scrum master screening questions check Scrum knowledge and experience earlier in the process.

What should the manager ask at the check-ins?

• Day 30: What surprised you about how this team works? Which impediment costs the team most, and is it inside or outside the team?
• Day 60: Which retrospective actions got done? Who did you need to talk to outside the team, and what happened?
• Day 90: What does the flow data show now? What do you need from me to remove the next impediment?

What the manager owes a new scrum master

• Access to the board, the tracker and the team's data from day one.
• Clear support that the scrum master does not assign work or report individual performance.
• Introductions to the managers who own the impediments outside the team, such as environments, approvals and shared services.
• Patience with month one: a scrum master who changes everything in the first Sprint has stopped learning.

Common mistakes

• Becoming the team's project manager. Assigning tasks and chasing status undermines self-management.
• Running the Daily Scrum. It is the Developers' event; the scrum master makes sure it happens and stays useful.
• Changing the process in week one. Without a baseline, nobody can tell whether a change helped.
• Only removing small impediments. The ones outside the team are usually the expensive ones.
• Scoring by velocity. It invites estimate inflation and says nothing about value.

Adapting the plan

• Several teams on one product: keep the day-30 observation for each team, then look for impediments that cross teams, such as shared environments, integration and dependencies; the 30-60-90 day plan for program managers covers cross-project dependency maps.
• Teams new to Scrum: weight month two toward teaching the events and the Definition of Done, and expect the flow data to be noisy at first.
• Kanban-leaning teams: the flow measures above become the center of the plan, and the WIP limit is the first working agreement to test.
• Credentials: Scrum Alliance's Certified ScrumMaster involves a 16-hour course and a 50-question test (37 correct to pass), renewed every two years with Scrum Education Units; Scrum.org's Professional Scrum Master I is an 80-question, 60-minute assessment with an 85 percent pass mark and no renewal, both as of November 2026.