Scrum Master

Definition of Done helps mark the item as potentially shippable and defines the criteria by which the work item can be called as completed or to be marked done. The key components of the Definition of Done include:

• Functional and Non-Functional requirements 
• Code quality and standards 
• Acceptance criteria and validations 
• Relevant work-item documentation 
• Deployment and roll-back plan 
• Metrics and reporting criteria  

As per the scrum guide, the sprint can be canceled by the product owner in consultation with the scrum master and the development team under any of the following circumstances: 

• External changes that cause the sprint goal to be irrelevant or unachievable 
• Internal discovery that causes blockers or challenges or requires a complete revisit of the solution to achieve the sprint goal 
• Learning opportunity i.e. when the team discovers a better approach and wants to take up the analysis/learning over starting development  

Agile, particularly scrum, is regarded as a lightweight framework because it prescribes the most optimal level of collaboration and structure of meetings. As per the scrum guide, it is prescribed for a 2-week iteration (10 days) to have the following set of ceremonies timeboxed to the mentioned duration to avoid derailing work and loss of productivity: 

• Sprint planning - 1.5 hours  
• Backlog refinement - 2 hours (1 session or 1 hour session per week) 
• Daily stand-up - 1.5 hours (15 minutes x 10 days of the iteration) 
• Sprint Review session - 2 hours 
• Sprint Retrospective session - 1 hour 

Measuring agile adoption across the enterprise involves reviewing and evaluating indicators of agile practices by conducting maturity assessments, evaluation workshops, process audits, etc. Apart from these, tracking some important metrics also helps know the agile process maturity. These metrics include: 

• Team velocity 
• Time to market 
• Net Promoter Score (NPS) 
• Lead time and Cycle time of work items 
• Employee engagement score 
• Backlog aging metrics 
• Definition of Ready, Definition of Done 
• Information Radiators 

All of the above help conclude the organization’s agile maturity and processes. 

There are multiple best practices you can bring into any team as a scrum master, though they may be subjective to the organization processes and governance model, some of the key best practices include:

• Managing impediments proactively and helping the team get unblocked in critical scenarios
• Empower the team to drive daily stand-up meetings in rotation to encourage accountability and process ownership
• Set up transparent information radiators, dashboards, and collaboration spaces to foster open communication and quick resolution of issues

When the Scrum teams follow the same pattern of the retrospective sprint by sprint, it does induce weariness among the teams. The Scrum Master needs to be creative enough to try out different patterns, sometimes changing the location also works. Anything that happens regularly with the same format tends to create an uninteresting environment in the meetings.

As discussed in the earlier question, the scrum master can use different types of retrospectives to create a fun introspecting atmosphere. Some of the teams opt to go out for lunch and have a discussion over there, it not only helps to collaborate but also provides a safe environment to discuss. Or you can use a different room. While creating a conducive environment to reduce the boredom, the Scrum Master has to make sure that the essence of a retrospective is not lost. The intent should be the same even when you are using different patterns.

To make the retrospective effective, the team should identify the action items. This gives a platform to the team to start a conversation, but only identifying will not serve the purpose. The action items should be targeted for closure and scrum master should take steps in realizing this goal. For every action item, there should be an owner, teams should refrain from assigning multiple owners to a single item as the idea of ownership dilutes. The scrum master should manage the repository of action items on a tool or an excel which is accessible to all the team members. Having a backlog of action items also helps as then the team can actually prioritize.

In the retrospective meeting, the team should go through the items from the last retrospective and talk about its status, in that way everyone can keep track of where they are and what more is required to achieve the goal of closure. Few organizations use retrospective tracker where the action items are categorized into – priority, ownership, status, description, identified on, type. Working on the actions items gives the team a boost that they are moving forward towards improvement and also it enhances the sense of ownership.

Though Scrum mentions the Scrum Master role as the person enforcing the process, it is important to understand what exactly does the enforcement mean and what its boundaries are.

Enforcement does NOT mean forcing the team to follow the process, but it implies putting in practice the core entities of the Scrum to help the teams be successful. The Scrum Master is the facilitator helping the teams reach their goal. During facilitation, the Scrum Master will use Scrum practices and would encourage the team to follow the scrum values.

Again, it is important to mark that we are talking about encouragement and not forcing. It is not a role similar to the project manager but this role will help the teams to bring their blockers to closure, it will be a collaborative effort and not a directive one. From time to time, the scrum master will try to show the benefits of adopting the processes and help the team acquire an understanding on the scrum processes which is like showing the right path but it is up to the team if they want to walk through it. The scrum master will also be acting as a coach for the team to help with outshine in the agile journey and be successful.

This question is a regular feature in Scrum Master interview questions and answers for experienced, be ready to tackle it.

Every organization opting for Agile creates a model to assess maturity at different levels. It helps them stay focused and goal-oriented. It is an assessment of an organization’s suitability for agile practices, providing an idea of the necessary steps for an organization that decided to become a learning organization.

The metric is based on the initial collection of data as to what the current situation is and what is the desired level. Hence, the parameters involving the assessment can be different for different organizations.

In our case, the focus was on the following:

• Ability to accept change
• Team communication
• Team Location
• Delivery Regularity
• Planning Methodology
• Testing
• Business Value Focus
• Technical Excellence

Each of the pointers mentioned had sub-details to analyze and assign an appropriate number. The assessment was done on a regular interval to check if the teams are reaching the milestones set in agreement with the management (agile focused). It also helps in identifying areas that need immediate attention. The team can swarm together to improve that item.

The team’s performance is not just related to a single event or a reason but there can be different scenarios that might be building up that situation. A good scrum master has to identify those patterns and look out for ways to minimize it. Let’s look at a few of the situations that might lead up to lowering the team’s performance:

• Planned Leaves or Holidays – The sprint commitment is directly proportional to the total available capacity of the team. If there are leaves or holidays, the commitment will go less and hence lowering the velocity.
• Legacy product – In case the code has been written long back with no documentation, the new members struggle to figure out things.
• New hire – Onboarding a new associate will impact the sprint commitments as the member is new and needs time to be brought to speed.
• Resignation – If the team members are leaving, it might take some time to fill up the gap.
• Experience – If the team comprises of experienced team members along with new one, then the level of seniority might hinder the team formation.

There can be many reasons, but the scrum master should keep their eyes open for any such patterns and try to help the teams get back to track through coaching and adoption of best practices.

The product backlog contains a list of items to be worked upon by the team but it is important to check if the items are in a ready state to be picked up in a sprint. The Team must be able to determine what needs to be done and the amount of work required to complete the User Story or PBI. The Definition of Ready can differ from product to product or from team to team. It is a working agreement between the team and the Product Owner on what readiness means. Let’s look at some of the parameters that can go in defining the Ready state:

Definition of Ready for a User Story

1. The PBI is in “Approved”, or equivalent, state for the team to pick it up for development
2. User Story dependencies identified
3. Acceptance criteria exist and are understood by the team
4. Acceptance criteria have sufficient details on the features to be developed and tested by the team
5. Performance criteria have been provided, where appropriate, and are understood by the team
6. The PBI has been written in the
7. Actor->Action->Outcome format
8. UX wireframes exist, where appropriate, and are understood by the team
9. Performance criteria identified, where appropriate
10. Team has a good idea of what it will mean to Demo the User Story

One of the advantages of working in Agile is the clear backlog visibility at least for three sprints. If the product owner is adding up the items in the backlog, then it might be he or she is getting ideas and they are just parking aside on the backlog. That doesn’t mean that the team has to work on all the ideas. A product backlog can have a list of items to be accomplished, but the team will only focus on the high priority items which can add value to the client.

Also, here, the role of a scrum master can come handy, this role can help the product owner understand how to arrange the backlog, and how to create items that can be consumed by the teams. The scrum master can explain different prioritization techniques that can be used for keeping the backlog sorted. But the scrum team is not expected to pull up everything that is on the backlog. One of the roles of the Scrum Master is to coach the product owner on how they can best converse their intent to the Development Team. There are many techniques to accomplish this, such as product visioning, product road mapping or release planning.

The focus of the team should be on delivering value to the customer. It is not only the responsibility of the team but also it is important from the organization perspective. Each story is built on the concept of priority and value added to the customer. If the team is able to bring value through frequent deliveries and product increment, then the client will be happy. The client satisfaction can also be one of the metrics to measure, if the client is able to realize value, it will be worth their money.

Another one can be, focus on minimizing the technical debt, once the product development starts, it is important to do the maintenance work from time to time to ensure the performance of the product, no one wants a dead code in the system. Bugs, refactoring, and research also requires regular attention to avoid building-up technical debt. Any metrics which cannot relate to the value delivered should be avoided in such scenarios as they portray a different picture, e.g, though velocity variance is a good metric to track if I relate to value delivery it won’t work well.

Hence, the focus should always be on value delivery, and it should be the prime goal.

Yes. The Scrum Master is one of the roles from the Scrum team which is responsible for ensuring the team is adhering to the Agile values and principles. The Scrum Master is the team facilitator. Along with that, the SM is responsible for clearing the obstacles, protecting the team from external interruptions and distractions that hinder the project goal.

The Scrum Master. It’s the responsibility of the Scrum Master to create a supporting understanding of Scrum in the whole organization. The Scrum Master is responsible for ensuring the team is adhering to the Agile values and principles. The Scrum Master is the team facilitator. Along with that, the SM is responsible for clearing the obstacles, protecting the team from external interruptions and distractions that hinder the project goal.

Yes. The Scrum Master position is the management level position, but it is not a manager position. Scrum Master does not manage the Scrum Team or even the Development Team but manages the Scrum process. If the Scrum Master is not at the management position, he or she may not have the influence to remove the impediments.

This is a frequently asked question in Scrum Master questions.  

By facilitating their decisions and removing impediments. Scrum Master does not manage the Development Team. It is the responsibility of the Development Team to manage its own efforts. However, the Scrum Master helps them by facilitating their decisions and removing impediments, and protecting them from external distractions.

In some projects, a development team member acts as a scrum master as there is no rule set up officially that a scrum master cannot be a developer. Definitely, it is hard to perform 2 roles at one time, however, it is definitely possible. A development team member playing the scrum master role depends on the team, team members skills and internal choice of manager or team. Ultimately, everything is possible in agile-scrum projects.

The Scrum Master should let the team decide the format of Product Backlog items. The product owner brings forward the main objective that should be achieved in the sprint and the PBIs that would help to attain these objectives. The development team selects the PBIs that will help to achieve the sprint goal based on the product owner input and creates the plan for delivering the PBIs. The scrum master ensures that the scrum rules are followed appropriately. There is no need for a scrum master to conduct events, but instead to facilitate as required. 

Expect to come across this popular question in SAFe Scrum Master interview questions.  

You should gladly volunteer because being a Scrum Master in an organization also involves responsibilities to coach the organization.

No. The entire team collaborates with stakeholders during the product review. Scrum Master can also work with stakeholders to help them understand Scrum. Stakeholders communicate with Product owner with respect to Product Planning, its progress, and Product backlog changes. Good communication helps project stakeholders engaged and informed and keeps the scrum team focused on finishing the accepted work for the sprint.

The development team needs to facilitate. The development team is responsible for performing development work and meeting the Sprint Goal. If they have any issues within their influence to resolve, they are responsible to solve it. Scrum Master is responsible for impediments that are outside the Development Team’s influence.

Not necessarily. It is preferable to conduct it at the same time and the same place to reduce the complexity of meeting overheads. Unless the Product Owner and Scrum Master are also part of the Development team it is not required for Daily Scrum. Daily Scrum is for the Development Team. The Daily Scrum is not planned as a status report or management reporting mechanism. Performing Daily Scrum highlights liability and commitment in the development team.

A must-know for anyone heading into a Scrum interview, this question is frequently asked in Scrum interview questions.  

The following are misinterpretations or breaking of the Agile Principles and suggested ways to fix the problem(s):

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software- Some people focus on the ‘happy customer’ aspect of this Principle and will do whatever the customer asks.  This may make the customer happy in the short-term, but the real value to the customer is delivering valuable increments of the product as early and continuously as possible.
   The fix – ensure the development team and customer agree on a regular Sprint and Release Schedule and ensure that they keep to it.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage- Some Agile teams understand the word "welcome" here as permission to forget about any requirements management at all. What is the easiest way to welcome change? Obviously, just get rid of any required documents!  However, this Principle does not mean abandoning any requirements management process.
   The fix – Ensure that the Product Owner maintains an ordered Product Backlog and that the Product Owner handles all change requests; the PO will decide if the change is justified and if it is whether the request is important enough to interrupt the current Sprint or whether it is placed on the Product Backlog in the appropriate business value position.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale- There may be some Development Team members that think this Principle applies at the Development Team level but does not apply to themselves individually.  It is difficult to imagine how these people think that the team will deliver without their individual contributions.
   The fix – Ensure that all Development Team members attend Release and Sprint Planning workshops and contribute effectively.  Additionally, ensure that all Development Team members attend the daily Scrum; it will soon become obvious if an individual’s progress on their chosen activities is less than ‘optimal.’
   The Scrum Master should engage any ‘miscreant’ Development Team member in individual mentoring to discover what the underlying problem is that is causing the problem and help the person to improve.
4. Business people and developers must work together daily throughout the project- Working together doesn't mean working without clearly defined rules and processes. Some teams interpret this Principle as the legalization of chaos; they think that, since we work together, we do not need to define roles, we should not document requirements, and we should not care about responsibilities.
   This is clearly nonsense; Agile requires that all the responsibilities necessary for successful product development must be identified, and an individual or group of individuals take on one or more of those responsibilities.
   The fix – As a Scrum Master, for new Scrum Teams, ensure that a workshop is held with the Scrum Team and key stakeholders to define all the necessary responsibilities and ensure that all the responsibilities have been accepted by one or more people appropriately.
   Do not allow individuals to ‘quote’ their named role job specification in an attempt to avoid responsibilities; if they have the knowledge and capacity to fulfill a responsibility outside of their job specification, then they could accept that responsibility.
5. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done- It may be difficult for some ‘managers’ and ‘supervisors’ in the early stages of an Agile transition to ‘let go of the reins’; they are used to assigning low-level tasks to individuals and monitoring their work closely; their implies a lack of trust on their part in the ability of individuals and teams.  Agile teams should be self-organizing and self-managing.
   The fix – As a Scrum Master, you must closely monitor the activities of ‘managers’ and ‘supervisors,’ and if these activities are disruptive to the Development Team, then you must mentor the individual ‘miscreants’ to explain the Agile philosophy and Principles to them how their ‘interruptions’ are causing delays in development progress.
6. The most efficient and effective method of conveying information to and within a development team is a face-to-face conversation- Face to face does not necessarily mean that all people contributing to the conversation are in the same room; some people believe it does and use this to avoid Agile when all people cannot be in the same room.
   However, technology has moved on since the Agile Principles were written; today, communicating via video-conference and desktop-sharing facilities is commonplace.
   Video-conferencing is preferred over teleconferencing because, with the latter, you lose the ability to observe ‘body-language’, an important part of any communication.
   The fix – As a Scrum Master, if communication with remote people is needed, whether within the Development Team or with stakeholders, encourage the use of video-conferencing at a time that is suitable to all the people in different time zones.
7. Working software is the primary measure of progress- This Principle states that working software is the primary measure of progress; it is not the only metric we can use to analyze product development.
   The Development Team measure and use its Velocity to help them plan; the business (product Owner) measures the benefit achieved from released increments.
   The fix – As a Scrum Master, you need to ensure that the Development Team and Product Owner agree the metrics that are to be used.  You must help to ensure that the metrics are measurable, relevant, and of value.
   You need to make sure that collecting any metric may have the effect of changing peoples’ behaviour; for example, if the number of lines of code per day was to be measured, developers may use verbose coding practices, thus reducing progress and technical quality.
   The focus of any metric chosen must be its contribution toward the overall business value accruable from the product increments being delivered.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely- This Principle focuses on the well-being of all involved with product development, but it must not be forgotten that the prime focus of product development is to deliver value to the ‘customer’; the Development Team cannot just keep working at a comfortable pace if they are not meeting the ‘value deadlines’ set by the ‘customer.
   The fix – As the Scrum Master, you need to ensure that the Development team estimates the Product Backlog Items and agrees with the Product Owner on what is possible in a fixed time and what is included in the Product Backlog MVP; ensure that the Product Owner is aware of his/her responsibility to measure the rate of delivery of business benefit.
9. Continuous attention to technical excellence and good design enhances agility- This Principle means that there must be technical ‘rules’ in place that must be checked for in each developed requirement source code before it can be considered “Done” and allowed to be reviewed by stakeholders.  If these rules are not in place or they are not checked for, then the quality level will decrease, resulting in an unhappy ‘customer’ and reduced progress as required rework is done.
   The fix – As the Scrum Master, encourage the Development Team, Product Owner and technical advisors to agree what the technical and design quality criteria are and how they will be checked for; the agreement forms the “Definition of Done” (DoD) that each requirement and increment will be checked against before it is reviewed by stakeholders.
10. Simplicity--the art of maximizing the amount of work not done--is essential- To some developers, it is tempting to ‘future proof’ their work, adding functionality that may be or is known to be needed later.
    This results in slowed progress and potential work when the perceived later need does not transpire.
    The fix – Ensure that there are some DoD criteria that check for future-proofing in the required source code.  This will encourage developers to:
    ‘Only do today what is essential to do today.’
11. The best architectures, requirements, and designs emerge from self-organizing teams- We say that the Development Team should be self-organizing for the work that they do during Sprints, but they are subject to constraints such as:
    • The overall technical architecture to work within; is set by corporate tech architects.  The Development Team can ask for amendments to the technical architecture, but they have no control over it.
    • The requirements – Requirements are the Product Owner’s responsibility; the Development Team can suggest changes to the Product Backlog, but they only have control over how the agreed requirements are implanted.
    • The design – There may be corporate design standards in place; again, the Development Team can suggest design changes but only have control over how the agreed designs are implemented.
      This Principle is not just about the Development Team; the self-organizing concept applies to the wider group of business and technical stakeholders that must work closely together so that the product can provide the best business value.
      The fix – As the Scrum Master, you must analyze any constraints that the Development team has to work with and ensure that adequate processes are in place whereby requested changes are speedily analyzed and accepted or not.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly- This Principle is embodied in the Scrum ‘Inspect and Adapt’ Pillar and is enacted through the Sprint Retrospective event.
    The Sprint Retrospective is not just about discussing what is wrong but also what is good, and maybe the team should do more of it.
    At the start of an Agile Transformation, the team may ‘find’ many things that are ‘wrong’; the long list may be seen by some to be time-wasting and others as demotivating; ‘how are we going to address all these problems?’.
    Because of this, many teams give up on the Retrospective!
    The fix – The discovery of good and bad things during a Retrospective should be time-boxed to maybe 15 minutes when the major points will be discovered.  There are many Retrospective Games that can be played by the team members to make the discovery more enjoyable. An important part of the Retrospective is that the team prioritizes the issues and plans how to resolve the top 1 or 2 issues in the coming Sprint.
    Progress on issue resolution can be made during the daily Sprint, and the overall success of the improvement plans can be checked at the start of the next Sprint retrospective.

It's no surprise that this one pops up often in Scrum Master interview questions.  

The following is a quite comprehensive list of attitudes and skills that contribute to being a great Scrum Master; of course, you don’t have to meet this entire list to be a great Scrum Master; consider it as some inspiration on areas you might want to research. 

• Involves the team in setting up the process- A great Scrum Master ensures the entire team supports the implemented Scrum process.
• Understands team development- A great Scrum Master is aware of the different phases a team will go through when working as a team. He/she understands Tuckman’s different stages of team development: forming, storming, norming, performing, and adjourning.
• Understands principles are more important than practices- Without a solid, supported understanding of the agile principles, every implemented practice is basically useless.
• Recognizes and acts on team conflict- A great Scrum Master has read the book ‘The 5 Dysfunctions of a Team’ by Patrick Lencioni. He/she, therefore, recognizes team conflict in an early stage, can apply different activities to resolve it, and, even better, he/she knows how to prevent conflict.
• Dares to be disruptive- A great Scrum Master understands some changes will only occur by being disruptive. He/she knows when it’s necessary and is capable of being disruptive enough to enforce a change without causing irreparable damage.
• Is both dispensable and wanted- A great Scrum Master has supported the growth of teams in such a manner they don’t need him/her anymore on a daily basis. But due to his/her proven contribution, he/she will get asked for advice frequently.
• Let the team fail (occasionally)- A great Scrum Master knows when to prevent the team from failing but also understands when he/she should not prevent it. The lessons learned after a mistake might be more valuable than some good advice beforehand.
• Encourages ownership- A great Scrum Master encourages and coaches the team to take ownership of their process, task wall, and environment.
• Has read all the stuff produced by e.g., Geoff Watts, Lyssa Adkins, Tobias Mayer, Henrik Kniberg, and Gunther Verheyen. 
• Has studied the Trello board that Growing Agile has published. The Shu-Ha-Ri levels offer a very useful structure to a knowledge base for every Scrum Master.
• Is RE-TRAINED- A great Scrum Master recognizes himself in the acronym made up by Geoff Watts, RE-TRAINED: 
  • Resourceful: is creative in removing impediments
  • Enabling: is passionate about helping others
  • Tactful: is diplomacy personified
  • Respected: has a reputation for integrity
  • Alternative: is prepared to promote a counter-culture
  • Inspiring: generates enthusiasm and energy in others
  • Nurturing: enjoys helping teams and individuals develop and grow
  • Empathic: is sensitive to those around them
  • Disruptive: breaks the status quo and helps create a new way of working
• Has faith in self-organization- A great Scrum Master understands the power of a self-organizing team.  Attributes of self-organizing teams are that employees reduce their dependency on management and increase ownership of the work. 
• Values rhythm- A great Scrum Master understands the value of a steady Sprint rhythm and does everything to create and maintain it. The Sprint rhythm should become the team’s heartbeat, which doesn’t cost any energy. Everyone knows the date, time, and purpose of every Scrum event. 
• Knows the power of silence- A great Scrum Master knows how to listen truly and is comfortable with silence. He/she is aware of the three levels of listening and knows how to use them.
• Observes- A great Scrum Master observes his team with their daily activities. He/she does not have an active role in every session; for example, the daily Scrum is done by the team itself.
• Share experiences- Great Scrum Masters share experiences with peers. This might be within the organization, but also seminars and conferences are a great way to share experiences and gather knowledge. 
• Has a backpack full of different retrospective formats- A great Scrum Master can apply lots of different retrospective formats. This ensures the retrospective will be a fun and useful event for the team. He knows what format is most suitable given the team’s situation.
• Can coach professionally- A great Scrum Master understands the power of professional coaching and has mastered this area of study. Books like Coaching Agile Teams and Co-Active Coaching don’t have any secrets for him/her. He/she knows how to guide without prescribing. 
• Has influence at an organizational level- A great Scrum Master knows how to motivate and influence at tactical and strategic levels.  Some of the most difficult impediments a team will face occur at these levels, therefore, it’s important a Scrum Master knows how to act at the different levels within an organization.
• Prevent impediments- A great Scrum Master not only resolves impediments but also prevents them. 
• Isn’t noticed- A great Scrum Master isn’t always actively present. He/she doesn’t disturb the team unnecessarily and supports the team in getting into the desired ‘flow.’ But when the team needs him/her, he/she is always directly available.
• Forms a great duo with the Product Owner- A great Scrum Master has an outstanding partnership with the Product Owner. Although their interest is different, the Product Owner ‘pushes’ the team, and the Scrum Master protects the team. 
• Allows leadership to thrive- A great Scrum Master allows leadership within the team to thrive and sees this as a success of their coaching style. They believe in the motto “leadership isn’t just a title, it’s an attitude”; it’s an attitude everyone in the team can apply.
• Is familiar with gamification- A great Scrum Master is able to use the concepts of game thinking and game mechanics to engage users in solving problems and increase users’ contribution.
• Understands there is more than just Scrum- A great Scrum Master is also competent with XP, Kanban, and Lean. He/she knows the strengths, weaknesses, opportunities, and risks of every method/framework/principle and how & when to use them. 
• Leads by example- A great Scrum Master is someone that team members want to follow. He/she does this by inspiring them to unleash their inner potential and showing them the desired behavior.
• Is a born facilitator- A great Scrum Master has facilitation as his/her second nature.

Scrum prescribes four formal events for inspection and adaptation, as described in the Scrum Events section of the Scrum Guide; as a Scrum Master you should attend the events and ensure the team is following the ‘Transparency, Inspect and Adapt’ processes:

• Sprint Planning
• • Inspect the average Team Velocity over the previous 3 or 4 Sprints, ensure that the velocities have been Transparent to the team and ensure that the team Adapt the Velocity to be used for planning the Sprint
  • Inspect the Product Backlog (PB) and ensure that it is up to date, that it is Transparent to all stakeholders and that the team Adapts the PBI estimates if necessary
• Daily Scrum
• • Inspect the Team Board and Adapt the plan for the next day ensuring changes are Transparent to all the team
  • Inspect the Impediments Board and Adapt plans to resolve impediments if necessary
• Sprint Review
• • Inspect the increment and Adapt the Product Backlog if necessary making sure that any changes are Transparent to all stakeholders
  • Inspect the Release Plan and Adapt it if necessary making sure that any changes are Transparent to all stakeholders
• Sprint Retrospective
• • Inspect the process that has been followed and make plans to Adapt the process if necessary making sure that any changes are Transparent to all team members

A common question in Scrum Master interview questions scenario-based, don't miss this one.

Frames of reference are everywhere. For example, if you are in the northern hemisphere and you look into the night sky, you will see the visible universe as a collection of stars grouped into constellations. Now imagine a person in the southern hemisphere looking at the night sky; the person will still see the visible universe as a collection of stars grouped into constellations, but they will be a different set; the two people have different frames of reference.

If the person in the southern hemisphere says to the person in the northern hemisphere, “I think that there is something happening to the fourth star in the Southern Cross constellation”, the northern hemisphere person may not know what the other is talking about and certainly could not tell if something was happening or not.

We all have our own unique frames of reference for every subject in our heads; they are based on our experiences of childhood, parenting, education, religion, previous interactions with other people, etc, and even where we are physically located.

If you live in a country where there are words written on the road to warn you of something, like “SLOW”, if you are in a car, you will see the word SLOW ‘normally’ but if you were in a helicopter above the word you will see it vertically elongated.

It is the same sign, but it is seen differently because of the different frame of reference for the viewers.

So why is this important to you? When people are communicating, the words and ideas that they express come from their own frame of reference, and the potential for miscommunication is high if the frames of reference of the listener are not similar to that of the listener. Imagine trying to describe a hippopotamus to someone who has never seen one; would you try an analogy with something your listener had seen? Would you try to draw one? Not simple!

As a Scrum Master/Facilitator, you need to be aware of different peoples’ frames of reference when they are communicating so that you can spot possible misunderstandings in listeners.

The participants in product development workshops will all have their own frames of reference from business and technical and even between people within the same skill set, depending on their individual experience.

Listen for jargon and abbreviations in conversation and ensure that all listeners know what the speaker is talking about.

The ‘Groan Zone’
After a period of divergent thinking (see Q – What are ‘divergent’ and ‘convergent’ thinking? ), most groups enter a Groan Zone.

Having just ‘brainstormed’ a list, the next task, in theory, is simple; sift through the ideas and pick a few to discuss in depth.

In practice, that task can be difficult because everyone has their own frame of reference; when people misunderstand one another, they become more confused, more impatient and possibly more self-centered; people repeat themselves, they interrupt, dismiss other people's ideas and rudely put each other down.

Without a facilitator, at some point, the participants will agree to almost anything, any half-baked, unrealistic, mediocre compromise, just as long as it will get them out of the room.

One way to help workshop participants gain an understanding of each other's ideas is to encourage them to ask direct questions of one another and listen carefully to the answers.

However, there are some challenges to this ‘simple’ approach:

• Some participants fear that asking questions might seem confrontational or rude
• Many people cannot cope with the ambiguity of unstructured inquiry and dialogue for very long
• It is hard for everyone to tolerate the poor behaviors and emotional turmoil that occurs when people feel misunderstood