How can a Scrum Master contribute to Sprint Planning in a way that enables the Scrum Team to work only on the most valuable user stories?
It is the prerogative of the Product Owner to define the business objective of an upcoming Sprint by identifying and ranking the most valuable user stories in the Product Backlog, and it is the duty of the Scrum Master to support the Product Owner in this. Pursuant, a suitable way for a Scrum Master to support a Scrum Team’s strive to work on the most valuable Product Backlog items is:
To ensure that the Scrum Team is involved in the product discovery process at an early stage;
To ensure that the Product Backlog refinement process is well practiced by both the Development Team members and the Product Owner; and
To ensure that all user stories are created in a collaborative effort between the Product Owner and the Development Team members (the goal being a shared understanding of the user stories and thus joint ownership).
Your candidate should note that although the Product Owner practically outlines the scope of the Sprint, it is the prerogative of the Development Team to address technical debt and bugs during the same Sprint. A Development Team should be able to allocate up to 25% of their available capacity for this.
A valuable user story is lacking the final user interface designs, but the design team promises to deliver on day two of the upcoming Sprint. The Product Owner for your team is fine with that and pushes to have the user story added to the Sprint Backlog. What are your thoughts on this scenario?
Whether an incomplete user story should be added to the Sprint Backlog depends upon the Development Team’s present concerns and experience with the circumstances. In the case of an incomplete or missing user interface (UI) design, for example, if the design team is almost certain to deliver because they have done so in the past, and if the user story is high value, and if the story can be accomplished within the Sprint despite its UI deliverables arriving late, and if the Development Team agrees to it — then an exception may be acceptable.
Beware that exceptions have a tendency to become accepted practices. An organization’s intent on being agile should not be allowed to bypass the Product Backlog refinement and Sprint Planning process. Your candidate should be aware that such situations are not tenable. Furthermore, if the implementation of a work item subjected to such an exception fails, no one will bother to read the fine print and acknowledge that an exception had been made. Instead, they will most likely view the Scrum process itself as having failed.
Your candidates may either accept or reject exceptions to the process. But they should also be able to analyze situations in which exceptions have been made, and explain the collateral damage that the Scrum Team may be exposed to.
Your team’s Daily Scrums are not attended by any stakeholder. Should that change?
Asking this question can easily spark a philosophical discussion about whether stakeholders should be allowed to participate in a Development Team’s Daily Scrums. Try to avoid this.
If stakeholders participate in a Development Team’s Daily Scrums, is it likely to result in a form of reporting that circumvents Scrum rules? Not necessarily. It’s good if some adaptation of Scrum can be made to work for an organization. Allowing stakeholders to participate in Daily Scrums need not be ruled out if the Development Team finds it acceptable. In fact, if stakeholders attend Daily Scrums regularly, this invariably and significantly improves communication between a team and their stakeholders.
So shall a Scrum Master encourage stakeholders to attend Daily Scrums? That depends on the context; your candidate should not rule out their participation immediately.
Should a Scrum Master remove impediments on behalf of the Scrum Team?
A Scrum Master should not be concerned with removing problems that the Scrum Team can solve themselves, no matter how often this requirement is mentioned in job advertisements. If a Scrum Master acts like a ‘Scrum helicopter parent,’ their team will never become self-organizing.
A Scrum Team must learn to make its own decisions. This almost inevitably results in failures, dead-ends, and other unplanned excursions when the team is learning something new. Consequently, in the beginning, a team will need more guidance than usual from the Scrum Master — and of a different kind than exemplified by drawing offline boards (see Questions 31 and 32) or updating tickets in JIRA. Such guidance should not, however, become an exercise in protective parenting — a team must be allowed to learn from their failures.
That being said, there is one area where the Scrum Master is indeed removing problems on behalf of the team. This applies when the Scrum Team cannot solve the problem by themselves, for example, because the issue is an organizational problem. Now we are talking about “impediments.” Only in this situation, the Scrum Master becomes the impediment remover of the Scrum Team.
How do you prevent boredom during Sprint Retrospectives?
When required to attend an uninspiring Sprint Retrospective, members of a Scrum Team will become bored.
There are many possibilities for variation that can be used to prevent a Sprint Retrospective from being boring, and team members from becoming bored. A different location, a different format, and shortening or lengthening the allotted time box are just some of the variations that can be tried.
Scrum Masters might also use a team’s choice of action items to encourage and structure discussions around issues that matter to the team, thus creating engagement through acknowledgment. Web sites like Retromat offer hundreds of different games and exercises to make Sprint Retrospectives enjoyable and valuable for the whole team.
There is no single solution, and consequently no single correct answer, to either boredom or this question. What’s important is that your candidate acknowledges that boredom with routine might become an issue and that there are ways to deal with it.
What are Scrum Masters overall responsibilities?
The Scrum Master:
Is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.
Acts as a servant-leader for the Scrum Team.
Helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t.
It helps everyone change these interactions to maximize the value created by the Scrum Team.
In simple words, SM is a person who believes in Scrum Values and processes and motivates everyone to follow it and creates an environment for everyone to follow it.
Describe the role of a Product Owner?
The Product Owner focuses on the success of the product, ensuring the business value of it. Their main responsibility is to identify and refine the Product Backlog items. Product Owner is the voice of customer for Team and represents customer often. PO keeps product Backlog up to date and guides team on when to deliver what part of Product Backlog.
What are traits of a good scrum master?
A servant leader
Who puts teams needs ahead of his/her
Who fosters leadership in team
A good impediment resolver
Patient listener
Coach to individuals and team
A protector for team
An effective facilitator
Is there a difference between Agile Methodology and the Scrum Framework?
Scrum Framework is itself an approach of Agile Methodology for product development. Agile is a long term process and Scrum is a slow term process. So going with the Scrum makes work more process more efficient by breaking the system into sprints. These Sprints help in delivering quality product in a short time period and adds the value for the subtle approach with Agile Methodology. Their collaborative approach not only gives quality product but also helps to remove blockages very easily with high efficiency.
Agile and scrum are two different approaches and so here are some differences between features of both of them:
Agile development is based on the iterative and incremental approach and with Scrum Framework it is implemented a way with which incremental builds are delivered to customer every 2-3 weeks.
Agile gives a leader and Scrum is mostly dependent on self-organised cross-team functioning. Eventually when both have a collaborative approach to product development high-quality product is delivered.
Agile is rigid method while Scrum Framework is rather a flexible approach.
Agile asks for a simple design and execution of software product but Scrum fosters innovative and incremental approach.
The most elementary measure of progress in the Agile Method is working software but with Scrum, working software is not a priority.
Customer competitive advantage through everyday work approach, technical advancements and adjusting the behavior is the principle of Agile Methodology which when structured with Scrum Framework gives a more incremental approach to a self-organised cross functional team with the efficient performance for collaborative iterative development approach.