What is Value Stream Mapping ?
Read more
The role of a Scrum Master is one that, time and again, has found itself on the lists of most promising jobs needed in the workplace of tomorrow. And if there's one lesson that the pandemic taught us, it's that business agility is an imperative to survive in a world that's as volatile, uncertain, complex and ambiguous as it has been in recent times!
A Scrum Master plays one of the most important roles on a Scrum team; that of ensuring that Scrum is followed to the letter! As the name implies, the Scrum Master has mastery over all things Scrum. He or she is the one who coaches the team on Scrum principles and practices, guiding them on the Scrum values and ensuring that the roles and rituals are done right.
So, if you've made up your mind to land that plum job as a Scrum Master, you'll have some tough interviews to crack. We've put together this list of top twenty Scrum Master interview questions and answers, so that you can get the edge over your peers!
In simple words, Scrum is an Agile framework that helps teams to work together in a flexible, collaborative manner. It specifies roles, artifacts and events that come together to incrementally deliver value on a Scrum project. Scrum has agility at its core and allows teams to course correct to adapt to emerging situations and volatile circumstances.
There are three accountabilities (earlier called 'roles') that are defined by Scrum; that of the Scrum Master, the Product Owner and the Developers.
Scrum.org defines a Scrum Master as the 'Role within a Scrum Team accountable for guiding, coaching, teaching and assisting a Scrum Team and its environments in a proper understanding and use of Scrum.'
In other words, the Scrum Master is the facilitator of Scrum who acts as a coach and mentor to the team, staying committed to Scrum principles and values and navigating the team through complex challenges during the course of the project.
Team sizing is very important to achieve optimal functionality. Each team should ideally comprise of 4-6 people to product optimal work; larger teams often struggle with communication, and smaller teams may not have all the skills needed to self-manage the tasks.
If a team is very large, by splitting it into two or three smaller ones, close interpersonal relationships can be developed, and the desired outcomes can be achieved.
A user story is a concise description of a feature or capabilitythat is captured from the perspective of the end user. It is written during the initial team discussions on the product, and can be written by anyone on the team.
The typical format of a user story is as follows:
A good user story is said to be one which meets the 'INVEST' criteria, where INVEST is an acronym that represents a checklist that helps to judge the quality of the user story.
There are some disadvantages to estimating in man hours:
A story point is a metric used in Agile that estimates the difficulty of a particular task. It takes into consideration the amount of work involved, its complexity, and the risk around it. It is a relative value; for instance, if a task A is estimated at 2 story points, it will take twice the effort of a task B that is estimated at 1 story point.
Story point estimates work well in Agile, for many reasons:
It is the responsibility of the Product Owner-not the Scrum Master-to set the priorities for the user stories.
The priority of each user story is evaluated based on parameters like its functionality, customer satisfaction, its complexity, risk and opportunities, the cost involved and the value it will deliver to the end user. The items that are prioritized first are those that will give the fastest return on investment, and the highest amount of customer or business satisfaction.This means that low cost, high return items will get top priority.
There could be instances when a user story is not defined well enough for the team to estimate easily. It could be that they have insufficient knowledge of this particular task, and may need to investigate further. They could, then, choose to deviate from the time allocated for this story, and work on a Spike story. In other words, they take a pause during the task to do some research and get more clarity to proceed further.
Agile requires that "Business people and developers must work together daily throughout the project". Not only does this encourage collaboration, but it promotes transparency and helps the team to get past impediments that hinder work progress.
This happens through the Daily Scrum, a short and time-boxed event during which the team members catch up on the work they are doing. Each member has to answer three questions in as simple a manner as possible:
During the Daily Scrum, each team member answers the following three questions:
This helps to retain focus and gets everyone on the same page. The Scrum Master will note all the impediments and will ensure that they are ironed out.
Two weeks is the most common length of a sprint-and ideally it should never exceed one month in duration. If the duration is more, the team could lose sight of the goal, and risks can increase as they are not getting feedback on time. A shorter sprint reduces risk and complexity and keeps the user stories manageable.
The Scrum Master facilitates the Daily Scrum, calling for the meeting at the same time and place every day. He or she is a keen listener, notes down what each team member has to say, and ensures that the meeting stays within the time limit (usually fifteen minutes). The Developers hold the responsibility of conducting the Daily Scrum, but the Scrum Master is the one who makes sure that the meeting happens as per plan.
There are three main artifacts in Scrum that contain important information and represent work or value. They are the Product Backlog, the Sprint Backlog and the Increment. The Product Backlog is an ordered list of all the features, functionalities, additions and fixes that will be included in the product release. The team commits to achieve the product goal, which is the future state of the completed product.
The Sprint Backlog contains the items in the Product Backlog that have been chosen to be completed in the upcoming sprint. It gives a real-time picture of the work that the developers will finish, in order to achieve the sprint goal.
The Increment is the total of all the Product Backlog items achieved in the current sprint as well as preceding sprints. It should be a working increment, of the required value and in useable form. Each increment should meet the Definition of Done, which means that it should be completed in all aspects.
A sprint can be cancelled, but not by the Scrum Master. Only the Product Owner has the authority to cancel a sprint. He or she can cancel the sprint before the time-box allocated for the sprint runs out.
A sprint is normally cancelled if the sprint goal becomes obsolete or is no longer relevant, due to changing circumstances. If there are any product backlog items that are 'done' and can be used, they are accepted by the Product Owner.
The Scrum Values are commitment, courage, focus, openness and respect. Commitment: The team must be committed to achieving the Scrum goals. Courage: They should have the courage to adapt to change, and stand up for what they believe is right.
Focus: Without deep focus on the work of the Sprint, there will be no progress. Openness: The team and stakeholders must work with openness and transparency. Respect: The team members should have mutual respect for each other, and should collaboratively uphold decisions made.
The three Scrum pillars are Transparency, Inspection, and Adaptation.
Transparency:
Every member of a Scrum team- Developers, Scrum Master, Product Owner and even the stakeholders and management must be transparent in their dealings with each other. If anyone has any problem, it should be reported. The team should keep each other updated with good news, as well as bad. They work in collaboration to achieve goals, and this means that everyone should be on the same page at all times.
Inspection:
The team inspects their own work at the end of each sprint. This happens during the Sprint review event, during which stakeholders and customers also provide feedback. The more frequent these inspections, the better will be the product and the more closely will it be aligned to customer expectations.
Adaptation:
Scrum is all about flexibility and continuous improvement. The team adapts based on the inspection, and also based on evolving customer needs. They have the ability to course-correct and be flexible to accept change.
The sprint retrospective is an event that is held at the end of every sprint. The entire team, including the Developers, Product Owner and Scrum Master must attend. Stakeholders are not required to attend, as the team should feel comfortable to hold frank discussions and they might not be able to do so if outsiders are present.
It is held to:
Scrum of Scrums is a technique used when scaling agile across multiple teams that work together on complex projects. These multiple teams follow the three pillars of empiricism, ietransparency, inspection, and adaptation, at scale.
A Scrum of Scrums is a virtual team, made up of delegates from each original team who get together to coordinate work and solve inter-team dependencies. The Scrum of Scrums meeting is held to give clusters of teams an opportunity to discuss their individual tasks, giving particular attention to the areas of overlap and integration.
These meetings are held as often as may be required; in fact Ken Schwaber suggests a daily Scrum of Scrums meeting that is timeboxed along the lines of the Daily Scrum.
An impediment is an obstacle faced by the team, which is hindering the progress of work. It is the Scrum Master's responsibility to address and remove these obstacles. Some examples could be:
Agile estimation is not easy, since the requirements are not fixed. Agile is adaptive, and accommodates change at every level; but due to this it could be very hard to stick to timelines and budgets.
There is very little documentation, and this can prove to be a problem in projects of longer duration as there may not be easy recall of the first few iterations.
If the Product Owner does not communicate the requirements properly, there could be discord.
The entire team may not be on board with Agile, and might decide to skip some important events like the Daily Standup (or Daily Scrum). This leads to loss of transparency.
People who are very set in traditional ways find it hard to accept and adopt this new way of working, so the transition to Agile in traditional establishments often proves difficult.
In projects where the customer requirements are simple, clear and not likely to change at all over the duration of the project, a waterfall approach will work better than Agile. Agile is prescribed in VUCA (volatile, uncertain, complex and ambiguous) projects, where the customer needs are emergent and the final product or service is not set in stone.
A Last WordSign up for one of our popular Scrum courses, get certified, and take your Scrum career ahead!