Skip to main content Search

Guide

The Scrum Master’s startup guide

What you need to know to get up and running as a Scrum Master

The Scrum Master’s startup guide cover image

About this guide

If you are starting out as a Scrum Master, or face some of the Scrum Master’s responsibilities, this guide gives you a basic understanding of your work and how to get going. Most Scrum Masters assume this role in addition to their normal “day job”. This guide is perfect for them. 

In many cases, Scrum Master can also be a full time role. But in those cases, full-time the Scrum Master often takes care of several scrum teams.

Much more often, Scrum Master is a role that someone in the development team takes on in addition to their normal duties. As a part-time Scrum Master, you will probably dedicate only 5-10% of your time to your Scrum Master duties (this does not include participation in the team ceremonies, which all team members naturally participate in).

Who exactly is the guide for?

If you are just starting to work as a Scrum Master, part-time while you continue your other duties: this guide is especially for you.

But it is also a great resource for teams who decide to rotate the scrum mastership between from team members.

No need to rush in to book a seat on a “Certified Scrum Master” two-day course. You can get up to speed and be an effective Scrum Master in just a couple of hours. So let’s get to it! 

Receive this guide as a PDF by e-mail

1. Why you need to do Agile well

With effective Agile methods and scrum, your team performs better and will experience less stress. The team will improve and work in a more sustainable way, for longer periods of time, without the need for overtime.

You will benefit in the following ways:

  • See better, how the work is progressing
  • Adapt better to unexpected changes in 
  • your environment
  • Deliver business value faster
  • Significantly lower your risk
Agile_Bennefits

Additionally, your key stakeholders are more happier because:

  • Customers are more satisfied
  • Management are more satisfied
  • Employee are more satisfied and team spirit is higher

2. The manifesto and principles that Agile is based on, in short

Agile manifesto

Agile_manifesto_Hands_Magnifying_Glass_x2_2024_Illustration_Eficode

Agile principles

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity – the art of maximizing the amount of work not done – is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

3. The values and principles that Scrum is based on

Scrum is based on the three principles of Transparency, Inspection, and Adaptation.

Transparency:

this means for example, that no work, specification, problems, risks or progress of work is hidden. Everyone on the team and outside must have access and visibility of how the work is proceeding.

Inspection: 

this means that the team is motivated and willing to look at the results of the work, and the process that created it – and then analyze the result and compare it to what the team wants to achieve.

Adaptation: 

this means that the team actively seeks to adjust course based on what it feels is the correct direction to take.

The Scrum values

Respect: 

All team members contribute to the target. Collaboration and other’s ideas are respected. Other people’s accomplishments are celebrated.

Openness:

Team members are honest when they need help. An open-minded team always seeks to improve and learn. Ceremonies like daily and review show clearly and openly how things went. Assumptions are voiced out loud.

Commitment: 

The team is protected from sprint scope changes, and the sprint planning session seeks opinions from the team to deliver. In the daily - the team feels pressure to deliver promise.

Focus:

The team finishes what they start and does not get sidetracked.

Courage:

Question the status quo, feel safe to ask for help and say no. The team does not fear difficult conversations.

4. The ceremonies in Agile

Agile ceremonies are meetings that happen regularly on a weekly, daily or per sprint frequency. The content and format of the meeting varies very little. The ceremonies are an integral part of the Agile way of working. Ceremony facilitation and improvement usually is the responsibility of the Scrum Master.

Scrum uses all the below ceremonies. Kanban uses four of them, but lacks sprint planning and review because Kanban does not have sprints. Kanban teams must have another frequency to discuss items that  fall into sprint planning and review agenda.
Agile_ceremonies_-_Scrum_Kanban_2024_Diagram_Eficode
Backlog refinement

Regular meeting to improve the top of the backlog, and maintain the rest of it.

Sprint planning

At the start of sprint, the team and product owner get together to plan and commit what can be done in the coming sprint.

Daily 

A short, daily meeting where the team self-organizes what has been completed, what is started next, and keeps work going forward.

Retrospective

Regular meeting that reflects on past work, and finds better ways to do things.

Sprint review

At the completion of the sprint, the team and PO get together to review done and not done items, and also reflect on learnings and the big picture.

Demo

The team presents complete work to stakeholders to get feedback.

Backlog refinement

Regular backlog refinement is key in a process that delivers high quality work. Backlog refinement relies on “Definition of Ready” – the team’s agreement on what kind of work it agrees to start.

Start with this
  • Agree with the Product Owner who organizes it.
  • Workshop the Definition of Ready with the team.
  • Start with a 1-hour meeting every week, with the 
  • whole team present. Investigate and trial other approaches later.
Key points
  • Regular – preferably one hour every week.
  • User value in focus – the team asks what user problem is solved with this backlog item.
  • Discussion – the team has discussions amongst itself and with the product owner – everyone is involved.
  • Definition of Ready – without a written Definition of Ready, the team will forget to what level the backlog item should be specified.

Sprint planning

The sprint planning is where the team finalizes any backlog items that it agrees to be part of the sprint scope. Sprint planning starts from a ProductOwner’s proposal or prioritized backlog. Definition of Done must exist for the team to be able to commit to any sprint scope. The team must measure velocity (the amount of completed work in each sprint) and use this velocity to guide how much work to load into each new sprint.

Start with this
  • Agree with the Product Owner to bring a proposal, 
  • or start with a prioritized backlog.
  • Workshop the Definition of Done with the team.
  • 2-hour meeting on the first day of a Sprint.
Key points
  • Start from the Product Owner’s proposed set of backlog items, and add what the team feels should be considered. Check that the backlog items pass Definition of Ready.
  • Perform effort estimates for each story that is suggested for the sprint. Do not load too much. Slightly over velocity is the most.
  • Definition of Done – without a written Definition 
  • of Done, the team cannot effectively commit to deliver anything.

Daily

The daily is the only meeting during the sprint that aims to ensure that the team achieves the sprint goals. That is why it is so important. The team must be made to feel that it is checking Done, In Progress and Still to be Done in the sprint backlog. If there are any problems, risks or blockers, these should be raised, so the team can react in an Agile manner to any setbacks. 

The daily is also a planned interruption. Things that are urgent, should not wait for the daily. But other things, that are not urgent, can wait. This way, other  interruptions can be minimized.

Start with this
  • Be strict about the rules.
  • Teach the team to update the scrum board before the meeting – every time.
  • Teach the team to self-organize (speaking order, staying on topic, meet afters) rather than always choreographing it yourself.
Key points
  • Use the traditional “Three questions of Scrum” if you want:
    • 1) What did I do yesterday?
    • 2) What I am going to do today?
    • 3) Is anything blocking my work?

But use of these questions is not mandatory. Equally effective is just to ask everyone to share what they think others should know. Just ensure that everyone reports briefly, and any longer discussions are taken offline.

  • Promote highlighting issues and solving them in meet afters.
  • Always start promptly at the same time (even if someone is late).
  • Strict timebox of 15 minutes - most meetings can be shorter.
  • Off-topic discussions only X seconds – then meet after.

Retrospective

The retrospective lets the team analyze, explore and improve their ways of working. The team considers what worked well, and what did not. There are thousands of methods to use to guide the retrospective discussion The key things are that the team agrees concrete action points to take in the next sprint. The team should focus most of their energy and time on the things under their control.

Start with this
  • You are the host and facilitator. Start with an easy method like ”mad, sad, glad”. But also explore and try other methods.
  • Watch the time – spend max half the time on exploration, a third on analysis and the rest on agreeing on actions.
  • Do not take too many actions at one time! Actions can be added to the sprint backlog.
Key points
  • Use different retrospective methods, not only a discussion on ”what was good, what was bad”;  there are thousands of retrospective methods out there.
  • Regular retrospectives are essential for the team spirit and improved performance. Keep a “retro” every sprint or every month.
  • A 1-hour retro is a good investment.
  • Retrospectives should be split into exploration, discussion and analysis, and action point agreement.

Sprint review

A sprint review is where the team checks the result of the sprint – which backlog items were done and which were not. This is also a place for reflection – do the completed items fulfill the needs of the user/customer? Did you find some new issues which need to be on the backlog?

Start with this
  • Check the done items against DoD.
  • Check why things were not done, and what to do with them.
  • This meeting can be combined with the demo (which we will look at next), but they can also be kept separate.
Key points
  • What were the reasons why something wasn’t done? What should be done differently to achieve more things in the future?
  • What to do with the things that were not done – move to the next sprint / back to backlog / not needed?
  • Has the team learned anything – about priorities or new items?
  • Sometimes compare the results with Definition of Done (DoD), to verify that the team obeys it.
  • Review the big picture situation.

Demo

The demo is used to show what was Done in the last sprint. The target audience is stakeholders that are interested in the work items. The demo session can be adjacent to the sprint review meeting, or it can also be at a different time if more stakeholders can participate in it. The key thing is to get comments and feedback.

Start with this
  • Arrange the demo adjacent to the sprint review, but with a separate invitation. The review is for the team, and the demo is for stakeholders.
  • Ensure you get feedback on the demoed items - if no other way works, ask direct questions.
Key points
  • The key purpose of the demo is to inform, communicate, and to get feedback from stakeholders and other teams.
  • You may record the session for viewing at other times.
  • Show only Done items.
  • In larger programs, it is also good idea to consider a program-level common demo.

6. The new Scrum Master checklist

The most important things to do as new Scrum Master are:

Read this guide completely.
Find and bookmark the scrum guide and read it the first time(you should return to it regularly to reflect on your skills and progress).
Agree with your Product Owner on who will invite to the team ceremonies. (If you don’t know who the Product Owner is, talk to your manager and halt the process here while you get a name.)
Book all the team ceremonies. Make the ones that can regular and recurring (which is most of them), in the calendar invitation, and book the necessary meeting rooms or video call arrangements.
Ensure you and your team are well prepared for your first round of team ceremonies with instructions from this guide.
Enjoy your Scrum Master role! You are a key player on your team’s road to successful scrum!

Recommended further reading

  • Scrum Field Guide
  • The Happiness Advantage
  • Refactoring
  • Finish
  • Agile Retrospectives
  • The Phoenix Project
  • The Unicorn project