The Scrum Master’s field guide to a newly formed scrum team — first steps
This guide is a list of suggestions you can implement as a Scrum Master when you are joining a newly formed scrum team. However, many of the suggestions described here may be useful in case you become Scrum Master for an existing scrum team.
First things first
In general, avoid using buzzwords when you explain the events and artifacts in scrum. Use your own words — it deepens your understanding too. Use planning for life events as examples everyone can relate to; planning a birthday party for example.
Remember to be patient. It is a newly formed team and it takes time for people to understand a new way of working. Don’t expect them to get it quickly — consider how long it’s taken you to get to your level of understanding.
Be kind, be respectful, be fair, be firm. You are there to help them, support them, and guide them on your mutual learning journey.
Be honest and transparent about your work, your observations, your thoughts.
Listen to your team. Listen to each individual team member. Listening is an essential part of your work.
Listen with the intent to understand,
not to respond.
— Stephen Covey
Don’t become the bottleneck in your team’s learning journey by taking on tasks they should do just because you want them to accept or respect you. It might have the opposite effect entirely.
Expect to make mistakes. Make amends, learn from them, share the learnings with others. Move on. You’re only human after all.
Do a regular health check of your own ways of working with the team. Ask for feedback from your team members and your peers. Adjust. Take your own medicine and take ownership of your own development.
Mindfully choose where and how your effort can give the most impact for your team. Learn from your peers. Study. Reflect. Experiment. Adjust.
Stay humble. Stay curious.
Lead by example.
How to read this guide
Reading the official Scrum Guide again is always a good idea. You will probably find new things you haven’t noticed before? Now is a good time to refresh your memory.
This guide here doesn’t replace the Scrum Guide but acts as a companion.
In the sections below I mention the tool JIRA which is an electronic tool for managing the product backlog items and the sprint backlog. Any tool will do — even paper based ones. JIRA is not a necessity.
Also, when I mention user stories in this guide it represents work to be done. These items are called artifacts in the Scrum Guide.
In a Scrum team there are three roles; The product owner (PO), the development team, and the Scrum Master (SM). In my personal view the PO and the SM are full time positions and they should not be part of the development team executing the sprint backlog. Note here, that the Scrum Guide mentions the PO and the SM as roles, not positions — and thus leaving any variation open.
The Product Owner
Start by talking with the PO about the roles and responsibilities of each role in a Scrum team.
- Provide a link to the scrum guide section on the role of the product owner.
- Send the PO the article “4 Daily Scrum Tips for Product Owners” by Roman Pichler. Read it yourself as well…
- The PO must be reachable; In the name of collaboration, the development team and the PO will need to collaborate on a regular basis on reviewing work done by the development team - as well as the team’s understanding of the items in the product backlog.
- The PO and the development team must share a common understanding of the work to be done. Having acceptance criteria in the user stories helps greatly with this understanding.
At the end of the sprint if the work done didn’t have the expected impact, it’s up to the PO to create a new user story in the product backlog with the desired outcome and proper description. The development team is not to blame for misunderstanding the user story.
- There is no need for the PO to approve or accept the user stories once they’ve been pulled in the sprint by the development team. The development team decides how to achieve the described outcome.
- Tell that the PO could benefit from listening in on the daily scrums to get a sense of the team’s work progress towards the sprint goal. Note it’s not mandatory for the PO to come to the daily scrum.
- The PO must continuously work on preparing upcoming work; Clarify the understanding that the PO is to define and create the product backlog items as preparation for the upcoming sprints.
- The PO must prioritize the product backlog regularly based on customer feedback and business needs.
- Have the PO think about a product vision for the Scrum team which can be presented and discussed in the session on alignment of expectations.
- Build a good and healthy relationship with the PO.
- You are there to guide, teach and protect.
- Like you, the PO is there to protect the team from outside influences.
- The PO is funding the product development being done by the team.
Alignment of expectations
Book a session with the entire team about alignment of expectations to the three different roles in a scrum team.
- Have the PO present the initial product vision for the team. Have the team reflect on it, discuss and agree. Document it somewhere visible on a wall next to the team.
- As preparation for the meeting, provide a link to the Scrum Guide section on the Scrum Team.
- The purpose of this session is to give the team an overview of roles and responsibilities.
- Discuss expectations to you as their SM as well as development team’s expectations towards each other and the PO.
- Discuss and document team working agreements. Write the agreements on a big poster together with the team and hang it up afterwards beside the team.
- Take notes for yourself on each team member’s expectations to you. Those notes come in handy afterwards, so you can customize your teachings to those team members specifically based on their needs.
- Have the team come up with a good team name. Delegate the creation of the team banner. Let them take ownership of their new identity.
Lead by example
- Tell them that you are there to support them in creating value to the customers. You are not part of developing the product or responsible for the delivery of the product. You are a facilitator and a process holder.
- Tell them you will set up a structure for them to work within in terms of tools and processes.
- Tell them in order to constantly improve, you will help them evaluate ways of working in the team on a regular basis. This also includes evaluation of the collaboration with the rest of the organization surrounding it.
- Tell them that you expect the development team and the PO to take over these tasks and ownership of them eventually. As a SM you may not be able to or wish to attend all scrum events.
Those tasks include their daily use of JIRA, the writing of user stories after sprint planning, and them removing roadblocks/impediments.
- Include team members in all the work you do for them, especially show them how you help remove impediments.
Session on ways of working
Set up a session with the new team on ways of working. Come prepared with posters of the different Scrum events. Make them beautiful.
Even prepare a few quick games for the team to learn about requirements, communication and collaboration.
The outcome of this session should be that the development team and the PO share a common understanding of the events and artifacts in scrum;
- The why
- The when
- The frequency
- The who does what etc.
- Especially the end-to-end value creation responsibility of the development team
- Explain the cycle in scrum; sprint planning, daily Scrum, product backlog refinement, sprint review, and sprint retrospective.
- Explain that you will help them calculate the team’s sprint capacity based on their availability.
- This first calculation only acts as a starting point. We must start somewhere, right?
Facilitate the creation of the team’s Definition of Ready (DoR)
- The DoR documentation is created and maintained by the Product Owner in close collaboration with the development team.
- Get the team members involved in the creation of a poster. Hand one of them the whiteboard marker. Watch the magic happen.
Facilitate the creation of the team’s Definition of Done (DoD)
- Facilitate the creation of a definition of done for the team’s work.
- Explain what it is
- And why it is needed. It gives us satisfaction when our delivery lives up to all the acceptance criteria.
- Involve the team members in the creation of the poster.
- The DoD documentation is created by, maintained by and is for the development team.
The development team must check that the work they’ve completed must live up to the acceptance criteria defined in the sprint backlog item. This task should be a natural part of the team’s DoD.
Production incidents, bugs and defects
Explain that production incidents always take priority over any work in progress in the active sprint.
- Adjust the sprint backlog items accordingly.
Defects found in the work developed in the active sprint are to be solved in the active sprint. “Working software” at the end of the sprint is the main goal.
- The user story status is changed back to in progress.
Bugs found in work finished in a previous sprint are to be:
- and added to the product backlog for prioritization.
Anyone in the scrum team can add stories to the team’s product backlog.
On the sprint planning event
Only stories that live up to the DoR can be pulled;
- Let the PO and the development team know that only user stories that meet DoR can be pulled in the sprint. Refinement of user stories in the sprint planning should not take place unless requirements have changed since last backlog refinement session.
- It is up to the development team to determine if they are comfortable pulling the user story into the sprint.
- Explain that a sprint goal acts as a guiding star during the entire sprint as to what the outcome should be.
- Only user stories that accomplish the sprint goals should be pulled in and worked on in the sprint.
- In scrum the PO defines the sprint goal before or during the sprint planning.
Tell them about the use of estimation of user stories;
- The use of Fibonacci number sequence to reflect risk and work effort;
- Relative sizing
- and perhaps the use of reference stories.
As part of the first sprint planning event teach the team how estimation can be done. Or even better, at the first backlog refinement session.
Just remember that the use of story points is not part of the official Scrum Guide.
On the daily scrum
Tell them about the timeboxed event;
- Max 15 minutes for the team to update each other on the progress towards the sprint goal.
- Explain why it’s not a status meeting.
- Explain who from the scrum team must participate (the development team) and who can attend (the PO, and other stakeholders).
- Tell them that you will start facilitating the daily scrum, but you will hand over the responsibility to the development team after a while.
On the backlog refinement sessions
Align expectations on the level of details in the user stories.
- The PO must convey just enough information for the development team to understand the customer needs.
- PO must provide contact information where the team can get more information.
- Analysis and requirements gathering is part of the development team’s daily work.
Tell the team that as part of the product owners’ preparation for the product backlog refinement sessions, the PO may occasionally need help from a team member to refine a user story. Explain this to the development team as it’s part of their work during a sprint.
Explain that the outcome of the backlog refinement sessions is that:
- the top priority product backlog items live up to the Definition of Ready (DoR) and thus ready to be pulled.
- And of course, that the development team understands the desired outcome of the user stories.
Tell the development team that it is a good practice for the development team to look at the top prioritized product backlog items together before the refinement session to familiarize themselves with the content. This speeds up the backlog refinement sessions.
On the sprint review session
Tell them that the development team and the PO should remember to set aside time for preparation of the sprint review;
- Who in the team should present what and how.
- Preparation time is part of their daily work.
The PO is responsible for inviting relevant stakeholders to the sprint review. Help the PO explore and define who are the main stakeholders to invite.
The Scrum Master protects the team
- Any direct request from outside the team to a team member must be directed to you as Scrum Master or preferably to the PO.
- Respect their time. They need focused time to be creative and do their job skillfully.
Protect against scope creep
- Explain that you will try to ensure that scope creep doesn’t happen during the active sprint; What the development team committed to do should stay untouched.
The Scrum Master helps the PO
Health check of the product backlog:
Tell the PO that you will help do a health check of the product backlog items regularly in terms of definition of ready. Not to challenge the needs described but to
- ensure a proper item size
- and proper description
- and well-defined acceptance criteria
- ensure that all items have business value
- perhaps make use of the INVEST or SMART ways of describing the work needed
Also, explain that you will help the PO ensure that the product backlog doesn’t become too large, and thus loose the overview of the outcome that we want to achieve.
The first few sprints
As a good practice, ask the team why we have these events. Let them explain and explore. If you don’t get the response you expect, explain.
The sprint planning — “Get in. Get out. Get started.”
The purpose of sprint planning is to select a set of product backlog items to work on and have a rough idea of how to achieve them.
The sprint backlog is a forecast made by the development team based on the knowledge they had at the time of sprint planning.
The PO explains the top priority backlog items briefly. The development should be familiar with the items already.
As your preparation for this event, read Mike Cohn’s article about the sprint planning event. You might want to share the article with the team for their understanding.
Bring the excel spreadsheet with the calculated sprint capacity. Remind them that the capacity calculation is a best guess at this point.
Have the team calendar readily available to look at.
For an explanation of the capacity calculation and the team calendar, see the section below called “One-time administrative tasks”.
- Remind the team that we start up with using man days as story points.
- Help the team estimate the user stories/items one at a time.
- Use the Fibonacci number sequence 1,2,3,5,8,13 etc.
- Help the team split the user story if estimations are too high. Split by acceptance criteria?
- Ask the team to assess if splitting user stories into tasks makes sense
If needed the development team may break the user stories into tasks. Sometimes it makes sense to estimate the tasks in hours. As a rule of thumb, a single task should never exceed a working day.
Help the team do a sanity check. Using the team calendar, help them assess if the pulled items makes sense in terms of the team calendar.
Do a confidence vote at the end of the sprint planning. Facilitate a discussion in the development team if the team is not confident. Adjust sprint backlog accordingly.
The daily scrum
Show them where to find the sprint goals.
- Remind them to align their work to it.
Are we on track?
- On a regular basis make them used to assessing whether they are able to meet the sprint goal.
- Address any concerns to the PO.
Avoid detailed discussions. It’s a planning and alignment session.
- Ask if this is something that can be discussed afterwards.
Make sure you only spend a maximum of 15 minutes. Stop the session after 15 minutes.
The event is an opportunity for a team member to ask for help
- If a user story has been in progress for a long period of time, remind them to reach out for help in the team.
- Keep track of how long a given user story is in progress. Electronic tools like JIRA have that functionality. If you have the individual user stories written on paper, simply put a dot on the post-it every day while it’s in progress.
Teach the team to use and look at the team calendar regularly as part of the planning.
- Any planned leaves, holidays, sprint review coming up that affects the planning?
Ask the team about any updates on the action items from the latest retrospective.
At the end of the event share your observations. What went well, what was unhealthy team work etc.
Can the event be improved? Kindly nudge the team if you can see that they can improve ways of working here. Ask them if the session was valuable and what could be improved. Adjust.
The daily scrum is a great opportunity to gather facts about our WoW.
You should facilitate the daily scrum for the first two or three sprints and then gradually step in the background. Remember to involve your team in that decision early on.
After that, observe how the development team ensures that the event is executed and how. Support them if needed of course.
The backlog refinement
- The PO presents the contents of the product backlog items.
- Development team asks questions to clarify.
- Clarifications and decisions on scope etc. must be documented in the user story.
- Any team member can update the user story. It isn’t restricted to the PO.
- Update the user story on the fly. Don’t wait.
- If needed, remind them of the Definition of Ready
- At the end of the session, ask the development team if they are confident in pulling the items in their current state.
The sprint retrospective
The sprint retrospective is the most important event in scrum. It’s a time where the whole scrum team gathers and has dedicated time set aside for discussing improvements.
Make the retrospective fun for all of you. Prepare a new format that inspires you. Your passion will be reflected in the team.
- Don’t obsess about a specific format. The discussions taking place are the most important.
- A retrospective can be held in a café or while walking two and two.
Make it a safe place to talk and share. What happens in the retrospective, stays there.
Use energizers and make use of a break if necessary.
Bring the poster about the team working agreement if needed.
Ensure that team members bring action items from previous retrospectives.
- Hold the development team accountable for the implementation of those action items; never a single person.
- Have the team give an update on those action items.
Bring the burndown chart. Explain how to read it and discuss the actual sprint progress.
Bring the CFD chart as well. Explain it and discuss it.
- Any trends visible? Compare the CFD to previous sprints.
- WIP limit? How many items are the team working on at a time? Have a discussion about the scrum value of Focus as well as a reminder of switching costs.
- Related articles on understanding the CFD:
“The Cumulative Flow Chart (CFD) in a nutshell”, by Christian Gut
- “Cumulative Flow Diagram”, by Pawel Brodzinski
Topics: be bold and courageous. Talk about the noisy pink elephant in the room!
Help the team narrow down max 2 action items which require little effort but has high impact.
- Every action item must be assigned a driver/lead. As a SM don’t assign it. Ask the team.
- Make sure that it doesn’t necessarily get assigned to the person who brought it up.
- Don’t assign tasks to yourself. You don’t want to become a bottleneck.
Don’t let the team postpone the retrospective because they are too busy. Being too busy is a good problem to discuss at a retrospective. Of course there are unusual situations that may require rescheduling the retrospective.
Remember that the retrospective should be enjoyable by all team members. Even the scrum guide mentions this =)
Remember to celebrate your success as a team.
The sprint review
As preparation for the sprint review, read these articles:
- “Your Sprint Reviews suck, and that’s why!” by Michael Küsters
- “What Could Possibly Go Wrong… With the Sprint Review?” by Luiz Quintela
- Share them with the entire team
Make sure the team collects feedback from the stakeholders during the event and let the PO and development team assess if they should create new user stories in the product backlog based on the feedback.
Inspect and adapt
Was this session valuable to you? At the end of these events, ask the team to do a quick evaluation of the session. Adjust ways of working accordingly.
One-time administrative tasks
Set up a common team calendar:
- Set up a dedicated Outlook team calendar for invites and scrum events, separate from your own. Read this article on why and how to set it up:
“Scrum Events: Who sends out the meeting invitations?” Posted on Scrum.org
- Explain that it can be used for planning purposes by team members by entering absence or planned leave.
- Sprint start and end dates can be added in the calendar too.
- Find and book the same meeting room for all the events if possible. Or at least make sure the daily scrums are at the same place and time every day.
- Remember to add Skype or MS Teams link in every invite.
- Remember to clearly describe in the meeting invite the purpose, agenda and outcome of the scrum events — and who must participate and who should attend.
From that team calendar, create the following invites for the next 3 months:
Daily scrum or whatever frequency you and the team decide — as often as necessary.
- Timeboxed to 15 minutes.
- Find a time of day that suits the entire team. Take time zones into consideration.
Mid sprint review if necessary — or do it as part of the daily scrum — Are we on track?
Product backlog refinement session(s)
- Duration maximum 1 hour per session.
- Book two sessions for a two-week sprint.
- At least have a backlog refinement session as close to the next sprint planning as possible.
- This ensures that the development team has the content fresh in mind so a repetition at the sprint planning can be kept at a minimum.
- Coordinate with other teams when to have the sprint review as they might require feedback from the same stakeholders as your team.
- Have the sprint review on the last day of the sprint.
- Have the sprint retrospective on the last day of the sprint or at least before the upcoming sprint planning.
- Timeboxed to 1 hour for a 2 week sprint.
Have a short session with the team about the shared calendar explaining what it is, show how it is to be used. Let the team do a test run.
Calculate the team’s sprint capacity — best guess
Ask the development team to inform you of any leaves or vacation for the upcoming 3 months.
Based on that, create an Excel spreadsheet where you can calculate the development team capacity for the next 5–6 sprints.
- Never include your capacity as Scrum Master. You are not part of the development team.
- Don’t include the PO’s capacity either unless the PO takes part in the daily work executing the sprint backlog.
- Remember to take public holidays into account — and if you have team members in other countries, include their public holidays too.
- Per sprint, calculate the total sum of man days available in the team.
- Use only 60% of that maximum in each sprint as a starting point for sprint capacity. This leaves a 40% buffer for participating in the scrum events and other tasks.
Setup a physical sprint board
Set up a physical sprint board close to the team.
Discuss with the team which columns or states to include on the board.
If the team also has an online sprint board, make sure to tell them to update their progress there too. We never know whom of our stakeholders might want to follow our progress.
Setup a sprint board in JIRA
Ensure all team members have access to JIRA. Show them where to order access themselves.
Create the upcoming 5–6 sprints in JIRA for the team so they are visible to the development team — especially the PO can benefit from that overview.
- Good practice: Naming convention for a sprint “Sprint 1–13/1–27/1”. This way they can always see when the sprint ends when looking at the “active sprint” view in JIRA.
Remember to give the PO admin access rights so the PO can start and complete or cancel a sprint in the tool. You don’t want to become the bottleneck.
Have a session with the entire team where you show them how to use JIRA;
- creating user stories (issues) and moving them to the different states in the scrum board
- starting and completing a sprint
Tips and tricks
TIP: On the backlog refinement session try having the development team present the user stories to the PO. This makes the development team feel ownership of the product. Also, any misinterpretation will be apparent to the PO and the phrasing of upcoming backlog items can be adjusted accordingly.
TIP: Advanced topic: When the team matures, you may want to suggest to the team that they estimate the user stories already in the backlog refinement session instead of in the sprint planning. And then keep the last refinement session as close to the following sprint planning as possible, so the user stories are fresh in mind. That way the sprint planning session can be executed quickly as no repetition nor estimation is needed.
TIP: During the daily scrum, have a team member follow up on the action items from the latest retrospective instead of you.
Before the daily scrum ask a team member for help. Instead of you following up have a development team member do it for you.
This has several benefits:
- You teach the team member to be aware of the improvements that they decided to implement.
- Secondly when someone gets the question from a fellow team member to whom the team member is accountable, the team member will make an effort to implement the improvement as agreed.
- Finally, by you involving a team member that way you show them a simple but effective technique of holding each other accountable for the work in the team.
Good practice: You want the development team to calculate the team’s sprint velocity.
In terms of predictability, it makes good sense to have an idea of how much work can be done in a typical sprint. Stakeholders and the PO should be particularly interested in this information.
In the beginning it’s perfectly fine that you come up with a way to estimate their sprint capacity, but you want the development team to take that responsibility as soon as possible. You don’t want to become a bottleneck or impediment on the team’s path to self-organization.
- After the first three sprints you should be able to find a trend in the amount of user stories or amount of story points accepted in each sprint.
- Involve the most critical team member in this analysis in order to on-board that team member and have the team member take ownership of the calculation.
- Ask the critical team member for advice on how to predict the sprint velocity based on the previously accepted work. Scrum is all about empiricism.