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!
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:
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.
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.)
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.)
If so, the Product Backlog items in question may no longer be valuable. Consider re-refining or deleting them.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
A Scrum Team should know its velocity or productivity, how could it otherwise possibly improve?
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.
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.
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?)
This closing question is by design an open-ended question to get some ideas for the next Sprint Retrospective.
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.
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.
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
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.
TL; DR: System-Level Scrum Stakeholder Anti-Patterns Learn how outdated organizational structures manifest themselves in system-level…
TL; DR: Scrum Master Tasks: Let's Bust Some Myths! Rumor says that a great Scrum…
TL; DR: Scrum Master Interview Questions on Creating Value with Scrum If you are looking…