How would you introduce Scrum to senior executives?
This is a deliberately open question meant to encourage discussion. In answering this question, your candidate should elaborate on how they would spread an agile mindset throughout an organization or, ideally, and more specifically, how they would create a learning organization that embraces experimentation in order to identify the best product for its customers.
A good candidate is likely to talk about the necessity of ‘selling’ agile to the organization in order to win the hearts and minds of the stakeholders. They will also point at the necessity to find a high-ranking executive to sponsor the transformation.
At the beginning of a transition any organization shows inertia to change, so to overcome this resistance executives and stakeholders need to know how Scrum will benefit them before they’re likely to make a commitment. (Read more: The Big Picture of Agile: How to Pitch the Agile Mindset to Stakeholders.)
One practical approach when introducing Scrum to senior executives is to organize workshops for higher management levels. Applying Scrum at the executive level has been successful in the past. Executives, and potentially even key directors, can gain a first-hand experience with agile practices if organized as a Scrum Team.
There is no right or wrong answers to this question. Good practices need to take into consideration an organization’s culture, size, product maturity, legal and compliance requirements, and the industry it is operating in.
With what metrics would you assess the value of a user story?
There are quantitative as well as qualitative measurements that may be used to assess the value of a user story or whether the investment is worthwhile. These may include, for example:
Revenue increases,
Cost-cutting benefits achieved by internal process improvements,
Increases in customer satisfaction rates (NPS),
Increases in signups for new products, or
Positive customer feedback received by the customer care team.
How would you create the first Scrum team?
When an organization is transitioning to Scrum and at the same time dealing with significant organizational, business, and technical problems, the founding members of its Scrum Teams should be volunteers who fully understand the challenge ahead of them, rather than people pressed into service. The best volunteers are those eager to prove that becoming agile is the most effective way to reach an objective.
Candidates for the role of Scrum Master should be astute enough to suggest inviting every member of the product delivery team, as well as the C-level executives sponsoring the transition, to a kickoff meeting. The objective of a transition kickoff meeting is to support the members of the engineering and product teams in how they choose to self-organize into the first cross-functional Scrum Teams. Transition kickoff meetings can last a few hours or several days, depending upon the circumstances of a particular organization.
Despite the importance of the kickoff meeting to a Scrum transition, going much deeper into its structure will take too much time from the interview. It’s more important that your candidates embrace the idea of team self-selection and present a brief roadmap of what should happen next for the newly formed Scrum Teams.
Although somewhat dependent upon the existing skills, experience, and training of the members of an organization’s new Scrum Teams, your candidates should anticipate having to teach the very basics of Scrum following a kickoff meeting. They might propose doing this through a series of workshops or on-the-job training with exercises in Product Backlog refinement, writing user stories, estimating, creating boards, and setting up collaboration software.
How a Scrum Master track the progress of a Sprint?
There are multiple tools like Burn up, burn down but most famous is Burn down charts. Here we check daily the amount of work remaining compared to the planned. Here in below burn down chart the Orange line is ideal burn down rate per day required to finish things on time and gray like is the actual remaining to finish things recorded every day, especially during the Daily Scrums.
How do you deal with scope creep in Scrum or Agile Teams?
Any incomplete work getting postponed to the next sprint is called scope creep if it happens regularly. The work gets postponed to the upcoming sprints and we never catch up. This can be due to many factors like
Unclear requirements accepted in Sprint
Skills not available
Definition of Done is not clear
No intermediate and immediate Demo to PO and last minute changes suggested
Acceptance criteria keep changing
Silos in requirement implementation in place of combined ownership
Improper or no Backlog refinement
To prevent it:
A proper and effective retrospective to understand the root causes and eradicate the top reasons for creep
The requirements must be clearly specified with acceptance criteria
Daily progress monitoring by team during Daily Scrum.
Effective backlog refinement of sprint backlog must be done.
Combined ownership of features/stories so that we focus on work completion than individual ownership and silos
A member of the Scrum Team does not want to participate in Sprint Planning and considers the meetings a waste of time. How do you deal with this attitude?
If the member of a Development Team does not want to participate in Sprint Planning and considers the meetings a waste of time, they’re exhibiting a type of passive-aggressive behavior. Although not particular to Scrum, this is a problem because the underlying attitude is toxic and will affect both team-building and team performance as now the knowledge of a team member will not be available at Sprint Planning.
When the member of a Development Team behaves as described, the team’s Scrum Master needs to take action. Counterproductive behavior can neither be ignored nor tolerated if the team is to continue functioning. Effective action is likely to require probably a series of escalating steps:
The Scrum Master may start by addressing the team member privately to discuss their reservations and, perhaps, more coaching needs or a longer training period.
Following private discussion, the entire Scrum Team can be involved by making the team member’s reservations a topic of discussion during one or more Sprint Retrospectives. This enables the Scrum Team to offer their support to their teammate.
If there is still no change in the team member’s attitude, a meeting with the team member and their line-manager is advisable.
If no change can be achieved, it might be possible to reassign the team member to another (probably non-agile) team, or to a Kanban team unlikely to force the team member out of their comfort zone.
Situations such as described highlight how Scrum is not meant for everybody.
How do you approach Daily Scrums with distributed teams?
Daily Scrums for Development Teams whose members are distributed between different offices or working remotely are not much different from Daily Scrums for Development Teams whose members are co-located. The exception is that distributed teams sharing board activity may require video conferencing when working with offline boards that mirror each other.
If a Scrum Team is using online task management or planning software like JIRA, the team’s boards can be online and updates can take place on-screen. This generally makes it easy for members of a distributed team to follow board activity. With online boards in place, a Zoom or Google Hangouts call will likely be enough for a distributed team to have their Daily Scrum.
Alternatively, the Development Team may try an asynchronous Daily Scrum by utilizing messenger software like Slack. It is the prerogative of the Development Team to decide on the best way of handling their Daily Scrum event.
If your team is picking reasonable action items but not delivering, how would you address the situation?
During a Sprint Retrospective, the members of a Scrum Team would usually pick some action items — tasks to be done — and include them in the upcoming Sprint Backlog. If these action items are subsequently not completed in a timely manner, the Scrum Master needs to follow up.
A team might not be completing the action items they’ve picked because they’ve run into an external impediment. If this is the case, the Scrum Master has to address the cause, and the team can then catch up during a later Sprint.
However, if there is no external impediment, the problem is likely due to motivation, attitude, or personal issues within the Scrum Team. In this latter case, the Scrum Master needs to provide the team members with sufficient encouragement or motivation to overcome the problem — a Scrum Team is self-organizing.
If a team is not completing the action items they’ve picked and the problem ultimately cannot be resolved, picking action items becomes a useless exercise and the Scrum Team’s continuous improvement effort will suffer as a result.
What does a good user story look like? What is its structure?
A good user story:
Includes a description,
Has acceptance criteria defined,
Can be delivered within a single Sprint,
Has all UI deliverables available,
Has all (probable) dependencies identified,
Has performance criteria defined,
Has tracking criteria defined, and
Is estimated by the Scrum Team.
How do you promote an agile mindset across departmental boundaries and throughout an organization and, in pursuit of that, what is your strategy when coaching stakeholders not familiar with IT?
There are various tactics a Scrum Master can use to engage stakeholders with Scrum, for example:
Most importantly, a Scrum Master should live and breathe the principles of the Scrum Guide and the Agile Manifesto. They should talk to everyone in the organization involved in building the product, and they should be transparent about what they do. (Read more: 10 Proven Stakeholder Communication Tactics During an Agile Transition.)
Product and engineering teams can produce evidence proving to stakeholders that Scrum is significantly reducing the lead time from idea to product launch.
Product and engineering teams can demonstrate that Scrum mitigates risk (i.e. the forecast of when new features could be made available), thus contributing to other departments’ successes in planning and execution.
A Scrum Team can be transparent with respect to their work and proactively engage stakeholders by inviting them to Sprint Reviews and other events where the team communicates their activity or progress.
Training for everyone in the organization, particularly the stakeholders, is important. One hands-on approach is to organize workshops designed to teach agile techniques for non-technical colleagues.