20 questions 29 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.
Start Learning the Ropes in 60 Minutes
I was recently asked to participate in the product backlog refinement done by 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 with topics I wanted to learn more about and listened to the team refinement 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.
29 Questions for the Team to Get a New Scrum Master Up to Speed
- 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 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 I have been working on it ever 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 refinement 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 refinement? 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 to user stories that may never make it into a sprint backlog becomes too high.
- How long does the refinement of a typical user story take? The refinement 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 of a kind of “technical writer” of user stories which then get estimated by the team. I suggest, however, turning user story creation into a joint effort of the whole team.
- Where are you discussing user stories? 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 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? 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 the 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 built.
- 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 become 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 do 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 story turns out to be way off its original estimation.
- What was your velocity for 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 be 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 of concern. See also: Scrum: The Obsession With Commitment Matching Velocity.
- Are you changing user stories once they 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 value. Making it larger after the sprint planning is, however, not acceptable.
- What are the obstacles the team is facing today?
- What are the dependencies on other teams? And if there are dependencies, are you waiting for other teams to complete their tasks? (Kudos to Deepak Karanth for suggesting #21 and #22.)
- Define and discuss at least three key team goals for the project. Some of the answers may seem obvious, i.e. meet our deadline within our budget, but this discussion can often bring out other goals which are not obvious to the Team initially. It can help the Scrum Master understand Team motivations and dynamics.
- What are the key success factors to achieving our team goals? Defining and discussing key success factors, i.e. minimizing the impact of dependencies, can help identify project-level impediments, risks, and issues that the Scrum Master can begin to address. It also is a good benchmark to review and update as the project progresses.
- What do team members hope to achieve with this project? I like to get a sense of people’s personal goals for the project in addition to the Team goals we will establish collaboratively. Having this information can help keep people motivated over the course of the project. Some people may want to learn new technologies, be part of a high-performance Agile Team, or have other goals.
- What type of work environment do we want to create on this project? This question can stimulate good discussion about how Team Members want to interact with each other to achieve the project goals. Often the discussion centers on trust, communication, collaboration, and respect, but it’s good to make sure there is some agreement (or an acceptance of differences) by the team about what is important.
- What can we do as a team to make sure that we support each other to achieve our team goals? This question can help the Scrum master understand how team members understand the importance of making commitments as a team rather than as individuals. It can also help the team establish informal agreements about the need for everyone to support each other, take on roles outside their specialty, and trust their team when they need to ask for help.
- What should we do when we are not achieving our goals or not supporting each other? Obviously, this can be addressed in a retrospective, but having the discussion early can be helpful to understand how team members perceive how these situations should be handled. It can help establish the need for open and honest communication built on trust.
- How should we celebrate success in achieving our goals? It’s important for the team to visualize and expect success. This discussion can help the team discuss rewards that are meaningful and keep them focused on realizing those rewards. (Kudos to Thomas Huff for contributing #23 to 29.)
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.
