TL;DR
20 questions for you — the new Scrum master — that fit into a 60 minutes time-box. Start learning how the new Scrum team is currently working and get up to speed. Download an easy printable template for your convenience.
Start Learning the Ropes in 60 Minutes
I was recently asked to participate in the product backlog grooming 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 grooming 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 with topics I wanted to learn more about, and listened to the team grooming several user stories asking questions from the list when appropriate. Surprisingly, the insights turned out to be much more qualified than I expected. Particularly, the low-hanging (user story and Scrum improvement) fruits could be identified rather easily.
20 Questions for the Team to Get A New Scrum Master up to Speed
These are the 20 questions I prepared for the backlog grooming session, half of which I actually asked. You can download them as a PDF (without the comments), print and use them for yourself. If you do so, I would appreciate your feedback how this worked out for you and what questions you would add to the list. (Please note that downloading the PDF will also subscribe you to our weekly hand-curated newsletter, if you haven’t yet signed up already. You can unsubscribe at any time.)
- 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 for some support.
- What is the typical age of a user story in the product backlog?
Again, I do not believe in the value of a user story that is 5 months old. And a “but have been on it since” is an excuse in my eyes.
- 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 three metrics that can provide some insight on whether “agile” has been successfully adopted by your organization.
- Does your product backlog contain user stories none of the current team members is familiar with?
Maybe those should be re-estimated with the current team members to make sure the estimation is still accurate?
- How often are you grooming the product backlog?
That should be done at least once a week depending on the state of the project.
- On how many user stories are you working in parallel during backlog grooming?
Ideally, a team should not be working on more user stories than it can handle within the next two or three sprints. Otherwise, the risk of allocating resources on user stories that may never make into a sprint backlog becomes too high.
- How long does the grooming of a typical user story take?
The grooming should not be taking more than one to two sprints.
- How are you creating user stories? (Is it a joint team effort with the PO or is the product owner writing the user stories and the team estimates them?)
There is a tendency to observe that product owners become more a kind “technical writer” of user stories which then get estimated by the team. I suggest, however, to turn user story creation into a join effort of the whole team.
- Where are you discussing user stories? Only during grooming sessions or also on Slack or via comments on tickets, for example?
Every team has it 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 user story is selected for a sprint backlog, this should be fine. Discussing its essentials afterward is a problem, though.
- Do you apply a “definition of ready” standard to your user stories?
That should indeed be a standard. A volatile velocity can at least partly be attributed to the lack thereof.
- If so, of what criteria is your “definition of ready” composed of?
Typical criteria for a “definition of ready” are: The description is available, acceptance criteria are defined, the story can be delivered within a sprint, all UI deliverables are available, all (probable) dependencies are identified, performance criteria are defined, tracking criteria are defined and the story is estimated by the team.
- Who is writing acceptance criteria and in what format?
It should be the product owner in collaboration with the team to create a shared understanding of what needs to be build.
- How are you estimating the likely effort of a user story?
An estimation poker would be useful.
- Are you estimating in man-hours or story points?
Estimating man-hours is betting than not estimating at all. However, I prefer user story points, particularly if the application in question is burdened with legacy code and/or technical debt. Predictability and stakeholder communications becomes easier this way as they are featured with 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 story sizes in your sprint backlogs?
This one tries to figure out, where the commitment sweet spot of the team is, based on the sprint backlog composition. To my observation, teams often work in a more successful way, when a sprint backlog comprises of one or two larger user stories, some medium sized stories and a few small ones.
- Are you re-estimating user stories at the end of a sprint? If so, under which circumstances are you doing so?
That should always be done if a user stories turns out to be way off its original estimation.
- What was your velocity of the last three sprints?
The team should know its velocity, 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 user stories than it could probably handled at the beginning of the sprint, so be it—nothing to worry about. Also, there are other incidents that might negatively affect the team’s actual velocity, e.g. sick leave or a critical bug a few days into the sprint. If the team, however, is regularly leaving user stories on the board because estimations were wrong, this is a sign for concern. See also: Scrum: The Obsession With Commitment Matching Velocity.
- Are you changing user stories once they are become an item of a sprint backlog? And if so, under what circumstances?
Well, making them smaller if the team runs into a problem is certainly not great, but acceptable—if the user story in its reduced form still delivers a value. Making it larger after the sprint planning is, however, not acceptable.
What Is Your Best Practice as a New Scrum Master to Understand How a Team Is Working?
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.
Are Questions Missing?
If you consider additional questions to be useful, please let me know and I will update the list. (And the related PDF.) Thank you in advance!
Business & Finance Articles on Business 2 Community(87)
