20 Questions From New Scrum Master to the Development Team
Secrets such as API keys and credentials are sprawled over the git, detecting them inside code can be a challenge and it all begins with selecting the right tool
Join the DZone community and get the full member experience.Join For Free
TL; DR: 20 Questions from New Scrum Master to the Development Team
From Scrum Master to Development Team members, this set of questions addresses the foundations of a Scrum Team's capability to build valuable products: technical excellence and what it takes to achieve this proficiency level. The questions have been modeled after some basic principles that high performing teams have in common—from keeping technical debt at bay to collaboratively creating a Product Backlog.
The Essential Role of the Development Team for the Success of the Scrum Team
No matter whether you picked Scrum for the right purpose—building emergent products in the complex domain—, whether your Product Backlog is actionable 24/7 or whether your Scrum Team is entirely self-organizing. If your technological basis is drowning in technical debt, and the Development Team lacks technical skills, you cannot be successful as a Scrum Team. Therefore, as the new Scrum Master, you need to immediately determine the Development Team’s state of affairs.
The Questionnaire: From New Scrum Master to the Development Team
The following questionnaire has proven useful in a team discussion or as a guide during an individual interview or as the basis for an anonymous survey. In either way, the 20 Questions from New Scrum Master to the Development Team get the discussion going. (You can download a template for your convenience here.)
The questionnaire comprises three topics:
Technical Excellence and the State of Technical Debt
- Who is creating your Definition of ‘Done?’
Typically, it is either the development organization or the Development Team. The question is an excellent bridge to learning about the Definition of ‘Done’ in general; for example, has it regularly inspected and adapted?
- 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?)
- Are you tracking the development of technical debt regularly?
I would expect an experienced Development Team to a) have a good understanding of the current level of technical debt and b) visualize technical debt to ensure its inclusion in any product decisions.
- How much time per Sprint do you allocate to refactoring and bug fixing?
First of all, the need for refactoring and bug fixing should be understood by the organization in general; otherwise, you might be working in a feature factory. Secondly, as a rule of thumb, I would expect the Development Team to spend at least 20 % of their capacity on keeping technical debt at bay to ensure the path to a sustainable level of business agility.
- How are you spreading knowledge among the Development Team members, how are you improving your technical excellence level?
I would assume that the Development Team embraces techniques like pair or mob programming, code mentors, brown bag session, hackathons, etc. If they are not yet practicing those, there is room for improvement.
- Do you have any skill gaps that would require formal training classes to improve your team’s effectiveness?
This question is preparing the Scrum Master for the discussion with the development organization or IT management. A Development Team’s struggle—typical indicators are, for example, missed Sprint Goals, a lot of bugs in the product environment, or a substantial lead time to roll-out a new functionality—might result from a lack of technical knowledge. The allocation of a training budget to the team might hence the way out of the misery.
- Do you have the right tools available—software, hardware, cloud applications—to accomplish the team’s mission?
This question is self-explanatory but points to a critical impediment the Development Team might be facing: inadequate tools for the job it is expected to accomplish. More food for thought for the new Scrum Master to prepare the discussion with the management.
- Are you involved in the hiring process of new Development Team members?
I believe that the Development Team members shall have the final say over who is joining their team. It defies the basic principle of self-organization if outsiders can determine the team’s composition.
Product Backlog Creation and Estimation
- At what stage do you participate in the product discovery process?
It is highly recommended to involve the Development Team as early as possible in the product discovery process. The sooner the Development Team members participate in the process, the lesser the chances are that solutions are pursued that are technically not viable or would not result in a return on investment.
- Have you ever interviewed customers of our product to learn more about their needs?
In most cases, when Development Team members haven’t yet had direct contact with customers of their product, it is a sign of a flawed process not leading to an actionable Product Backlog, thus limiting the Scrum Team’s success potential in the long run. There are plenty of reasons for that: Functional silos within the organization are not collaborating, the Product Owner is not taking collaborative Product Backlog creation seriously, or there is no “Product Owner” in the first place as a steering committee is handling the product design, or the industrial paradigm is still ruling: coders have to code, the business analysts can do the talking, right?
- How often are you refining the Product Backlog?
That should be a continuous exercise. In my experience, it has proven to be useful to have at least one regular refinement event where the whole Scrum Team participates.
- On how many work items are you working in parallel during Product Backlog refinement?
In my experience, a Product Owner should not have the Development Team refine more Product Backlog items than it can handle within the next one to two Sprints. Otherwise, the risk of allocating resources on work items, that may never make into a Sprint Backlog, becomes too high.
- How long does the refinement of a typical work item take?
The refinement should not extend throughout one to two Sprints; context switching perils and work-in-progress limits apply to refinement sessions as well.
- How are you creating work items?
Is it a joint team effort 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 work items which then get estimated by the Development Team. I strongly suggest, however, to turn work item creation into a joint effort of the whole team to create a shared understanding. Learn more: Essential XP: Card, Conversation, Confirmation.
- How are you discussing work items? Only during refinement sessions, or also on Slack or via comments on tickets, for example?
Every team has its 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 the Development Team selects a work item for a Sprint backlog, this should be fine if the Product Owner agrees, too. Discussing its essentials during the Sprint for the first time might be a problem, though.
- Is your Product Owner changing work items once they become a part of a Sprint Backlog? And if so, under what circumstances?
Well, making them smaller, if the Development Team runs into a problem, is certainly not great, but acceptable—if the work item then still delivers value. Making it larger after the Sprint Planning is, however, not acceptable. It is paramount that the Product Owner respects the Development Team’s prerogative to control the composition of the Sprint Backlog.
- 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. (By the way, you cannot ‘not estimate.’ Even when applying #noestimates, you are sizing work items in a way that resembles a kind of estimation. It has just a different label.)
- 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 are the three main challenges the Development Team is facing today?
This closing question is by design an open-ended question to get some ideas for the next Sprint Retrospective.
The interview script supports an initial conversation between the Development Team and the new Scrum Master to speed up the latter. The questions focus on winning traits of high performing, value-creating Scrum Teams. They range from the Definition of ‘Done’ to technical excellence to product discovery to collaboratively creating an actionable Product Backlog.
What suitable questions are missing? Please, let me know so that the list can be extended.
Published at DZone with permission of Stefan Wolpers, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.