20 Questions New Scrum Masters Should Ask Their Teams to Get up to Speed
TL; DR: 20 Questions a New Scrum Master Should Ask
Twenty questions for you — the new Scrum Master — that fit into a 60 minutes time-box. Start learning how your new Scrum Team is currently delivering the product and get up to speed: from Product Backlog forensics to metrics to team challenges and technical debt. Download a printable template for your convenience.
Do you need to talk to your Product Owner? Here you go: 20 Questions from New Scrum Master to Product Owner.
🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 33,000-plus subscribers.
🎓 Join Stefan in one of his upcoming Professional Scrum training classes!
Start Learning the Ropes as a New Scrum Master
I was recently asked to participate in the Product Backlog refinement of a team that was looking for a new Scrum Master. I was skeptical in the beginning. I had only limited knowledge about the project—a commercial website based on a CMS—, the refinement session was time-boxed to 60 minutes, and I hadn’t met the team members before beyond a very brief “hello.”
So, I prepared a questionnaire comprising team-related topics. I wanted to learn more about and listened to the Scrum Team, refining several work items. When appropriate, I asked one of the prepared questions. Surprisingly, the insights turned out to be much more qualified than I expected. Particularly, I could identify the low-hanging “Scrum fruits” to improve product delivery relatively easily. Remember that as a Scrum Master, the stakeholders will always judge you by whether “your Scrum Team” can deliver a valuable, potentially releasable, “done” Product Increment regularly.
The questionnaire I used as is available as a download for your convenience:
Cannot see the subscription form?
Please click here
Let us get into the questions for a new Scrum Master:
- How large is your Product Backlog?
I do not believe in Product Backlogs that are larger than what the team can handle in three, maybe four Sprints. If the Product Backlog exceeds this threshold, the Product Owner might be in need of some support.
- What is the typical age of a Product Backlog item?
A Product Backlog item that has not been touched in five months is obsolete. Cluttering the Product Backlog with ideas, reminders, or other low-value items increases the noise, thus probably impeding the value delivery of the Scrum Team. (Admittedly, I am a fan of Product Backlog forensics.)
- What is your average lead time from an idea being added to the Product Backlog to its delivery?
No one could answer that question in the before-mentioned session. But it is actually one of only a few metrics that can provide some insight on whether Scrum has been successfully adopted by your organization. (Read more: Agile Metrics — The Good, the Bad, and the Ugly.)
- Does your Product Backlog contain work items none of the current team members is familiar with?
If so, the Product Backlog items in question may no longer be valuable. Consider re-refining or deleting them.
- How often are you refining the Product Backlog?
That should be a continuous process. As a new Scrum Master, however, I would love to have a Product Backlog refinement session once a week with the whole team.
- On how many Product Backlog items are you working in parallel during Product Backlog refinement?
Ideally, a team should not be working on more work items than it can handle within the next two or three Sprints. Otherwise, the risk of allocating resources on work items that may never make it into a Sprint Backlog becomes too high.
- How long does the refinement of a typical Product Backlog item take?
The refinement should not be taking more than one to two Sprints. Otherwise, the Product Owner might need some support in preparing ideas properly for the refinement sessions.
- How are you creating Product Backlog items? (Is it a joint team effort with the PO, or is the Product Owner writing the work items and the Development Team estimates them?)
There is a tendency to observe that Product Owners become more a kind “technical writer” of Product Backlog items, which then get estimated by the team. I suggest, however, to turn Product Backlog item creation into a joint effort of the whole team. Remember Ron Jeffries’ CCC: card, conversation, confirmation?
- Where are you discussing Product Backlog items? (Only during refinement sessions or also on Slack or via comments on tickets, for example?)
Every team has its own habits, and maybe commenting in Confluence, Jira, Github, or utilizing Slack is an effective means of communication in your organization. As long as this happens before a work item is selected for a Sprint Backlog, this should be fine. Discussing its essentials afterward is a problem, though, as the Sprint Goal might be compromised.
- Who is writing acceptance criteria and in what format?
It should be the Product Owner in collaboration with the Development Team following the Definition of “Done,” thus creating a shared understanding of what the team needs to build.
- How are you estimating the likely effort of a Product Backlog item?
There are plenty of practices on estimating a work item if your Scrum Team estimates at all. (Think of #noestimates or creating similarly sized work items instead.) The emphasis should be on creating a shared understanding among all team members what shall be created. An estimate is a side-effect, not the primary purpose.
- Are you estimating in man-hours or story points?
Estimating in man-hours is better than not estimating at all. However, I prefer story points, particularly if the application in question is burdened with legacy code and/or technical debt. Predictability and stakeholder communications become easier this way as story points have a built-in buffer.
- How are you practicing the estimation process if the team shares different opinions?
Preferably, you should observe the team’s estimation process in real life. But in case you have to ask: is it a typical vote-discuss-revote cycle? Or: when and how do you pick an estimate? (Examples: 50:50 split, e.g. 3*3 and 3*5 – which one do you take? Or a majority split: 2*3 and 4*5. Or the estimations cover a range, e.g. from 2 to 8?) It is a good way to learn more about the team building state, too.
- What is a typical distribution of work item sizes in your Sprint Backlog?
This question tries to figure out, where the productivity sweet spot of the team is, based on the Sprint Backlog composition. In my observation, Scrum Teams often work more successfully when a Sprint Backlog comprises one or two larger Product Backlog items, some medium-sized stories, and a few small ones.
- Are you re-estimating work items at the end of a Sprint? If so, under which circumstances are you doing so?
That should always be done if a Product Backlog item turns out to be way off its original estimation. Re-estimates make good data-points for Sprint Retrospectives, too.
- What was your velocity for the last three Sprints?
A Scrum Team should know its velocity or productivity, how could it otherwise possibly improve?
- How many user stories are typically not finished within a Sprint and for what reasons?
If the team is bullish and picked more Product Backlog items than it could probably handle at the beginning of the Sprint, so be it—nothing to worry about if the Development Team meets the Sprint Goal nevertheless. If the Development Team, however, is regularly leaving work items on the board and not meeting Sprint Goals, this should be a major concern for the new Scrum Master. See also: Scrum: The Obsession With Commitment Matching Velocity.
- Are you changing Product Backlog items once they become part of a Sprint Backlog? And if so, under what circumstances?
Making work items smaller if the Development Team runs into a problem is certainly not great, but acceptable—if the work item in its reduced form still delivers value and the Sprint Goal is met. Extending it after the Sprint Planning, however, would only be tolerable if the Development Team agrees on the extension, and the Sprint Goal will not be compromised.
- How would you consider the level of technical debt?
As a new Scrum Master, you want to know everything about the current level of technical debt and dependencies on other Scrum Teams or external suppliers. These issues are directly responsible for your Scrum Team’s ability to deliver product Increments. (Read more: Technical Debt & Scrum: Who Is Responsible?)
- What are the three main challenges the Scrum Team is facing today?
This closing question is by design an open-ended question to get some ideas for the next Sprint Retrospective.
Conclusion — The New Scrum Master and the Scrum Team
What is your preferred technique to get familiar with a new Scrum Team as soon as possible? Where do you start? Please share your experience in the comments.
✋ Do Not Miss Out: Join the 8,000-plus Strong ‘Hands-on Agile’ Slack Team and Learn more about Agile Metrics
I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
If you like to join now all you have to do now, is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.
📖 Related Posts
20 Questions from New Scrum Master to Product Owner
Agile Failure Patterns In Organizations
Hiring: 38 Scrum Master Interview Questions To Avoid Agile Imposters
Agile Metrics — The Good, the Bad, and the Ugly
Why Agile Turns into Micromanagement
📅 Scrum Training Classes, Workshops, and Events
You can secure your seat for Scrum training classes, workshops, and meetups directly by following the corresponding link in the table below:
See all upcoming classes here.
You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.
Tags: Development Team, Scrum Master